DON'T PREVIEW THIS AS IS.

Marcus, please cut it down to a test case which does not run forever, I imagine l & h being smaller
could help.

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

2h13m on my system... and peaked just under 4GB memory.

With l=25, h=20, 1m28s, so if anyone want to play start from there.

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

Can you share a picture of what you are trying to do?

On Sat, 1 Oct 2022 at 08:21, Michael Marx michael.marx@tpg.com.au wrote:

Correction, that 2h13m was just sample_piece(),

without base() & antiwarp(), which should be minor,

and without the bottom four cube_intersect() conekowski_2d()'s, so god knows how long that would
be...they look expensive.

Same for the 1m28s.

A subsequent (same reduced code) l=30 h=30, was F5=2m20s, F6=0m15s.

Sanjeev, this is what the reduced 2h13m produced, looks similar on the back face.

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

Oh, that seems complicated
I was thinking of something like the attached image.
This took around 5 minutes in my computer (M1 Macbook air)

On Sat, 1 Oct 2022 at 08:42, Michael Marx michael@marx.id.au wrote:

Marcus,

First, you should add convexity=10 to all your linear_extrude()'s, 10 may not be perfect, but is a
good number. This fixes preview strange effects, like faces disappearing when moving the display.
Alternatively, if it is not a hungry operation wrap

the linear_extrude() in render() {},

Next time, please comment out or stick into a test module those expensive operations,

like the three at the bottom and mention they can be tested separately.

I normally load up a file and hit F5 to see what's going on, getting a 2hr preview up front is not
nice.

If you have specific errors, it is nice to try to cut down your model to try and find the main
culprit. Try using '*' to block out chunks, a but of trial & error.

 (2022-09-25_probedruck_textur.scad 3rd piece in x-y-plance)

A. Is the first error only with the sample_piece() or with the three operations at the bottom of
the file included?

B. Is the empty screen just with the 3rd piece, or are all the other bits rendered as well?

As you have found minkowski() is expensive. intersection() can be too.

More on this later.

But make things smaller when testing, bigger usually means more faces, means more processing.

I added:

sf=1/25;

and made your scale

scale([sf,sf]) import("holztextur.svg",center=true);

So you can make l & h smaller, shrink the scale too, this makes for quicker tests.

(However sometimes that can make some errors disappear - like some CGAL errors)

Breaking this down may help others.

First 2022-09-25_probedruck_textur.scad

Module sample_piece() has two sides,

the plane square edged, cheap re CPU, but no 45 degree solution,

though small recesses may be printable. Comment that out for testing.

Then the other side with the minkowski. Expensive.

Then there are three tests at the bottom, commenting those out for now.

I have not looked at the other .scad yet.

For now, can you answer A. & B. above, ATM I don't know which bits you are trying to debug.

With

sf=1/50;

l=10;

w=2;

h=10;

&

module sample_piece(){

//render()

union(){

cube([l,w,h]);

*translate([0,w+eh,0]) rotate([90,0,0]) linear_extrude(eh, convexity=10) wooden_texture_2d();

rotate([90,0,0])

       intersection() 

            {

            linear_extrude(1, convexity=10) 

                 square([l,h]);

            minkowski(){

                 linear_extrude(pseudo_3d, convexity=10) 

                       wooden_texture_2d();

                 cone();

            }

       }

}

}

That previews in 10m, and renders in 22s.

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

and with 2021.01 (can't run newer ones), it has many degenerate faces (yellow) & some
self-intersections (magenta).

Just reporting this for now.

It may explain CGAL errors.

From: Michael Marx [mailto:michael@marx.id.au]
Sent: Sat, 1 Oct 2022 15:54
To: 'OpenSCAD general discussion'
Subject: [OpenSCAD] Re: minkowski + mesh is not closed

Marcus,

First, you should add convexity=10 to all your linear_extrude()'s, 10 may not be perfect, but is a
good number. This fixes preview strange effects, like faces disappearing when moving the display.
Alternatively, if it is not a hungry operation wrap

the linear_extrude() in render() {},

Next time, please comment out or stick into a test module those expensive operations,

like the three at the bottom and mention they can be tested separately.

I normally load up a file and hit F5 to see what's going on, getting a 2hr preview up front is not
nice.

If you have specific errors, it is nice to try to cut down your model to try and find the main
culprit. Try using '*' to block out chunks, a but of trial & error.

 (2022-09-25_probedruck_textur.scad 3rd piece in x-y-plance)

A. Is the first error only with the sample_piece() or with the three operations at the bottom of
the file included?

B. Is the empty screen just with the 3rd piece, or are all the other bits rendered as well?

As you have found minkowski() is expensive. intersection() can be too.

More on this later.

But make things smaller when testing, bigger usually means more faces, means more processing.

I added:

sf=1/25;

and made your scale

scale([sf,sf]) import("holztextur.svg",center=true);

So you can make l & h smaller, shrink the scale too, this makes for quicker tests.

(However sometimes that can make some errors disappear - like some CGAL errors)

Breaking this down may help others.

First 2022-09-25_probedruck_textur.scad

Module sample_piece() has two sides,

the plane square edged, cheap re CPU, but no 45 degree solution,

though small recesses may be printable. Comment that out for testing.

Then the other side with the minkowski. Expensive.

Then there are three tests at the bottom, commenting those out for now.

I have not looked at the other .scad yet.

For now, can you answer A. & B. above, ATM I don't know which bits you are trying to debug.

With

sf=1/50;

l=10;

w=2;

h=10;

&

module sample_piece(){

//render()

union(){

cube([l,w,h]);

*translate([0,w+eh,0]) rotate([90,0,0]) linear_extrude(eh, convexity=10) wooden_texture_2d();

rotate([90,0,0])

       intersection() 

            {

            linear_extrude(1, convexity=10) 

                 square([l,h]);

            minkowski(){

                 linear_extrude(pseudo_3d, convexity=10) 

                       wooden_texture_2d();

                 cone();

            }

       }

}

}

That previews in 10m, and renders in 22s.

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_con
tent=emailclient>  width=www.avg.com

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

BTW,

how big is the final box?

how fine-grained do you want the wood effect?

Performance is a factor of size & fine detail.

You could show an example of say the largest side, with l, h & sf with just:

module sample_piece_flat(){

union(){

       cube([l,w,h]);

       translate([0,w+eh,0]) 

            rotate([90,0,0]) 

                 linear_extrude(eh, convexity=10) 

                       wooden_texture_2d();

 }

}

That previews quickly.

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

Have you considered something like the following as an approach to your general problem:

/* Sample piece for wooden texture options - uses overhang options and Minkowski*/
/* v2 2022-09-28 translation to English to ease support of OpenSCAD Mailinglist*/
l=100;
//w=2;
h=80;
//eh=0.5;
//pseudo_3d=0.001;
//base_layer_height=0.15;
//warp_protect_distance=4;

module wooden_texture_2d(){
intersection(){
translate([l,0,0]) scale([1/10,1/10]) import("holztextur.svg",center=true);
square([l,h]);
}
}

height = 1;
resolution = .05;

for(z = [0:resolution:height - resolution])
translate([0,0,z])
linear_extrude(resolution)
offset(z)
wooden_texture_2d();

Simply set “height” to the height of the thickness of the ‘wooden' panel and “resolution” to something that’s some multiple finer than the layer height for the printer you will be using.
This will give you a 3 dimensional 45 degree sloped object of the 2d pattern you started with.
You can use a coarser resolution when you are developing, and increase it when you are ready to render, although preview is pretty zippy for the sample you provided at .05 resolution.
Rendering is still slow, but if you’re preparing this for an FDM printer it’ll still be incredibly faster than using minkowski.
Hope this is useful.

I may be over-simplifying this, but if the SVG won't import cleanly, yet displays correctly in a web browser, just convert the SVG to a PNG or GIF (or take a screenshot of it) and use surface() to load it.

• Revar

Managementsummary: Dimensions too large.

I used inkscape to convert the SVG to PNG. The resulting PNG is

$ exiv2 holztextur.png
File name       : holztextur.png
File size       : 613284 Bytes
MIME type       : image/png
Image size      : 2628 x 2056

Then I tried to import the image as surface

$ cat 2022-10-01_surface.scad
surface(file="holztextur.png",center=true,convexity=10);

and I get

$ openscad 2022-10-01_surface.scad
Killed

.

I am just assuming that 2000 pixel is fundamentally oversized for OpenSCAD. Downsizing the image is fine.

convert holztextur.png -geometry 25% holztextur.25.png

I would like to discuss a sane dimension. The longest side in the final object will be 20cm; The plastic thread is very fine at 0.1mm; Oversimplyfying: Each possible plastic thread gets its own pixel. I would expect a (according to Nyquist–Shannon sampling theorem) sane dimension is at minimum 2 pixel per plastic thread. Maybe I am getting it totally wrong, I may sand the product after printing and nobody will ever notice.

More opinions on sane dimensions are welcome.

Previewing in lower dimensions is fine. Can I make OpenSCAD deal with the PNG dimensions for the final render and STL-export?

Cheers
Marcus

Managementsummary: Would anybody help me confirm this is not a programming bug?

I was curious whether this is an out-of-memory issue or something else. I ran in valgrind

$ valgrind openscad 2022-10-01_surface.scad
==6099== Command: openscad 2022-10-01_surface.scad
==6099==
terminate called after throwing an instance of 'CGAL::Assertion_exception'
  what():  CGAL ERROR: assertion violation!
Expr: -CGAL_IA_MUL(-1.1, 10.1) != CGAL_IA_MUL(1.1, 10.1)
File: /usr/include/CGAL/Interval_nt.h
Line: 279
Explanation: Wrong rounding: did you forget the  -frounding-math  option if you use GCC (or  -fp-model strict  for Intel)?
==6099==
==6099== Process terminating with default action of signal 6 (SIGABRT)

I would like to confirm this does not happen with nightly and is dependent on my environment (Debian CGAL-Libraries, CPU, ...). But I recently failed to compile OpenSCAD, so I would like to ask anybody with nightly debug build: Can this behavior be confirmed?

Files for reproduction attached.

Cheers,
Marcus

Not sure about the crash, but surface() is not good with larger sizes.
Vague recollection of memory issues.

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

On 01.10.22 13:49, Marcus Poller wrote:

With the inherently high resolution your model has, I see only
one realistic chance but that's based on the experimental roof()
feature, so it's not possible for a script that needs to work
archived/unchanged for a long time.

• Convert all curves in the SVG to lines at a resolution as
  low as possible:
  Extensions -> Modify Path -> Flatten Beziers

• Use roof() import("file.svg") which will directly add the
  45° 3d structure

It's still going to be slow when combining that with the other
parts of the design. But on a system with enough memory in might
at least produce a result at some point.

ciao,
Torsten.

Yes, back in the day doing lithophanes. https://www.thingiverse.com/thing:78719/files
(wow almost a decade)
We lad to limit it ~100-200 x 100-200.
That was surface() with .dat (& 32 bit),
but I imagine the internals for .svg are not much better.

If you could answer the 'BTW' questions it may help re expectations.
Big and fine-detail tend to be bad.

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

On 01.10.22 14:37, Marcus Poller wrote:

Like the explanations says, this is a check in CGAL that verifies
the execution supports floating point rounding math settings.
Valgrind does not support that, triggering this assertion. This
does not happen on the real (Intel) hardware.

It's possible to disable this check by compiling with a special
define CGAL_DISABLE_ROUNDING_MATH_CHECK - I don't remember if the
cmake setup has explicit support for this (it's always added for
WASM compile as that does not support rounding math either).

I have no idea what subtle issues the disabled check will have
on CGAL algorithms. It will make them run, but there might be
differences in point classification producing different results.

ciao,
Torsten.

I'm also wondering if some external processing could be relevant.
Sanjeev's thingi, below, may be relevant.
I have not looked at it in detail, but offloading to python (?) may be good for details. ?????

======================

Dear All,

I have experimented with jupyter notebook to calculate points in space and then passing the same to
openscad for creating 3d shapes.

Found it to be quite interesting.

Wrote almost all the functions of openscad in jupyter notebook.

you can refer to the page below for few examples:
https://github.com/sprabhakar2006/openSCAD

you need to have some working knowledge of numpy and jupyter notebook for this to work.

Regards
Sanjeev

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

BOSL2 has some new texture support that seems relevant to this, though I'm
not sure if it can really solve the problem.  You'd have to compute the
surface somehow, and there might be issues with how the edges get created,
but it will create the shape as one polyhedron, so that should be about as
fast as is possible.

https://github.com/revarbat/BOSL2/wiki/skin.scad#function-texture

Note that the documentation for the texture stuff needs some work.  You can
create your own texture using an array or VNF---you don't just have to use
the built-in ones.

On Sat, Oct 1, 2022 at 9:24 AM Michael Marx michael@marx.id.au wrote:

I appologize, I haven't really been following this thread.

I guess @Marcus Poller:
By any chance are you trying to create terrain for Unity3D?  I have
a workflow process for that.

Alternately, if you're just trying to recreate an svg curve in

OpenSCAD, do you have a way to extract points from that curve and create a
cube or cylinder or sphere [x1,y1,0] for each point on the curve,
possibly rotated to angle with the last and next points?

Thus Torsten Paul hast written on Sat, Oct 01, 2022 at 03:07:53PM +0200, and, according to prophecy, it shall come to pass that:

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);
    }
  }
}

On 03.10.22 13:32, Marcus Poller wrote:

That's due to the extreme flattening causing self-intersections. You
can either use an additional small offset(0.1) to clean that up:

roof() offset(0.1) import("/tmp/holztextur_flatten.svg");

Or allow shorter segments for the flattening. Giving a value of 3.0
gave a still mostly rounded shapes with 21962 compared to 322372 of
the original SVG.

ciao,
Torsten.

Hi Michael,

Michael Marx wrote:

How did you create the image?
My errors are gone and its likely a combination of flattening_beziehers + offset(), I would like to confirm my assumption.

Cheers,
Marcus

Marcus,

That image is from 'netfabb Studio Basic' Repair option.
Unfortunately they (now taken over by Autodesk) don't offer the same post-trial Basic version any
more, and it cost an arm and a leg and your first born.
(tho they seem to offer free education licences, but you need to login for info)

If you want to post a .STL I can have a look.

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

In the beginning was The Mailing-list.

This was the support contact for the OpenSCAD User community, to the OpenSCAD Developer community.

It had a Mailing-list history archive.

Slightly before my time the private server hosting it lost a disc and said history was history.

As I understand it, this lead to finding a hosted provider and Nabble's price was right.

So a Forum was born, basically as a bonus from the new Mailing-list archive.

The Developer community kept their Mailing-list and any Forum posts
were nicely routed to them, they could reply to the User community.

I actually preferred the Nabble Forum and helped out with lost/orphaned/wayward posts.

That then lead to getting invited as a formal Admin and I took over much of the Nabble support.

Including signing up to Nabble's Support Forum and working with their Admin. They were usually
helpful.

Then, at practically no notice, they killed the email interface, basically to cut costs.

Hmmm, starting to turn into a novel...

Anyway see attached for some of the Nabble history and the owners (Franklin) attitude.

So as Jordan pointed out, it is probably the audience on the Mailing-list that you want access to.

That is the Development community, most (I haven't done a survey*, but certainly the core
Developers) like emails.

They don't have the time, or desire to regularly logon to a Forum and scan for anything they have
not seen.

That is the purpose of this environment, an avenue to the Developers, it has the incidental benefit
of Community support.

But there are many other Community support arenas available.

*Luckily Jordan did a nice job recently, summarising his survey, and listing these alternatives.
Please see attached.

I do have on my bucket list, finding a Mailing-list integrated Forum, as I mentioned I too do like
them.

But right now there are tooo many other things happening in my & the wider world. Same for the
other Admins.

If anyone has suggestions that are dirt cheap & easy to administer, let me know. No promises.

MichaelAtOz

OpenSCAD Admin.

p.s. I doubt anyone noticed, but I recently made the old Forum static,

no post or replies can be done and no new registrations. I have copied it for archival.

Nabble will likely want to delete it in the future.

p.p.s. As this topic erupts from time to time then goes around the same circles, I'm likely to
ignore another flare-up.

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

The short answer here is that although there are repeated requests  ways to
recreate a forum exist, reasons are systematically found why it is
“impossible”. Like for instance refusing to admit the existence of Google
groups.

This allows the same people here to shut up any legitimate conversation eg.
about 3D printing by claiming it is off topic for this list.

edmund

On Tuesday, October 4, 2022, Michael Marx michael@marx.id.au wrote: