1
$\begingroup$

When I export a model with multiple objects, the face indexes of the second object, for example, won't start with 1, because they are "global", which means you have to keep track of every (v, vn, vt) occurrency. I want blender to export .obj and have faces indexes starting at 1 each time, even if it's necessary to duplicate some vertex. Is it possible? PS.: I know I could export them separately, but that's not practical.

$\endgroup$
  • $\begingroup$ If you are referring to the line of the form f 1//1 2//1 4//1 3//1 in the obj file then, I would say: How the indexes should be calculated is defined by obj specification, Blender or any other app which wants to deal with the obj format will have to comply with this specification. The indexes here are, I presume, referring to the vertices defined above in the same file. So even if you write a python script to reset the index to 1 for every new object, that won't serve your purpose because the wrong vertices will be referred to in such cases. $\endgroup$ – Blender Dadaist Oct 3 '18 at 6:11
  • $\begingroup$ It is not possible with the basic blender ops. You could write a script like in blender/<version>/scripts/addons/io_scene_obj/export_obj.py $\endgroup$ – quiliup Oct 3 '18 at 21:05
0
$\begingroup$

I do not understand the question. Can you specify why it is impractical for your specific case. Where and how do you plan to import the data?

Obj files will need a unique face index as different objects are separated by obj groups referring to the vertices which are included in each object. Otherwise the file would result in something different when importing somewhere else. If you want to alter the way the wavefront obj format is imported or handle the data externally in a specific way you could always parse the file for obj groups using python and sort it the way you would like for your specific application. Alternatively you could also export all objects separately using python, obviously depending on the constraints you have making it impractical for your specific case.

$\endgroup$
0
$\begingroup$

The .obj specification requires that each type of vertex data is numbered sequentially throughout the file.

Referencing vertex data

For all elements, reference numbers are used to identify geometric vertices, texture vertices, vertex normals, and parameter space vertices.

Each of these types of vertices is numbered separately, starting with 1. This means that the first geometric vertex in the file is 1, the second is 2, and so on. The first texture vertex in the file is 1, the second is 2, and so on. The numbering continues sequentially throughout the entire file. Frequently, files have multiple lists of vertex data. This numbering sequence continues even when vertex data is separated by other data.

In addition to counting vertices down from the top of the first list in the file, you can also count vertices back up the list from an element's position in the file. When you count up the list from an element, the reference numbers are negative. A reference number of -1 indicates the vertex immediately above the element. A reference number of -2 indicates two references above and so on.

Therefore it would violate the .obj specification to write a file that counts vertex indices on a per object basis as well as reading an .obj that way.

All .obj reader/importer that follow the specification will require the global sequential indices for each type of vertex data. Even if you were to write an exporter following your proposed idea, it couldn't be properly read by any other software.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.