PDA

View Full Version : Vertex color in OBJ file



Dan Ritchie
03-20-2016, 03:07 PM
I don't believe that Lightwave can handle loading vertex colors from OBJ files.

However, there does appear to be a socially accepted and highly compatible extension to the format that goes as follows (obj wiki), so I'm throwing it out as a feature idea.

Geometric Vertex
A vertex can be specified in a line starting with the letter "v". That is followed by (x,y,z[,w]) coordinates. W is optional and defaults to 1.0. Some applications support vertex colors, by putting red, green and blue values after x y and z. The color values range from 0 to 1.

jwiede
03-20-2016, 07:28 PM
I don't believe that Lightwave can handle loading vertex colors from OBJ files.

However, there does appear to be a socially accepted and highly compatible extension to the format that goes as follows (obj wiki), so I'm throwing it out as a feature idea.

Geometric Vertex
A vertex can be specified in a line starting with the letter "v". That is followed by (x,y,z[,w]) coordinates. W is optional and defaults to 1.0. Some applications support vertex colors, by putting red, green and blue values after x y and z. The color values range from 0 to 1.

Perhaps I'm missing something, but that doesn't seem a particularly "compatible" extension to the OBJ format: Essentially that's got the fourth parameter of a vertex line ("v ...") as either "w" or "r", with no stateless means to differentiate between them. Choosing between "x,y,z" and "x,y,z,w" can be determined on-the-fly by whether the optional fourth param exists, but that only holds true for a single, optional parameter. Once that optional fourth parameter's presence can potentially have multiple interpretations, the grammar becomes ambiguous, and parsing becomes messy.

There's no way to know a priori upon parsing the fourth parameter whether it is "w" or "r", that can only be determined after determining the presence of both the fifth and sixth parameters. Parser has to stick fourth into a temp token until it finishes parsing the line, only then can it determine whether that value is supposed to be "w", "r", or a syntax error (in case where 4 and 5 are present, but no 6).

Sensei
03-20-2016, 07:39 PM
I don't believe that Lightwave can handle loading vertex colors from OBJ files.

Vertex color should be implemented as rows with command #MRGB (ZBrush OBJ extension)

It's supported by TrueOBJImport (http://www2.trueart.pl/?URIType=Directory&URI=Products/Plug-Ins/TrueOBJImport)
for years.

If you have some nonstandard file format, you can just pay to make loader for it..

lertola2
03-20-2016, 07:43 PM
Zbrush exports vertex colors in .obj files. If Newtek were ever going to add vertex color importing I want to put in a request that it be able to handle vertex colors from zbrush. That would be a fantastic feature. But I am not going to hold my breath for it. I think that Newtek considers .obj import as a done feature and will be very reluctant to work on it any more.

Dan Ritchie
03-21-2016, 11:44 AM
Zbrush exports vertex colors in .obj files. If Newtek were ever going to add vertex color importing I want to put in a request that it be able to handle vertex colors from zbrush. That would be a fantastic feature. But I am not going to hold my breath for it. I think that Newtek considers .obj import as a done feature and will be very reluctant to work on it any more.

The obj loader has been revised several times. I think it's in the 2.5 version somewhere.

Dan Ritchie
03-21-2016, 02:06 PM
Perhaps I'm missing something, but that doesn't seem a particularly "compatible" extension to the OBJ format: Essentially that's got the fourth parameter of a vertex line ("v ...") as either "w" or "r", with no stateless means to differentiate between them. Choosing between "x,y,z" and "x,y,z,w" can be determined on-the-fly by whether the optional fourth param exists, but that only holds true for a single, optional parameter. Once that optional fourth parameter's presence can potentially have multiple interpretations, the grammar becomes ambiguous, and parsing becomes messy.

There's no way to know a priori upon parsing the fourth parameter whether it is "w" or "r", that can only be determined after determining the presence of both the fifth and sixth parameters. Parser has to stick fourth into a temp token until it finishes parsing the line, only then can it determine whether that value is supposed to be "w", "r", or a syntax error (in case where 4 and 5 are present, but no 6).



It's not as complicated as all that. To parse it, you only need to know the number of tokens in the string to make a decision on the w parameter, assuming loading in a line at a time.
For export compatibility, just include the w parameter, and other parsers won't trip over the color parameters. Update the wiki OBJ page with some extra information, and call it a day.

MichaelT
03-24-2016, 08:17 AM
If I remember correctly, vertex color data isn't in the OBJ format. Those that do support it, do so by an unofficial addition to the format. AFAIK that is. Still, I think that should be supported, given the importance for games.

Sensei
03-24-2016, 08:55 AM
ZBrush implementation of extension introducing Vertex Color, is cool, as it's backward compatible with existing loaders of this file format.
Data with vertex color are inside of comments starting with #
And being ignored by already existing software.

Unlike putting something after Z axis, in v commands.
Every properly written standard OBJ loader should scream about error in such file.

Dan Ritchie
03-24-2016, 11:10 AM
"The wrong way is not doing any work because it is always the wrong way"

The right way would be to support the variants that provide benefit to users and leverage desirable features of other program, which might be both.

jwiede
03-24-2016, 12:28 PM
"The wrong way is not doing any work because it is always the wrong way"

The right way would be to support the variants that provide benefit to users and leverage desirable features of other program, which might be both.

Well, there are clear, significant advantages to format additions which retain back-compat with pre-existing IO routines, versus those that achieve the same improvement but do not retain back-compat. That's why given a choice between former-type and latter-type approaches, standards bodies/groups nigh-always select approaches of the former-type when such a choice arises.

Dan Ritchie
03-24-2016, 06:17 PM
Quietly stops posting on lightwave forums because everything I say is wrong.

Dan Ritchie
03-25-2016, 10:30 AM
Well, there are clear, significant advantages to format additions which retain back-compat with pre-existing IO routines, versus those that achieve the same improvement but do not retain back-compat. That's why given a choice between former-type and latter-type approaches, standards bodies/groups nigh-always select approaches of the former-type when such a choice arises.



Can you give an example where compatibility is broken?