teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
JordanBrown2 has joined #openscad
teepee_ has joined #openscad
juri____ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
juri_ has quit [Ping timeout: 255 seconds]
JordanBrown2 has quit [Ping timeout: 252 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
kintel has joined #openscad
<kintel> pca006132 VBO preparation is just really slow. I'll continue refactoring the code to reduce the number of options and different code paths, then block the feature on performance improvements.
<kintel> I think, however, that the critical path is going to be per-frame performance, not preparation performance. ..but today's performance feels way low for larger designs.
kartheek has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
LordOfBikes has quit [Ping timeout: 256 seconds]
LordOfBikes has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<pca006132> kintel: tracy does record stack frame, but for the best result you need to specify things like -fno-omit-frame-pointer
<pca006132> and there are instrumentation macros for recording the precise stack frame
<pca006132> but they are quite slow
<pca006132> yeah, I think performance improvement for VBO can be done later
<pca006132> making thing simpler can help future optimization as well
J23k12 has joined #openscad
J23k83 has quit [Ping timeout: 250 seconds]
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #openscad
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #openscad
<pca006132> and also I think a major issue is the 10k calls for create_vertex, wonder if it can be optimized a bit...
<pca006132> there are only 300 calls to draw triangle in the older renderer, for the example I was using
mmu_man has quit [Ping timeout: 276 seconds]
JordanBrown2 has joined #openscad
hyperair has quit [Ping timeout: 276 seconds]
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #openscad
hyperair has joined #openscad
hyperair has quit [Ping timeout: 246 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
hyperair has joined #openscad
<JordanBrown2> teepee I think I have a fix that handles the \r-only case. I want to do a little more testing and then I'll push it.
<JordanBrown2> Follow-on project, maybe: what's the minimum Bison version that we require? It seems that Bison 3.8.1 (ca 2021 if I read and remember correctly) adds better support for tracking locations of parse constructs.
JordanBrown2 has quit [Ping timeout: 256 seconds]
kartheek has quit [Quit: Leaving.]
<J23k12> Still needing 6 more designs for SCADvent
fling has quit [Remote host closed the connection]
fling has joined #openscad
fling_ has joined #openscad
fling has quit [Ping timeout: 240 seconds]
fling_ is now known as fling
fling has quit [Remote host closed the connection]
fling has joined #openscad
mmu_man has joined #openscad
teepee_ has joined #openscad
foul_owl has quit [Ping timeout: 276 seconds]
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
foul_owl has joined #openscad
<gbruno> [github] HyperWinX opened issue #4893 (Artifacts when rendering small project with a lot of vertices) https://github.com/openscad/openscad/issues/4893
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<J23k12> pca006132  do you think https://github.com/openscad/openscad/issues/4893  is a bug with manifold - it is working fine with the 2023.11.23 build  - and as this using recursions it may be similar the  issue i had
<pca006132> I just tried, it works fine with latest master
<pca006132> the recursion precision issue was fixed in previous update of manifold
<pca006132> from the rendering time (32 minutes), I think it is not using manifold
<J23k12> oh you are right but the  details listed "Features: fast-csg, fast-csg-safer, fast-csg-debug, manifold, …"
<pca006132> and to trigger that precision bug you need to apply something like 120 transformations to a mesh, this recursion is really shallow
<J23k12> was worried if 2023.12.05 had another issue
<pca006132> I am not entirely sure about the precedence of manifold over fast-csg
<pca006132> on my machine the model took ~6s, I think even if the computer is slower it should not take 32 minutes for manifold to render that...
<J23k12> hm i thought manifold but need to check
<pca006132> I think the list of features is just something that list all available features
<pca006132> not things that are enabled
<pca006132> it is the output from `openscad --info`
<J23k12> fastCSG and manifold - uses » Rendering Polygon Mesh using Manifold...
<J23k12> ah oh that  is terrible for debugging  if we don't know what was active to replicate
<pca006132> indeed
<J23k12> ah activated features have a *  (at least in the gui)
<pca006132> I think the output in the issue has no *
<pca006132> so it is either the cmd output or it is GUI with no experimental features enabled
<J23k12> yes  - so his comment "activated all features"  was the change/fix and not the source of the issue
<J23k12> which also means that  the CGAL renderer seems to have an issue with these resolutions /size settings
<J23k12> I tried it but it is still rendering (989/1000)
<InPhase> Maybe the settings for rendering system should be radio buttons instead of checkboxes...
<pca006132> yeah, I think this is the direction to go
<pca006132> also, I am not sure if this is caused by CGAL renderer or recent refactoring(s) we did, as the version in the issue is very new
<J23k12> would be less confusing for  "fastCSG" "fastCSG-safe" .. as you don't know if this safe is additional or exclusive
<pca006132> btw I have no intuition about the progress bar
<pca006132> iirc it is not very useful for indicating the progress
<J23k12> yes depends on the design - often the last % is a union that takes a lot time
<pca006132> at least I am pretty sure that this does not work for manifold, manifold evaluates the CSG expression lazily
<pca006132> so boolean operations are instant, you just pay for them later
RichardP_ has joined #openscad
RichardPotthoff has quit [Ping timeout: 260 seconds]
<gbruno> [github] HyperWinX closed issue #4893 (Artifacts when rendering small project with a lot of vertices) https://github.com/openscad/openscad/issues/4893
<gbruno> [github] Alex-Kent opened issue #4894 (Optional split editor pane) https://github.com/openscad/openscad/issues/4894
<J23k12> so 4893 rendered with CGAL but  scad is now frozen and can't be used anymore
<J23k12> This may be still a bug  - as the issue is now closed by using a workaround doesn't fixed the issue with CGAL
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
<J23k12> hm maybe this is just a memory issue as that design require multiple GB RAM in CGAL
<pca006132> do you have VBO enabled?
<pca006132> or using the old renderer?
<J23k12> with VBO
<J23k12> but the recursive grid seems to be super slow
<J23k12> i am at 6GB and only 1/10 progress
<J23k12> so i assume this killed the render on #4893 with 16GB ram
<J23k12> 25% 8GB
<J23k12> 45% and 22GB
<J23k12> i wonder is there a limit for triangles on a render in SCAD?
<pca006132> probably no...
<pca006132> ah, I guess the problem is render but not preview
<pca006132> have to say that the terminology for render and preview is extremely ambiguous
<J23k12> and he used "render()" in the preview
<J23k12> 73% 37GB
<pca006132> ah
kintel has joined #openscad
<J23k12> 98.5% 50GB
<J23k12> I wonder if  contests  for SCADvent are the way to go -  but  we get some creative code https://www.reddit.com/r/openscad/comments/18c3xu5/comment/kcs6if4/?context=3
<teepee> but how to do that without basically posting all the desings upfront anyway
<kintel> pca006132 With the VBO performance issues added to the mix, I feel it's even more important to set up some more structured performance testing tools. The stuff that ochafik was working on might be a good starting point
<J23k12> teepee only if they are submit to a non public location
<teepee> hmm, that makes communication a bit more complicated, only mail comes to mind as easy way
<pca006132> for performance testing do you mean benchmark suite?
<J23k12> teepee or a submit web form.
<teepee> I guess we could create that
<J23k12> with a check that a license and name is present - Ü
<kintel> pca006132 also, the draw_triangle analysis is odd - I suspect completely different code paths were taken, so counting those calls may not be representative
<pca006132> ok
<pca006132> btw can opengl draw the buffer on a worker thread, and only swap it on the GUI thread?
<pca006132> that way the GUI will not freeze
<J23k12> teepee  more "average"  user code is maybe to that bad - it sure is nice to have sophisticated solutions but  simpler versions that are easy to understand are adding value too
<J23k12> s/to/not
<teepee> I totally agree, which is why I do like the simpler designs too, like the math thingies we had a while ago
<kintel> pca006132 yeah, I meant the benchmark scripts that ochafik wrote to test the geometry backend
<kintel> Multi-threaded OpenGL isn't something I'd recommend doing, but it's technically possible if we carefully set up separate contexts per thread and synchronize any sharing of GPU resources
<kintel> It's not OpenGL calls that are expensive with VBO enabled though, it's the CPU stuff. Rendering is actually incredibly fast
<pca006132> yeah but the problem is that those CPU stuff are blocking the GUI thread
<kintel> right, so any CPU stuff can be farmed out.
<kintel> ..but we may want to do that with render() in preview mode as well
<pca006132> anyway I think this can be left for later
<pca006132> looks complicated
<kintel> heh, a lot of that stuff is complicated, but with food refactoring it can be made more manageable
<pca006132> btw I was thinking about the updater, not sure if Qt networking can do async request and get a popup window stuff
<pca006132> not familiar with GUI stuff (used to write .net GUI but it was a long time ago)
snaked has quit [Quit: Leaving]
<kintel> pca006132 should be doable. We're practically only going to check at most once per startup, and likely less often
<kintel> ..but it's annoying to write GUI code in OpenSCAD as we don't have any automated tests
<kintel> VBO looks generally faster for our test cases though, so this strengthens the argument that the root cause is algorithmic complexity, not just overhead
<kintel> With indexed PolySet I'm sure we can rewrite VBO preprocessing to
JordanBrown2 has joined #openscad
<kintel> *too
lastrodamo has joined #openscad
<teepee> if that's lawyer safe, I don't know, but I would not care too much if people posted with an alias and declared it as such
<teepee> same happens on Printables too essentially
<teepee> and we have one of those by Scopeuk already too :)
<J23k12> well guess someone also need to check if that code is not just copied from anywhere posted with a different license ( as seen on printables)
<InPhase> teepee: Pseudonym copyrights are valid, but they simply alter the duration of copyright.
<InPhase> At least within the US this alters the duration.
<InPhase> However those durations in both cases are long enough that we will probably all be dead before the difference matters, so we'll leave that problem to someone else.
<teepee> argh! off-by-one error: https://imgur.com/a/5fTK0G8 :)
<InPhase> And with CC0, probably nobody cares, because after expiration, it goes from CC0 which is licensed like public domain, to actual public domain.
<J23k12> and at least it is a high karma account from 2009
<teepee> yeah, printables is fun with CC0 stuff, I recently reported one which claimed "re-uploaded" as CC0 but then original was CC-NC on thangs or whatever site it was from
<teepee> yes, I've seen that account active creating stuff even not being very active on reddit at all
<J23k12> nice form .. stacked extrusions or is it a polyhedron?
<teepee> and with much more complicated stuff
<teepee> polyhedron
<teepee> just limited fixed number of points per layer
<teepee> not sure where that Z value is coming from yet :)
<J23k12> hm from the code i would not assumed "much more complicated" stuff - as this star could be made much easier
<teepee> oh, well, of course, from the Z value given as mid point for the end cap, doh
<J23k12> so render finished after 3h but can't see anything as SCAD froze
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aiyion1 has quit [Remote host closed the connection]
aiyion2 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #openscad
<gbruno> [github] gsohler edited issue #4880 (Track all the issues/bugs of python-pr3-squashed PR) https://github.com/openscad/openscad/issues/4880
<teepee> J23k12: so I'll grab that design from reddit, right? we have some sort of star theme going on this year anyway, so that fits nicely ;-)
<J23k12> yes that was the plan - If you grab it and make the image and 3mf  i don't need to and can gratefully take a bath  - Ü
<teepee> it's intentional that it's open at the bottom?
<J23k12> probably  as it is a holder for a tea light .. it might help with keeping heat from the plastic
<teepee> right, so more decoration than holder :)
<teepee> well, fine by me
<teepee> I'll add a safety note anyway :D
<JordanBrown2> ENOKINTEL :-(
<J23k12> "Star shaped holder for 40mm led Tea-Light [CIC]"  not sure what CIC means .. else this could be used as description (it is from the original reddit post from him)
<J23k12> i guess the tealight would hold between the inner tips
<J23k12> (not sure where the 40mm would be)
<teepee> code is cool - or china internet corporation
<teepee> :)
<J23k12> yeah https://acronyms.thefreedictionary.com/CIC  didn't found anything  but  »code is cool« sounds fitting
<J23k12> ha maybe Cause It's Cool
<J23k12> JordanBrown2 what? ENOK?
<teepee> missing some specific person to be online I assume
<J23k12> hm .. nothing i could help with
<Scopeuk> I'm guessing no kintel :-( with added typo
<J23k12> oh that makes sense .. i was wondering about  ENOK (a jeep) or ENOCH  ..   and INTEL
<teepee> so assuming I get the baubles script working well we are good till 20th
<Scopeuk> ahh possible exception no kintel in the format ofan old kernel exception
<teepee> and I have another christmas tree, this one for adding one of those cheap 20 led strings lights
snaked has joined #openscad
<JordanBrown2> Scopeuk what typo?
<JordanBrown2> and yes, of course, UNIX-style errno symbol like ENOENT, ENOSPC, ENOMEM.
<JordanBrown2> it's no fun if you have to explain the joke :-)
<gbruno> [github] t-paul pushed 1 modifications (Add BountySource warning.) https://github.com/openscad/openscad.github.com/commit/357a812270a6004bbe818a80de4f1da3f531613e
guso78k has joined #openscad
<guso78k> JordanBrown2 you mentioned:  They could be ignore(...) or highlight(...) or background(...) or only(...)
<guso78k> in ModuleInstanciation, I see just tags for highlight, background and root(only)
<guso78k> how to "ignore something in openscad ?  won't it be just commented such as '//'  and wont have any relevance to me ?
<teepee> * modifier
<lf94> > ENOKINTEL < lol
<JordanBrown2> what teepee said
<JordanBrown2> it's not the same as commenting something out. First, because a single * will take out the entire object, even if it's multiple lines.
foul_owl has quit [Ping timeout: 245 seconds]
lastrodamo has quit [Quit: Leaving]
<JordanBrown2> Second, the stuff will still execute, so any errors will happen, and echoes will happen, and so on.
<JordanBrown2> it just causes that CSG node to be ignored.
<guso78> OK thx
foul_owl has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<teepee> no, subtrees commented out via '*' are already deleted in the parser
<teepee> that "still executed" only happens with '!' and it very likely needs to
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
kintel has joined #openscad
<kintel> JordanBrown With the logs, it's not an error, it's a promise - you just never know when I will resolve :)
<Scopeuk> asyncwait(kintell.avaliable)
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
guso78k has quit [Ping timeout: 250 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gbruno> [github] jordanbrown0 opened pull request #4895 (Uniform support for \n, \r\n, \r as line breaks. Fixes #4882.) https://github.com/openscad/openscad/pull/4895
<gbruno> [github] jordanbrown0 closed pull request #4891 (Ignore \r characters. Fixes #4882.) https://github.com/openscad/openscad/pull/4891