califax has quit [Remote host closed the connection]
califax has joined #openscad
J24k36 has joined #openscad
J24k78 has quit [Ping timeout: 256 seconds]
LordOfBikes has quit [Ping timeout: 244 seconds]
LordOfBikes has joined #openscad
sinned69158 has joined #openscad
mmu_man has quit [Ping timeout: 260 seconds]
sinned69158 has quit [Quit: Poof goes the quack]
sinned69158 has joined #openscad
sinned69158 has quit [Client Quit]
sinned69158 has joined #openscad
sinned69158 has quit [Client Quit]
myosotis has quit [Quit: myosotis]
<UltimateCodeWarr>
Is there a block diagram, a workflow of the code on how this Open Cad works?
<InPhase>
There are diagrams in the doc directory, although I think they are 2016 era.
<InPhase>
Some principles are still the same, but heavy refactoring has happened in the intervening 8 years.
<InPhase>
Plus many important new features.
<UltimateCodeWarr>
What I was expecting to see would be some sort of Rendering Transcript in the "Console" area, where it would say, Time to Parse scad model, 250ms Time to construct geometries ... 15 seconds, you know the major food groups, a profiling type thing so we would know when we added something to the diagram to make the engine choke.
<UltimateCodeWarr>
Then it might be a little less of a whodunnit murder mystery to isolate parts of the code that were non optimized, or struggling to keep up.
<UltimateCodeWarr>
I added one threaded hole, and the whole thing stopped rendering, it was taking 25 seconds to generate the 3D model, then one more ... the straw that broke the camels back.
<InPhase>
Well that wouldn't help too much. It's pretty rare to write OpenSCAD code that spends significant time calculating values. You have to do something uncommonly wild and recursive and some sort of extreme calculations well beyond what is normally done. This part is just very fast at normal scales of operation. Almost all time is spent rendering, and almost all of THAT time, on models that are
<InPhase>
frustratingly slow, is at the top level union of everything.
sinned69158 has joined #openscad
<UltimateCodeWarr>
I haven't looked at the code, but do they use the Math Functions like Sin Cos for everything or do they use look up tables?
<UltimateCodeWarr>
A look up table would be a hashmap to where if they said Sin(90) and it would just be an indexed lookup.
<InPhase>
There are two major exceptions to what I just said. One, is if you end up generating a cascade of undefined values that propagate through to your geometries, and you try to make a bunch of geometries with undefined values. This causes some really frustrating lags that I currently regard as a design-flaw type bug. We should really catch this case and just terminate.
<UltimateCodeWarr>
Rather than a computationally expensive call. It's a way to trade RAM for speed, but RAM is cheap these dasy.s
<UltimateCodeWarr>
(I get an OpenSCAD is not responding ....)
<InPhase>
The other, is if you happen to be running on a system with far too much RAM, and you start swapping, and even worse if you have a magnetic disk, a render can drag your entire computer to a crawl. This is not an OpenSCAD issue really, but just that computers of this design have a catastropic drop off of performance once the small RAM limits are exceeded.
<InPhase>
s/far too much RAM/far too little RAM/
<InPhase>
And lookup tables have not helped performance in like 10-15 years.
<InPhase>
Maybe 20. I forget when the exact inversion point was.
<UltimateCodeWarr>
well, the console should make it known to the user what is happening in the wiring under the board, and when various performance thresholds are breached.
<InPhase>
Specifically I mean trig lookup tables there.
<UltimateCodeWarr>
RAM has been getting faster and faster, I can't see how you can beat a lookup vs all the clock cycles it takes to perform complex math.
<UltimateCodeWarr>
Would be interesting to wrapper the Trig Calls with lets say a 4 digit precision LUT of their values, and see if it makes any substantial improvement. I bet it would.,
<InPhase>
Simple. RAM bus bandwidth hasn't kept up with processor parallelization. Lookup tables kill performance with cache misses, which can take much much longer to resolve than the calculation times.
<InPhase>
Whereas calculation on doubles has gotten highly optimized in processors.
<InPhase>
RAM heavy calculations are typically waiting on the RAM, as this is the slow bit.
<UltimateCodeWarr>
Well, what would be interesting to show is the times where each of these operations are taking place, and then work to optimize where the biggest speed hits are it. When it just delivers the generic " Rendering took 25 seconds" reminds me of the old 1980's Error 85
<UltimateCodeWarr>
If you did do some sort of benchmarking tests across multiple platforms, would be interesting to see if the there are performance penalties for using some sort of lowest common denominator common code portability module vs using real native calls.
<InPhase>
Lots of people do these tests. I've done it many times, which is why I stopped doing lookup tables. Whereas I used to rely heavily on them. I even wrote a guide to how to do them once in 2001, and distributed it to a bunch of people. It's obsolete now. :)
<InPhase>
If you want to speed up floating point calculations, vectorization is the modern solution.
<UltimateCodeWarr>
Above renders, in about 23 seconds on my system. Which is ....terrible for the number of parts I have, at least I would expect it to be more snappy. Now when I comment in the line on 287, single threaded hole, it locks up on Windows 11, no diagnostic as to what is going on, it just hangs.
fling has joined #openscad
<UltimateCodeWarr>
I got about 8 threaded parts.
<InPhase>
I cannot examine this file without knowing where you got "catchnhole.scad" and "knurled.scad"
<UltimateCodeWarr>
Not using either at the moment
<InPhase>
I typically put the urls to where I get each included library in a comment on the same line. This is a gift to yourself in the future.
<UltimateCodeWarr>
That's a good idea
<InPhase>
Okay, I'll comment those out.
<InPhase>
Okay, I get a 9 second render with the file as-is. Not shocking as this has 12 million facets.
<InPhase>
Let me try uncommenting this line 287.w
<InPhase>
It looks like you're doing one of the exception cases...
<UltimateCodeWarr>
I just want to make nut to fit on top of that hollow cylinder up highest on the Z-plane
<InPhase>
Yeah, so you see your translate at the top of plate_base that you sloppily left on the left unindented?
<InPhase>
That's closed on line 284.
<InPhase>
The variables you are using on line 287 are defined inside of this scope.
<InPhase>
So by the time you get to line 287, the variables you are passing into bare_threaded_hole don't even exist. They are undefined.
<InPhase>
So you are trying to generate a thread with undefined dimensions, and then doing a whole bunch of geometric calculations with nans.
<UltimateCodeWarr>
Isn't there some kind of 'pre-processor' that should kick in and say.... undefined variable, aboriting render?
<UltimateCodeWarr>
I mean the other stuff worked just fine, didn't have an issue.
<InPhase>
Me 25 minutes ago: "This causes some really frustrating lags that I currently regard as a design-flaw type bug. We should really catch this case and just terminate."
<UltimateCodeWarr>
xactly, some "Sanity Checks"
<InPhase>
It's not actually an issue unless you're calling some very complicated routines.
<InPhase>
But, you are, by passing this into an elaborate library, and unioning this with a whole bunch of other stuff.
<InPhase>
And so it explodes wildly out of control on an already heavy design.
<InPhase>
And... those checks are simply not in place. They should be now that designs are getting so complicated and heavy because OpenSCAD has gotten so much faster.
<InPhase>
So now we have this exception case where the "so much faster" vaporizes from the undef case in question.
<InPhase>
It's kind of a new problem to be this much of a change.
<InPhase>
And, the solution has not yet been sorted out.
<InPhase>
I move those 3 variable defines out of the translate scope, and your design goes back to 10 seconds to render for me.
<UltimateCodeWarr>
Ok, thanks for the fix, I appreciate it.
<InPhase>
You also have goofy looking threads disembodied threads floating in space. lol. But probably that was a poor set of parameter choices.
<UltimateCodeWarr>
I'm a noob trying to make an exploded view
<InPhase>
You'll see what I mean when you render it. :)
<UltimateCodeWarr>
It will end up looking something like some bicycle forks (I have to invert it) to where there will be eyelets in the forks to hold the camera housing.
<UltimateCodeWarr>
I want to be able to swivel the camera (pan left and right) and (up and down) and be able to lock it in position securely.
<UltimateCodeWarr>
And then I will be ready for your Gear library when that's realized (as you were mentioning earlier) If I decide to motorize it.
<InPhase>
I was mentioning never having made a gear library. :)
<InPhase>
But lots of other people have.
<UltimateCodeWarr>
Well you said you never had a need for one, well.... now you do :)
<UltimateCodeWarr>
What OS/Processor you using InPhase, your rendering times are really good.
<InPhase>
I picked up a Framework 13 with a Ryzen 7 7840U.
<UltimateCodeWarr>
Would be neat if the OpenSCAD had a benchie module, where it could ask for users to submit their stats.
<InPhase>
And it's running with DDR5-5600MHz for those RAM heavy bits.
<UltimateCodeWarr>
I'm on an ASUS I7-9750H UltimateCodeWarr 2.6Ghz 16 Gigs RAM / SSD
<UltimateCodeWarr>
Anyone using the "Apple Silicon" M2 Pro?
<InPhase>
UltimateCodeWarr: The RAM speed differences between yours and mine are probably the primary source of the ~2X performance difference.
<InPhase>
People are mostly focused on buying processors, but we're mostly sitting around waiting on RAM for this heavy stuff.
<InPhase>
I saw that most potently on my LLM work, so I made sure to get 64GB of the top speed DDR5 I could get. I got a big LLM performance boost, and OpenSCAD picked up good benefits as well.
<UltimateCodeWarr>
I have SODIMM 2667 MT/s
<InPhase>
Yeah. I saw that listed as the top speed that processor can work with.
<UltimateCodeWarr>
I was looking at some of those Mini PC's on Amazon: Beelink SER8 Mini PC some had the DDR5 / 64gb and the Ryzon 9 for under $1000
<UltimateCodeWarr>
If I could get a 3-400% boost in CAD speed, would be nice.
<InPhase>
Watch for which speed of DDR5, since it seems to make a wild difference, and usually at almost the same price. It's not worth going for the slower RAM.
<InPhase>
The 64GB of RAM I got currently retails for $17 more than the 4800MHz equivalent, which would be 15% slower.
<InPhase>
That's a massive performance difference for $17. :)
<UltimateCodeWarr>
That Envision S13 SFF PC on Amazon looks to be at a good price point, has the 5600 DDR
ccox has quit [Ping timeout: 276 seconds]
fling has quit [Ping timeout: 260 seconds]
<pca006132>
you can't judge performance by the number of parts...
<pca006132>
render time is typically proportional to the number of facets, and for threaded parts there can be many facets
<pca006132>
if you union two high-resolution spheres together, it takes time, and you can't say "just combine two spheres, how can this take several seconds?"
<UltimateCodeWarr>
Is there any best practices like : if (lowres) { cylinder() } else { threaded_cylinder() }
<UltimateCodeWarr>
Wish there was something automagic where it could have a call-out on each part for how much time it took and so you can take your most computationally expensive parts and either parameterize them for low res until time to bask in all it's glory
<pca006132>
typically either minkowski or things with many facets
misterfish has joined #openscad
<pca006132>
the main problem with timing each module is that... manifold does some tree-rewriting optimizations, with that the timing for each module can change
<pca006132>
depending on what you are unioning them with
<UltimateCodeWarr>
Another way to do things that would be nice would be to be able to switch between code-view, and part hierarchical view where you could hide/omit or show various parts, with a marco at the top, all off, all on for quick full / sparse renders.
<UltimateCodeWarr>
If you hid a part, it could show the last known good render of it instead of re-rendering it or something
<pca006132>
and looking at your comment about LUT... LUT can be slow when it is big, cache miss that causes DRAM access can take several hundred clock cycles
<pca006132>
there is already a geometry cache
<UltimateCodeWarr>
Ok, will glad you are leaving no stone unturned.
<pca006132>
but if something that changed intersects with something that was not changed, you still have to do boolean on them
<pca006132>
at least when lazy-union is not enabled
<UltimateCodeWarr>
Has anyone put together a block diagram of all the transformations that need to happen to go from source code to stl?
<UltimateCodeWarr>
And by source code, I mean the scad language
<pca006132>
it is too complicated and depends on the backend...
<UltimateCodeWarr>
Then it's going to be difficult to find talent to work on it.
<pca006132>
if you only consider manifold, typically it is like: identify all the potential intersections (coarse phase), figure out all the intersections, create new faces on the halfedge data structure
<pca006132>
and then do triangulation on the complicated new faces, perform simplification on the new mesh, remove unused vertices, compute normals etc.
<pca006132>
starting from the mesh simplification part they are sequential, because it is hard to parallelize, operations depends on each other
<UltimateCodeWarr>
Has the code ever been though any sort of profiling operation (3rd party tool) to try and identify any performance bottlenecks?
<UltimateCodeWarr>
I remember looking a lot of code where you would see things like: for (i=0; i< big_num; i++) { x = point[i].x = point[i].x* cos(90)+sin(30); point[i].y =point[i].y* (sin(90)+cos(30); }
<UltimateCodeWarr>
When asking the developer could it be optimized they would say, no it's as tight as possible.
<pca006132>
I wouldn't say that everything is as tight as possible in manifold, but if it matters to performance, we probably looked at it
<pca006132>
and compiler optimizations can pull things like cos(90)+sin(30) out of the loop
<pca006132>
parallelizing such a loop may or may not be beneficial, it really requires some experiment and compare the results
<UltimateCodeWarr>
Well, looks like that discussion said you sped it up by 1000% so, my hats off to you.
<UltimateCodeWarr>
The it's just 'processor bound' and the only thing that will help is a lot more horse power.
<pca006132>
there are still things we can do, but the remaining things are typically very hard to do
ccox has joined #openscad
<pca006132>
not low-hanging fruits
<UltimateCodeWarr>
lol
<pca006132>
and I wouldn't expect things to become magically faster by 10x for example, maybe 3-4x is possible
<UltimateCodeWarr>
Well, on to other aspects of the software then.
<UltimateCodeWarr>
I can barely use cad, let alone program it.
<pca006132>
from my experience you don't really need to understand the entire algorithm to optimize it
<pca006132>
looking at the profiling result, do some changes that preserves all behavior and things will be fine
<pca006132>
but if you want more, you will have to modify the algorithm, this is where things get a lot harder
misterfish has quit [Ping timeout: 260 seconds]
misterfish has joined #openscad
fling has joined #openscad
mmu_man has joined #openscad
L29Ah has left #openscad [#openscad]
L29Ah has joined #openscad
GNUmoon has quit [Remote host closed the connection]
<Guest40>
translate([5, 0, 0]) wall(0.1, 10, 3); // Tường bên phải
<Guest40>
}
<Guest40>
// Cửa sổ
<Guest40>
translate([-3.5, -5.1, 1]) window();
<Guest40>
translate([1.5, -5.1, 1]) window();
<Guest40>
// Cửa chính
<Guest40>
translate([-5.1, -1, 0]) door();
<Guest40>
// Bàn và ghế
<Guest40>
translate([-3, -2, 0]) table();
<Guest40>
translate([-2.5, -2.5, 0.1]) chair();
mtm has quit [Ping timeout: 264 seconds]
Ingvix has joined #openscad
mtm has joined #openscad
Guest40 has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #openscad
JakeSays has quit [Ping timeout: 246 seconds]
misterfish has quit [Ping timeout: 264 seconds]
snaked has quit [Quit: Leaving]
cart_man has joined #openscad
<cart_man>
Hey everyone. I know the author of this library is in this channel -> "gear_generator.scad" . Who was that?
<J24k36>
check for a name in the library
<InPhase>
I've never heard it mentioned in here by that filename until you brought it up the other day. I also don't know which gear generator you are referring to by that, as googling it finds tons of other gear generators that are probably not the one you are referring to. If you posted the file we might have an easier time sorting out who wrote it.
<cart_man>
J24k36: Dr Jörg Janssen and Contributions by: Keith Emery, Chris Spencer
<J24k36>
Jansens that is a good one .. have used it before
<InPhase>
Well it looks like Joerg Janssen wrote it.
<InPhase>
Yeah.
<InPhase>
Checking the chat log, it seems nobody mentioned it before except J24k36 was advocating for it before as a good gear library. :)
<J24k36>
hehe well it comply with DIN
<InPhase>
Oh, and gimzmoe used it once last year.
myosotis has joined #openscad
<cart_man>
InPhase: We have logs?
<InPhase>
Yes actually, in the topic. But more importantly, I have logs. ;)
<cart_man>
Can you make a module return earlier than the last line of the module? Like a return in a function that skips further steps in the same function?
<J24k36>
it will always execute as known before - but you sure can use switches
<cart_man>
J24k36: It is a bit confusing. I am not quite sure how I filter through tbhis array. It is not a switch as I know it? -> https://pastebin.com/YNjqYEV4
<J24k36>
the first needs to be ds not d
<cart_man>
J24k36: Ahh ok great!
<J24k36>
and as d will be one then the other .. you also get both echos
<J24k36>
the if needs to be if (d=="right") though
<J24k36>
probably easier to just change the loop to for (ds=d)
<UltimateCodeWarr>
I've seen that sort of thread on both weights, and house lifting jacks. It's better than some 'all thread' as it is more stout. I like to do tooless design as much as possible, and so anything that has enough grip to hand tighten and hold is a good thing.
<J24k36>
or one Roof(10,[1,1])difference(){ WKreis(5,20,grad=120); circle(15); } Gewinde(winkel=30,innen=true,kern=26,ratio=0.75,dn=30,p=5,dicke=3,center=0);
<J24k36>
with UB.scad
<UltimateCodeWarr>
That's Awesome!
<J24k36>
but it is just rough estimate - would need to measure the dimensions
<UltimateCodeWarr>
Thx J24k, incorporated those 5-sided spinners
<UltimateCodeWarr>
The other thing I was looking for was Special Kind of Knurling, like a Radial Knurling where when you want two parts to be squished together, a little extra grip to make them stay together is great. Something like: