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: