Hi Matthias,

True. I was thinking of this as an alternative to what we have 
currently. You could perhaps think of different types of LightsChunk's 
that has different behaviour, some which use traversal data for scoping 
and other which allow more direct manipulation of active lights. 
However, that may just add complexity and confusion instead.

I'm just not sure there is a single way of doing this to everyones 
satisfaction.

Cheers,
/Marcus

Matthias Stiller wrote:
> Hi Marcus,
> 
> I prefer not to attach lighting information on material basis, this 
> would mean that the number of materials will expand very quickly making 
> it harder to expose to the enduser of an application (users tend to 
> understand a light as an entity and not a subpart of a material). 
> Instead I would opt for the current behaviour or something like states 
> that can be "attached" anywhere in the scenegraph and finally collected 
> by the render traversal. For example it could be useful to enable 
> wireframe rendering somewhere in the tree as well as controling 
> lighting. I think this has been already discussed by the coreteam, but 
> I am not sure what the final conclusion was.
> 
> About global light sources I tend to disagree with the current solution. 
> Of course I understand Dirk's reasoning, but dealing with importing 
> other systems files one has to reorder the scenegraph and sometimes it 
> is not possible to achieve a 1:1 mapping. A flag indicating if a light 
> is local/global would be a nice option for me as an application 
> developer.
> 
> Regards
> 
> Matthias
> 
>> Just to toss an idea:
>>
>> I've previously worked with commercial scene graph which required the
>> user to attach the light to each lit geometry. (The light-node's
>> position was used as light position). Could that be folded into a
>> "LightsChunk" (or whatever you may call it) that would keep a list of
>> lights to be applied, this moving it into the material?
>>
>> This is not at all what you do today though.
> 
> 



_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to