I'm unsure about how big is reasonable using surface(). I have, however, converted 1024x1024 grayscale images to .scad file heightfields and rendered them using BOSL2's heightfield() and cylindrical_heightfield() modules in reasonable time.  (link to img2scad.py script below.)  I would think surface() would be faster, though.

https://raw.githubusercontent.com/revarbat/BOSL2/master/scripts/img2scad.py https://raw.githubusercontent.com/revarbat/BOSL2/master/scripts/img2scad.py
https://github.com/revarbat/BOSL2/wiki/shapes3d.scad#functionmodule-heightfield https://github.com/revarbat/BOSL2/wiki/shapes3d.scad#functionmodule-heightfield
https://github.com/revarbat/BOSL2/wiki/shapes3d.scad#functionmodule-cylindrical_heightfield https://github.com/revarbat/BOSL2/wiki/shapes3d.scad#functionmodule-cylindrical_heightfield

• Revar

Hi Hugo,

Thank you for taking your time and writing this approach into code!

I had varying results depending on the choosen resolution. It's very easy to crash OpenSCAD (possibly a starvation of RAM) and the performance benefit will be gone when I render several textures the same way.
I will keep playing with it and give the mailinglist an update in a few days. The roof()-function has been proposed as an alternative.

Thank you once more!
Marcus

Michael Marx wrote:

190mm X 110 mm X 60 mm for the bottom, about the same size for the lid.

My personal perception is: The deception of wood depends an the amount of details. I would like to go sub-millimeter in line width.

I attached a picture of the current prototype. I am unhappy with it, because the annual rings are not visible all over the surface. I think some more depth would provide more shadow and enhance the deception. I am also thinking about painting the piece. Any elevated fine line will allow for more paint to stick, so any continous fine line would produce more shade. I am further thinking abound sanding the piece, but I guess that would require further elevation of the annual rings.

I haven't thought about yet. I was under the impression that any shape can be split into a series of surface triangles, that a graphics card can handle a million triangles per second. I just did not see the amount of calculation spent.

Yeah, that's great. I'm doing just that

module myminkowski(preview=true){
  if(preview) {
    linear_extrude(extrude_height) children(0);
  } else {
    minkowski() children();
  }
}

That solves my preview performance. :-)

Once I go from preview to render, I still get those error messages. I will need to fix them.

Cheers,
Marcus

If they are repeatable & you can delete or comment out any extraneous code,
post them & I'll have a look. (and give me an expectation of how long it runs for)

Likewise any crashes, it is better if we can catch whatever causes them.

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 10/1/2022 3:47 PM, Marcus Poller wrote:

I am not a strong enough 3D geometry guy to be sure, but I think that
what graphics cards do is linear on the number of triangles, where what
an actual render does is quadratic on the number of triangles.

When you union two things, a graphics card just has to figure out what
pixel is in front.  It doesn't have to figure out that two objects
overlap and so the now-internal surfaces need to be eliminated, new
edges calculated, et cetera.

I think this is why OpenSCAD preview is so much faster than render.

On Sat, Oct 01, 2022 at 09:20:56PM -0700, Jordan Brown wrote:

I think you can make it near-linear if you use a fractal coordinate
system so that you can quickly eliminate most that will NOT intersect.

This is easy: every pixel of your object (even the internal and
"backside" ones!) is transformed onto XY of your screen. The
transformation also gives "some sort" of a Z which can be ignored for
where to draw that pixel. However, even though it is not really
"distance-to-viewpoint" or anything else physical, the resulting Z
value is monotonic. i.e. for objects/pixels further away it is always
larger. So the trick is to draw and fill in ALL triangles, but once
you get to a pixel, you only draw the pixel if your current Z-value is
less. And when you draw a pizel of course you update the z-value for
that pixel.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Andrew,

Short answer, as I'm leaving in 30 seconds, no, that forum is dead.

Long answer a bit later today.

MichaelAtOz

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

Make that tomorrow...

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

That's been a failure. The flattened structure does not roof(). It does import and display, but as soon as I use roof(), it disappears.

Reproduction:

Inkscape 1.0.2: Select Image, Extensions -> Modify Path -> Flatten Beziers -> Value 50 -> Apply, Save
OpenSCAD 2022.09.20.ai12175: I had to enable roof in Edit->Preferences->Features->Root->tick_the_box

I attached SVGs and Code to reproduce.

I understand that the idea of converting the SVG into something more edgy is to reduce detail and therefore speed up preview.
I will port the idea to my existing models and compare its rendering time.
Flattening could be a nice improvement over other ideas I got from this mailinglist

module wooden_texture(preview=true){
  render()
  if( preview) {
    linear_extrude(1,convexity=10) import("texture_flatten.svg);
  } else {
    minkowski(){
      import("texture_full_detail.svg");
      cylinder(r1=1,r2=0,h=1);
    }
  }
}