Hi Anthony, actually OpenSG knows only local light sources. The "global" light sources are a relict from the beginning when the local light sources code was not implemented yet.
The default behaviour is this: - The light sources only lit their children in the scenegraph. And the light sources limit is 8. - If you put your scene not below the light source you get undefined behaviour because the light source could be culled away! To get real local lights you have to enable this via renderAction->setLocalLights(true) Perhaps I should change the default to this. Now you get this behaviour: - The light sources only lit their children in the scenegraph. And there is no light sources limit. - If you put your scene not below the light source your scene will be unlit. For local light sources it is correct behaviour to cull them away if they are not visible. Changing the light sources volume is not a good idea and also not necessary. I tried to reproduce your problems with a small test scene but it works fine for me can you write your scene out as a osb file to reproduce the strange culling and lighting problems. Andreas > > 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 > > _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
