Obj loader coordinate sytem fix

[rutom]

Hi,

I have realized that the .obj format uses the same coordinate system as OpenGL: X goes right, Y goes up, Z comes out of the screen. I have seen that in the obj loader there is a flipping on the X coordinate to switch from the right handed Wavefront coordinate system to the left handed Irrlicht system. I think it is not enough, we need to rotate the coordinate system about the X axis by 90°.

So I propose the following change:

irrlicht-1.8.2/source/Irrlicht/COBJMeshFileLoader.cpp

Old

const c8* COBJMeshFileLoader::readVec3(const c8* bufPtr, core::vector3df& vec, const c8* const bufEnd)
{
const u32 WORD_BUFFER_LENGTH = 256;
c8 wordBuffer[WORD_BUFFER_LENGTH];

bufPtr = goAndCopyNextWord(wordBuffer, bufPtr, WORD_BUFFER_LENGTH, bufEnd);
vec.X=-core::fast_atof(wordBuffer); // change handedness
bufPtr = goAndCopyNextWord(wordBuffer, bufPtr, WORD_BUFFER_LENGTH, bufEnd);
vec.Y=core::fast_atof(wordBuffer);
bufPtr = goAndCopyNextWord(wordBuffer, bufPtr, WORD_BUFFER_LENGTH, bufEnd);
vec.Z=core::fast_atof(wordBuffer);
return bufPtr;
}

New

const c8* COBJMeshFileLoader::readVec3(const c8* bufPtr, core::vector3df& vec, const c8* const bufEnd)
{
const u32 WORD_BUFFER_LENGTH = 256;
c8 wordBuffer[WORD_BUFFER_LENGTH];

bufPtr = goAndCopyNextWord(wordBuffer, bufPtr, WORD_BUFFER_LENGTH, bufEnd);
vec.X=-core::fast_atof(wordBuffer); // change handedness
bufPtr = goAndCopyNextWord(wordBuffer, bufPtr, WORD_BUFFER_LENGTH, bufEnd);
vec.Z=core::fast_atof(wordBuffer);
bufPtr = goAndCopyNextWord(wordBuffer, bufPtr, WORD_BUFFER_LENGTH, bufEnd);
vec.Y=-core::fast_atof(wordBuffer);
return bufPtr;
}

[CuteAlien]

The old code is used _a lot_. So changing it would break all existing project using it. Can't do that without a really good reason.

I must admit I'm not even certain how this really should be handled or if there is a correct solution. I mean x to -x already feels somewhat wrong as it's not the coordinates which should change but the interpretation of what they mean (aka the camera system). So I always wonder if that should be done internally or rather a explicit command or a parameter on load. It might maybe make sense to add a feature to loaders to modify objects coordinate systems on loading. Thought you can do that stuff also after loading by modifying the mesh itself. So we can do that in 2 steps already.

Additional flipping axes - that would be a even stranger hack. Thought if we make it a parameter on loading it would make sense adding that as well. But it's again only about the interpretation of the data and there isn't even a rule in Irrlicht which axis for the camera is up. Most people might use Y up that is used in the examples. But you can use Z up if you prefer that. Unlike with the handedness you don't need another camera there - existing cameras can do that. Otherwise just rotate your obj files after loading it the ones you get from your modeler are orientated to a different camera.

I doubt all Irrlicht loaders & writers really have a standard behavior for this. I suppose one really should document what exactly they do and then go over all loaders and writers and standardize them. But who's going to do that? I don't even have test-models for half the formats Irrlicht claims to support :-/

[rutom]

OK, I see.

You are right, all coordinate system definitions are just matter of taste. However I find it a bit awkward, that many(most?) of the systems use right handed coordinate system (OpenGL, DirectX), but not Irrlicht. I guess this has some historical background.

[hendu]

DX is left-handed, unless that has changed very recently.

[CuteAlien]

Yeah, I guess that is also the historical background - Irrlicht probably was developed for D3D first (some more places in the code hint at that).

[chronologicaldot]

... there isn't even a rule in Irrlicht which axis for the camera is up. Most people might use Y up that is used in the examples. But you can use Z up if you prefer that.

I wondered about that. I use the Y axis since that's the way both of the default cameras (FPS and Maya) are set to use, and it makes sense from a GUI-to-3D standpoint (at least for me).