> > Date: Mon, 19 Jun 2006 10:19:02 +0200 > From: Andreas Zieringer <[EMAIL PROTECTED]> > Subject: Re: [Opensg-users] Light scopes > To: [email protected] > > 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! >
This default behaviour isn't working properly because lights with infinite volumes are being clipped in my case. I will try to generate a small scene and the osb of this later. > 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. > > I would like to suggest that you (we?) explore an orthogonal mechanism to make it possible to have lights that are infinite in scope and non-local. I'm sure it would make life easier for others who are dealing with an imported or imposed scene-graph structure. Other scene graphs I know have both local and global light sources. E.G. Performer has pfLight as a geostate property (i.e. its inherited) and pfLightSource as a global light source whose influence doesn't depend on scene-graph position. What I am actually looking for in my case is the exact OpenSG equivalent of a pfLightSource node, which, from what you say, doesn't exist currently. I would just note that having purely local lights leads to a combinatorial expansion of the number of lights required in some scenes: each light needs to be copied in to sub-graphs where there is a non-identical overlap in scope (e.g. having two lights and three "targets" each with different influence under the lights requires you to set up at least two different copies of one of the lights so that you can inherit the correct influence down the graph). This is a difficult situation in any scene graph, but there are alternatives to scope by hierarchy. > Andreas > > Regards, Anthony -- >> > >> > 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
