<lf94>
It could be really nice experiment to re-impl openscad's lang on top of one of these
<lf94>
clean re-impl
<JordanBrown[m]>
OpenSCAD's performance problems do not normally derive from an unclean implementation of its language. The time spent executing the program is normally (not always, but normally) negligible. The bulk of the time is normally spent doing the boolean geometry operations, which is all inside CGAL. If you don't have a faster geometry engine, you won't see a performance improvement.
ur5us has joined #openscad
<JordanBrown[m]>
In fact, we can now experiment with that directly - the python-support branch will let you run your program in Python, generating the same sort of CSG tree that OpenSCAD-language would generate and processing it through the same geometry engine.
<lf94>
Yes, that's what I meant earlier. CGAL must be replaced.
<lf94>
I don't blame OpenSCAD itself but this library
<lf94>
Hell we could do a CSG based on cubes only because for 3D printing your cubes only have to be as tall as your layer height.
<lf94>
And the intersection and difference becomes trivia
<JordanBrown[m]>
My print volume is approximately 10 gigavoxels.
<lf94>
and with backface culling it'll be even better
<JordanBrown[m]>
but we are already not bad at preview. It is full rendering, where we need to know the front, back, and insides of the object, where we have performance problems.
<JordanBrown[m]>
but 10 gigavoxels is actually not a ridiculous volume to work with.
<lf94>
1.4GB of memory to store all the bits to represent each block in space of my printer
<lf94>
actually that's not right, because 0.2 only applies to the height
<lf94>
My nozzle width is 0.6
<JordanBrown[m]>
but your XY positioning is probably finer than your nozzle width.
<lf94>
Ah true
<lf94>
0.2 is probably fair, if not probably off a bit
<JordanBrown[m]>
and it's monochomatic; you forgot to divide by 8 bits per byte.
<lf94>
whoops, my bad; so that's to store each block of space as one byte :)
<lf94>
so that's great
<lf94>
what do we need to store in one byte
<lf94>
probably nothing
<lf94>
1 bit is enough
<lf94>
either block is there or not
<JordanBrown[m]>
My printer is 250x200x200 and 0.1 x 0.1 x 0.1 is 10 gigavoxels is 10 gigabits.
<lf94>
1.25gb
<lf94>
really great honestly
<lf94>
Most cases are definitely not using their entire build volume
<JordanBrown[m]>
Performance characteristics would be ... different. Currently rendering one cube is nearly free, and the union of two cubes is very cheap, but in a voxel world it depends on the sizes of the cubes.
<JordanBrown[m]>
Also you'd have to be able to convert voxels back into triangles to export as STL.
<lf94>
The sizes will all be the same for us, and we can optimize in a shader by using large neighbor sizes
<lf94>
Surely there's a way to go from GPU -> file geometry?
<lf94>
I was thinking of rendering the bits in a shader
<lf94>
and then export the resulting mesh
<JordanBrown[m]>
No idea.
<lf94>
hoping the GPU will do the inside culling
<lf94>
and we can just export the surface
<JordanBrown[m]>
Standard GPU operations only care about turning the front into pixels, not about figuring out what's going on in the back and the inside. GPUs can be used for other parallel-intensive tasks, but they would be totally different algorithms.
<lf94>
hm, yeah, I'll have to use compute shader then
<lf94>
lol, render it all in blender or similar.
<lf94>
any modeling program that can programmatically create cubes
<JordanBrown[m]>
Sure, you could stupidly emit the exposed sides of each voxel, but that's an awful lot of triangles.
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
<lf94>
makes me think signed distance fields could be useful here
<lf94>
telling me exactly which cubes i need to emit for their surface
<JordanBrown[m]>
Beyond me.
<lf94>
Using a neighboring algoritm im sure that's enough to omit cubes
<lf94>
"if this cube is surrounded on all sides, omit it"
<lf94>
(from being rendered)
<JordanBrown[m]>
Sure, emitting only exposed sides is easy.
<JordanBrown[m]>
but a 200x250x0.1x0.1 area is 10 million triangles.
<JordanBrown[m]>
Of course, surfaces aligned on XYZ are more or less easy to recognize and optimize away. It's the surfaces that are flat but are not aligned on the axes that are harder to recognize.
<lf94>
they'll be aligned to a grid for sure though
<JordanBrown[m]>
Well, sure, but with jaggies.
<lf94>
that's fine, everything is jaggy when you look close enough :2
<lf94>
:)
<lf94>
when you 3d print, it's the same story
<lf94>
we're at an advantage because we can cap the resolution
<JordanBrown[m]>
Eh... I think diagonal motion on a 3D printer may really be diagonal.
<lf94>
that's from the slicer
<JordanBrown[m]>
And the slicer doesn't get it from the triangles in the model?
<lf94>
they get it from the shape of the model
<JordanBrown[m]>
One could imagine a scheme that detects corner voxels and clips off the corner. That would help. (But would introduce more triangles.)
<JordanBrown[m]>
And it is turning a pile of voxels back into a shape that is exactly the problem :-)
<lf94>
I mean there are triangle reduction algorithms too that can be used when exporting to a mesh
<JordanBrown[m]>
I'm sure this is a well-explored area. Just not by me :-)
<lf94>
yeah.
<JordanBrown[m]>
Hmm. One problem is when you have transforms outside your booleans.
<JordanBrown[m]>
scale(10) union() { a(); b(); }
<lf94>
:s yikes, yes
<lf94>
well
<JordanBrown[m]>
if you convert a() and b() into voxels to do your union, then your scale will give you big voxels.
<lf94>
i guess it cant be a direct openscad impremevent then
<lf94>
improvement*
<JordanBrown[m]>
What we need is somebody who understands 3D algorithms and GPU programming to reimplement CGAL functionality on a GPU.
<JordanBrown[m]>
Probably need a small army of PhD students for that.
<lf94>
Yeah my ideal CSG impl is one that a single person can do
<JordanBrown[m]>
Hmm. Booleans are, I think, distributive with transforms. You can, I think, convert scale(10) union() { a(); b(); } into union() { scale(10) a(); scale(10) b();}. Repeat until you've pushed all of the transforms to the bottom.
<lf94>
yes, what I was thinking
<lf94>
brep+voxels is interesting
LordOfBikes has quit [Ping timeout: 246 seconds]
LordOfBikes has joined #openscad
<JordanBrown[m]>
InPhase, teepee: https://github.com/jordanbrown0/Train has my model train program implemented using separate-objects-and-geometry, and using hybrid-objects-and-geometry.
<JordanBrown[m]>
I tried to just change syntax, but as I was doing it I did see a few places to make it better. The hybrid syntax made it more obvious when I should make a global variable instead be a property of an object.
linext_ has quit [Quit: Leaving]
<JordanBrown[m]>
For instance, truck is a railroad car truck. In Train.scad it is a geometry object with a couple of accompanying globals that describe its dimensions; when I converted it over to hybrid it became obvious that those should be properties. I could of course have done that in the "separate" version too, by having truck be an object with a "model" or "geometry" property that contained the actual geometry, but I didn't think of it - the
<JordanBrown[m]>
hybrid version seemed to make it more obvious that I should do that.
<JordanBrown[m]>
Train.scad is the original; Train2.scad is the hybrid version.
<JordanBrown[m]>
OTOH note that in steamLoco() the wheels array really should be local, but is exported to the resulting object. I could move it to the "let" block in front of the object, or put it inside something that would create a new scope, but both of those seem like alien answers.
<JordanBrown[m]>
The hybrid style requires a semicolon at the end of a list of object properties. {( a=1; b=2; )}. Of course it also *allows* a semicolon there, without it being sort of a special case, so when you add c=3 you don't have to remember to add a comma on the previous line.
<JordanBrown[m]>
Also, of course but not entirely obvious, the hybrid version had a lot of lines with one fewer level of indentation, because geometry inside an object was one level rather than two.
<JordanBrown[m]>
I did want a "has_geometry" function of some sort to distinguish objects with geometry from objects without. I didn't *need* it, because in the relevant case objects have a "length" property iff they have geometry.
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #openscad
milza1 has joined #openscad
milza has quit [Ping timeout: 252 seconds]
milza1 is now known as milza
ur5us has quit [Ping timeout: 255 seconds]
retrosenator has quit [Read error: Connection reset by peer]
Junxter has joined #openscad
J2359111763 has joined #openscad
J23591117 has quit [Quit: Client closed]
ur5us has joined #openscad
use-value has quit [Read error: Connection reset by peer]
califax has quit [Remote host closed the connection]
califax has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
castaway has joined #openscad
KimK has quit [Read error: Connection reset by peer]
Junxter has quit [Read error: Connection reset by peer]
Junxter has joined #openscad
KimK has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
guerdy has quit [Read error: Connection reset by peer]
guerd87 has joined #openscad
guso78 has joined #openscad
<guso78>
right now experimenting with path_extrude, which shall extrude a 2d Profile along a 3d curve in space. Maybe its possible to have a set of 1d object functions analog to the 2d(circle, square). Maybe 'line' 'arc' 'spline' 'parabolic' 'chain-line' are imaginable ...
<guso78>
JordanBrown[m], which brand of printer do you have and are there special reasons for your decision ?
<guso78>
JordanBrown[m], i am really interested in getting an windows executable of the python branch even when its probably not at edge of development. how can i get it ?
splud is now known as NeuroDeviant
retrosenator has joined #openscad
<Scopeuk>
guso78 pull requests on github trigger the ci which does builds
<Scopeuk>
I've not tested it to see if there are external dependencies etc which it doesn't currently bundle
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<guso78>
Scopeuk,Thank you, will have a look!
use-value has joined #openscad
<guso78>
Scopeuk, i had a look! It appears, that this version of openscad was compiled without the -DENABLE_PYTHON compile time switch, so all python and everything is just disabled.
<guso78>
Last but not least: Shame on me, i was not able to spell my Name correctly in the AboutDialog. Maybe you want to restructure the order/hierarchy anyway ?
<Scopeuk>
I forgot about the extra compile time switch, not sure if we could push that through on the branch build files to force the ci to generate it, other than that it would be replicating the windows build enviroment (it runs under linux by default and there is a setup script)
<Scopeuk>
that does take a long time to build if I remember correctly however
<guso78>
Scopeuk, i was actually wondering that a Windows build does exist and does work, so i was impressed. Knowing now, that python is disabled, now i understand.
<guso78>
I understand that its a big decision do offer one extra set of downloads for the python. Also I understand that nobody wants to have "evil Python" compiled in by default. So i am wondering which chance python has to reach the people. ( I believe it should get a chance)
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<teepee>
I don't see a problem with compiling that in for the nightlies once it's merged to master
<teepee>
that's why we have the enable switch
<teepee>
we "just" need to figure out how to package things so it's working on other systems
<Scopeuk>
I guess it's mostly dll dependencies on windows?
<Scopeuk>
I think JordanBrown[m] has had it running on windows with a bit of fiddling arround
<guso78>
yes python adds just one more python dependancy . believe it was 15 or more already ....
<Scopeuk>
if it is just dll's then (licences permitting) we can bundle the dll's in the exe directory, if my windows call tree recolection is correct it tries exe directroy -> system path -> user path when searching for references
<Scopeuk>
guso78 this is runtime dependencies for the absence of doubt, rather than build deps
<guso78>
what are the license restrictions in openscad ? I read about the CGAL special permission
<teepee>
anything compatible with GPL3+
<teepee>
openscad itself is GPL2+ but CGAL makes the binary GPL3+
<guso78>
i believe especially QT needs a special setup to "run". this special set up the presence of files (fonts, etc )
<guso78>
... is the presence ...
snaked has quit [Remote host closed the connection]
snakedGT has joined #openscad
<teepee>
I don't know about that, we use the open source version which is compatible license wise
<guso78>
need to read in to GPL2+ and GPL3+ , never cared before
<guso78>
teepee, i have seen getting --enable-python running in command line mode was on your task list. you can find the solution in openscad.cc in my python branch
<Scopeuk>
generally things are a bit fuzzy around dynamic linking although I think gpl3 tightens that a little, the licencing faff is something I accept as necessary but I dislike
<teepee>
guso78: you can post smaller changes via PR against the still existing python-support branch
<teepee>
I'm not going to have much time for a couple of more days though
snakedGT has quit [Ping timeout: 260 seconds]
<guso78>
how can i PR small "features" of my branch to python-support in git / github. is this related to cherry-pick ?
<teepee>
create a branch in your local repo based on the upstream/python-support branch
<teepee>
add things in that branch, maybe by cherry-pick from somewhere else
<teepee>
if you push that to github it should offer creating a PR automatically
guso78 has quit [Quit: Client closed]
snakedGT has joined #openscad
snakedGT has quit [Ping timeout: 246 seconds]
snakedGT has joined #openscad
NeuroDeviant is now known as splud
epony has quit [Quit: QUIT]
L29Ah has quit [Read error: Connection reset by peer]
L29Ah has joined #openscad
<JordanBrown[m]>
guso78: CraftBot+. Recommended by the 3D printer store. I do like the closed-frame design and the fact that it moves the head in XY and the bed in Z, rather than moving the bed in Y. But I do not have any experience with other brands to compare. https://craftbot.com/products/craftbot-plus-pro
<JordanBrown[m]>
guso78: How to get a Windows executable? Install MSYS2 and build it.
<teepee>
question is more how to officially release, not so much self-build
<teepee>
the easiest way is for the normal linux packaging as we can just declare the dependency and get the correct version
<teepee>
it gets more interesting with AppImage and Snap/Flatpak and of course the other platforms
<JordanBrown[m]>
On Windows there don't seem to be any DLLs currently distributed with the release build of the program. ntldd shows it using a pile of DLLs from Windows. It does show using OPENGL32.DLL from \msys64, but I suspect that's an artifact of the fact that I'm running ntldd under MSYS2; OpenSCAD certainly doesn't require MSYS2.
<JordanBrown[m]>
That's not to say that it *can't* bundle DLLs, just that it currently doesn't.
L29Ah has quit [Read error: Connection reset by peer]
guso78 has joined #openscad
_xxoxx has joined #openscad
Junxter has quit [Ping timeout: 252 seconds]
snakedGT has quit [Remote host closed the connection]
snakedGT has joined #openscad
snakedLX has joined #openscad
snakedGT has quit [Ping timeout: 246 seconds]
<Scopeuk>
JordanBrown[m] OPENGL32.dll is a base part of windows and is part of the abstraction before the graphics drivers
snakedLX has quit [Ping timeout: 256 seconds]
linext has joined #openscad
<linext>
i'm confirming that an amd 7950x renders STL files more than twice as fast as an intel i9-9900k
<teepee>
but seeing issues in some corner cases - one idea is that the logic roof() uses would help solving those issues
<guso78>
teepee, another issue which i was always missing is offset in 3D style(not 2D) its geometrically well defined , but lot of pitfalls to obey
<teepee>
as it keeps points correlated when offsetting
<teepee>
yes, keeping good geometry is much more difficult than obvious at first glance, and CSG processing usually needs good, non-self-intersecting geometry
snaked has joined #openscad
<guso78>
you can always do union on an self-intersecting object and you will get a manifold object, which tells the mathematical truth ...
<guso78>
union keeps the "voxels" once the overlap count >= 1
Guest27 has joined #openscad
snaked has quit [Quit: Leaving]
Guest27 has quit [Quit: Client closed]
snaked has joined #openscad
<JordanBrown[m]>
There are any number of libraries that do "sweep a 2D object along a path".
<JordanBrown[m]>
guso78: Minkowski is, I believe, a generalization of offset in 3D.
<JordanBrown[m]>
Scopeuk: Yep, and yet there's one supplied by MSYS2 too. I noted it because ntldd reported it, but like I said I'm confident that OpenSCAD does not rely on the one supplied by MSYS2.
use-value1 has joined #openscad
use-value has quit [Ping timeout: 256 seconds]
use-value1 is now known as use-value
snaked has quit [Quit: Leaving]
_xxoxx has quit [Read error: Connection reset by peer]
<JordanBrown[m]>
I think that Minkowski with a sphere is precisely offset in 3D.
<teepee>
if you want the rounding and limit to positive offset :)
<teepee>
as we only have minkowski sum
<JordanBrown[m]>
Yes, I was thinking only of simple offset.
<JordanBrown[m]>
Minkowski difference is just the complement of the sum of the complement, right?
<JordanBrown[m]>
that is, subtract your object from the universe, minkowski-sum, subtract that from the universe.
guso7841 has joined #openscad
teepee_ has joined #openscad
guso7841 has quit [Quit: Client closed]
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]
<guso7878>
Is Minkowski Difference usable in OpenSCAD
<guso7878>
?
hrberg has joined #openscad
<guso7878>
I have another more straight forward Idea to so the Offset in 3d
<InPhase>
guso7878: Sure. But runtimes can grow quickly given the way it grows rapidly in facet count.
<guso7878>
My Plan ist to move the Planes Up or down along their normal and recalculate the Edge Points.
<guso7878>
Its Cuts of 3 or more Planes each
<guso7878>
And yes i will Not get the roundings
<guso7878>
I am mainly Interesses in negative offsetting existing stls to untighten existing joint-fittings
guso7878 has quit [Quit: Client closed]
guso7818 has joined #openscad
teepee has joined #openscad
guso7818 has quit [Ping timeout: 260 seconds]
retrosenator has quit [Remote host closed the connection]
guso7848 has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 260 seconds]
ToAruShiroiNeko has joined #openscad
Guest38 has joined #openscad
guso7848 has quit [Ping timeout: 260 seconds]
ToAruShiroiNeko has quit [Ping timeout: 246 seconds]
Guest38 has quit [Quit: Client closed]
ToAruShiroiNeko has joined #openscad
guso7867 has joined #openscad
buZz has quit [Ping timeout: 252 seconds]
guso7867 has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
buZz has joined #openscad
buZz is now known as Guest578
snaked has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
peeps[laptop] has joined #openscad
<peeps[laptop]>
there isn't really a way to directly do minkowski difference (or negative 3D offset) through user scripts. since complement isn't a supported operation
<peeps[laptop]>
i mean, you can kind of do it by picking an appropriate sized bounding box and subtracting from that, but its rather fiddly. also in some of my experiments, repeated application of minkowski often ends up with geometry errors
<peeps[laptop]>
our 2D offset is (in terms of morphology) is equivalent to "dilation" when offset is positive, and "erosion" when offset is negative
<peeps[laptop]>
the other basic operations which would be nice to nateively support, in 2D and 3D, would be "opening" and "closing" (basically rounding the convex and concave vertices of an outline, respectively)
<peeps[laptop]>
...without otherwise affecting the overall size of the object
qeed has quit [Remote host closed the connection]
qeed has joined #openscad
lostapathy has quit [Ping timeout: 246 seconds]
<InPhase>
Oh, you meant literally the opposite direction of minkowski.
<InPhase>
I was answering assuming you meant a difference() combined with minkowski().
<InPhase>
I have done this numerous times to make things like shells of other objects.
lostapathy has joined #openscad
milza has quit [Quit: milza]
guso78 has quit [Quit: Client closed]
teepee has quit [Remote host closed the connection]