FineCutBodies

Anybody could help me, if i have several different jit.gl.nodes objects, with their own jit.gl.camera objects, then:

1, If i don't have it's own camera in the jit.gl.node, then sending "enable 0" to the node will turn off all the 3D calculations inside that node, using less GPU power...

2, If i have a camera connected to the node with "drawto NODEname" then if i send "enable 0" to the node, then it will keep rendering...

How can i tell the node not to do any work and keep the GPU processing power for other nodes? :)

Attached a patch to demonstrate the idea...

3, Is there a way to change the erase_color for a jit.gl.node? I mean what if i would like to have different erase_color for the different nodes? I have 2 ideas to solve it, but both seems bad for me :DDD

a, make a videplane for every jit.gl.node-s with "transform_reset 2" with different colors (althought i don't know how to solve the depth buffer problem here)...

b, turn off "automatic" rendering on the node, and before sending a bang every frame, i can change the jit.gl.renders's erase_color to the node's own erase_color, then change it back... Not sure if this would work, but don't seems a proper solution...

1, If i don't have it's own camera in the jit.gl.node, then sending "enable 0" to the node will turn off all the 3D calculations inside that node, using less GPU power...
2, If i have a camera connected to the node with "drawto NODEname" then if i send "enable 0" to the node, then it will keep rendering... 

Another question:
3, Is there a way to change the erase_color for a jit.gl.node? I mean what if i would like to have different erase_color for the different nodes? I have 2 ideas to solve it, but both seems bad for me :DDD

a, make a videplane for every jit.gl.node-s with "transform_reset 2" with different colors (althought i don't know how to solve the depth buffer problem here)...
b, turn off "automatic" rendering on the node, and before sending a bang every frame, i can change the jit.gl.renders's erase_color to the node's own erase_color, then change it back... Not sure if this would work, but don't seems a proper solution...

jit-gl-node-and-camera

and you can attach a camer to the node and the camera also has @erase_color.

In your example, I don't see anything that relates it to 1 or 2. I see no enable 0's. Do you have an example that doesn't work?

For 3...jit.gl.node has @erase_color.
and you can attach a camer to the node and the camera also has @erase_color.
Have you tried these?

In your example, I don't see anything that relates it to 1 or 2. I see no enable 0's. Do you have an example that doesn't work?


3, i tried the node's erase color obviously, but that didn't affect the erase color of the main picture, but now i've tried the erase_color of the camera and that works perfect... i don't know why, but at least i have a solution :D Thanx Dale!

regarding 1-2, there is no enable because it's not working :) but here is an example what i try to achieve... You can see the node's "enable is changing, but rendering still occurs!

Althought after you told to try the erease_color of the camera i've tried to "disable" both the node and the camera connected to it, and seems that makes the trick, if i turn off both the node and the camera attached to the node then the rendering of that 15x15x15 cubes will stop and FPS will go up to normal, if i enable the camera or the node, then FPS will drop, so it seems i can solve it right now, althought i'm not sure about the logic behind it, so maybe i have to watch other objects too? That would make sense for me if i turn off a node, then anything connected to that node will be out of the game, but it seems it's not the case...

I few things concern me in the patch you provided directly above.

I recommend you use the first two suggestions and then disable your node and camera both until the third errant behavior is investigated.

Stay away from @drawto. I've found that the behavior is sometimes erratic than using the context argument. If you can in your patchers, change it to such on all your object, for example on your cameras and gridshapes

In my experience, when you are capturing a node to a texture, the context name for the texture should be the node. Change those names on your two textures to be the nodes they are capturing and not Kevin

I think there is errant Max 6.1.3 behavior, the camera on a node does seem to continue drawing the node context and sending captured textures. Below I attached a simplified patcher.

I recommend you use the first two suggestions and then disable your node and camera both until the third errant behavior is investigated.


thanx Dale, exactly that's what i do in my project, disable both... just on't understanded why it works ths way...

1, regarding the drawto , i have a huge project now and drawto seems to work fine for all so i dont think i'll change them now, but will remember next time for sure!

2, as i understood a node is not a new context, so any textures rendered/captured to the node, will be captured to the context as a node have to be part of a context. So any node should see all the textures inside the context, especially as i need to use textures in a node rendered in another one... also works perfectly for me that way all the textures are rendered into the main context and all the "sub"-nodes can reach them... Am I wrong?

it looks to me like the only issue is that when a gl.camera is bound to a gl.node, you have to disable both the gl.camera and the gl.node to stop rendering.

if you disable both (@enable 0) does that fix your problems?

it looks to me like the only issue is that when a gl.camera is bound to a gl.node, you have to disable both the gl.camera and the gl.node to stop rendering.
if you disable both (@enable 0) does that fix your problems?


yeah that works perfectly... if any of them is enabled then the rendering occurs, but if both is disabled then all rendering is not happening...

@finecutbodies, Regarding (2), there is a difference. I don't know technically why, but it does not work in both ways in my experience. Take that exact same simplified repro I pasted above, and change the jit.gl.texture to have main (instead of node1) as its context. After making this change, the videoplane can no longer access the texture. I attach this as an example:

jit.gl.node and camera