Adding support to meshes without object specification and per vertex color

[SergioRAgostinho]

I'm dealing with a couple of obj file which are not being being properly parsed by PyWaveFront.

The traits are:

• vertex information is provided without providing an object name per the o keyword, i.e. it's a single nameless object.
• they have per vertex color (see last two sentences of the "spec" entry).

I'm gonna extend the library to support these for my use case. Should I submit them here as well? I believe they're both still within the specification.

[greenmoss]

Sure, PRs always welcome

[SergioRAgostinho]

I've started looking into the second point regarding the per point color specification. These are the changes I'm thinking about implementing:

• Normally, either all vertices have the color augmentation or they don't and the usual material spec is used. This means the moment you detect color info on a vertex you can reject any subsequent material use until a new object is provided. Materials and per vertex color are mutually exclusive
• Since now we will have meshes with no materials, I'm thinking about moving the vertex information to the Mesh data structure and only retain indexes to the vertex list in the Materials data structure.

Does it sound reasonable?

I'm a little concerned with the changes because I haven't been able to render anything with the draw command before. I need to read a little more into pyglet to make sure I'm not skipping some fundamental setup step.

Edit:
Just noticed you're packing tightly [texture-coords, normals-coords, vertex-coords] inside for every single point, even in situations in which there isn't any texture coord associated or even normals...

In detail

• [ ] move (combined) vertex information to Mesh data object and keep (combined) vertex indices in Material.
• [ ] pack texture coords, vertex coords and normal coords individually inside Mesh.
• [ ] update the drawing routines
• [ ] start parsing color entries on the parser
• [ ] augment Mesh with a colors list
• [ ] update drawing routines to make use of per vertex color information

Basically I need to make a lot of changes in order to implement what I wanted cleanly. At this point it's just easier to address the things quickly in my own fork and we can go point by point if you think this is useful for the lib.

[greenmoss]

I think I'm way behind your knowledge here 😄

If you propose the PR, I will trust your knowledge, and merge it.

[greenmoss]

(close was accidental)

[einarf]

What you write here makes sense. This is something I considered doing as well. What needs to be done is to figure out the vertex format of each mesh. We can build a string describing the format and map them to vertex modes in https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glInterleavedArrays.xml

The format string (eg. C4F_N3F_V3F) can then be used to inspect the format externally without relying on pyglet itself. Draw modules can map string to draw mode using GL/pyglet enums.

Vertex formats should then be limited to

GL_V3F,
GL_C3F_V3F,
GL_N3F_V3F,
GL_T2F_V3F,
GL_C4F_N3F_V3F,
GL_T2F_C3F_V3F,
GL_T2F_N3F_V3F,
GL_T2F_C4F_N3F_V3F,

Also moving vertex data away from the material is vital.

[SergioRAgostinho]

My idea was to load everything individually each as vertex attributes, i.e.: have texture coords, load that in an individual step; have normals, load that also as an individual step, so on and so forth.

This assumes use of OpenGL’s core profile. Not sure if that’s what’s is being used here, since I don’t remember seeing any shaders in the repo.

Maybe pyglet doesn’t even support it…

[einarf]

Loading positions. colors, uvs, normals separetely makes sense compared to how the current parser is handling things now. This means a method can simply yield the values and consumed into a list to vastly reduce memory allocation speeding up the parsing significantly.

You don't really need core profile as long as you end up generating a list of interleaved data with the formats supported by glInterleavedArrays (in my previous post). Before reading the polygon list, you will also know the vertex format, so you can let the user send in their preferred vertex format in the polygon reader function and simply make it yield each individual float value that can then be consumed into a list or numpy array externally.

Pyglet just use interleaved vertex data that looks just like an interleaved VBO. You are just restricted to the supported enum values I listed earlier. That is pyglet's problem to figure out in its draw functions.

Just figure out the corresponding format enum value for glInterleavedArrays here:
https://github.com/greenmoss/PyWavefront/blob/d05ba434f105b1144defc7357d499f725c6086b0/pywavefront/visualization.py#L64-L68

[einarf]

The parser can use its own constants independent of pyglet to describe the what data is avaialble. For example: T2F, C3F, V3F, N3F.

Another idea is to base it on GLTF if it's conceivable that a type is not always hardcoded to N components:

 [
    ("POSITION", "VEC3"),
    ("TEXCOORD_0", "VEC2"), 
    ("NORMAL", "VEC3"),
    ("COLOR", "VEC3"),
]

This can break the pyglet drawing for some models, but I don't really know is that's even possible to fix. I would try to make it work when possible, but if we are living by the contraints of pyglet, we may be doomed 😄

[einarf]

As an example:

I'm using this package to load obj files for https://github.com/Contraz/demosys-py. It only supports core 3.3+/4.1+ using VAOs.

I mashed together a 15 min scene loader last night (no materials): https://github.com/Contraz/demosys-py/blob/master/demosys/scene/loaders/wavefront.py

Main problem is that I always have to assume vertex format and components for each type and that I don't have any control over the vertex format in general. Also, half of my models don't even load because of #32 (also related to this)

[SergioRAgostinho]

You don't really need core profile as long as you end up generating a list of interleaved data with the formats supported by glInterleavedArrays.
[...]
Pyglet just use interleaved vertex data that looks just like an interleaved VBO. You are just restricted to the supported enum values I listed earlier. That is pyglet's problem to figure out in its draw functions.

That is true, no need for over engineering. The focus of this lib should be on parsing values from obj data a providing appropriate data structures to retrieve them.

Before reading the polygon list, you will also know the vertex format, so you can let the user send in their preferred vertex format in the polygon reader function and simply make it yield each individual float value that can then be consumed into a list or numpy array externally.

I would say to automatically pick the enumerate option which matches the data available. I stress on my original point that I would not try to focus too much here on providing a lot of flexibility on the drawing routines.

I think we have a feasible set of ideas here. There's some preliminary points I want to address first before venturing into this but I'm available for providing feedback on in case any of you wants to pick this up already.

[einarf]

I would say to automatically pick the enumerate option which matches the data available. I stress on my original point that I would not try to focus too much here on providing a lot of flexibility on the drawing routines.

Agreed. Keep it simple for now and rely on the formats pyglet can deal with. as long as the library exposes the details about the vertex format for each mesh, it can be transformed on the outside if needed. If it becomes a problem in the future, it can always be solved then.

Might take a stab at this in the future, but do tell if you start working on this. Will have to properly understand how these changes might affect the current flow in the library.

[einarf]

Some ideas for a more flexible/fast implementation. This means parser.py will need some changes.

• dir should be an attribute as it can be accessed by all parser methods anyway. Set in __init__.
• Parser should have generator attribute we can call next on to get the next line. This means parser methods can yield multiple lines if necessary such as consuming the entire vertex list in one method call. This is flexible enough to make it up to the method implementation.
• Parser should have a line attribute representing the current line the parser is working on. This attribute is cleared when we are done with the line. This means parser methods can still over-read from the generator without losing data.
• Let each parser method work on self.line. We are currently doing a lot of splitting and unnecessary iterating in the parse function. Let it be up to each parser method.
• Resolve the parser methods in __init__ using class inspection looking for parse_ functions. Store each function in a dict using the line_type as key to avoid creating an additional string in the parse function.

Also remember to support meshes without o spec meaning we need to keep a separate reference to the current mesh that is cleared after poly list is parsed.