Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am seeking a means to read and write OBJ geometry files with logic that does not modify the geometry representation. i.e. read geometry, immediately write it, and a diff of the source OBJ and the one just written will be identical. Every OBJ writing utility I've been able to find online fails this test.

I am writing small command line tools to modify my OBJ geometries, and I need to write my results, not just read the geometry for rendering purposes.

Simply needing to write the geometry knocks out 95% of the OBJ libraries on the web.

Also, many of the popular libraries modify the geometry representation. For example, Nat Robbin's GLUT library includes the GLM library, which both converts quads to triangles, as well as reverses the topology (face ordering) of the geometry. It's still the same geometry, but if your tool chain expects a given topology, such as for rigging or morph targets, then GLM is useless.

I'm not rendering in these tools, so dependencies like OpenGL or GLUT make no sense.

And god forbid, do not "optimize" the geometry! Redundant vertices are on purpose for maintaining oneself on cache with our weird little low memory mobile devices.

share|improve this question
    
I believe the reason for this is OBJ is kind of awkward from a rendering standpoint. My main problem with it was, the f (faces) specification is like an index buffer, but the calls for material changes can happen at arbitrary moments. But in something like OpenGL, you cannot change the material partway through rendering the index buffer. So material properties must be parked in as vertex attributes instead (such as per-vertex color, which OBJ does not support directly). –  bobobobo Jul 22 '13 at 16:09
add comment

2 Answers

up vote 1 down vote accepted

I have written a command line OBJ manipulation tool myself, which has the representation preservation as one design goal. It does not offer an intermediate form of the model (so it does not "load" it), but rather reads the file line by line and dumps the same line back, unless the requested operation such as scaling or centering needs manipulating the data. All comments and empty lines etc are preserved. Maybe this could be something you could expand to fill your needs.

https://github.com/tapio/obj-magic

share|improve this answer
    
nice tool you've written. is it supposed to be similar in function to imagemagick? –  stephelton Nov 11 '12 at 17:17
    
I've since written similar 'filter' logic in C, and am good. Read the OBJ as text, and then perform any necessary transformations on the verts, norms, or UVs from such data parsed out of that text. Saving the OBJ is then simply echoing the text lines holding unmodified data, and writing out new lines for the modified data. –  Blake Senftner Nov 11 '12 at 19:34
add comment

Parsing OBJ files is trivial; you shouldn't need a library to do it. All you have to do is read the file line by line, add v/vt/vn data into arrays, and add 'f' faces into 'g' groups and remember the 'usemtl' material for each group. (This is assuming you don't use the fancy OBJ features like lines or curves.)

I've written a simple python script to minimize OBJ files by removing duplicated vertex data. Feel free to use it and strip out the minimization steps that you don't want.

https://github.com/ccxvii/asstools/blob/master/objcrush.py

share|improve this answer
1  
I wouldn't say it's trivial. The format is poorly specified, and there are a lot of non-compliant obj files out there. –  stephelton Nov 11 '12 at 19:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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