stereo 3D anaglyph camera
Testing out the new frustum & colormask capabilities of jit.gl.camera, and everything's working beautifully. Hoorah for 6.0.2!
Anyway, I'd like to use jit.gl.node to parent both cameras so that they can be manipulated as one, but I can't figure out how to do it. When I use jit.gl.node with multiple jit.gl.gridshapes, it works just as expected, but when I try it with multiple cameras, the cameras stop working. Obviously there's something I'm missing.
Attached patch shows a simple anaglyph camera. I'd very much appreciate it if someone could update with an example of how to use a jit.gl.node as a parent for the cameras.
Plus a minor problem: manipulating objects with jit.gl.handle is very jittery with the anaglyph camera. Rotating objects via rotate message is fine.
pH
Here's an updated patch, added side-by-side mode to the camera.
This is much more fun than jit.gl.sketch/javascript/glcommands!
By the way, does the jit.gl.render stereo attribute actually work? When I set it to 1, I get this error:
"myWindow" is something other than a jit.matrix, jit.window, jit.pwindow, or jit.gl.texture"
but maybe that's because I don't have an active stereo display to test it on at the moment?
pH
OK, I get it. I wasn't adding the cameras AND the objects to the same jit.gl.node, and so the objects disappeared once the cameras were added to a different node.
So here's another update. The jittery handle goes away, but now I have a new problem.
To get the anaglyph mode to run correctly, I have to set depth_clear to 1 - otherwise the rgb channels conflict. But when depth_clear is set to 1, the objects render in a fixed order, which is often wrong. Setting depth_clear to 0 fixes the rendering order, but screws up the channels. In the previous non-node version, depth_clear 1 rendered in the correct order.
pH
(I guess this thread is my own private party - having a blast)
In any case: The various flavors of node (anim vs gl) are starting to make a little more sense.
Here's a much better anaglyph 3D camera (requires custom shader - attached). Using jit.anim.drive (much better than jit.gl.handle) to navigate (thanks Andrew, and thanks Robert for the arrow keys).
I have a couple of little questions about jit.anim stuff:
* jit.anim.drive's ui-map seems to intermittently reset to the default - no embed attribute like dict, so I copied my ui-map into a dict object, and loadbang it in - but there must be a better way.
* I want my camera to stay upright - setting tripod 1 works to keep the up vector up with cameras, and it seemed to work with jit.anim.node when it was connected directly to a camera, but it doesn't seem to work when it's connected to a jit.gl.node.
hi perry, glad you got the anaglyph stuff working.
the anim.drive dict should be editable by double clicking on the anim.drive object, and should save when you save the patch. if you can give me some reproducible steps showing this is not the case, i'd appreciate it.
if you want to use tripod mode, i wouldn't use the animation controls on the gl.node, but instead on the gl.camera's.
here's a modified patch showing this:
[edit - unfortunately i just uncovered a bug with anim.drive that requires you to toggle off and on the automatic attribute of anim.drive to make the animation work. i'm looking into that right now ]
Thanks Robert.
The anim.drive bug (not working till you toggle automatic) explains why it's seemed to be acting so flakey.
My problems with anim.drive losing a custom ui-map might have been simply that I changed an attribute in the object & it reverted back to its default ui-map - which, even though I understand why that happens, is unfortunate, as nothing warns you that you're about to lose your edited text. It would be nice if there were a way to get it to spit out its ui-map (the way dict does on bang).
In the same vein, since your solution requires the use of two anim.drives, is there any way to maintain them both in the same state? That is, is there any way to automatically transfer the contents of one into the other? Otherwise, I assume that editing a dict object & banging it to set the ui-map of both anim.drives is the best option?
thanks for the report.
i'll look into ways to make this more robust and easier to use.
the ui_map attribute stores the name of the mapping dictionary, and you can send the message getui_map to retrieve this dictionary name out the dumpout, and send that directly to another anim.drive. however i am noticing some issues with this currently, so i would wait for the update when i can work out these ui-map dict issues before trying this solution.
for now, yes, simply send the same dict to both objects to duplicate the mapping.
Hi Robert -
Just getting back to this stuff after many, many months. When I run the last version that you posted, here's what happens:
- dragging in the window moves only one of the views
- keys (wasd, etc) don't have any effect
- anim_reset doesn't reset the jit.anim.drive
When I run the previous version that I posted (using jit.anim.node & jit.gl.node), I have none of those problems - but then the tripod attribute has no effect on the cameras, which is what I was trying to solve in the first place.
So it seems that there might be some issues with using multiple jit.anim.drives in the same window?
hi perry.
yes, some things have changed with 3d ui objects over the last few updates, so unfortunately this patch no longer works as expected.
objects that listen to the window for ui events (anim.drive, gl.handle, etc) will now only let one object receive ui events at a time.
the issue with the keys not working is unrelated. key events can only be sent to a ui-object that is bound to the context of the window, not the context of the gl.node. i consider this a bug (or at least, limited functionality), and will work on a fix.
the anim_reset message should still work. although it doesn't actually reset the transformation, it simply disables all currently enabled animations. you must also send the anim_reset message to the 3D object (or anim.node) to reset it's transformation.
fortunately, this patch can work as you need with a few minor adjustments. we can use the same anim.drive to control both cameras, and instead of adding it to the gl.node context, we add it to the main render context. we do this by giving the jit.window a name argument, and providing that same name argument to the @drawto attribute of the anim.drive. then instead of connecting the anim.drive object directly to the gl.camera, we connect to a trigger, then to the two gl.camera's. this prevents the object from implicitly adding itself to the gl.node context that the attached cameras belong to.
hope this makes sense. let me know if not.
great patch
what is offset (rgb) area.
Hi Robert -
Still trying to sort everything out. Ultimately what I want to work out is a stereoscopic first person controller.
Towards that end, I've set up a jit.anim.node hierarchy, with a jit.anim.drive at the top. This patch doesn't deal with anaglyph or frustum yet, it's just a side-by-side stereo view with an overhead view on top. The main issue here is that the wasd keys always move along the world axes (so when you turn 90 degrees with the mouse, w/s move you left and right instead of forward and back).
Is there any way to get the keys to move along the local jit.anim.node axes (the same way they would if the jit.anim.drive was connected directly to a camera)?
Also, I'm pretty sure that jit.anim.drive does not remember its dict when closed - I'm banging a dict with @embed 1 into it upon open - to test, just disconnect the loadbang from the dict.drive & the jit.anim.drive will lose its custom ui mapping (at least it does for me).
good solution.
you simply need to set @anim_mode local on your parent jit.anim.node.
this will set both turn_mode and move_mode to local, which along with @tripod 1, should give you the desired behavior.
thanks robert, I think we nailed it!
Here's a cleaned-up patch, with all the frustum stuff & both 3D modes (anaglyph & side-by-side) put back in. Plus a mode with an overhead view of the 3D camera.
hey guys, i just wanted to bring your attention to the a new example file that hopefully explains the different ways you can share dictionaries with anim.drive in max 6.1
you basically have two options: referencing or cloning.
referencing will allow changes to propagate to all references, and cloning copies the dictionary so that the anim.drive creates it's own local copy.
hopefully that makes sense, and is useful for your needs.
Max 6.1/examples/jitter-examples/render/anim/anim.drive.ui.dict.maxpat
Hi Perry,
thanks for the great patch. I tried to integrate a structure where I can make multiple instances of an object and modify the group dynamically, see the the patch below.
The problem I have is that these instances only appear on one side so are not within the s3d world. It has to do with the automatic attribute but I could not figure it out, maybe you or someone else can help
thanks
Falk