First, a bug perhaps, then I'd like to start a discussion about lighting scopes in OpenSG. I have problems making my lights work; OpenSG culls lights against the view volume as if they were nodes - this is really unusual behaviour for a scene graph and is to my mind logically incorrect, but then I'm not the author of OpenSG :-) On the mailing list I saw a suggestion to make the bounding volume of the light source infinite, with code such as the following:
beginEditCP(world_light, Node::VolumeFieldMask); Volume &v=opensg_equiv->getVolume(false).getInstance(); v.setInfinite(true); v.setStatic(); endEditCP (world_light, Node::VolumeFieldMask); unfortunately that doesn't work for me - the light source still gets culled if it isoff screen This is with lights as leaves of the scene-graph. Worse, if I move my lights to the top of the scene-graph (something that I do not want to do, see below, but which seems to be the suggested practice), then the culling system breaks. That is, if I add a light directly under the world root, set its bounding volume to infinite (otherwise it still gets culled!), then the bounding volume traverser only every reports 3 nodes tested (using the HUD statistics), rather than about 1000 (the number if I take the light out again). And in fact, if the light is not on the screen, the whole scene gets culled. I can fix this by writing my own traverser, but it should be possible to do this type of thing, and others must have, so at the very least it could be a better documented FAQ. The behaviour I see occurs in 1.6 and also the daily build from June 6th. -- So to the discussion, OpenSG scopes lights in the opposite way to most scene graphs I have used. As far as I recall, it is usual pick up the position of the light from the scene graph, and add a separate relation that adds a object scope, but OpenSG does it the opposite way around - having a beacon for position and inheriting scope from its scene graph path. This actually changes the way most people think of modelling scenes because in, say, 3DS Max and most modellers, lights are just entities. Translating from most scenes to OpenSG will involve moving the parenting structure of the lights. In my application, where OpenSG is just the implementation of an abstract renderer inside a VR platform, I need (well really only want, but the implementation alternative is hard to maintain because lights are fully dynamic entities) OpenSG nodes to be in the same rough structure as the VR scene's database, so that editing and fault detection across the graphs is rapid and deterministic. So I want the lights to have the parent relationships that they had before. Essentially, there are two isomorphic scene graphs, and they must be synchronised. The VR platform's renderer already had ports to OpenGL and Performer, but translating the Performer renderer to OpenSG has hit a couple of tricky snags like this one. Unfortunately the code is 5000 lines long so far, so extracting usable snippets is a little tricky. -- Anthony _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
