|
|
Anaglyph Rendering Just idly wondering if an Anaglyph Render macro patch would be feasible. I'd envisage a macro patch you'd place glsl shaders/3D primitives/Kineme3D objects inside, and it would automatically render the geometry twice, with appropriate offsets, and output a pre-combined anaglyph image. It would basically be a variation on the Render In Image patch. Now I think of it, if an Anaglyph Render patch would work, maybe you could also have SSAO and DoF versions... Possible? Pointless? Anyone any thoughts on any of the above? a|x |
I've actually been thinking along similar-ish lines (mostly for shadows, in my case) -- I suppose it's possible to do anaglyphs, except for one possibly-fatal flaw: color control. There isn't any way for a macro patch to control the color/tint of the stuff it renders.
I guess it could render in its own context, and then manually tint (similar to Render in Image), at some additional overhead cost...
this isn't really what you were asking, but you can get simple anaglyph output by simply duplicating your objects and placing them ever so slightly apart on the x axis. QC does the rest, as its real 3D space.
Hi toby.
I know that, but I still think it would be cool to have a patch that did that for you, especially if it could be made faster (using VBOs etc.) than the manual method.
a|x
a macro patch cannot assist with speed -- it'll execute the subpatches twice, which is the same as you doing it yourself. a macro patch can't really VBO-render subpatches (unless it knows exactly how to render every subpatch itself, which isn't realistic), as VBOs require vertex, normal, and texture coordinate data.
the only possible performance improvement I can think of with this patch would be applying the anaglyph red/cyan tinting (manually applying some core image filters, rather than you doing it manually), which isn't particularly show-stopping (the filter's embarrassingly simple, so it's not a big timesink).
I few months back I took the output of a render in image, and feed it to two sprites that are inside of GL Tools color channel patches, and offset until it looked as I remember it should. I never bothered get glasses to test with, and it was only an x offset... I wasn't sure if there should be angle or not? I did a test on some printed material years back and all we used was an x offset.
Ok, I did a quick look (thankfully it was in my email, so I could find it easily)... this is a version that is hooked up to the apple cam...
Let me know if it works, as I said, it's totally untested (though I have some red/blue/green plastic lighting "gels" around here somewhere, I wonder if they would work for home made glasses in a pinch?).
The main thing, I would think, is that the offset on the x's may need to be reversed depending on the layout of the glasses, and the color channel settings would need to be changed depending on if the glasses use green/blue/cyan... for cyan, just let green and blue both pass through.
Technically, you're supposed to use asymmetrical frustums (not rotation nor translation/offset):
http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/stereorender/
(from 1999!)
It might look cool, but it probably won't look 3D. The two images need to be rendered from slightly different angles, rather than just offset in 2D on the x-axis.
Toby's method works, I was just wondering if there would be mileage in creating a plugin to save you the bother of setting-up duplicate geometry inside 2 RII patches, then passing the results of both patches through a CIFilter to combine the views.
a|x
Yeahhhh, that was what I thought.
I do know that for a simple "ooh, that pops out effect", you can use x offset, at least on the printed page, but I remember not being "wowed" with it either...
It looks like this could be simulated in QC (asymmetrical frustrum)... with two sets of objects :o)
Interesting. Is that practically different from a small X-offset?
a|x
Oh, OK. So it's possible to create a macro that will automatically execute all it's sub-patches a given number of times? I guess this is likely to have similar performance to the builtin Iterator patch. Could you have both Left and Right 'passes' rendered to textures, that could then be combined using a simple CIFilter to a 3rd output image/texture?
a|x
it depends on the scene's depth -- for close up objects, the x-offset method works fine, but the farther from the viewer, the most difference there is.
The side effects of using other methods (x-offset, rotation, etc) are all detailed on that page -- I don't remember them all off the top of my head, but I remember asym-frustum being the most optimal for single-projection settings.
I seeeee... Is manipulating the frustum for the two passes something that could be done in a custom QC Plugin?
a|x
The frustum is defined by the OpenGL matrix (Projection, I think) -- you can cook this with GLTools, but it's difficult unless you're a mathematics professor.
A custom anaglyph patch could also do this automatically without too much difficulty.
If you're in custom-plugin land, I guess you could probably use gluLookAt or some other library to create the View/Projection matrix for you...
a|x
I was thinking the patch would render each side in monochrome (you loose color info with anaglyphs, anyway), to a 2D texture, then the two textures would be combined into a third output texture, via a simple CIFilter.
I guess this is exactly what you were thinking, too.
a|x
i suppose you could attach a tb_dirty_monochrome_clip to a sprite and offset.