Results 1 to 12 of 12

Thread: Vertex color in OBJ file

  1. #1
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    388

    Vertex color in OBJ file

    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.

  2. #2
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,470
    Quote Originally Posted by Dan Ritchie View Post
    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).
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  3. #3
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,884
    Quote Originally Posted by Dan Ritchie View Post
    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
    for years.

    If you have some nonstandard file format, you can just pay to make loader for it..
    Last edited by Sensei; 03-20-2016 at 07:42 PM.

  4. #4
    skeptic lertola2's Avatar
    Join Date
    Dec 2008
    Location
    New York City
    Posts
    1,110
    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.

  5. #5
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    388
    Quote Originally Posted by lertola2 View Post
    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.

  6. #6
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    388
    Quote Originally Posted by jwiede View Post
    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.

  7. #7
    Registered User
    Join Date
    Jan 2016
    Location
    Stockholm
    Posts
    1,447
    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.

  8. #8
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,884
    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.

  9. #9
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    388
    "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.

  10. #10
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,470
    Quote Originally Posted by Dan Ritchie View Post
    "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.
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  11. #11
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    388
    Quietly stops posting on lightwave forums because everything I say is wrong.

  12. #12
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    388
    Quote Originally Posted by jwiede View Post
    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?

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •