arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
KimK has joined #openscad
markasoftware_ has quit [*.net *.split]
ali1234[m] has quit [*.net *.split]
Alexer has quit [*.net *.split]
redlizard has quit [*.net *.split]
cbmuser has quit [*.net *.split]
Alexer has joined #openscad
redlizard has joined #openscad
markasoftware has joined #openscad
cbmuser has joined #openscad
arebil has joined #openscad
ali1234[m] has joined #openscad
Cadair has quit [*.net *.split]
NoGare[m] has quit [*.net *.split]
Cadair has joined #openscad
NoGare[m] has joined #openscad
ChanServ has quit [shutting down]
ferdna has joined #openscad
ChanServ has joined #openscad
qeed has joined #openscad
qeed_ has quit [Ping timeout: 260 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
ur5us has quit [Ping timeout: 268 seconds]
ferdna has quit [Quit: Leaving]
hyperair has joined #openscad
<Scopeuk>
I am curious of the result, if something could generate overall shape as nearest primitive (cube/cylinder/cone/sphere) and a set of difference of primitives punching negative space that would be a good starting point for functional parts
<Scopeuk>
obviously it would fall appart for anything organic/sculpted
splud has quit [Quit: Leaving]
splud has joined #openscad
amahl has joined #openscad
arebil has quit [Ping timeout: 265 seconds]
mhroncok has joined #openscad
lastrodamo has joined #openscad
pah has joined #openscad
clemens3 has quit [Quit: WeeChat 2.7]
pah is now known as pa
<dTal>
I think it would fall apart for any design more complicated than a box with some holes in
clemens3 has joined #openscad
<Scopeuk>
true but for a good chunk of pure functional designs that will get you pretty close as a starting point
<Zauberfisch>
but I have another question: if I have a angled object and I want to join a flat object onto it, how do I get a good joint without it cliping either into the inside of the vent or not being jointed perfectly
<Zauberfisch>
I know I can use difference. is the solution that I copy paste line 15 and substract it from line 18?
<teepee>
the alternative to copy&paste is using modules which are special functions creating geometry so
<teepee>
module myshape() { cube(); }
<Zauberfisch>
ok, but having the same thing again just as a substraction is the right way to do this?
<teepee>
ok, back from meeting :)
<teepee>
subtract what?
<InPhase>
Zauberfisch: Yes, hollow by difference is the standard approach.
<InPhase>
Zauberfisch: Your scad life will get easier though when you start using varables for all those repeated values, and start calculating them by operations on the initial variables.
<InPhase>
Zauberfisch: Imagine you go to print it and discover it should be 123 instead of 124. :) Better to be able to change one value. Especially when you notice that changing the 124 changes the 0.542 and so on.
<Zauberfisch>
ok, thanks for confirming
<Zauberfisch>
InPhase: yeah, I have already switched to variables
<Zauberfisch>
being a software developer I do see the value of variables :)
<InPhase>
Excellent. :)
<Zauberfisch>
I just started using openscad. this is my first drawing that is not a single cube
<Zauberfisch>
so I used static numbers to test it in the beginning
<InPhase>
Zauberfisch: Repeated modules serve the geometric role of functions in code. And we have functions for calculations that are redundant. There are also list comprehensions analogous to Python's, but with very slightly different syntax.
<InPhase>
Zauberfisch: Modules can also operate on their syntactic children via children(), which lets them serve the role of operators.
<InPhase>
Thus ends the software developer level crash course description. Have fun. :)
<Jack21>
oh you are right in 2021.01 it is .. in 2021.09.18 it is not
<teepee>
that's quite a difference, still not expected
<Jack21>
2021.03 also not
<teepee>
that version does not exist
<Jack21>
2021.03.24 it says
<teepee>
looks like just nobody reported the issue yet, it's just a build issue
<Jack21>
probably not used very much -
<teepee>
yeah, seems like it
<Jack21>
also because it often take 10min to save a rendered geometry as 3mf
<Jack21>
(while other programs only need seconds )
<Jack21>
but a 30mb stl is only 3mb in 3mf (or something like that)
<teepee>
yep, different structure and automatic ZIP helps quite a bit
<teepee>
GUI now saves STL as binary by default which is also helping a bit
<Jack21>
so i take it that 3mf will be in future versions - glad to hear - Ü Thx
<teepee>
yes, it's probably just affecting the windows builds, for some reason it does not see the 3mf stuff and disables it
<teepee>
but that's certainly not how it should be
<teepee>
should be back in the next days I hope
<teepee>
yep, linux version works fine OpenSCAD-2021.09.18.ai8658-2021.09.18.ai8658-x86_64.AppImage
<teepee>
so the code is ok
<teepee>
ah, looks like some environment names changed
<Jack21>
amazing how fast issues can be fixed on this com channel, thanks to you
<teepee>
not fixed yet, but at least it's clear why it happens
<teepee>
just needs some changes to find the correct files
<Jack21>
is this just some general code for a 3mf module or does someone wrote this specific for openscad - what i want to know if there is hope that the performance improves as it takes sometimes more time to save then the render (so i save stl and convert in 3mf with e.g. meshmixer)
<teepee>
the main code is lib3mf officially maintained by the 3mf consortium
<InPhase>
I just retested import/export in the master branch (on Linux, compiled myself). Seems to work, runs fast, and is stable, so the build system fix should bring it back.
<Jack21>
appreciated - thanks
<InPhase>
Jack21: Is there a particular condition under which you found it slow?
<teepee>
there's some code to convert the data for use in the library, so there's some openscad code too
<InPhase>
Jack21: If you have an example design I'm willing to test that.
<Jack21>
InPhase: more or less everytime i render somthing more complex
<InPhase>
Jack21: Just many faces?
<teepee>
I suppose a couple of spheres with $fn = 500 might already be a first test case :)
<teepee>
I've never did measurements
<Jack21>
just tested a $fn=1500 sphere .. still saving (rendered fine in 0sec)
<InPhase>
I just reloaded a 21MB ascii stl with import, rendered, and hit 3mf, and it completed the save faster than I can measure. Definitely subsecond.
<Jack21>
just one sphere .. still saving
<InPhase>
That would be a 5MB binary stl if I had generated it with the recent code branches, for comparison.
<InPhase>
I will try the sphere.
<InPhase>
Okay, the $fn=1500 sphere was more like 1 second. But it dumped out a 31MB file, so there was probably a bit of calculation involved.
<InPhase>
Jack21: Which version are you running this test on?
<Jack21>
seems with 2021 this already improved .. with 2019 it took ages
<Jack21>
as it was gone (not shown) in the dev snapshot versions i could never test it since now
<Jack21>
(why i had to use still 2019 as 2021.1 didn't close proper an hence is not usable for me)
<teepee>
it's a zipped XML, so I don't know how the library handles that internally, but I would expect it to be reasonable
<InPhase>
Okay. So it tried, it just didn't find it.
<Jack21>
just so you know the 2019 version is still saving the sphere .. ( while the later test with 2021.1 finished long time ago)
<teepee>
yeah, I think the new cmake file does not read the path correctly
<teepee>
FindLib3MF
<InPhase>
Jack21: Was the 2021.1 at least on the scale of a few seconds?
<Jack21>
yes something like that
<InPhase>
Jack21: Okay, excellent. There might have been some changes to 3mf between those two. It was a long time and a pandemic ago. :)
<Jack21>
hehe
<InPhase>
Jack21: By doesn't close properly, were you getting hit by that segfault on close of 2021.01?
<InPhase>
I forget if it was that release which had that issue on Windows.
<InPhase>
I think that was fixed already in the master branch.
<Jack21>
something with that detached windows .. was fixed in the dev snapshots after 2021.01
<InPhase>
I think it's getting soon time for a new release. We've had some nice improvements, but there are maybe a few more small things that would be nice to fit in yet.
<Jack21>
(iam testing the snapshots from time to time to give you feedback if something is not as expected - but seems i just shouldn't use windows)
<InPhase>
I suppose the rendering speed boosts are not going to quite make it. That will require new eyes attending to it at some point I think. But we could still get that use<> performance boost in there which in some cases would be quite substantial.
<teepee>
aha, optimistic InPhase :)
<Jack21>
are you using multiple cores? (parallel )
<Jack21>
seen that request/feature long time in the pipeline
<othx>
that was last seen in #openscad 4 years, 19 days, 1 hour, 39 minutes, 19 seconds ago saying 'hey anyone know a program that can give me pictures of all angles of a cad model?'.
<InPhase>
botsnack! hahah
<InPhase>
botsnack!
<othx>
YUM! This is why I love #openscad.
<teepee>
so far there's 2 stuck attempts
<InPhase>
Jack21: I mean I have them, although OpenSCAD does not currently do a good job of taking advantage of multiple cores. Most of the heavy lifting comes from libraries that cannot utilize them yet. Although the CGAL library is working on that right now. It's probably wise to give them a brief window to get that stable though.
<InPhase>
Jack21: Once we finish cleaning up all this context mess, I think it will be more feasible to parallelize the computation side. We just need to actually keep the constants constant like we say we do.
<teepee>
we so need ochafik back
<InPhase>
Yes. His job was a huge loss to us. He should quit.
<Jack21>
probably not that simple as dividing the objects and render seperately and join together - i had projects where i just open several instances of oscad and every is using a core and renders a part
<teepee>
in theory, that's it, the devil is in those library data structures that are difficult to handle
<InPhase>
Jack21: For the calculation step, a pure declarative language should parallelize very well.
<InPhase>
Jack21: We had some... messy impurities, that make that not right. But they're being fixed.
<teepee>
true, but that's rarely the time expensive part
<InPhase>
On certain models it adds some time, but yeah, it's rarely the thing that makes people throw fits.
<InPhase>
I think there are some interesting designs coming out which utilize the calculation side more intensively though, so it will merit some attention.
<Jack21>
isn't the 3mf already checking for copied geometry for referencing instead of saving the data twice .. that should save render time aswell (if that is not already done)
<InPhase>
The more performant we can keep the calculations, the farther people will push that. In some cases, like those grammar generator recursive type items, the calculations take quite some considerable time.
<InPhase>
Jack21: Well I don't see any opportunity to optimize what I'm seeing in the master branch for 3mf. It's very fast on my end.
<Jack21>
what i ment was that the renderer does that first so 10 spheres take the same time like one sphere (btw. the 3mf test in 2019 is still saving the sphere - Ü)
<Jack21>
probably only would save time if the objects are not overlaping
<InPhase>
Jack21: I don't spot any PRs that should change the 3mf performance, but it was probably built with a very different version of lib3mf. Perhaps the upstream library improved significantly.
<InPhase>
There were some 3mf changes since then, but nothing that screams performance boost to me.
<InPhase>
teepee did sort the triangles and vertices... I suppose it's possible the library reacts differently after this? But probably not.
<teepee>
yeah, if at all, I would have expected things to be a bit slower
<teepee>
I don't remember which version of lib3mf was in 2019
<Jack21>
i am just waiting for the next snapshot and being happy then
<teepee>
yep, I guess it's not really important anymore, as long as it's exporting in reasonable time
<teepee>
oh
<teepee>
I know what that could be for a single sphere
<teepee>
it might have converted that to CGAL before export
<teepee>
the new export accepts both internal datastructures directly
<InPhase>
Ooooh, yeah.
<InPhase>
I see that now in your triangle sorting PR. :)
<InPhase>
There's a big whole mess of CGAL stuff removed.
<InPhase>
Now if we had good benchmarks, you would have noticed how good of a job you did. :)
<teepee>
well, it's quite a corner case, except with lazy-union in the dev snapshots
<InPhase>
This, three times on every triangle. O(N^2) I think. t.m_nIndices[0] = std::distance(vertices.begin(), std::find(vertices.begin(), vertices.end(), triangle.vertex(0)))
<InPhase>
You replaced that with a simple direct call.
<Jack21>
would it be difficult to give the color information to the 3mf lib to save them aswell?
<Jack21>
(maybe the STL button could change to 3mf too)
<InPhase>
We'd have to contemplate carefully what other tools out there are properly supporting 3mf.
<Jack21>
3mf also can hold license and designer of the geometry
<Jack21>
i just think this will be used in future - as fusion360 is not changing this lightly i assume
<InPhase>
Before taking "radical" steps like changing the button everyone is so used to pressing. :) Otherwise, the emails and complaints we would get over the button change.
<InPhase>
Yeah, I'm sold on 3mf is the future.
<teepee>
that's an easy one, keep default like it is, make toolbar configurable :)
<Jack21>
maybe in the expert mode a switch to change the button
<InPhase>
teepee: Configurable and default should be the one we think is right. :)
<teepee>
yeah, we can change the default later I suppose
<InPhase>
teepee: 95% of users just need the correct answers given to them.
<Jack21>
( when pressing stl an overlay "are you sure - 3mf is so much better -- wanna try" .. just kidding)
<InPhase>
Jack21: Industry change by harassment, yes. ;)
<Jack21>
embrace the future.. also saving multiple objects in a file could be nice (but that already works in stl just not with openSCAD)
<InPhase>
Scopeuk: Pretty much. :)
<Jack21>
multi material is also not that common
<InPhase>
Jack21: Multi-material and multi-color is the whole reason I'm embracing 3mf. We're not ready for it internally, but, this is the future.
peepsalot has joined #openscad
<Jack21>
Ü i know
mhroncok has quit [Quit: Leaving.]
peeps[zen] has quit [Ping timeout: 260 seconds]
<amahl>
being able to use different settings (like infill %, ironing) for different features sure would be handy. which is the same feature as multi-material and multi-color
<InPhase>
amahl: Yeah. And texture labels, like smooth versus rough, which are more computationally reasonable as attributes passed along to a slicer.
<InPhase>
These sorts of things are important for mechanical part design, in controlling where friction is low or high.
<InPhase>
Imagine a simple case of a rod embedded in another rod that you want to be able to grip and rotate. Knurling isn't as necessary if you can just control the texture.
peeps[zen] has joined #openscad
peepsalot has quit [Ping timeout: 265 seconds]
<Scopeuk>
Surface finish is an odd one. It functionally makes sense but model to real world i want as wysiwyg as i can have it
<InPhase>
Scopeuk: Which we can do by supporting textures in the opengl code as well.
<InPhase>
peeps[zen] was working on some nice stuff in that direction.
<Scopeuk>
Its an eco system thing at that point. Along with anything else that renders the stl (say the application i use to measure dimensions)
<InPhase>
Ultimately, the real value of this is multimaterial and multicolor, but that requires special printers. Texture is something we can hit already with the existing ones, so might come first. :)
<Scopeuk>
Sure, the variable infill/print settings i also like the idea of although i'm not certain as to when i would use it
<Scopeuk>
I do like the idea of cmykw printing but i'm to cheap/lazy and used to functional parts to put in the requisite effort
buZz has quit [Ping timeout: 265 seconds]
peeps[zen] is now known as peepsalot
<peepsalot>
Scopeuk, InPhase: a shader using normal mapping could probably be written to emulate printed layers
buZz has joined #openscad
buZz is now known as Guest1911
<Scopeuk>
It would look cool although to an extent i want to see what i ask the printer for (i fully acknowledge my recent wysisyg comment). Layer lines are a defect if only a mild one
Guest1911 is now known as buZz
<peepsalot>
guess i misinterpreted the conversation *shrug*
<InPhase>
I think visible layer lines would be pretty helpful in the design process actually.
<InPhase>
It really depends on how close it gets I guess, but on small parts almost any visual hints to where the lines would be could be a nice boost.
<InPhase>
There might be requirements for a valid result like bottoming your design at z=0, but I do that anyway to keep straight what's happening.
<InPhase>
Let me clarify that I usually would NOT want that. But that it would be really nice to be able to turn it on for certain designs.
<Jack21>
you could get that by intersecting the child with a layer cube and color it .. the result would be visible layers
<peepsalot>
i don't think CSG operations like that between different materials would be well defined. how would it know "layer cube" material takes precedence over default or previous material
<Jack21>
(i used this to color an object according to z so i can get an image to 3D engrave it with a 2D laser)
<peepsalot>
or, you mean a cube with a bunch of layers having gaps in Z?
ali1234 has quit [Ping timeout: 268 seconds]
<Jack21>
one cube is translated through the object by a loop while i gives the color([i/steps,i/steps,i/steps])
ali1234 has joined #openscad
<Jack21>
for layers you would just alternate the color i%2?0:1
<Jack21>
i mean it is only for the preview so doesn't affect the render
qeed has quit [Read error: Connection reset by peer]