[sharing] Triplehead2go rendering setup (updated for Max6 and jit.gl.node)

    Feb 17 2012 | 5:40 pm
    Now that the shared context problems are resolved in Max6.0.4 I updated my Triplehead2go rendering setup (original: https://cycling74.com/forums/sharing-is-bladibla-render-multiple-views-of-1-gl-scene-for-triplehead-setup). It renders 3 rotated views of the scene and maps them on the 3 outputs (3x800x600). It now works with jit.gl.node which makes it quite a bit cleaner. It includes a preview window using shared contexts on GPU for performance.
    Question 1: although sync is set to 0 on the windows I need to manually resend 'sync 0' after the patch has loaded for it to take effect. Any ideas why? I need it because my preview monitor runs at 60hz while my triplehead beamers run at up to 85hz. With sync on Jitter locks to the 60hz monitor.
    Question 2: is there a more efficient way of doing this than rendering the scene as 3 separate meshes, one for each view?

    • Feb 17 2012 | 7:00 pm
      q2: there (edit: may be) no need to repeat the rendering, when you can use jit.gl.camera to have multiple views. It can definitely do different viewports, but can it do multiple rotations, for instance?
      this patch by robert ramirez shows a simple version of it - look out for the @viewport attribute:
    • Feb 17 2012 | 8:01 pm
      tanx for the tip! i was totally oblivious to the existence of that object... will work out whether it's applicable to this case.
    • Feb 18 2012 | 1:03 pm
      and here's the jit.gl.camera version. uses 3 camera's instead of 3 meshes. renders each view to texture and videoplane separately for slab processing. pretty nice and clean. i like.
    • Feb 18 2012 | 2:08 pm
      now that i think of it, it probably could do with one view node instead of 3. it can contain the 3 videoplanes. gonna try that.
    • Feb 18 2012 | 3:47 pm
      yup, that works. i don't think it gets any simpler than this. great stuff this node object.
    • Feb 20 2012 | 4:16 pm
      now with keystone correction / projection mapping using jit.gl.cornerpin on each of the 3 outputs.
    • Feb 21 2012 | 10:49 am
      Nice work. As far as I can tell the videoplanes are now extraneous - once you use jit.gl.cornerpin you lose all of the translation and rotation possibilities.
    • Feb 21 2012 | 11:14 am
      you're right, tanx.
      i thought the videoplanes were grabbing the cornerpin outputs but they aren't. can be removed from the patch and it will still function.
      now i need to come up with something to clip the 3 cornerpin outputs to the 800x600 size of each triplehead output. i don't want them to overlap or bleed into each other. thought the videoplanes were doing that.
    • Jun 27 2012 | 8:53 am
      sorry to dig up an old thread, just what to say thanks a bunch, this patch is great!!!
    • Jun 28 2012 | 8:13 am
      you're welcome :)
    • Jul 23 2012 | 4:11 pm
      Super exemple!
      What's happening with the light in this configuration? Each camera seams to get it's own shadows/light angle.
    • Jul 23 2012 | 8:42 pm
      not sure about what's happening there, haven't been using lighting in my projects
    • Mar 02 2013 | 1:29 am
      Holy space balls this is great!
    • Mar 02 2013 | 8:44 pm
      @dtr your model is configured for 3 walls joined consecutively on the horizontal axis. What if I wanted to use this in the corner of a cube like this: http://l.rgbimg.com/cache1nSkH8/users/l/li/littleman/600/ml6lNgW.jpg
      @j-Ambroise Vesac were you able to fix the shading of a 3D object?
    • Mar 02 2013 | 9:04 pm
      You'll have to play with each camera's position, rotation and look_at parameters to get the view perspectives you need.
    • Mar 03 2013 | 12:52 pm
      Wait a sec... Do you mean one beamer projecting into that corner? Then you'd make the output window the size of your beamer resolution and play with the cornerpins (or videoplanes) to map your surfaces.