Retrieving the palette index from the mesh generator

[groud]

Hello, thanks for this awesome library!

While working on using this library to import .vox models into Godot, it seems like I faced a limitation regarding how meshes are returned to the user. While using ogt_mesh_from_paletted_voxels_polygon I figured out I could not find a way to access the palette index associated to a given generated vertex. However, it would be very useful to me to retrieve the corresponding material properties (metalness, emissive, etc...).

Please let me know if I am right here, and there indeed no easy way to retrieve this. If I am and you are interested, I would be happy to contribute a simple enhancement to the library, likely by adding a palette index property in ogt_mesh_vertex (Or maybe removing the color property, since it could be retrieved from the palette anyway ?).

[jpaver]

Hi Gilles,

Hello, thanks for this awesome library!

You're welcome!

I figured out I could not find a way to access the palette index associated to a given generated vertex. If I am and you are interested, I would be happy to contribute a simple enhancement to the library, likely by adding a palette index property in ogt_mesh_vertex

I do think adding the color index onto the ogt_mesh_vertex type would be great, feel free to submit a PR that implements this this :)

As it turns out, this is already something that you can do by injecting the color index into the alpha component of your palette before calling ogt_voxel_meshify. I use that trick myself while adjusting colors into linear space and end up directly using the color index in my own shaders (exactly for emissive/metalness etc, except I just assume certain index ranges correspond to certain shader features).

My code looks like this prior to calling ogt_voxel_meshify:

  // we convert all colors from gamma-to-linear and store the index within the alpha component.
  ogt_vox_rgba palette_data[256];  // input/output palette
  {
      const float k_one_over_255 = 1.0f / 255.0f;
      for ( uint32_t i = 0; i < 256; i++)  {
          ogt_vox_rgba original_color = palette_data[i];
          // scale from 0..255 range to 0..1 range
          float f = (float)original_color.r * k_one_over_255;
          float g = (float)original_color.g * k_one_over_255;
          float b = (float)original_color.b * k_one_over_255;
          // convert from gamma-to-linear
          r = powf(f, 2.2f);
          g = powf(g, 2.2f);
          b = powf(b, 2.2f);
          // scale back to 0..255 range
          r *= 255.0f;
          g *= 255.0f;
          b *= 255.0f;
          // reassemble the output color and inject the color index into alpha component
          palette_data[i] = make_color(real_to_uint8(r), real_to_uint8(g), real_to_uint8(b), (uint8_t)i);
      }
  }

... but I like your way better :)

While working on using this library to import .vox models into Godot,

That sounds awesome! If you do get this working and end up open-sourcing it, please drop me a link so I can link to it from this library's README.md. I've had a number of folk pinging me and wanting to know how to do this, but I haven't had all that much time to research how to do this in Godot myself :)

Thanks for the suggestion!

[groud]

I do think adding the color index onto the ogt_mesh_vertex type would be great, feel free to submit a PR that implements this this :)

Cool! I already have the code kind of ready, I'll PR it ASAP.

As it turns out, this is already something that you can do by injecting the color index into the alpha component of your palette before calling ogt_voxel_meshify

Oh, that's quite a good trick, I did not think about that!

That sounds awesome! If you do get this working and end up open-sourcing it, please drop me a link so I can link to it from this library's README.md. I've had a number of folk pinging me and wanting to know how to do this, but I haven't had all that much time to research how to do this in Godot myself :)

I'll see if that is possible. The implementation I am working on relies the Godot development branch, which is not really bug free right now. I'll try to open-source it if I can manage to have a clean enough code.

I think porting the library on the current stable version would have been quite complex on the current stable release anyway (the native code extension was rewritten for the version to come), so I am not surprised it was not integrated into an add-on earlier on.

[groud]

Closing as solved by: https://github.com/jpaver/opengametools/pull/18