maybites

Due to a probem I already made a post about (

https://cycling74.com/forums/creating-a-working-cubemap-with-6-cameras/)

 I have found an erratic behaviour with lighting and jit.gl.nodes:

This patch should quickly show where the problem is:

1. If you select the first setting you will see a sphere moving in a window. this is due to a rotation of a camera in the rendering context "foo".

Note: the shading of the object does not change.

2. If you switch over the camera and the sphere into the jit.gl.node context "subcon" the lighting changes. It is obvious that the lights position has changed somehow (where to?) and it is now somhow (how?) dynamically connected with the cameras movement.

I think this is weird. I would expect that jit.gl.node would react the same way as jit.gl.render did before. There is a forum 

 by Rob Ramirez where it says that by default "the gl.light’s position/orientation are tied to the root gl.render camera position/orientation."

but if this is true, then why didn't it happen before with the "foo" context, too? why is the light tied to the the camera in the first place? how is it possible to untie the two?

3. If you now switch off the jit.gl.light object, you will see that the same happens with the default light source aswell, but again not in the "foo" context".

again, here I would expect same behaviour between jit.gl.node and jit.gl.render.

4. if you enable the light again, switch back to "subcon" and change the camera position (which is not used anyway) to 0. 0. 0. the lighting gets even stranger. instead of a shaded sphere I get shaded concentric rings displayed on the sphere.

in summary: I am confused. But my question is simple:

How can I controll the lights position and its influences unpon the scene without beeing tied to the cameras position and orientation when using a jit.gl.node object?

Due to a probem I already made a post about (https://cycling74.com/forums/creating-a-working-cubemap-with-6-cameras/) I have found an erratic behaviour with lighting and jit.gl.nodes:

1. If you select the first setting you will see a sphere moving in a window. this is due to a rotation of a camera in the rendering context "foo". 

I think this is weird. I would expect that jit.gl.node would react the same way as jit.gl.render did before. There is a forum reply by Rob Ramirez where it says that by default "the gl.light’s position/orientation are tied to the root gl.render camera position/orientation."

jit-gl-light-and-jit-gl-node-show-erratic-behaviour

i will take a look at this and the cubemap post and see if i can find a solution for you, sometime after the holiday.

hi maybites.
thanks for the patches and explanations.
i will take a look at this and the cubemap post and see if i can find a solution for you, sometime after the holiday.


I am glad you are looking into this. The Cubemap problem is most likely solved with answering the above questions.

In hindsight: Step 4. above is probably happening because the lightsource's position and the cameraposition are identical. but this explanation doesnt make the behaviour less confusing.

Hi Rob
I am glad you are looking into this. The Cubemap problem is most likely solved with answering the above questions.

In hindsight: Step 4. above is probably happening because the lightsource's position and the cameraposition are identical. but this explanation doesnt make the behaviour less confusing.


Warning, there be dragons here. In my experience, lighting of subcontexts is not functional without a lot of patcher work. All the needed matrices for lighting calculations are not correctly setup in subcontexts. A hint towards this is that you can only put a gl.light on the root context.

It is possible to get it working by passing through all your needed vectors and matrices into a custom lighting shader. That's how I had to solve it on one of my patches. jit.anim.node is your friend here to get the matricies like modelview.

Another trick I used was to just accept that lights and the camera only work together in the root context. So I would do a more complex bang sequence on the root gl.render. It would send the camera position/lookat of any subcontext to the root gl.render so that the needed lighting matrices were made. Then I would render the subcontext that I needed. Repeat with each subcontext.

It is possible to get it working by passing through all your needed vectors and matrices into a custom lighting shader.

Thats a workaround that came to my mind aswell. Thanks to the orange book there are examples on how to do this. I assume the glsl's gl_LightSource will work with all the added jit.gl.light objects? would you share the relevant snipplet in your shader code where you reference the jit.gl.light objects?

It would send the camera position/lookat of any subcontext to the root gl.render so that the needed lighting matrices were made.

I implemented your suggestions to my first patch, and now the lighting behaves as expected. So the culpit is - at least in my understanding - a missing transformation of the light's with the correct modelview-matrix before each renderpass. Missing in so far as I would expect that the jitter framework should take care of this. Or do I miss here something?

It would send the camera position/lookat of any subcontext to the root gl.render so that the needed lighting matrices were made. 

I implemented your suggestions to my first patch, and now the lighting behaves as expected. So the culpit is - at least in my understanding - a missing transformation of the light's with the correct modelview-matrix before each renderpass. Missing in so far as I would expect that the jitter framework should take care of this. Or do I miss here something?


jit.gl.light and jit.gl.node show erratic behaviour