textures

[adrianVmariano]

Now that there are several texture modules I wonder if they should be in their own file, maybe texture.scad. They aren't thematically very close to the other contents of skin.scad.

If get_texture() is meant to be used by users maybe it should be just texture()

I had some ideas for improving the table of textures. One idea is to break it into two tables, one for VNFs and one for height fields. Then you can have a one-time explanation that VNFs run more slowly but produce more consistent triangulation. The VNF table could be divided into two sections, one for the textures that are repeats and another for textures that are VNF only.

Another idea for the table would be to list the heightfield and VNF versions of the same texture together in one line, so it's easy to see when you have both options and when you do not.

You need examples showing how textures fail with height field and then work with VNF.

The get texture docs never actually call get texture in the examples. They list two size args and say basically nothing about what they are ("depend on the texture") and then don't even show examples. Are the tex_size args being passed as those size args? Not obvious. If so, maybe the get_texture size arg should be a vector? Is that size stuff documented somehow/somewhere?

[adrianVmariano]

It's not clear that textures available only as a vnf should have "vnf" in their name. So having "bricks" and "vnf_bricks" makes sense, but "dots" instead of "vnf_dots" seems better. Otherwise the user has to remember that "dots" is a vnf style texture.

[adrianVmariano]

A clarification on the second idea for the table: have a column for height field textures and a column for vnf textures, and then a column for description. When a texture is only vnf you list its name in just the vnf column. If it's both you list both names. And then there's just one description. And if the texture size parameters depend on the texture should they be documented in this table as well?

[revarbat]

Current progress:

• The get_texture() function has been renamed to texture().
• The textures table has been split into heightfield and VNF Tile tables.
• The arguments to texture() have been renamed (inset=, gap=, roughness=, etc) and the texture tables show which args are supported by each texture.
• texture() is now called explicitly in each example.

[adrianVmariano]

What do you think of the idea of a single table with a column for VNF or heightfield? (Or both?)

And what about only using the "vnf_" prefix on texture names if the text has a heightfield version as well?

[adrianVmariano]

I was looking over this issue. Did you decide you don't like the suggestions I made? Because at this point, we should either make the changes I suggested to the docs, or decide they aren't happening and close the issue.

I was looking at the docs and I really think that it would be nice if you could see immediately whether a heightfield texture has a matching vnf texture. And I also question the need to prefix all the vnf textures with the vnf prefix. Is it important to the user that the textures are vnfs? Maybe it is because the heightfields take the "n" argument and the vnfs do not? It does seem like my idea to have one entry for two textures doesn't work because they take different args.

I think the descriptions of the args are all too vague. Docs are just generally vague, actually.

I assume n is the actual number of points in the heightfield array, that is, the array will be n x n? Or n x 1 for textures like ribs? What is required? If a user wants to make their own texture can they give any array?

For the VNF case, what is actually required if a user wants to make their own VNF? A VNF whose projection onto the XY plane exactly covers the unit square? Or just is contained within the unit square? Or uses the corner points of the unit square?

For vnfs, what is n? Presumably it's the number of points used to sample the shape.

And what is inset? That's totally unclear. Nothing is stated about why 0 or 0.5 are magical values. Also roughness is not explained either.

[adrianVmariano]

Oh, and why are there height fields that have no corresponding vnf? It seems like if we keep the layout as it is now, there should be some kind of column with an X or some other indication that tells you "this texture is available in the other type". I do really like the idea of putting "same" textures adjacent in the table (e.g. one large table), which would then eliminate the need for this.

[revarbat]

The reason I haven't merged the tables as yet is because heightfields usually take an n argument (which usually means an NxN array of heights), and VNF tiles take a variety of other arguments.

As for describing the individual arguments, that ends up being per-texture as they mean different things per texture. For example, inset= for "vnf_dots" or "vnf_dimples" VNF tiles sets the distance from the edge of the texture to the edge of the dot/dimple. For "vnf_trunc_pyramids" and "vnf_bricks", inset= specifies how much the top of the pyramid/brick is inset from the bottom of the pyramid/brick.

Some textures only have a heightfield variant because they are not susceptible to mis-triangulation, and a VNF tile variant would only make it slower.

Some textures only have a VNF tile variant because not one of the triangulation styles can make a heightfield version that doesn't suck.

What I really want is a table with a close-up image of the texture in the first column, followed by a column for Heightfield Name, followed by the VNF Tile Name, followed by a long Description column that can explain argument usage for that tile. Implementing that in the current docs system and GitHub Wiki Markdown is complicated, though. And honestly, the VNF and heightfield textures are not exact matches for each other.

[revarbat]

One example of VNF Tile and heightfields of the same notional texture not matching: "brick" vs "vnf_bricks". The former has a roughness= which would be impractically slow to implement as a VNF Tile.

[adrianVmariano]

Would it make sense to have more named args so that they can link more closely to what they do? That is, instead of trying to make inset= work for all the textures? I would think specifying dot diameter would make more sense. And not sure, but trucated pyramid height might be more natural. But even if you leave it as is, you can make the description say something like "inset" when it is used controls the geometry of the texture in a fashion that depends on each different texture. See below for details.

I realized that the problem of the vnf textures being slightly different from their height field companions makes it unreasonable to have a single table entry for both. But they could be adjacent in the table, for example, so you can immediately see that they come as a pair. And the question remains about whether prefixing everything with "vnf" when the texture exists only as a vnf is useful or just an extra complication. It may be worth doing since they take parameters differently.

But it seems like you need something explaining that height fields inherently require sampling, so you will always need to specify the number of points (n), whereas VNFs only require sampling for curved shapes. And like I said, something about what a valid VNF is for a texture in case I want to make my own. Unless there's going to be a separate texture section that lays it all out somewhere.

[adrianVmariano]

Another problem: functions that accept textures look like their usage messages weren't updated, and they don't show the texture args.

I wonder if it makes sense to have a section that shows how to make a texture, with an example of a texture and then the corresponding output. The guidance on use-built textures is basically missing, especially for VNFs.