Thoughts about exporters/importers of an .obj file

Blitz3D Forums/Blitz3D Beginners Area/Thoughts about exporters/importers of an .obj file

RemiD(Posted 2012) [#1]
Hi, :)

I am currently trying to understand how to code an exporter/importer of an .obj file for Blitz3d.

I have tried to export a simple cube with several groups and several materials from the softwares :
Anim8or
Wings3d
Fragmotion
Blender

Each time, i have assigned exactly some tris to the same groups, and others tris to the same materials.

However when i open the different .obj files with notepad i don't see consistent datas from one .obj file to another.

The .obj files exported with Fragmotion and Anim8or have 8 vertices and 12 faces, which corresponds to a cube.

The .obj files exported with Wings3d and Blender have 8 vertices but only 6 faces... But there are 4 vertex indexes for each face so i guess it refers to quads...

The groups and materials seems to be exported correctly by Fragmotion but not by Anim8or and i don't know for the 2 others.

Moreover the datas are not written in the same order, sometimes the materials lines and the groups lines are before and near the faces lines (which makes the faces their childs), sometimes no.

I thought a file format had rules but it seems each .obj file seems to be different from one exporter to another.

That's not a problem for me because i only need to have an .obj importer that imports an .obj file exported with Fragmotion and the export seems to be clean so that's ok.

But i have difficulty to understand how the programmers of modeling softwares manage to retrieve the correct datas from a mesh file that has no clear rules.
Retrieving the vertices and the faces seems easy enough, but retrieving the faces associated to a specific material or to a specific group is difficult or impossible if the lines are put in such a random order.

I guess that's why it is rarely possible to work with several softwares without breaking a mesh.

Last edited 2012


Yasha(Posted 2012) [#2]
I think the important thing here is to recognise the difference between "import/export" and "load/save".

Importing or exporting is generally understood to mean saving to something other than the program's native data format. In other words, to export, the data must be converted out of whatever format it's in while the program works on it, then written to disk. To import, the data must be read, then converted to the internal format. In contrast, loading and saving (e.g. writing a .wings file with Wings3D) normally implies no conversion - the data will be written in pretty much the same form as the program uses it.

Why is this important? Because it hides the fact that the different internal formats may have different things they can easily represent, and because of this some data may not be converted symmetrically, resulting in the same thing at the end of the process as there was at the start.

What we can guess from these results is that the .obj file can represent faces with more than three sides if desired. However, since Fragmotion uses the B3D engine (if I recall correctly), we know that its internal data format will never produce a four-sided polygon. Since .obj is flexible on the issue, it just writes triangles as one might expect of a conventional mesh. Meanwhile, Wings3D has a similar "winged edge" rule with its internal data structures meaning its polygons can have a large number of vertices; so it probably writes its face information more directly and outputs quads, because internally in the Wings engine, the cube really was represented by quads. If you load that exported Wings cube into a B3D engine editor like Fragmotion, it will be made up of triangles even if the exported file describes it in terms of quads, because the importer has to convert it to the internal triangle representation.

In other words, even though the models look the same onscreen, their different internal representation when loaded in the editor means that really, a very slightly different model is being exported, and therefore it is actually logical that differences in the file should accumulate.

The issue with materials and groups is probably closer to an error: most mesh formats have something like these but they all differ in much more substantial ways than vertices and triangles which usually mean more or less the same things from engine to engine. This data will be corrupted on re-exporting if the engine it's in in between doesn't have a direct equivalent to the concept of a group or material. Many don't, and remember the "import/export" distinction (from load/save) means that an editor has no responsibility to preserve data it can't immediately understand - which answers your question about retrieving correct data: often, they don't, and can't because that data simply can't be read... and then ceases to exist to be re-exported.


Overall, my own advice is to not use .obj if you can avoid it. It's not designed for 1) work with the B3D engine, 2) use as a transfer format, or 3) support for B3D features. Data will be lost, and many things cannot be represented accurately. Fragmotion exports .b3d files... why not use those?


RemiD(Posted 2012) [#3]

Fragmotion exports .b3d files... why not use those?



Because the import/export of .obj files with Fragmotion produces clean .obj files, but the export of .b3d files with Fragmotion produces a .b3d with several errors :
-a useless animation is added
-a useless joint is added
-For each triangle, 3 vertices are added
-therefore the materials are not associated with the tris and vertices as i want...
-the groups are not exported correctly.

That's bad for me because i need to have clean meshes (closed not unwelded) with low tris and low vertices in order to have nice shadows with DSS without wasting too many ressources (3 times the numbers of vertices is really bad when a routine uses them to calculate shadow volumes !)

I am working on an.obj importer and i think this will be better to have a clean mesh imported, i have also posted a question on the Fragmotion forum in order to improve the .b3d exporter but i have no answer for the moment.



Thanks for your explanations, i see what you mean about the faces not being handled the same way depending on the software.

Last edited 2012


RemiD(Posted 2012) [#4]
I have just managed to code a clean .obj importer with materials for Blitz3d and guess what ? The .obj exporter of Fragmotion does not export the materials colors properly.

Now i have clean meshes colored with random colors.

Ok i stay calm...


RemiD(Posted 2012) [#5]
Just to let you know that there has been an update of Fragmotion and now it exports the .b3d file correctly (without duplicated vertices).

This is a good news, this software is really good for modeling, skinning, animation.

Last edited 2012


RustyKristi(Posted 2016) [#6]
I'm curious about your object importer if you could share it. I see there's one by Volderman in the archives but it looks quite complicated.


RemiD(Posted 2016) [#7]
I remember to have finished it in the past, but i can't find it... (4 years ago probably !)

An obj exporter/importer is easy to code anyway, since you can open and read and debug the obj file with notepad (it is a text file !)