How to get a 3D model into pyglet?

[Nathan]

Does anyone have any pointers for the best way to get models from
blender to pyglet?

After googling awhile, I found that the wavefront object file format
(one of the choices in blender's 'export' menu) is text that I can
parse. Is there a better way to get models to use for 3D stuff?
Rather than reinvent the wheel writing my own parser, I'd love to
discover an easier and better way.

~ Nathan

[Richard Jones]

On Feb 18, 2008 2:32 PM, Nathan <nathan...@gmail.com> wrote:

Does anyone have any pointers for the best way to get models from
blender to pyglet?

There's some old code in pyglet's SVN under contrib/model for OBJ format models that you're welcome to look at, use, extend (hint :)


    Richard

[Gary Herron]

On Feb 17, 7:32 pm, Nathan <nathan.sto...@gmail.com> wrote:
> Does anyone have any pointers for the best way to get models from
> blender to pyglet?

Blender is scriptable via Python, so you could write your own export.
And the nice thing is that all the (2-3 dozen or so) import/export
methods are written in Python -- so you have lots of example code to
draw on.

I had to do something like this for a project I was working on -- I
only needed to extract geometry and texture coordinate information.
No fancy lighting or animation stuff. The geometric data in a
blender model is exposed in an easy to access form, so my code was
quite short.

And here's the nicest part: There is no need to parse any foreign
format. The export routine extracts the data from the Blender model
and puts it straight into whatever structures I want to use in my
OpenGL program, (mostly OpenGL VertexArrays) and then pickles those
structures and writes them out to a file. That's the end of the
export step. My Pyglet code can then read/unpickle those files,
recreating those structures, and I then have all the data in exactly
the form I want for display. Very clean, Python from beginning to
end, and all steps under my complete control.

Gary Herron

[Drew Smathers]

Yes ... very old.  As in "Doesn't work anymore."  Anyhow, I wrote my own .OBJ parser before I even knew it existed:
http://hg.enterthefoo.com/Miru/file/6de2b2e10543/miru/tools/obj.py

I discovered the contrib/model one afterwords and wasn't very impressed, so I kept my own.

There are some caveats/limitations to my implementation:

1. If want a triangle mesh then you'll have to triangulate you model in blender first (easy)
2. Your texture image contained in an .mtl file must be of power-of-2 dimensions with w==h (ex. 2x2, 4x4 ... 512x512)
3. You'll have to convert the objects returned by parse to something meaningful in your view implementation - your Mesh object, likely.
4. It doesn't fully implement the Wavefront specification - the old contrib one didn't either

To see how (3) works in miru, see miru.mesh.loadObj function:
http://hg.enterthefoo.com/Miru/file/91b9e3184232/miru/mesh.py

If the above caveats/limitations are acceptable to folks, I'd be happy to add my implementation to contrib.

--
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/  \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\  /\\\ \\
/ /\\\  /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
              d.p.s

[PhilipBober]

> 4. It doesn't fully implement the Wavefront specification - the old contrib
> one didn't either

That's not really surprising. Does anyone actually implement the whole
thing?
The full OBJ spec has commands to run arbitrary commands (so "csh rm -
rf ~" is a valid .OBJ file)

(I wrote an OBJ parser a while back, sorry to go somewhat offtopic)

[Drew Smathers]

On Feb 18, 2008 6:49 AM, PhilipBober <pdb...@gmail.com> wrote:

> 4. It doesn't fully implement the Wavefront specification - the old contrib
> one didn't either 

That's not really surprising. Does anyone actually implement the whole
thing?
The full OBJ spec has commands to run arbitrary commands (so "csh rm -
rf ~" is a valid .OBJ file)

Yes - I think the spec is ridiculous.  I wasn't meaning to suggest that we should try to implement the whole spec. 

 

(I wrote an OBJ parser a while back, sorry to go somewhat offtopic)

Yeah, just looking at your code, I think we more or less implemented the same features.  The two reasons I decided not to throw mine away and hack on yours was:

1.  I don't think triangulation should be the role of the importer - though kudos for actually implementing this :)
2.  I think the parser should be decoupled from the view layer because:
    A. You can rewrite/replace your drawable Mesh object etc. independent of the parser
    B. You might want to other things with the mesh - smoothing etc.
3.  I'm lazy and my obj parser was already working for my needs.

I think some improvements could be made to mine:

1. Optional filters for post-processing - for example: triangulation as you implemented
2. Support a few more "reasonable" features of the Wavefront spec.

Would you be interested in collaborating on this?  And to Alex - if we arrive at something sufficiently abstract and useful in any pyglet application, would you be interested in putting this in pyglet core?  I imagine this would entail more work - e.g. a Mesh class in pyglet.  If there's not sufficient interest in the community, then I definitely don't want to waste any effort.

Cheers,

[Alex Holkner]

On 2/19/08, Drew Smathers <drew.s...@gmail.com> wrote:
> And to Alex - if we
> arrive at something sufficiently abstract and useful in any pyglet
> application, would you be interested in putting this in pyglet core? I
> imagine this would entail more work - e.g. a Mesh class in pyglet. If
> there's not sufficient interest in the community, then I definitely don't
> want to waste any effort.

Possibly/eventually. At the moment pyglet doesn't even dip its feet
into providing 3D support, so an OBJ loader (+ mesh class) would be a
little oddball. I think eventually pyglet will grow some sort of
scenegraph though, at which time an OBJ loader would of course be
integrated. (But I would expect to see said scenegraph stable in a
3rd party library first before integrating it).

Alex.