Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heightfield() arguments should parallel texturing arguments in cyl, linear_sweep, rotate_sweep, etc. #1346

Open
RAMilewski opened this issue Jan 14, 2024 · 9 comments
Labels
Release Blocker Need to fix before release

Comments

@RAMilewski
Copy link
Contributor

Heightfield uses an argument list quite different from other texturing modules.

tex_depth, tex_size, tex_reps, tex_inset would all be useful in heightfield.

"style" seems to mean different things in heightfield() vs cyl(), etc.

@adrianVmariano
Copy link
Collaborator

It seems the heightfield() produces results rotated 90 deg from texture(), which is not great.

@adrianVmariano
Copy link
Collaborator

Oh, actually style means exactly the same thing to heightfield as it does to texture: it's just passed through to vnf_vertex_array.

@adrianVmariano
Copy link
Collaborator

Actually heightfield is transposing the data, not rotating.

I think that what needs to happen is heightfield is deprecated and replaced by a module that applies a texture to the top face of a cuboid. Not sure what it should be called. This new module would accept the usual texturing args and would not transpose the data like heightfield does.

There could be extra args to truncate heightfields or scale them to [0,1], I suppose.

@RAMilewski
Copy link
Contributor Author

Could it be just extending cuboid() to allow textures and specify where with "faces = " much like rounding is specified with "edges = " ?

@adrianVmariano
Copy link
Collaborator

How would that interoperate with chamfers and roundings? Or would it be mutually exclusive?

I was vaguely thinking about something that did one face of a cuboid and you could then attach() it to other objects where desired. Another issue with multi-face support would be controlling rotation of each face.

@RAMilewski
Copy link
Contributor Author

I hadn't thought that through completely. But if you're texturing one face, you still have the same issue don't you?

@adrianVmariano
Copy link
Collaborator

If you're texturing one face you can rotate the texture before you put it on. And if you're attaching a texture to several faces, you can rotate each one individually as needed.

@RAMilewski
Copy link
Contributor Author

A heightfield attached to the top of a cuboid will fail an F6 render unless bottom < 0.

@RAMilewski
Copy link
Contributor Author

Heightfields treat texture data differently than other objects:

include<BOSL2/std.scad>
include<data.scad>
$fn = 72;

cuboid([90,40,0.25], anchor = BOT)
    attach(TOP)
        heightfield(data, size = [90,40], bottom = -1e-12, maxz = 1);

back(25) left(30)
    linear_sweep(circle(d = 90/PI), h = 40, texture = data, tex_reps = [1,1]);

back(25) right(30)
   cyl(d = 90/PI, h = 40, texture = data, tex_reps = [1,1], anchor = BOT);
Screenshot 2024-03-06 at 12 12 26 AM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release Blocker Need to fix before release
Projects
None yet
Development

No branches or pull requests

2 participants