Hiya, well done for the new GL Tools release, guys!
Just flipping through the example compositions, and I noticed a couple of things.
Previewing one of the QTZs by selecting it in Column view in the Finder crashed the Finder (not sure which one it was now, or if it's repeatable)
The Stereo Render environment seems to be broken on my machine
MacBook Pro 3.06GHz 'unibody'
MacOS X 10.6.1
GeForce 9600M GT 512MB VRAM
Quartz Composer 4.0 (build 103.1)
I just get a strobing image (see screenshot).
This is a real shame, as that's the one I was really looking forward to trying. Anything I can do to help track down the bug?
a|x
The Stereo Render environment seems to be broken on my side too. macboob pro2.4 osx 10.5.8 GeForce 8600M GT 256 MB
I think you'll find it's the QuickLook daemon , pun intended, coupled with the incontrovertibly difficult maths to make a visual going on in the example composition, and in any composition employing the stereo environment patch.
[Randy turned in on himself, no mean feat for a 40 stone man]
The solution, if found to be applicable on your machine, is so easy, you'll kick yourself :-).
Just place a clear in the first level down in the stereo environment patch
you'll also need a clear within the Polygon Mode patch too.
I'll give that a go as soon as I get a chance.
Thanks, cybero.
a|x
Adding extra Clears doesn't seem to work for me. I just get VRAM junk whatever I do... :(
a|x
Try this one out - do you get the same VRAM junk ?
I don't on iMac, 10.6.2.
3rd party plugins I wonder - but don't really know on that score.
[plus I've got a whole load of 3rd party plugins dating from 2008 upwards and no problems with what's installed by me, mmm].
You might need to close down and restart QC 4.0, bit mode doesn't seem important FWIW.
Well, funnily enough, I don't get VRAM junk with your example. On the other hand, I don't seem to get any output from the Right channel image output.
Hmmm...
a|x
Here's the simplest case I could cook up with the Stereo patch.
It just doesn't seem to work for me though. I get flickering, and the right image output isn't there most of the time.
Maybe smokris could tell me if there's something wrong with my setup? Any chance of a heads-up on what the various obscurely-named controls do, too?
a|x
The GL Stereo patch is a trifle puzzling, merits further study and some very careful handling. I do get right and left image data from both the patches image outputs and can also feed in image input.
Retaining iterated objects is tricky :-)
Needs careful staging.
Well, I've been playing with your example and have achieved loads of VRAM - see this video on YouTube, just uploaded.
Although there should be a rendered object this glitches even with or without an enabled object patch - buffer clutter results - love it for that and when appropriately trained then the patch does do some interesting things, but I'm finding it to be slightly unreliable .
I had included / used the new 1024 patch - which I've also done a visualizer with, but even with a plain sphere instead, as per the example I'm posting here, it will glitch, that's because I'm jigging way too many settings on the Stereo patch.
Guess that proves this patch needs a steady hand.
There seems to be some odd interaction with 10.6's new deep aversion toward rendering every frame. If, for example, you attach an LFO to the Cube inside the Stereo Renderer, it may improve reliability (since it's forced to continuously redraw the cube instead of just drawing it once and going to sleep). I'll try to find a real solution for this.
I don't have a GeForce 9600M available at the moment to test on, but one should be arriving within the next week or so, and I'll add it to the test suite.
And definitely let me know if you're able to reproduce the Finder crash issue and/or isolate the crash log from it.
Object Z just translates all the geometry within the environment (equivalent to the standard
3D Transformationpatch)./| / | / | /| | / | | /| | | Camera []< | | | \| | | \ | | \| | Near Z Clip ^ \ | \ | \| Screen Z ^ Far Z Clip ^Screen Z defines the confocal plane --- where both the left eye and right eye will see the same image. As geometry diverges from the Screen Z value, the image locations in the left and right eyes will diverge.
Geometry closer than Near Z Clip and further than Far Z Clip is culled.
IOD (IntraOcular Distance) defines the separation between the eyes. Larger IOD leads to greater image divergence.
If you set Screen Z and Object Z to the same magnitude, opposite sign (e.g., Screen Z = 10, Object Z = -10), an object placed at the origin within the environment (e.g., a
Spherewith default values) will be visible, rendered with center at 10 units from the camera. The image will diverge slightly as it approaches the camera.Thanks smokris, for the excellent explanation and for the bug info. The lazy-rendering thing makes sense, in fact. In my very simple setup, I had a cube inside a trackball. When I rotated the trackball, both images sometimes appeared, but then the right one would disappear when I stopped dragging the trackball. I think there's something else going on too though, because of the pixel-junk we've both been getting.
Incidentally, I'll give it a go with the GeForce 9400 too, see if that's any different.
a|x
OK, tested the same basic QTZ with the 9400, and it's the same. The Right image actually appears when the composition is first started, but disappears when the trackball is dragged (the opposite of what I thought before). Even when it's there though, it flickers on and off rapidly. The left image seems 100% stable, and I don't get VRAM junk with the this simple setup.
a|x
Nice ASCII Art, by the way :D
a|x
Have you tried with the Viewer at a 1:1 aspect ratio?
Haven't tried that. Does having a square window help?
It might.
To be clear, I've seen this plugin in a variety of versions... and haven't tried the very very latest yet (still keeping a pretty much working build I have around, and in 10.5 where it is solid).
Issues that I know of, besides what has been mentioned, are-
-In some systems, you have to have a 1:1 aspect ratio, or otherwise, make sure that width is always greater than height. I find that to be different on various computers.
-If it actually gets running and outputting image on both sides (try a sphere or teapot...a standard QC object for your tests), you may still have problems with K3D, with Particle Tools, and possible with Mesh stuff (I have not been able to test mesh stuff, because I haven't had it working in SL well enough to yet). Things with K3D or Particle Tools may not draw at exactly the right depths or respect the z values correctly. This can be overcome, but I don't think that current K3D or Particle Tools builds handle this.
-Image ports/tooltips can have a weird side effect where you see the image upside down on the tooltip window, yet it will still render out correctly when put to billboard. I'm not sure if that is a tell of a larger problem or not.
-I have seen the freeze problem as well, in one of the builds while using SL, and also noted that as long as an lfo/interpolate, etc was attached that things evaluate. Part of me wants to say that aspect ratio plays a part in this as well, but I could be wrong.
The issue with aspect ratios is fixed with the final released version, I believe.
Kineme3D 1.2 or later should work. I haven't tested it with ParticleTools recently.
The texture-flipping issue was also specifically addressed.
Good news about K3D 1.2 and on indeed. Stereoscopic explosion will be a nice one...I've been really hoping about that one.
I can't remember what the Particle Tools issue was... I remember that it was working out for all scene info to be "outside" of the stereoscopic patch (and other things like 3d loaders, warps, etc., as well). Certain Particle Tools renders don't work correctly as well, but that carries over to the standard Render In Image environment, so no complaint there.
FWIW , the Kineme3D renderers work well unless asked to seriously iterate, plus, within the Stereo patch, publishing up ports results in unrecognised selector errors.
Also Mesh does indeed work and publishes ports up without any problem that I've encountered thus far.
See attached example files - uses bunny.3ds for the 3D and uses Class_III.dae for your Mesh and all should be just fine.
Cybero, I'm talking about when you actually view them stereoscopically and whether or not depth info is correct when you view them on that kind of playback equipment, not simply whether they render or not.
Well, the IOD is what I'm given to understand gives stereo separation control. When set high I get two separate images, one flickering - the right image and one constant - the left image.
Unfortunately I don't happen to have the specific equipment to completely test out the validity of the examples posted but was given to understand that they were stereoscopically capable due to their rendering in the viewer window.
I don't even have a cheap and cheerful pair of red / green 3D glasses at hand - daft question perhaps, but would those give a better sense of what does and doesn't work on the examples I posted?
Are the examples I posted simply incorrect?
You definitely need 3D specs to know if it's working. On the other hand, if you don't get a constant image out of both Left and Right image ports, we can fairly definitively say it's not working.
;)
You also need to set the two output billboards to Add blend mode, and eliminate the Green and Blue channels from the Left one, and the Red channel from the right (as in my example QTZ). This can easily be done with the Color inputs for each Billboard.
a|x
Thanks for the heads up, tb.
Well, I've checked my examples and those settings are good and in place as per the example you kindly posted.
Of course I still have a flickering image so I guess that means this patch is not working 100 % correct.
Cheers for the constructive advice tb & GT.
Just posted a new version --- https://kineme.net/release/GLTools/16
Let me know if you notice further flickering or unexpected behavior.
I'm not able to reproduce this --- can you provide a step-by-step procedure?
Genius! Thanks smokris, this one works on my system. The original one from the v.1.5 Compositions folder still gives GPU junk and flickers though. I guess you put in more Clears. Is there some rule about where you have to insert extra Clear patches when using this environment?
Great work, and thanks for responding so quickly to my moans (I'm a bit of a spoilt kid sometimes, for which I apologise).
a|x
It should only need a single
Clear.(In the GLTools 1.5 demo composition, that
Clearpatch was accidentally disabled. I fixed that in the GLTools 1.6 demo composition.)Ahh.... I see.
Do you have access to an OpenCL-capable machine, smokris? Just wondered if you could try something for me, if so..
a|x
Yeah, at gridlab.ohio.edu there's a wide variety of CL-capable devices I can use for testing.
Nice, glad about the update. I was just noticing I was getting the same glitches as TB when testing today (we have the same config laptop...maybe not OS version, but hardware wise). It was total glitchout.
I've just posted you two urls for movie captures of the actual step by step procedure that results in 3D Object input splitter problems when providing published ports. Also shows a nifty disappearing trackball related trick in the Stereo patch:-). BTW it has moved from being a selector error to an index matching class error
This definitely seems more stable and is it also faster ?
This works (GL Tools 1.6) on 10.5 too. I was getting weirdness with v1.5. Thanks
Excellent. Glad to hear it.
Actually, scrub that smokris. I was thinking my OpenCL-driven composition wasn't working inside the Stereo environment, but it was user error on my part with Additive blend mode and a light-coloured background.
Incidentally, is there a reason why objects rendered with the Stereo patch appear much smaller than without it? You explanation of the various parameters was very clear, but I'm still a bit unsure about how to zoom in on things. Or would it be easier just to move the objects a bit nearer using a 3D Transform?
a|x
Incidentally, here's a very simple CIFIlter kernel to composite the Left and Right images and output a single image. Probably only works properly if both images have 100% opaque foreground and 100% transparent background, identical dimensions (which they should have, I'd have thought).
kernel vec4 tb_compStereo(sampler Left, sampler Right) { // Sample Left image vec4 l = sample(Left, samplerCoord(Left)); // Sample Right image vec4 r = sample(Right, samplerCoord(right)); // Return R-channel from Left image, G and B-channels from Right image // and Alpha as addition of alphas from two input images return vec4(l.r, r.gb, l.a + r.a); }Not tested, but should work, barring possible typos ;)
a|x
Just installed 1.6 on my MBP/9600, and for some reason, whenever i replace the default spheres - in the sample comp - with another object , such as my particle plugin, the Right image stops working. Its output is plain black, or eventually flicker.
Funnily enough, that was what I was getting with v.1.5. Are you using the example composition from the older v.1.5 examples folder, by any chance? Apparently, the Clear inside the Stereo patch was disabled in the older QTZ.
a|x
Sorry to flood the forum with posts today, but I was wondering....
would it be possible to have the Stereo patch support multisampling? I've got used to seeing nice smooth(ish) edges to geometry in the Editor, but the only way to smooth the output of this patch (and the standard Render In Image patch, for that matter), is to do brute-force supersampling or apply some kind of edge-blurring post-process (unless I'm missing something here).
Come to think of it, a drop-in replacement for Render In Image that did multisampling would be a REALLY good thing. Should I make that a Feature-Request?
a|x
You get that sort of result - I don't - I get image on both outputs, including your 1024 plugin. see attached example. works aok for me :-). it's based upon the tb simple example. putting your plugin or similar exotica [3rd party] into the kineme example's treble iterator really slows down the rendered results fps wise. that's my experience to date with trying that. i am finding it pretty difficult to get more exotic than Apple's objects to really iterate to that extent, although having some success with iterations. BTW, got a snazzy 1024 visualizer sorted :-) - windy
btw the example posted here is in a real rough draft stage - problems with getting signals to set and reset the repel, shake and such, work in progress.
Wow, with a bit of tweaking, you can get some pretty cool results with this!!
Will post some screenshots in a while, after I've restarted my laptop again. I think the crashes are OpenCL-related, rather than GL-Tools-related, though (so cool, so f*cking unstable)....
a|x
You need Red/Cyan glasses for this. There's quite a lot of fringing, but I think that's pretty-much inevitable with Anaglyphs...
It definitely does have a sense of depth, though.
Supersampled to try and smooth the edges a little, but still a bit 'bitty' unfortunately.
a|x
mmmm, you're right. i seemed to have missed the extra clear patch.
-- btw - Particle Cloud is not intended to be put inside iterators. Performance can be dramatic...
LOL
true - especially the dramatic performance :-)
cool results - I'm seriously going to be looking for some good anaglyphs - can you get them as clip ons, I wonder, search and the answer is yes and dirt cheap too :-)
Thanks!
Some work better than others. Also, when the object come too close, the separation becomes too extreme for your brain to fuse the two images.
Re. the glasses, I got a 5-pack of them for not-very-much, from some Dutch website, years ago, when I bought a Loreo 35mm 3D camera. They're cheapo cardboard Red/Cyan ones with no arms. Also got two different but superior pairs free with Hexstatic albums :D
I met a guy who knows Hexstatic the other day, coincidentally.
a|x
Although I've gotten pretty good results with iterating mesh with kineme 3d and apple opencl in this stereo patch, I hadn't found a way to make .md2 animate, until I realised that I'd set the scaling way, way too low.
It uses a different projection matrix than the standard QC GL renderer.
You can effectively zoom in by reducing the FOV input value, by moving the Object Z input value closer to zero (making sure to adjust the Near Z Clip input so close objects aren't clipped), or by using a
3D Transforminside the patch.Just been reading here http://local.wasp.uwa.edu.au/~pbourke/texture_colour/anaglyph/ that there's another approach to compositing the two channels, for use with Red/Blue glasses.
Don't have a pair to try it with, but the CIFilter kernel to do it might look something like this:
kernel vec4 tb_compStereoRedBlue(sampler Left, sampler Right) { // Sample Left image vec4 l = sample(Left, samplerCoord(Left)); // Sample Right image vec4 r = sample(Right, samplerCoord(right)); // Green channel is average of Left and Right green // Red from Left, Blue from right return vec4(l.r, (l.g + r.g) / 2.0, r.b, l.a + r.a); }Anyone with Red/Blue glasses out there who can give it a go? It's supposed to give better colour, I think. I might try and pick up a pair myself sometime.
Those stills look great Alex, found a nice tip for anaglyph recently on vimeo: double up the specs to get better filtering. The gels are just too cheap and thin in the cardboard specs!
Now we just need to have the camera angles narrow as an object gets closer to avoid the separation issues. I spotted a physical camera system which did this at a trade show a year ago with a winding handle (be great to have it automated), trying to think of a way to do it DIY for my eyetoy usb cameras.
The very last build isn't putting out both image channels in SL on my system - latest SL seed... (haven't tested in Leopard). Tried this with stock and 3rd party patches.
It also reveals an interesting weirdness with DAE/mesh and the stereo environment. I can actually make DAE's stop rendering by "not" having a lighting macro inside of the stereo environment, whether or not the DAE's actually have anything to do with the macro... the DAE's are actually outside of the lighting macro, but turning lighting off makes them crap out.
I'll give that a go (I have several pairs here)!
Hmm.. but that would make it look further away again, surely... I'm still a bit confused about how the various controls of this patch interact, but i guess you should be able to automate how the IOD, for example, related to Object Depth.
I think the Screen Z parameter effectively does that, by setting the depth at which there is 0 separation between the left and right channels. Or perhaps I'm completely wrong on that....
BTW, is that a pre release seed of 10.6.3 or just 10.6.2?
On 10.6.2 I screen grabbed some similar weirdness regarding Trackball and knocking out of Mesh Renderers outside of the TrackBall if the Trackball is switched off. I was trying to grab how asking for input splitters on 3d Renderers causes exceptions. This was mainly using tb's simplified example.
Part One
part one movie shows difficulties and facilities for Mesh rendering and for loading 3d objects.
Part Two
part two especially shows the 3d Object input splitter, publishing ports problem.
BTW - I do get dual image output.
Correct, Screen Z specifies the plane in which the left and right images will be projected identically.
Depending on what you mean by "toward" and "apart" --- I used "diverge" to mean "the projected images start to differ".
Closer than Screen Z, the Left Eye sees the object shifted toward the right, and right Right Eye sees the object shifted toward the left.
At Screen Z, the Left Eye and Right Eye see the same image of the object.
Further than Screen Z, the Left Eye sees the object shifted toward the left, and right Right Eye sees the object shifted toward the right.
@gtoledo3, what's the GPU in the system you're testing?
Mesh Rendererdeep within nested iterators, you get a crash inC3DEngineContextCreateSharedContext(). I haven't been able to recreate this ---Mesh Rendererworks just fine for me (see attached screenshot). If you take the contents of theGL Stereo Environmentand paste them into the top level another composition (taking theStereo Environmenttotally out of the equation), do you still get a crash if you insert aMesh Renderer? And if you do this inside a normalRender In Imagepatch? If so, please file a bug with Apple.Well, I went around things in a reverse engineer route using tonebursts simple exemplar and step by step adding features to replicate the precise iterative combination used, within the environment patches, Polygon & Stereo used in the source code example.
It works.
:-)
See attached screen grab.
and attached reverse engineered example.
These constructs still can just crash QC when first opened and asked to render - for the most part they are reliable and I wonder if there isn't something about the QC cache that trips such constructs up?
What I mean is, if and when something goes amiss , especially due to .dae / OpenCL related assets, even restarting doesn't seem to clear the kludge. Constructs, such as the one attached below, that are usually to be relied upon can cause QC 4 to crash.
Quite definitely get a crash whenever I try to place a Mesh renderer into the pre-existing construct in the sample compositions.
Also able to run Animated & Static Strings too.
Pretty robust.
Thanks for clearing that up for me: I had not even tried GLTools 1.6 at that point yesterday. I can now report it is working well on my machine: MBP/10.5.8/GeForce 8600M GT.
In your comp there a|x are you using a radial gradient? I'm having trouble adding backgrounds: which layer should I add them too? Back to beginners class for me :/
The standard
Gradientbackground patch won't work insideGL Stereo Environment--- it draws its geometry (apparently) at z=0, which is culled byGL Stereo Environment's projection. (This also applies to the projection used by theGL Frustumpatch.)Loving the new tools, thank you all for the work.
haha smorkis had my trying to click the close button on his screen pic. damn it.
Yep, it's a radial gradient. I added it at the top level (outside the Stereo Environment). I have a little drop-in Clip macro for it.
Hope that helps,
a|x