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. -- +---------------------+----------------------------+ | VREC GmbH | | | Matthias Stiller | | | Robert-Bosch-Str. 7 | tel: +49 6151 4921034 | | 64293 Darmstadt | web: http://www.vrec.de | | Germany | mail: [EMAIL PROTECTED] | +---------------------+----------------------------+ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
