Jump to content

Talk:Wavefront .obj file

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Examples, etc.

[edit]

for whatever reason, .OBJ has been the catch-all import/export format of 3D graphics, much like .TXT is used for documents. [email protected]

I'd like to suggest adding a link on how to load obj files in C++ opengl programs. I don't anybody talking about it or explaining how it can be done, yet this a fundamental thing for any program hoping to do something more complex then a drawing a few triangles: http://3dcodingtutorial.com/Working-with-3D-models/Importing-the-model-in-C++.html —Preceding unsigned comment added by 85.204.189.171 (talk) 11:55, 8 May 2008 (UTC)[reply]

I don't think that that is actually relevent, although noting that this is one of the simplist formats to write your own reader for in any given language may be. ho humm. SirEelBiscuits (talk) 05:22, 13 May 2008 (UTC)[reply]

Yes it is simple but as long as most 3D modeling tools support it why not use? And even more why not give an example on how to do it since this topic is about Wavefront obj format 85.204.189.171 (talk) 15:25, 16 May 2008 (UTC)[reply]

Actually the above link was pretty helpful. Exactly what I was looking for. Perhaps someone with more experience then me should fill up the blanks in the wiki article. I see no reason to have a complete explanation right here 89.136.53.15 (talk) 12:55, 20 June 2008 (UTC)[reply]

I like this format because it's easy to use. I just wrote my first opengl program that imports a model from 3d studio max. But I've been told that using my obj files somebody can easily recreate the 3d model and use it in his own programs? Are there any better formats? Something harder to reuse?89.136.54.196 (talk) 16:17, 27 June 2008 (UTC)[reply]

Yes - embedding the files in your binary.
You see, the point of an external format is mainly to be able to reuse it somewhere else - you can export .obj with whatever program you use, and then "reuse" it in a game.
Either way, even if you embed it in your binary, there's still a way to reuse it. You might try encryption, but I don't quite understand why you want to keep others from using them.
The best method to do it is to prohibit it with a license. From my experience (as a programmer), people generally respect the license. Darkuranium (talk) 07:09, 12 August 2008 (UTC)[reply]

Two small, closely related topics, which (less the rather large examples) could work better as one article. Discuss.  — SheeEttin {T/C} 06:42, 21 May 2010 (UTC)[reply]

The only issue with doing this is that it could become very confusing as to which file type was being discussed. --Fintelia (talk) 16:36, 17 July 2010 (UTC)[reply]

Make it a subsection and MTL becomes a redirect to said subsection. If those are the only problems ill do the merge now. Sir Robert "Brightgalrs" Schultz de Plainsboro (talk) 03:20, 26 November 2010 (UTC)[reply]

Ka and map_Ka?

[edit]

What if both Ka and map_Ka is defined. How they interact? Ka is ignored, or maybe it is multiplied by map_Ka? Similary with other K*?

Software that supports OBJ

[edit]

This list needs improvement to be useful. I moved it here for now. Software needs some sort of categorization, and description of support like exporting or importing?! Tom Ruen (talk) 01:46, 24 January 2011 (UTC)[reply]

I just tried it on Blender with no luck. Do I need to adjust a preference to allow it to recognize .obj? —Tamfang (talk) 04:52, 24 May 2012 (UTC)[reply]

Works fine in blender. Notice how this trash wiki article says nothing about animation support? — Preceding unsigned comment added by 184.97.45.190 (talk) 22:34, 31 May 2012 (UTC)[reply]
So I launched Blender (on MacOS 10.6) and opened a directory where there are a bunch of OBJ files, and nothing shows up. Well, it works fine in the sense of not crashing.... —Tamfang (talk) 22:55, 31 May 2012 (UTC)[reply]
Blender reads .obj files in fine for me, and for others since at least 2006 and probably before. Perhaps it just has a user interface issue for mac users? ★NealMcB★ (talk) 18:40, 8 October 2014 (UTC)[reply]
Blender is an animation suite; it looks to "open" scenes and whatnot, not individual objects. To open an object, you need to "import" it in to a scene, not "open" it directly. ~ LukeShu (talk) 18:55, 7 December 2015 (UTC)[reply]

On 64bit Linux: Meshlab v1.3.2 opens the one .obj file I have. Inkscape v0.48.4 does not open the file. On Windows 7: Autodesk Inventor 2015 and SolidWorks 2014 do not open the file. --Lead holder (talk) 12:20, 6 November 2014 (UTC)[reply]

What units have the OBJ vertex coordinates?

[edit]

I fear they have no units (mm, inch). If they have no units, why? And shouldn't this info be part of the article? Are there "common" OBJ units? Do people use the comment function to define the units? 87.159.158.45 (talk) 10:42, 22 February 2013 (UTC)[reply]

sequence of entries

[edit]

Do all the vertex entries have to come before all the face entries, or can they be intermixed if each face refers only to vertices defined above it? —Tamfang (talk) 00:14, 22 January 2014 (UTC)[reply]

So I tried it; Shapeways accepted a file with mixed entries. I didn't try putting a face before any of its vertices. —Tamfang (talk) 07:02, 24 March 2014 (UTC)[reply]
The documentation referenced in the article([1] and [2], page B1-21) mentions the option to reference vertices with negative indices (referring to vertices declared just before the referencing element (e.g. "f"). I have no idea if this is commonly used, but the current section "Vertex Indices" seems to be too strict. It could mention an example as below. --Rumpel42 (talk) 15:06, 23 March 2016 (UTC)[reply]
 v 0.000000 2.000000 2.000000
 v 0.000000 0.000000 2.000000
 v 2.000000 0.000000 2.000000
 v 2.000000 2.000000 2.000000
 f -4 -3 -2 -1

References

.obj files vs. .obj files

[edit]

Isn't there something to say here about the obvious conflict with DOS/Windows OBJ files, the problems this conflict can cause, the workarounds people use to get around the problems, and/or the reason(s) that Wavefront made this surprising choice of extension in the first place? (Or did these obj files actually come first?) —Steve Summit (talk) 02:20, 12 November 2014 (UTC)[reply]

History and Intent

[edit]

I was the original author of the .obj format, with input from David Yost, Bill Kovacs, Jim Keating, and Kim Shelley in 1985. It was originally developed as the geometric object interface for (i.e. a way to move geometric objects between) modeling, scene animation, and rendering programs that did not live in the same runtime environment and that were being written by different groups at Wavefront. At the time, interactive modeling programs were marginal at best, and the majority of models were hand edited or procedurally generated, and we needed a format that was simple to generate, parse, read, and hand edit. Also, to support writing animation and rendering development before there was an interactive modeler we needed some representation of object geometry. In response to some of the questions posed in this talk section:

  • There was no consideration given to .obj and .mtl files becoming a standard at the time they were defined. They were defined because of the pragmatic necessity to allow the groups writing modeling, animation, and rendering to have some way to simply communicate with each other. I suspect it became a standard because it was simple to generate, parse, read, and hand edit.
  • The .obj extension was chosen as an abbreviation for object. At the time we were writing in C and DEC VAX machines. C files complied to assembly (.asm) files. There were no other .obj files at the time.
  • The negative vertex indexing arose from the need to hand edit geometry into an object that came from a generator or modeling program. This new geometry needed to be added relative to the other geometry without screwing up the other geometry. It was always added after other geometry (vertices and faces) so it was a stand-alone bit that could be cut and pasted when the base geometry was regenerated. Again, the original motivation was supporting hand editing, though it is often useful in generation when multiple generators write to the same file (i.e. The block they write is self-contained and independent of ordering with other geometry.
  • Ka and map_Ka: as I recall, if both were specified, Ka would be a multiplier for what was in the map. The reason for that is the map is often more a description of texture intent (really dimensionless and colorless) and the Ka multiplier (or the constant multiplier for any of the components) provides the contextual interpretation of the texture.
  • .obj files were intentionally unit-less as they were not thought of as having a relationship to a physical reality. They were just definitions of geometry that could be transformed as appropriate for the animation. Units only become important when you have representation in a physical space that need to correctly relate to each other out-of-the-chute. At the time, there was nothing else to integrate with.

Royster.hall (talk) 05:15, 16 November 2018 (UTC)[reply]



Speaking as an Author, I'd like that history very much! Maybe you know of a book or file format web page with dates that can be referenced? I noticed over a year went by, so I'd say just edit the section. Or maybe you could post a blog somewhere?

Alternatively, I could interview you (as part of my book), publish the interview giving proper credit, then we could insert that as a reference, or does that sound like a dodge?

Jgwinner (talk) 03:34, 17 September 2017 (UTC)[reply]

Binary format

[edit]

Why isn't binary format covered? AXONOV (talk) 19:20, 13 January 2022 (UTC)[reply]

Statements vs Elements

[edit]

The terms "statement" and "element" are not clearly defined in the article. In a Wavefront OBJ file, each line is called a "statement". The term "element" refers to a specific type of statement that defines a group of related data in the file. An element is composed of one or more statements and provides a way to organize and group data that belongs together. Spatha Spatula (talk) 00:06, 18 February 2023 (UTC)[reply]

Vertex normal vectors and vertex texture coordinates are not fully explained

[edit]

Vertex normal vector indices and vertex texture coordinate indices are covered in detail, however there are no paragraphs explaining vertex normal vectors and vertex texture coordinates, which are the values pointed to by the corresponding indices. This is in contrast to the coverage of geometric vertices, parameter space vertices, and face elements which are fully explained in the article.

The article should also be consistent in using full terms, for example:

vertex normal vector, vertex normal vector index

vertex texture coordinate, vertex texture coordinate index

geometric vertex, geometric vertex index

Spatha Spatula (talk) 02:08, 18 February 2023 (UTC)[reply]

[edit]

Just a quick explanation that I updated the PBR extension for OBJ to a page on my personal website (https://benhouston3d.com/blog/extended-wavefront-obj-mtl-for-pbr/extended-wavefront-obj-mtl-for-pbr/) from the previous link that went to my old company website (https://web.archive.org/web/20160226114608/http://exocortex.com/blog/extending_wavefront_mtl_to_support_pbr). Exocortex was acquired and the exocortex.com website was shutdown, so I republished the PBR extension on my personal website (as I was the original author of it anyhow.) I am adding this comment here so that no one things I am just engaging in self-promotion, rather I am fixing a broken link. --Ben — Preceding unsigned comment added by BenHouston3D (talkcontribs) 18:55, 30 May 2023 (UTC)[reply]

Remove "Object file" and "Relocatable Object Module Format" from the "See also" section

[edit]

In my opinion, those are conceptually different from 3d model file formats and should be moved to the "Obj disambiguate" page instead. It would be like adding "Horse" or "Wild Horse" to the see also section of the Ford Mustang article. 76.140.114.90 (talk) 20:57, 11 February 2024 (UTC)[reply]