> Date: Tue, 20 Jun 2006 16:23:15 -0500 > From: Dirk Reiners <[EMAIL PROTECTED]> > Subject: Re: [Opensg-users] Light scopes > > > Hi Anthony, > > On Mon, 2006-06-19 at 17:04 +0100, Anthony Steed wrote: > >> > >> > 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. >> > > Please do, thanks. The whole Infinite volume part is not as trivial to > use as it should be. > > >> > 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. >> > > Conceptually my problem with truly global lights is that you have to do > a separate traversal to collect them before you can start rendering > them. You can avoid that by folding it into the culling traversal, but > conceptually scoping lights by their position in the graph is the > cleaner solution, as it avoids special casing for lights. > > Would it be possible to just have a bunch of lights at the top of th > graph at all times and just turn them on and off as needed? >
This is what I did to solve my specific problem - I just inserted eight lights at top of scene. However to manage that turned a 3 lines of Performer code into ~200 lines of OpenSG code (lights in my VR software are dynamic so I need to keep a table with the mapping, and I need several special cases for adding and deleting parts of the scene graph). Global lights have a certain ease of use to them, although they sit outide the conceptual model of scene graphs serving solely to wrapping and isolate OpenGL state changes. They are widely supported in modelling packages. >> > 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. >> > > Hm, ok, that's a problem. We haven't seen a need for that kind of light > setup before, but I can see it being useful for skilled developers. I'll > have to think about a good way of managing that. > > The way I understand it Performer just has a bitmask of active > lightsources in the GeoState. As a first shot I'm thinking about giving > Lightsources ids (0 to 31), and have a LightActiveChunk with a mask to > indicate which lights should influence this Node. I would still like to > limit it to children of the light, i.e. allow exclusion of Nodes rather > than global lights. Do you see any problems with that? > I don't have a need for this specific feature, but I'll just observe that this seems to suggest a global table of id numbers - you'll need to know what ids are currently in use since programmers will not expect id numbers for specific lights to change once they have coded the relationship. > Yours > > Dirk > > > Anthony Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
