thius sounds suspicious to me. Maybe we mixed up the way how to import lights a little bit in some importers. 

From my point of view we should use the transformation of the node and use the light position parameter relative to the node. Everything else is a bug. Or have I misunderstand anything here ( to the other AssImp-Developers )?


On Wed, Apr 9, 2014 at 1:45 PM, Sergio Acereda <sacereda@brainstorm.es> wrote:

I'm having some problems understanding how to proceed reading light
structure from assimp. I understand every transformation can be found in
nodes hierarchy, and , theorically, every light have some local
parameters relative to the corresponding node in the hierarchy:


In directional lights, I find 3ds parser placing same translation
information both in hierarchy node and light->mPosition, duplicating
this displacement,but hierarchy node don't have rotation parameters.
This is placed in mdirection parameter.

Now, if I move to a spot light, it happens the same thing,but now
mdirection is placed as well.

In light.h,it says mposition and mdirection are relative to the
transformation of the node corresponding to the light.

On the other hand, in 3DSLoader.cpp:ParseChunk, reads as follow:
// Cameras or lights define their transformation in their parent node
and in the
// corresponding light or camera chunks. However, we read and process
the latter
// to to be able to return valid cameras/lights even if no scenegraph is

aren't these statements contradicting each other?

So, how should I proceed when importing lights with assimp?

Thanks in advance,

Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
Assimp-discussions mailing list