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?
> 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?
Yours
Dirk
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
