You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Ok, as announced in a thread in the beginner's forum I have fixed some of the most annoying 3ds loader bugs:
Transparent materials
Vertex colors (No need to use small textures to imitate flat coloring)
Shininess
Some Shading flags such as Wireframe and Gouraud shading are recognized
I will also include the bug with missing faces into my patch (which was correctly reported several times the last weeks. Note that the bug fix seems to be nonsense, because the indices count would have to be divided by three. But the actual number stored in the variable is the face num, so no need to divide).
I will post the bug fixes tomorrow when I have the source code online. But I've tested it and it really works. Lights still to come, though. And many other things, too.
Ok, the patch is available at http://parsys.informatik.uni-oldenburg. ... d/irrlicht
I have included a simple change previously found in Loader.patch so expect some warning if you have applied Loader.patch before. I am still not really sure about the indices ordering and similar things. But if enough people are testing their 3ds models with the new loader it might be enough to fix all open problems.
I have included the fix from http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=10920 which is the previously mentioned Index/Face bug. In order to clearly state the semantics of the variable I have renamed it from CountIndices to CountFaces.
Many things for 3ds still unsolved, so lots of work to do.
Forgot to mention the screenshot for transparent materials:
If you have some files which are still not rendered correctly (but Irrlicht has the general capabilities to do it) please publish example models such that I can have a look at them. And don't forget to add a screenshot such that I will know how it should look like (also mention the program you got the screenshot from, some tools might render differently).
BTW: Does anyone know a good description of the 3ds file format which also explains semantics of the values? I have only syntax descriptions and it's sometimes hard to map from 3ds naming to Irrlicht naming. At least for me, knowing almost nothing about 3d rendering.
I have fixed another bug which made most 3ds files unloadable. It was a strange (and not officially supported) version number contained in the file. So I have added a one line fix to accept also this version chunk.
Now most of the 3ds files from 3dcafe I have tested are working. Unfortunately I found some files which have inverted face normals such that only back faces are rendered. Does anyone know about a flag or a 3ds file version which uses a different orientation?
Some more fixes for 3ds are available in the latest patch version. Most importantly the texture loading has been fixed for files with more than one texture per material (e.g. for bump mapping). Previous versions of the loader just used the latest file name stored in the material, which is usually the secondary texture such that no correct texturing could be achieved. This is now fixed, and moreover bump mapping and reflection materials are also implemented. I could not test them, yet, due to lack of appropriate input files.
Second, I changed the ambient color storage from emissive to ambient which seems to fit better (though also not tested, see above )
I have found a rather complex model with advanced materials included, which is not textured at all in Irrlicht. I don't know why or how, so if anyone could give some hints I'd really appreciate. More on this problem can be found here http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=12433
Ok, I found some more problems. Irrlicht is currently ignoring the local transformation matrix which is stored with each object in 3ds. This is ok for simple and old models, since they usually have the identity matrix stored, but not for more advanced models and newer ones. It rather looks like an 'explode view' if you have such models, sometimes only some parts are misplaced or similar weird things.
I have added the loading part right now, but I don't know how to handle this matrix. At least all my tries have failed up to now. My procedure is the following: read the matrix and store 3 rows for rotation and one for translation in a matrix4 (i.e. right most column is empty). Then, for each vertex of the meshbuffer do matrix.transformVect(vertex) before adding the vertex to the buffer. But the output is as weird as before.
Anyone who knows how to handle these matrices correctly
I'm going from memory here... The mesh matrix that is in the file is local to world. There is also node heirarchy in the file. Each node has a relative position, rotation and scale from its parent node. There is also a pivot point. That pivot could be causing your problems.
You might have a look at lib3ds. It is an open source project for parsing 3ds files.
No, I don't think that 3ds has an object hierarchy. According to the documentation all vertices have world coordinates. But the documentation also says that the matrix is only used for the keyframe animations. Darn! This means that all vertices should be correctly placed by default
I wll keep on experimenting with these values, I guess. Maybe lib3ds will help, too. I just checked out their cvs version this afternoon as the latest release is several years old and lacks several chunks. Thanks Travis!
Hmm, maybe you're right in the end The keyframe area has all these elements you mentioned. But I thought that these things are only required for animations. Or maybe also to calculate the inital positions? lib3ds is no help here, it just takes the positions from the vertex list. Just as Irrlicht.
So maybe I have to start on this animation thing
No, I'm not talking about keyframe data. That is just for animation. You don't need to do anything with keyframe data for static meshes.
The 3ds file format supports heirarchy. You will see this once you start looking at the code or at lib3ds. There are several different node types [object, camera, light, ...]. Each node type has an offset, scale and rotation as well as a pivot offset. You actually need to walk the node heirarchy and build up the node matrices. The trimesh object type contains a mesh which also contains a matrix. A composite node matrix and the mesh matrix are not necessarily the same.
It might be easiest to build an external mesh loader that used lib3ds to parse and read the 3ds file. :)
All this information is below the KFDATA chunk which holds the keyframe data. All other data does not use hierarchy or relations between the nodes at all.
lib3ds does not use the information parsed from the file to calculate a new position or anything else. It is purely a parser without any additional postprocessing. Thus, it won't help. I'll need a 3ds viewer which is both open source and capable of visualizing these enhanced meshes. The problem is that really no semantics of the file is given anywhere. Just the syntax. Everything else has to be found just by experimenting as it seems.
Whoops. I was wrong... I got to looking at the code and the values I mentioned [except the pivot] are all derived from the keyframe data.
As for needing examples, lib3ds supplies several. Those examples can be used to figure out what is going on. You can find the 3ds2rib converter source here. It also comes with an OpenGL based 3ds viewer. The source code for that is here.
Yes! This should help. I really missed this player thing completely. It works perfectly (i.e. displays the meshes correctly). And browsing the source it seems to use the keyframe data and set up all elements there. So I will dig into them and see how much work it will be to position all nodes correctly. And when I'm done with it it should be not too hard to even add animations, I hope. But first for correct static meshes Thanks a lot Travis!
Ok, I can confirm that hierarchy and relative positioning is both required to display 3ds objects correctly and part of the keyframe data. All hierarchical objects have at least the main keyframe (probably all objects have it, but if non-hierarchical this does not matter). All 3ds files I have tested yet are non-animated, but have one keyframe...
In order to display the objects correctly, this hierarchy has to be built and used upon object construction. Right now I have only parsed out the values, but did not integrate with the object construction. So not very useful, and thus not published. If anyone wants to help out on this topic I can send the latest patch file by mail. Please contact me via the patch page.
)
The keyframe area has all these elements you mentioned. But I thought that these things are only required for animations. Or maybe also to calculate the inital positions? lib3ds is no help here, it just takes the positions from the vertex list. Just as Irrlicht.
Thanks a lot Travis!