3DS Loader does not smooth mesh normals?

[thomascheah]

Hi,

I remembered this is posted somewhere else, but I am not sure what is the outcome or solution at the end of that thread. If there is already a solution, I apologize for double posting. Appreciate if someone can point me to the thread with solution.

Anyway, I noticed that the 3DS Loader in Irrlicht does not smooth the mesh normal as most 3D application like Milkshape.

Below is the screenshot for two similar mesh object saved in two different file formats.



As you can see, the .3DS mesh looks faceted while its .X counterpart looks smooth. I am not sure whether this is a bug in Irrlicht, as I notice that it does not only ignore the smoothing information in 3DS file, but also unweld its vertices as the mesh is loaded. The sphere has 89 unique vertices as shown in Milkshape model info. When I try to get the vertex count in Irrlicht, it contains 360 vertices = 120 triangles * 3 vertices per triangle. This seems perfectly logical initially. But on a second thought, it also implies that now the normal of each vertex of each triangle has the same direction where the triangle is facing (in fact, all normals of a triangle will have the same direction), and thus explains the faceted shading above. I know in most 3D engine, the normal of a vertex that is shared among triangles are usually averaged out to produce a smooth shading across triangles.

The following url contains the actual model that I used for testing this. Feel free to test it out.

http://www.objectiveworld.com/tmp/sphere.zip

I am not sure if there is any workaround on this? I tried using RecalculateNormals with smoothing on, it does not improve anything. On examining the implementation of RecalculateNormals, it does average the normals of every vertex. I think the main reason why it does not produce any effect is because 3DS loader in Irrlicht unweld the vertices as the mesh get loaded, and there won't be any shared vertices, i.e. if a vertex is shared by 3 triangles, it will unweld become 3 vertices of the same value by the loader, and thus the RecalculateNormals won't able to average out the normal with other triangles that shared the same vertex normal.

Any ideas how can I get around with this?

[hybrid]

Hmm, I don't recall the exact vertex handling, but I don't think that I changed too much there from the initial implementation. But it might be worth looking into it. However, smoothing groups are somewhat more difficult as they are related to the grouping that 3ds uses. And that's not really nice to implement. However, using the smoothing method might work if we can fix the vertex count somehow.

[vermeer]

hmm...some comments:

- *.3ds has too many problems, tho I understand some tools only export to that. One of the biggest, is...Whenever it finds a shared UV point, it will break the mesh, unweld vertices, there were a vertice has 2 UV pairs. I checke for example, in your sphere, in several viewers easily seen the seamn there where the borders-limits are....

-Your sphere shows in 2 of my tools like 27 or 30 unwelded vertices(edit-- could be just the seam in Uvs limit! ). This happens so often with exporters, specially with *.3ds, that rarely is user's fault. Of course, in this case, wouldnt be irrlicht either.
An unwelded vertice is what happens in the UV islands seam : mesh broken will not be able to have continuous smoothing there, no matter the smoothing setting. If the sphere gets unwelded in every vertex, avery face, looks like all flattened faces. Is possible that irrlicht finds 27 unwelded vertices, and then cant only but break all mesh. This happened in several 3d tools importers.

-In my tools, the mesh looked like to have some more extra errors, but I havent dedicated the time to check. Of course, I am not saying this all for sure, but am 95% certain.

-for the weld of vertices, in Milkshape: if I remember well, menu Vertex, "Weld together", and then export. can be the particular ms3d 3ds exporter.

- grab this sphere, I think this one I made does not have unwelded vertices more than the ones in the pure seam of UVs (worse uvs, as I didnt take the time to do good ones. The seam must show in normals acrross the middle edgeloop.)
http://www.filesend.net/download.php?f= ... ea2330b0da
So you can use for tests. If it's show all broken, I'd be more sure than is irrlicht problem, as this one imo hasnt got unwelded vertices.

-Some tools do this, when find an unwelded vertex, break it all, others, just wont even load, others, just smooth it all whatever it is (no good for error caching )


edit-- hummm...well, now I am not sure...your sphere could be ok...anyway, there's some thoughts above and an extra sample for you two.

[thomascheah]

I think the main problem is caused by the 3DS loader in Irrlicht unwelds the vertices as the mesh gets loaded. Either that, OR 3DS file itself stored vertices in its unwelded form. I think most likely is the former, since when I view the sphere mesh above in Deep Exploration (a 3D model viewer program), the number of vertices reported by the program is exactly 89, which is the number of unique (welded) vertices in the mesh.

I guess one way to work on this problem is to implement smoothing in the 3DS loader. Simillar as how RecalculateNormal in IMeshManipulator works, each vertex normal is averaged against vertex normals of other triangles that has the same vertex position. I am not sure how complex it will be, but I might give my best attempt to modify the 3DS loader to incorporate this feature. (Appreciate if anyone, especially Hybrid, can point me to the right direction and provide me some heads up on the possible gotchas that I might encounter.)

However, I am wondering whether it will produce anomaly on certain meshes, for instance, imagine a mesh that consist of two planar objects that have an edge connect to each other to make a V shape. In this case, smoothing of normals might be undesirable as it will produce a smooth gradient at the connecting edge.

More comments are welcomed!

[greenya]

OR 3DS file itself stored vertices in its unwelded form

If it would be trues -- 3dsmax will not be able to import own 3ds files with smoothed faces -- but it does it successful.

[vermeer]

Actually...if you do that after loading the 3ds, maybe happens that. But the 3ds file itself cant bring shared uvs seams as continuous in smoothing, so, one tip would be use hard edges as limits of the big UV areas.

In blender, as there's no smoothing groups (real ones) yet, trick (is what autosmooth does, I think) is to separate, break the mesh. Like with 3ds shared UVs edges, there will be seen a crease.

Imo, is better to export as OBJ or other thing than 3ds, tho...

Anyway, I am not a coder, but if you really , really need *.3ds, maybe that solution of applying the normals after the mesh has been imported... Maybe grab by import the smooth groups chunks of faces (in an OBj this would be way simpler, is a ascii file, can be parsed even by a brainless artist like with vb, even... ) , and then apply smoothing/creases in irrlicht depending on this info.

But imo, as OBJ already ports all this info, seems quite eaiser just use that one.

Only thing is if you are using *.3ds for it can carry camera and animation -I think even lights-

I'm frankly unsure now if OBJ comes now native in Max 8, (if not, the really should add it, and solid per once, as the free ones available have problems) , if not, u can grab the free one from habware.at.

I've heard of other engine, where they'd load this problematic files -md3, not 3ds in that case- and by code solved the creases prob...

[vermeer]

However, I am wondering whether it will produce anomaly on certain meshes, for instance, imagine a mesh that consist of two planar objects that have an edge connect to each other to make a V shape. In this case, smoothing of normals might be undesirable as it will produce a smooth gradient at the connecting edge.

Artist side, there are two ways for the artist to specify which edges he/she wants smooth, which hard.

One, manually, which has two variants, my prefered one is Wings/maya aproach (select you edges, hit the Key for hard. That's it.) The Max/Milkshape variant is selecting faces, which form so a sort of big chunk, and the border will be hard. Somewhat slower proccess imo.

The is also an automatic way, also available in max, wings, maya, (and a sort of workaround in blender) , is set an angle threshold, all will be smooth if is not sharper angle than that angle threshold specified. ie, an autosmooth of 60º. One of 60 - 45 or so, use to be good for statics, levels, one of 60 -75, even 90, better for organic stuff.

If the artist can only count on this, well, is better than nothing, and provided he models so to make things look cool with certain autosmooth threshold, then, irrlicht shoul show models 1:1 , as is same threshold.
The loader should just take that threshold value from the mesh for a comfortable workflow.

But taking hard edges or smooth groups as they come, no autosmooth threshold, is quite more powerful: that is, more accurate, and more control/quality for the artist.

BTW, there's an internal stuff I never end to understand well(not that i really care;) ): the difference between vertex normals and smooth groups, internally. The fact for the artist is...usually most packages export vertex normals (which as well show as is in artist packages) , few treat or export smooth groups (Max and MS3d do)

I often end up having porting problems of smooth groups, but rarelly vertex normals give a prob...

Md5 format support vertex normals, and max does export well them. Yet tho, yup , is a format for characters. And plugin is not dumb easy to use, but way easier than x one.

[robmar]

Irrlicht 1.7.2 still has the same problem with meshes not being smoothed in 3DS format. Obj meshes are fine, but they are 3 times the size.

Anyone any info on loading 3DS meshes with smoothing?

[hybrid]

There's a patch on the tracker, but it's not mature enough for inclusion to the engine. Don't know if we will add it anytime soon. Just zip the obj files if you have problems with download sizes.

[robmar]

Thanks for that. Its more the load speed durring runtime, if there are 80 reasonably detailed meshes to load, then its a hundred megabytes or more data to process than if they were in binary 3ds format.

[hybrid]

Can't you use any of the other binary formats for Irrlicht? Static meshes will probably load merely the same with every format, and just differ in loading time and file size.

[robmar]

You mean b3d, md2 or md3?

[fmx]

Try .OBJ format first and see what results you get

[robmar]

Being using that for months, big bulky text files up to 80 MB whereas binary formats are under 20 MB for same mesh. Loading these large files causes long delays between changing scenes. I guess I could make intek happy and buy an i7, but I´m trying to make the code run blitz-schnell!

[Mel]

Compress the OBJ file inside a Zip