New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch node and lights #838
Comments
I put the example on glitch to experiment with: |
Ok, I modified x3dom a bit in the example by introducing a ._traversed property for lights: https://glitch.com/edit/#!/x3dom-light-switch?path=traverseLights.js:19:3 Enabled lights are collected each frame by viewarea.getLights(). By also checking if they were traversed as children of grouping nodes, one can exclude lights not in the active switch child. This also requires resetting to being non-traversed before each traversal which seem to work well by doing that in the getViewMatrix method. This is not ideal since it has nothing to do with the view matrix. getViewMatrix probably happens right after CollectDrawables is done going through the scene which would be correct but maybe there is a better place. See below. Also, collectDrawableObjects is meant for Shapes, not Lights, but really is called for all child nodes of grouping nodes, including scene. Perhaps there is a better solution but seems worth testing more thoroughly before submitting a PR. Hm. it looks like this would not work for rendered texture since Line 4060 in dd0d075
would reset all ._traversed to false before .getLights is called a little later. Actually in the main renderScene, getViewMatrix gets called a couple of times before the RTRenderPass is done. runtime.exitFrame may be the only other place without having to dive into gfx_webgl. So introducing an internal doc.exitFrame method after the render call may be best and I modified the example accordingly. |
You may be able to use https://x3dom-light-switch.glitch.me/traverseLights.js as a temporary fix for your scene. |
Does using the switch node instead of the 'on' attribute provide substantial benefits ? Can you outline your use case ? |
Hello Andreas, |
Actually, this was a good opportunity to get background on what X3D specifies. I modified your example to work with any X3D viewer: https://glitch.com/edit/#!/x3d-switch-global-light?path=simpleLight.x3d Most do what you would expect, eg. switching the light on and off. Still a little unsure to introduce this change since it affects performance a little bit, checking all lights at each frame. |
Thanks, then it really may be unnnecessary, as I can really easily switch the lights when needed.
|
Closing for now, please reopen as necessary. |
I experience that setting whichChoice for Switch nodes does not handle the contained lights properly - ie. they are always on, even if they should be off by the switch state. So they have to be turned off by explicitly setting the "on" attribute.
I guess lights should behave as other nodes, shouldn't they?
I only tested it with external inline nodes, no idea if it works for explicit x3d switch definitions.
Tester html and x3d file below:
The text was updated successfully, but these errors were encountered: