Hi Carsten,
Well, my application would be more or less like a 3D editor (with the goal
of feeding some photorealistic renderer). Users would be able to
activate/deactivate lights selectively for any objects to achieve the
desired result (although the default behavior would be global lights). This
wouldn't reflect how lights work in reallife, but instead simply provide a
mechanism to achieve desired effect.
Another application to selective lights is when you have manipulators
(translation arrows for instance) attached to an object, which could have
specific lighting needs, to always be visible, yet be attached as a child to
the geometry they control.
Does this make sense?
Thank you,
Raphael
On Thu, Jul 30, 2009 at 4:11 PM, Carsten Neumann <[email protected]>wrote:
> Hello Raphael,
>
> Raphael Sebbe wrote:
> > I have one problem though, it seems to be a constraint imposed by the
> > scene graph.
> >
> > Let's say I want to represent a scene where objects can be selectively
> > lit by lights, that is I can enable a light or disable a light for any
> > particular object. It seems that this cannot be easily expressed in
> > opensg. However this is a fairly common problem.
>
> hm, can you let us know a bit about the context in which you need this
> feature?
>
> > The problem is because objects that are lit by a light must have that
> > light as parent. More over, opensg imposes that a node can only have one
> > parent. This is a very hard constraint, especially considering that both
> > transforms and light states are expressed through that single parenting
> > capability.
>
> it's true that a Node can only have one parent, but a NodeCore (which is
> what defines the behaviour of a Node) can have many; Light is a
> NodeCore. Also the position of the light source is not defined by its
> position in the scene graph, but rather by the coordinate system of its
> beacon node.
> OTOH multi parent scenegraph's have the IMHO very confusing property
> that you can not determine a node's location in the world (unless you
> visit that node as part of a traversal from a root), because there are
> multiple paths to (potentially) multiple roots...
>
> > (I am talking about local lights, global light can't be disabled for
> > objects as far as I understand it)
>
> no, and the idea for OpenSG has always been that lights affect their
> children and are positioned in the scene with their beacon. The fact
> that OpenSG 1.x also has global lights is more a historical
> implementation issue with the local lights than intention.
>
> > The only solution I can see is to duplicate local lights all over the
> > graph, but this is tedious and not elegant solution to a simple lighting
> > need.
>
> hm, I'm not sure I'd agree that you have simple lighting needs, but ok
> ;) - you are right, I can't think of another way to do this other than
> adding the Light NodeCore to multiple Nodes in the scene.
>
> > Have you guys thought of other possible implementation of lights, that
> > would be more like "attribute" that can be turned on/off through the
> > graph traversal?
>
> Speaking only for myself, I've not thought about it, but I'd be willing
> to if you give us some more details on your use case; I'm afraid I've
> not quite understood that yet:
> Why do you want to light one object and not another one even though they
> are close to each other (assuming that being children of a common object
> suggests spatial proximity)? This does not seem to mirror the effect of
> lights in the real world. I guess I'm missing something important. ;)
>
> Cheers,
> Carsten
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Opensg-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users