maybites

1. rendering of a torus with jit.gl.node and capture the texture with jit.gl.camera

2. using jit.gl.videopane with this texture and render it with a second camera.

3. simultaniously share the texture with another context and display it in a different window

now: when I move the second camera (render step 2) it changes the lighting situation in render step 1. It actually feels as if the second camera is setting the default light position of render step 1.

does anyone know how I can stop this happening?

1. rendering of a torus with jit.gl.node and capture the texture with jit.gl.camera
2. using jit.gl.videopane with this texture and render it with a second camera.
3. simultaniously share the texture with another context and display it in a different window

does anyone know how I can stop this happening?


moving-jit-gl-camera-using-jit-gl-node-moves-default-light-position-aswell

thanks for the report. coincidentally, i was just noticing this issue.

this is currently how lights work for max 6, however i agree this is not ideal.

consider the bug logged, and we will work on a fix for a future release.

thanks for the report. coincidentally, i was just noticing this issue.
this is currently how lights work for max 6, however i agree this is not ideal.
consider the bug logged, and we will work on a fix for a future release.

not that I need this feature immediately - for the time beeing I can render the scene in a different context and then pass on the texture.

but I do understand the reason of existence of jit.gl.node correctly: it can be used to create render chains, right?

if yes: your bugfix will go into the direction of having full control over each renderstage, like its own lighting setup - which is something I wasnt able to achieve either:

is there a way to get noticed once a bug is fixed?

this feature is very powerfull and I intend to build an active 3d stereoscopic patch - but need to add a "postprocessing"-render stage after the creation of the stereoscopic frames.

which leads me to my next question: what is the advantage of using jit.gl.node compared to using another rendercontext and sharing the texture?

I assume its one less jit.windows cluttering the desktop and some performance advantages, but then there is another effect I noticed:

when resizing the output window of render step 2 it also has an influence of the dimensions the jit.gl.camera is capturing the texture under render step 1. I was unable to change jit.gl.node's "dim" attribute or jit.gl.camera's "dest_dim" attribute. Is there a way to set them individually from the parent-context's windows size?

and since I have (hopefully still) your attention: the draw (or bang) on the render context, in which the jit.gl.node chain is embedded, seems to bang internally each jit.gl.node and its attached jit.gl.camera. - is there a way to control the seqence of this events?

and last but not least - but slightly beside the above points: the provided example "multi.lights.material.maxpat" renders the toruses "unsmooth" when disabling/enabling the lights. maybe this is a b.. ?

not that I need this feature immediately - for the time beeing I can render the scene in a different context and then pass on the texture. 

but I do understand the reason of existence of jit.gl.node correctly: it can be used to create render chains, right? 

if yes: your bugfix will go into the direction of having full control over each renderstage, like  its own lighting setup - which is something I wasnt able to achieve either:

is there a way to get noticed once a bug is fixed? 

which leads me to my next question: what is the advantage of using jit.gl.node compared to using another rendercontext and sharing the texture? 

and since I have (hopefully still) your attention: the draw (or bang) on the render context, in which the jit.gl.node chain is embedded, seems to bang internally each jit.gl.node and its attached jit.gl.camera. - is there a way to control the seqence of this events? 

and last but not least - but slightly beside the above points: the provided example "multi.lights.material.maxpat" renders the toruses "unsmooth" when disabling/enabling the lights. maybe this is a b.. ?


ok, upon looking further at this issue, i must retract my previous statement asserting your first post exhibits a bug.

i think this is actually expected behavior.

currently in max 6, lights are global to the scene. meaning gl.nodes cannot have their own lights distinct from the gl.render. the gl.light's position/orientation are tied to the root gl.render camera position/orientation.

in your first patch, you were adjusting the root camera position, and noticing the lights were affected. this is expected. in order to achieve the effect of moving the camera without affecting the lights, you can create another child gl.node that contains the gl.camera and gl.videoplane.

i've modified your first patch below to show this:

hopefully this helps answer some of your other questions.

for the time being, this will remain unchanged (lights can only be added to the root gl.render context).

in your second patch, if you remove the light from the gl.node and add it to the root gl.render, it will have the desired effect.

in the third patch, you are demonstrating the @adapt feature of a capturing gl.node or gl.camera.

by default, gl.node and gl.camera are @adapt 1, which means their capture-texture dimensions will match that of their destination window.

simply set @adapt 0, and the capture-texture will take the dimensions from the @dim attribute.

is there a way to control the seqence of this events?

you can control the order of gl.nodes and gl.camera with the @layer attribute.

and last but not least - but slightly beside the above points: the provided example "multi.lights.material.maxpat" renders the toruses "unsmooth" when disabling/enabling the lights.

i assume you are referring to a stutter in rendering. this is because the internal shader for the jit.gl.material object needs to be rebuilt every time lights are added or removed from the scene.

this can be alleviated by instead of using @enable, set the the @diffuse/@specular attributes to 0 0 0 0, to disable the light.

please continue to ask questions if anything is unclear. we are still refining the opengl engine, so these discussions are helpful.

ok, upon looking further at this issue, i must retract my previous statement asserting your first post exhibits a bug.
i think this is actually expected behavior.

in your first patch, you were adjusting the root camera position, and noticing the lights were affected. this is expected. in order to achieve the effect of moving the camera without affecting the lights, you can create another child gl.node that contains the gl.camera and gl.videoplane.
i've modified your first patch below to show this:

hopefully this helps answer some of your other questions.
for the time being, this will remain unchanged (lights can only be added to the root gl.render context).
in your second patch, if you remove the light from the gl.node and add it to the root gl.render, it will have the desired effect.

in the third patch, you are demonstrating the @adapt feature of a capturing gl.node or gl.camera.
by default, gl.node and gl.camera are @adapt 1, which means their capture-texture dimensions will match that of their destination window.
simply set @adapt 0, and the capture-texture will take the dimensions from the @dim attribute.

i assume you are referring to a stutter in rendering. this is because the internal shader for the jit.gl.material object needs to be rebuilt every time lights are added or removed from the scene.
this can be alleviated by instead of using @enable, set the the @diffuse/@specular attributes to 0 0 0 0, to disable the light.

please continue to ask questions if anything is unclear. we are still refining the opengl engine, so these discussions are helpful.


thank you robert. indeed, most of my question got answered, and I slowly get my head around jit.gl.render's architecture. But some new questions crop up:

is there a difference using jit.gl.render' @shared_context [contextname] vs jit.window's @shared 1 attribute?

since its not possible for jit.gl.node to setup its on lighting scene, one way to circumvent this would be to render the desired scene in a different render context and then pass on the texture to the target render context.

is there is a performance penalty in using shared render context instead of using jit.gl.node?

is there a way to use jit.gl.render without window? i.e. when using (in the root of the context) jit.gl.camera with attribute @capture set. -> jit.gl.node has a @capture attribute, jit.gl.render has not. (I ask this simply assuming rendering the output to a window uses recources which would be wasted in the above described circumvention)

and when thinking of it: what is actually the advantage of jit.gl.node? in my current understanding it seems to be a convenient way of sharing textures inside the same context.

no, it was referring to the way the toruses surfaces are rendered. "unsmooth" means, its individual faces are displayed instead of a "smooth" surface (like using @smooth_shading). However I updated to max 6.0.5 and this effect is gone. BUT: this new max6 version comes with a very severe performance penalty, my CPU runs on 100% without having any patch to run. at least for the first 3 minutes. after that it settles again to normal usage.

and last and not so important but interesting to know: when are shadows going to be part of jit.gl?

since its not possible for jit.gl.node to setup its on lighting scene, one way to circumvent this would be to render the desired scene in a different render context and then pass on the texture to the target render context. 

is there a way to use jit.gl.render without window? i.e. when using (in the root of the context) jit.gl.camera with attribute @capture set. -> jit.gl.node has a @capture attribute, jit.gl.render has not. (I ask this simply assuming rendering the output to a window uses recources which would be wasted in the above described circumvention) 

and last and not so important but interesting to know: when are shadows going to be part of jit.gl?


@shared_context is deprecated, use @shared.

my assumption is that two contexts would use more resources then a single context with gl.node. but it's entirely dependent on your particular use case.

if you want two entirely different scenes with entirely different lighting, i think two render-contexts are your only option at this point.

maybe describing more about your end result will yield some better suggestions.

every render context (ie jit.gl.render object) needs a drawing destination (ie jit.window, jit.pwindow, or jit.matrix).

the window can be set to @visible 0, if desired.

jit.gl.render still supports the "to_texture" message, which takes an argument of a named gl.texture to draw it's contents to.

however, jit.gl.camera or jit.gl.node @capture 1 is the recommended method for capturing a scene to a texture.

jit.gl.node has many uses: capturing groups of objects to a texture, hierarchical transformations, applying attributes to groups of objects, context-free grouping of objects for use in abstractions, etc. many things that required jit.gl.sketch in max 5, are made easier with jit.gl.node.

the 100% CPU usage is simply the max database being rebuilt. it should not continue to be a problem.

we can offer no forecast for shadow functionality, however it is definitely on our radar.

if you want two entirely different scenes with entirely different lighting, i think two render-contexts are your only option at this point.
maybe describing more about your end result will yield some better suggestions.

every render context (ie jit.gl.render object) needs a drawing destination (ie jit.window, jit.pwindow, or jit.matrix).
the window can be set to @visible 0, if desired.

jit.gl.render still supports the "to_texture" message, which takes an argument of a named gl.texture to draw it's contents to.
however, jit.gl.camera or jit.gl.node @capture 1 is the recommended method for capturing a scene to a texture. 

we can offer no forecast for shadow functionality, however it is definitely on our radar.


things clear up. I still dont understand half of the benefits of jit.gl.node, but for now I am set and my patch works just fine. Thank you.

When you talk about ´active 3d stereographic´, is it because you need active 3d glasses, or it´s enough with red and blue glasses?

the first was my intention, actually is still my intention, but the task is a bit behind schedule :-)

moving jit.gl.camera using jit.gl.node moves default light position aswell