Vertex colors?

[omgitsraven]

I know this would be a fairly significant change, but I still want to at least bring up the possibility: could there be a version of lambda-shape and remap-shape that would take/modify an rgb value too, that would be written out to the exported mesh? (This would require support for exporting in .obj or something similar of course...)

For the most part, I think I'd mostly be doing detailed texture/material work as surface shaders in things like Blender... but there are some cases where I'd want the ability to make use of information that came from the shape's definition.

The main example that I'm thinking of is taking a long box, and twisting it all around with remap-shape, and then wanting to be able to make a detailed shader elsewhere that knows how far across the original (un-twisted) shape each point on the surface is. (So the lambda-shape would generate the r based on the x coordinate, for example -- then the subsequent remap-shapes would alter all the coordinates, but would NOT alter the color values, so they would be carried forwards as-is, so there would still be a consistent gradient from one end of the box to the other, no matter how twisted into a ribbon it gets.)

You could also use this to identify different sections of the shape based on how they were built; for example a box, covered in bumps that were added by blending spheres onto its surface, where the box is blue and the spheres are green, and the blend automatically transitions between those two colors, and then in Blender I can use the relative amounts of the two colors to drive a transition between two separate materials, so the box looks one way and the bumps look another, with that smooth gradient between them.

I've done this sort of thing a lot when using SDFs in raymarching shaders, so I know the principle works; I'm just not sure how much of an ordeal it would be to adapt these functions to pass through more than just the three spatial properties, and then to also incorporate the result into the preview and the export.

[mkeeter]

This is a neat suggestion that would have far-reaching implications, so it's not in the near-term roadmap. (I am likely going to add a system for assigning single colors to shapes in the near term, though).

You've correctly thought about the parts of the Scheme interface that would need to change, but this would also affect the meshing system in interesting ways!

Consider meshing a box with a complicated function for RGB. Normally, you'd like a box to be collapsed down 8 vertices / 12 triangles. However, with arbitrary functions for RGB, you'd also need to only collapse octree cells where the color is locally linear (i.e. could be reconstructed through interpolation). This opens up a can of worms – how do you pick what's "close enough" for color-matching accuracy? What if you also have other properties (e.g. density) that want higher or lower resolutions? Does this cause mesh resolution to explode?

So... it's complicated 😃

[omgitsraven]

Oh, phooey, I hadn't thought about that :) I guess I assumed that in this mode, it wouldn't simplify meshes... but I'm not sure how much of a hit on performance that would be, in practice.

[3dGrabber]

However, with arbitrary functions for RGB, you'd also need to only collapse octree cells where the color is locally linear (i.e. could be reconstructed through interpolation).

Couldn't that be avoided by using texture maps instead of vertex colors?

[omgitsraven]

Yeah, but then you'd ALSO have to start worrying about UV unwrapping, etc…

[speps]

Two recent papers in this area: - Volume encoded UV maps - Mesh Colors (Cem Yuksel papers) First one seems like it could be a good fit. From: RavenWorks Sent: 25 February 2018 16:16 To: libfive/libfive Cc: Subscribed Subject: Re: [libfive/libfive] Vertex colors? (#145) Yeah, but then you'd ALSO have to start worrying about UV unwrapping, etc… — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[omgitsraven]

Material indexing is close to what I want, in the sense that I'm just labeling the shape so that I can do the actual decoration elsewhere, but the key thing is that I need it to be able to be a gradient, i.e. floats rather than just integers; I need to convey information about the progress from the start to the end of something. I just figured vertex colors would be the simplest way to encode data like that in a way that can be easily exported for other programs to read.

[galex-713]

what’s about making color parametric too? so it could continuously (by opposition to discretely) and even non-linearly, given some functions, change across volume? Also for more natural effects I guess using hsl instead of rgb would maybe make more sense: in a primary run I’d even see only hue, maybe implemented as a vector or complex number, as I already saw modelisation of complex functions graphs using colors (hue), that might sound consistent.

[omgitsraven]

Parametric is definitely what I had in mind, but the question at that point is how to export the result to another program -- the meshing algorithm optimizes for spatial detail, so a flat portion would have any color detail lost into the more spread-out vertices. (Though, maybe there could just be an option to not optimize the mesh, to avoid that?)

[doug-moen]

Colour mesh export is supported in Curv. If you want to try it out, Curv has the same features and F-Rep geometry representation as Libfive, but using a different language. https://github.com/doug-moen/curv

Here's what I did to make it work.

In addition to a distance function, every shape has a colour function, which maps arbitrary points (x,y,z,t) onto an RGB triple. Curv supports animation, so t is the time coordinate. There is no support for transparency right now, so I output RGB instead of RGBA.

Curv supports multiple colour spaces, but they are all converted to a common internal representation, which is linear RGB.

For shapes that don't have a colour, a default colour is assigned, which is just a constant colour function.

All of the shape operations (CSG operations like union and intersection, transformations like rotate, etc) are generalized to support colour.

I am specifically interested in 3D printing of full colour objects. The 2 most popular full colour 3D file formats supported by 3D printing services seem to be VRML version 2, and X3D. There are 3 options: you can colour each face, colour each vertex (with interpolation across faces), or provide a UV map and a separate texture file.

UV mapping is a lot of work to implement, and I was targeting Shapeways.com "full colour sandstone", so I export X3D files with per-face colouring. That was easy to implement. If I generate a mesh with lots of triangles, and with adaptive meshing turned off, then I get satisfactory results.

UV mapping should provide better results, especially with small triangle counts. But it is complex to implement. I'm interested in finding an open source project that implements this, which would speed up a Curv implementation.

I am also expecting the 3D printing industry to standardize on a voxel based interchange format at some point (the 3MF committee is voting on a proposal this week). Full colour voxel grids are very easy to export given a signed distance field and a colour field.

[andybak]

It might be worth considering a "post-mesh-generation" procedural UV mapping scheme.

For example 3DS Max has a bunch of map modifiers which can be applied to a mesh that assigns UVs to each poly based on various properties of the poly (mainly it's orientation).

Tri-planar mapping is fairly common. In Max this is similar to box mapping. Basically each triangle is assigned one of 3 UV maps based on which face of a cuboid it is closest to being orientated with. The actual UV coordinates are taken by projecting the triangle onto an axis aligned bounding box.

Other mapping techniques are spherical, cylindrical, planar etc.

To be fair - there's no reason this needs to be part of libfive - it could easily be a separate app.

The original topic of this issue - vertex colors could be incredibly useful in a more general sense. Any per-vertex attribute that preserves some of the original structure of the tree would be useful in assigning maps (and indeed useful for other purposes).

[pocomane]

(I am likely going to add a system for assigning single colors to shapes in the near term, though).

Any news about the color assignment? Also a very simple system would suffice for my use case: I want to be able to quickly highlight part of a model while I am designing it. I am not using libfive-studio, so I will need to export the information in a format that supports colors too... but this is a subsequent step :)

[d01010101]

I am likely going to add a system for assigning single colors to shapes in the near term, though.

Any chance for this?