migration from irrlicht 1.4.1 to 1.8.4

[CuteAlien]

Ehm, if it's tagged with 1.4.2 but different from that - no idea (I also was just a user back then). Sounds strange. Maybe you got 1.4.1?
But doesn't matter too much if you hit the exact same version - as long as you get the bug. Just get some version from around 4.6.2008 (1.4.1) or 22.9.2008 (1.4.2).

[kas1e]

Found it ! That was hard, but there is:

commit r1612 look (all fine, same code):




commit r1613 look (missed textures, shifted buildings, rotated zombies):



commit 1613 are "Fixed the handedness of the coord system" CMS3DMeshFileLoader.cpp

Now of course open question : is it fixed indeed, and its code of the game need to be adapted for "fixed" version. Or, its not fixed, but instead broke things.

[kas1e]

And the gulti lines, are those at top of commit, where they added "-" thing for last verticies. Once i comment them out, i.e. those:

Code: Select all

 
vertices[tmp].Vertex[2] = -vertices[tmp].Vertex[2];
 

and

Code: Select all

 
triangles[tmp].VertexNormals[0][2] = -triangles[tmp].VertexNormals[0][2];
triangles[tmp].VertexNormals[1][2] = -triangles[tmp].VertexNormals[1][2];
triangles[tmp].VertexNormals[2][2] = -triangles[tmp].VertexNormals[2][2];
 

Then rendering back to normal.

But not sure, is it game or irrlicht.. Maybe in game something didn't done which should be done, or done for "unfixed" ms3d loader, or, its just fix of ms3d loader not fix, but broke things.

[CuteAlien]

And the model looks OK when loaded in the meshviewer example? In that case check your code if you do some scaling by -1 after loading your meshes. Maybe you fixed it back then in code?

edit: I did a quick test with 2 ms3d models downloaded from the web. And both definitely got way worse when I changed those lines you mentioned. But I also notice that the animated model I found (some Zebra) looked wrong either way (textures where correct, but animation is messed up).
Problem now is that I don't know if it's just a broken model or a problem in Irrlicht. Guess I'll have to find and test a few more.
edit2: Found official viewer and Zebra looks fine there. So it seems texturing is correct, but animation is broken.

[kas1e]

You may try ms3d loader from r1612 (if i see it right, it can be just replaced over one from r5952 with no problems). And if there zebra will be fine, then yep , that it.

Btw, by animation messed up you mean going in wrong direction, like swapped + - , etc ?

edit: and interesting that that mesh of zombie i have, looks fine in 09.MeshViewer, but looks wrong (rotated) only in game. I.e. i can't rule out game's code too of course ..

[CuteAlien]

Yeah, I tried using that - but it's unfortunately not that simple because non of the make solution on Windows worked for me in a quick test (didn't investigate further why, but neither Makefile nor C::B worked out of the box, or even after some quick fixes I tried and the newest VS makefiles it had back then was VS 2008 which I have no longer installed). And I can't just replace the loader as since then the quaternions have changed so old ms3d loader can't just be replaced on it's own.

The bug I have doesn't seem to be about anything swapped. Thought that might be hard to see as textures in this model are pretty symetric (at least left-right). Actually it seems the skeleton is even correct. It looks to me like what's broken in my test is that too many vertices are affected by one of the bones in the skeleton, so to me it looks like a bug in when reading the weight-painting.

So not related to your bugs I think.

[CuteAlien]

The bug in my test-model is from r3221 where weight-loading was changed.
Basically this model needs a weightFactor=1.f/100.f; instead of weightFactor=1.f/255.f;
But I guess Hybrid had a model where it was other way round as changed this.
And while looking at it - the code there looks very different in official reader for subVersion 2... which seems to need to read more dat or it will be completely wrong.

Seems this is another todo which isn't really a quick thing to fix on the side :-( Model formats are really tricky when you don't have a bunch of good test-models (or can create your own). Basically - I could fix it now for my case easily - but that would probably break the other case for which this fix was added. And I have no clue what is correct on a quick view.

But none of this looks like your bug (edit: But looks a lot like you worked around an Irrlicht bug in 1.4 somehow and your workaround should be removed now as Irrlicht seems to work more correct there now).

[kas1e]

Then probably for just that game i can build irrlicht with "fixed for that game" ms3dloader and be done with it

[CuteAlien]

Sure, if it works it works :-) But take a look if you see some strange setScale call with -1 in parameters. Either for mesh or for model. Something like that should have been needed to get it working in the past. Or maybe call scale() or scaleMesh() using IMeshManipulator. Or a transform call with a specific matrix. Makes it usually easier in the long run fixing things in a correct way.

[kas1e]

@CuteAlien
I made a mix of previous ms3d loader (that one which works before fix we discuss lately) and some old version of irrlicht (r2000) , which is 1) fast 2) have no bugs mostly.

But now i have found some strange issue . It happens for example in r4000 and in latest (at least 3 days old) trunk. Issue, is that my fps person is just fall down under the ground

See that on the video: https://youtu.be/GHA3vCI2gdk

In irrlicht 1.8.4 there is no such bug (which i do not know what revision is, as its looks like that separate releases differes with trunk revision numbers)

Have any ideas ?:) I was thinking before that its only about trunk's code, but probabaly r4000 is muuuuhc more older. So it can be that the same issue arise 2 times, one time back in past and on time in trunk now (at least as i say in 3days old trunk).

[CuteAlien]

Maybe something with collisions change. I really don't know too much about older changes.
I guess you are using createCollisionResponseAnimator? So first check if you have that call, maybe it wasn't needed in the past or so.
Next guess would be that your floor has no collisions. So check the mesh you pass to createCollisionResponseAnimator - if it is non-null.

Tiny side-note: If you use fps-camera from Irrlicht, I just checked-in several fixes in svn trunk. The version in 1.8 kinda works... but it's far worse. So if you go with 1.8 it might still be worth copying over newest CSceneNodeAnimatorCameraFPS code from trunk. And I totally don't say that because I want another person testing all my new changes ... *looksaway* (seriousy, 1.8 ignored all kind of mouse movements, rotation was bad!).

edit: I remember I made a few fixes in collision system since 1.8. But don't expect that to break anything. But without test-case it's always tricky :-/

[kas1e]

Ok, will do all the tests today with latest trunk.

Strangly that this issues comeup with r4000, then seems so disappear till 1.8.4, and then again come back in trunk.

Will write all findings back

[CuteAlien]

I didn't fix this one. This really sounds like a collision problem. I only fixed camera-rotation.

[kas1e]

I think that floor should have collision : because if not, it should not work in 1.8.4 (as well as in 1.4 / 1.5 / etc).

Also checked if i had createCollisionResponseAnimator() call : yeah, i have it all over the place like ISceneNodeAnimatorCollisionResponse* anim = m_pGame->getSmgr()->createCollisionResponseAnimator( blbllalbalba ), etc. So game use those calls for sure.

As for test case .. yeah , that for sure hard.. I may try to go usuall way by checking revision per revision till find out what commit broke it.

Is r4000 are previous to 1.8.4 release, or, its all independent and you can't say so ? I mean, with 1.4.2 i can't find what exactly revision was used for. Same for 1.8.4 now. If r4000 is before 1.8.4 release, then indeed something was broken 2 times. If it past 1.8.4 release, then no surprise it broken in trunk as it still one same bug happens after 1.8.4. But need to know if r4000 are past or pre 1.8.4

[CuteAlien]

I think Irrlicht 1.8 was probably r4344 (at least that's the last commit before the release date I see in changes.txt).
Note that most later changes didn't go in 1.8 even when there were a few more 1.8 releases. Main development branch isn't back-ported to 1.8, only other way round (all 1.8 fixes get into trunk).

About collisions. I think there had been some bugs with IMetaTriangleSelector. But those should be fixed by now.
It's often simple to create a test-case by adapting some example or the demo. Like replacing the model there with your own and maybe setting 1-2 positions.