Jump to content

  • Log In with Google      Sign In   
  • Create Account


Obj file format: face data


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 johnstanp   Members   -  Reputation: 262

Like
0Likes
Like

Posted 21 July 2009 - 10:21 PM

Here is a line in a obj file that describe the data of a face( polygon ): f 36793/36793/36793 36794/36794/36794 36800/36800/36800 I've read the obj file format specification and nothing is said about the unique correspondance of a point( Vector3 object for example ) and a texture coordinate and a normal, for a mesh. That should mean that a point shared by two polygons can have two normals or texture coordinates associated to it. So the mesh should be rendered polygon by polygon( an openGL function call for each polygon ) in the general case? P.S:I am a noob in computer graphics...So be indulgent if my question sounds a little stupid. In the case I am right, what would the most performant rendering technique in opengl, for openGL v1.4? [Edited by - johnstanp on July 22, 2009 5:10:19 AM]

Sponsor:

#2 RobTheBloke   Crossbones+   -  Reputation: 2333

Like
0Likes
Like

Posted 21 July 2009 - 11:13 PM

Quote:
So the mesh should be rendered polygon by polygon in the general case?


Yes. ish. The obj file format is good for storing data for modelling packages, not so great for rendering efficiently. As such you need to change your data layout to be friendly to vertex arrays if you want efficient rendering.

Personally, I'd always use a small app to load and obj file, convert to vertex arrays, then output into your own custom format. Adding new file format support is then just a case of modifying your conversion app, and doesn't lead to bloat in your game.

see the dot3 bump mapped obj loader (The one with 10 examples in!). Don't use Dot3 bump mapping though! It's crap and old!

The rest of the source examples in that zip start from rendering each tri separately, then gradually improve to create an indexed vertex buffer object (which is the best way to render data in OGL). Hope that helps.

\edit should have mentioned display lists, which could be the easiest route depending on what you want. I personally hate them, which is why i forgot to mention them

#3 johnstanp   Members   -  Reputation: 262

Like
0Likes
Like

Posted 21 July 2009 - 11:25 PM

Quote:
Original post by RobTheBloke
Quote:
So the mesh should be rendered polygon by polygon in the general case?


Yes. ish. The obj file format is good for storing data for modelling packages, not so great for rendering efficiently. As such you need to change your data layout to be friendly to vertex arrays if you want efficient rendering.

Personally, I'd always use a small app to load and obj file, convert to vertex arrays, then output into your own custom format. Adding new file format support is then just a case of modifying your conversion app, and doesn't lead to bloat in your game.

see the dot3 bump mapped obj loader (The one with 10 examples in!). Don't use Dot3 bump mapping though! It's crap and old!

The rest of the source examples in that zip start from rendering each tri separately, then gradually improve to create an indexed vertex buffer object (which is the best way to render data in OGL). Hope that helps.

\edit should have mentioned display lists, which could be the easiest route depending on what you want. I personally hate them, which is why i forgot to mention them


Thanks for the link and the advice...Well, I never intended to use the obj file format for my project, but I thought that writing a loader for a format that has many conversion tools, and an importer to my own binary format would be wise.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS