Does anyone know why a meshBuffer that rendered in 1.8.5 is would be broken in 1.9?

[n00bc0de]

I was having issues with my anim8or import recently which I couldn't explain but then I tried to run it again in 1.8.5 and it works. Its not crashing in 1.9 but nothing gets rendered. Was there a change in the rendering backend that I need to consider?

For reference, this is the anim8or parser repo: https://github.com/n00b87/an8-parser/tr ... cht_loader

The main.cpp file should just be able to build and run if you have irrlicht setup. If you build it in 1.8.5 then everything renders fine but 1.9 nothing shows up.

[CuteAlien]

Nothing should stop rendering, but lots of things changed in the material, mesh and node systems since 1.8, so always possible we broke something no none noticed yet.

I've done a quick check. First tiny note: You load test5 which is not in the repository. And your load function hangs in that case.
Switching to test4 I can reproduce it works in 1.8 and not in trunk. Can't spend more time on it right now, but on first look it seems the boundingbox isn't set in the mesh. Maybe force a recalculation, skinmeshbuffer has some function to force another recalculation I think.

[n00bc0de]

Thanks for looking at it. I tried the bounding box recalculation on the mesh buffer and it didn't do anything. I will try to look at some of the other loaders to see what they are doing that I am not.

[CuteAlien]

OK, I can also check in the evening what's different, that was just the first thing I noticed with a little debugging.

[n00bc0de]

Thanks. I have tried a lot of stuff with the mesh buffer so far and still can't figure out whats wrong. Maybe its not the mesh buffer but something else. Is there a change log with all the changes that have been made since the last stable release?

[n00bc0de]

@CuteAlien Ok. After some more digging, I have determined that it definitely is the mesh buffer.

I ran this code after creating the scene node on both 1.8.5 and 1.9:

Code: Select all

for(int i = 2; i < node->getMesh()->getMeshBuffer(0)->getIndexCount(); i+=3)
{
	irr::u16 t1 = node->getMesh()->getMeshBuffer(0)->getIndices()[i-2];
	irr::u16 t2 = node->getMesh()->getMeshBuffer(0)->getIndices()[i-1];
	irr::u16 t3 = node->getMesh()->getMeshBuffer(0)->getIndices()[i];


	irr::video::S3DVertex* vertices = (irr::video::S3DVertex*)node->getMesh()->getMeshBuffer(0)->getVertices();

	irr::video::S3DVertex v1 = vertices[t1];
	irr::video::S3DVertex v2 = vertices[t2];
	irr::video::S3DVertex v3 = vertices[t3];

	std::cout << "Tri: " << "( " << v1.Pos.X << ", " << v1.Pos.Y << ", " << v1.Pos.Z << " ) "
						 << "( " << v2.Pos.X << ", " << v2.Pos.Y << ", " << v2.Pos.Z << " ) "
						 << "( " << v3.Pos.X << ", " << v3.Pos.Y << ", " << v3.Pos.Z << " ) "
						 << std::endl;
}

On 1.8.5, it outputs the vertices but on 1.9 it outputs "nan". Do you have a clue of what could cause this?

[CuteAlien]

I can tell you where it comes from, but I've still got to think about what it means. There was a change in r5378 (and some later changes, but that was the one breaking this) which optimized quaternion::getMatrix. New calculation is faster - but assumes the quaternion is normalized first. So it normalizes it.

Problem here is: The quaternion you deliver can't be normalized as all values are 0. Old solution resulted in a identity matrix which more or less makes sense. Then again ... setting all values to 0 in a quaternion should usually not be done. You are no longer describing a rotation that way. So hard to tell what it really means.

I could make the function slower again (have to see if it really makes a difference) - but also you shouldn't ever set 0,0,0,0 as rotation, something is going wrong there on your side as well.

[n00bc0de]

My loader was just reading values from the anim8or file without checking whether the quaternions are valid. Its an easy fix though.

I actually was starting to think it was either matrices or quaternions from the test I was doing as well. I would rather just fix my code to use the faster quaternions. I think if I crunch I can have it changed in a couple hours or so.

Thanks for your help with this.