BZK[m] has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 240 seconds]
guso78 has joined #openscad
juri__ has joined #openscad
J73 has joined #openscad
J62 has quit [Ping timeout: 245 seconds]
juri_ has quit [Ping timeout: 256 seconds]
juri__ has quit [Read error: Connection reset by peer]
pharonix71 has quit [Ping timeout: 240 seconds]
juri_ has joined #openscad
juri_ has quit [Read error: Connection reset by peer]
pharonix71 has joined #openscad
teepee_ has joined #openscad
juri_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<Church->
Guys: speaking about improving rendering speed. What do you think of idea of more effective cloning mechanism? Way i see - for parts, that are used many times in model, create some directive .. eg. cache(), or add some function clone() .. that effectively after 1st render of that specific part caches result and then just inserts it again?
<Church->
this way .. even if something heavy like eg. minkowski is used for that part, even if it would be used 100x times, there would be no recalculation of that, except whatever translate/scale/rotate used on reused clones?
<Church->
(idea stems from one model, where creator "solved" rendering speed issues by exporting as stl, and then reimporting & reusing it)
<Church->
s/recalculation/rendering steps prior/
<Church->
Obviously, render may try in many cases guess what code might be reused/rendering duplicated, for auto speed up, but if creator explicitly tells with directives about such cases, it might be more foolproof
<J73>
try lazy union as the union at top level of all "clones" take time .. also there is a cache and you can flush it to see the difference
<peeps[zen]>
yep, all intermediate geometries are automatically cached. the only thing a "cloning mechanism" would add to that would be convenience of referencing some geometry without repeating the full csg.
<guso78[m]>
If there was a function to place an object in a Matrix, the Base object would Always stay constant, Just the Translation Matrix would Change.
<guso78[m]>
This would br a perfekt Applikation of clone
<peeps[zen]>
it wouldn't improve rendering speed because caching your "object"
<peeps[zen]>
sorry typo. because *it's already* caching your object
<peeps[zen]>
any time a subtree of the CSG output matches, it will use the cache
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
guso3 has joined #openscad
guso78 has quit [Quit: Client closed]
<Church->
so for example, if i have part as module, and just put/translate/rotate it several times, it is cached already and it won't be remade again, whenever i use that module somewhere in code?
<teepee>
yes and no... it's cached *with it's values*
<teepee>
so if you pass in different values every time, it's not the same cached object
<teepee>
so don't do module big_complicated_one(translate_to) {}
<teepee>
but translate([... different values ...]) big_complicated_one()
<guso3>
so if i define a module_compliacted1 and module_complicated with exact same structure and values, but different names, ist still cached right ?
<teepee>
no, name is part of the cache key I believe
<teepee>
well, "no" is the wrong answer... this should result in 2 separate cached objects giving the same result
<guso3>
yeahh, module names are included in the output of NodeDumper.cc ...
<guso3>
i am just wondering about a cmake compilation effect, which i have been experiencing. compiling openscad from scratch finshes quite fast. but if compiled i alter a header file whish is used more often. inremental recompilation time is really slow. so often deleting build directory and recompile from scratch is way faster.
<teepee>
with ccache enabled? maybe that's confusing things
<peeps[zen]>
CSG output does not contain user-defined module names, it gives the result of instantiating those modules with the given args, in native modules
<guso3>
peeps[zen] that means, openscad cache will save time for the user in this case :)
<peeps[zen]>
yes, it should. you can see extra cache related operations hits/misses with --debug=all i think. you can be more specific providing a file name GeometryCache or CGALCache, can't remember if wildcards are supported like *Cache
<guso3>
teepee, i just learned about ccache and that its functionality inside CMakeLists.txt. i am wondering, if there also exist an option to control it from the command line ?
<peeps[zen]>
also, some of those messages only are enabled on debug build
<teepee>
I think you can disable it completely but otherwise there's no tuning as such
<peeps[zen]>
not sure if the cache related ones requires debug build, off the top of my head
<peeps[zen]>
user-defined modules become "group()" nodes in CSG output (which is used for cache keys, after stripping whitespace and some other normalization)
<guso3>
in general the caching thing is a very good property.
<guso3>
reading though the very old PR's i realized, that teepee has once considered peristend caches, which would safe the caches beyond openscad session, which would give openscad yet another speed up boos(if used often)
<guso3>
(however for development if would be a horror and it would need an option to disable it while testing new functionality)
<teepee>
and we still want that I suppose
<teepee>
that said, with the WASM version it's maybe slightly less critical now
<guso3>
i realize that the hybrid -cgal is what is refereed to as lazy-union in the GUI. is there some short written document describing the idea behind ?
<guso3>
teepee, yes, i like to have persistent cache ! where is it ? '=D '=D XD
<teepee>
in that PR :)
<guso3>
suppose it s working but was neither merged nor rebased for a very long time ...
ur5us has joined #openscad
<teepee>
yep, sadly that's the case
<guso3>
suppose that rebasing a stone-aged pr would be a total fail. i am wondering if git offers functionality to rebase in 100 -commit-steps only ....
<teepee>
in this case it might not be that bad as most of the inferfacing code was supposed to be separate
<teepee>
the actual hooks into the existing code are maybe easier to put in back manually
<teepee>
but then, I've not tried it so I could be wrong :
<teepee>
:)
<guso3>
nice! but this was also supposed to be a more general question
<teepee>
it really depends a lot on the conflicts, some can be very annoying, sometimes it's easier than expected
<guso3>
yeahh, did the same for python-pr2, it was relatively easy because i was the author. anybody else would probably have much more effort.
<teepee>
it's really hard to predict, even though git does a much better job than the old systems, sometimes it's just horrible
<guso3>
in general i realize, there is just too few time to handle/care/review the flood of PR's arising :(
<teepee>
there's even quite a number of my own PRs that need finishing up :/
teepee_ has joined #openscad
<Church->
ok, then here another "mad scientist (possibly stupid :) ) idea": add ability to split code in render "parts". As in - if only some part is changed/adjusted, not rerender rest of them but take from previous rendering.
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<Church->
and 3rd mad idea: presave with rendering results of model or it's part so to as far if it is asked to be rendered with same params, it is taken ready from saved result cache. and if that module/scad file/lib is included in other scad file, then it should be able to load that prerendered in past result aswell
<guso3>
unfortunately, finishing a PR is something which is best done by the original author. However for finished PR, github offers a nice feature to request code reviews which greatly helps to maximize code credability. Hpwever,  it appears that this mostly performed by github itself ....
guso78 has joined #openscad
<guso3>
Church- this is what is established by the cache feature. Any sub-node which is unchanged will not be recalculated, but the cached result will be used instead. however, if you want to be subnode in render quality and it cached, you can use "render" keyword.
<teepee>
important point, render() is only relevant for preview
<teepee>
it forces mesh generation even in preview mode
<Church->
gus3: but will it be saved if i close the file? will it be loaded on file open? will it display render result immediate if i press render (if no constants altered since previous in past rendering)?
<Church->
imho there might be value to eliminate same work already done in most scenarios (LOL, though may also provide less incentive to optimize model code :) .. eg. "something took half a day to render", but now it load rendered result immediately, so "good enough" :) )
<peeps[zen]>
cache persists as long as the openscad process is open, (and you haven't explicitly commanded "Design->Flush Caches" from the menu) and as long as objects aren't evicted for going over size limits (set in preferences)
<InPhase>
I think the cache defaults are pretty low, so if you are designing on a computer which is not a pocket calculator, raise those size limits.
TheCoffeMaker has quit [Ping timeout: 268 seconds]
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Read error: Connection reset by peer]
TheCoffeMaker has joined #openscad
guso78 has quit [Ping timeout: 245 seconds]
guso3 has quit [Ping timeout: 245 seconds]
<peeps[zen]>
i'm the operator with my pocket calculator
<teepee>
that sounds so Kraftwerk :)
<peeps[zen]>
i knew some germans would get the reference :D
<Church->
well, my first association was that parody guy, Zlad from Molwania or something by Borat :)
<Church->
I had listened to Kraftwerk in past, even had been to their concert when they were in Riga .. but they are not among my very favourites. all kudos for being among very first in genre, but since then it advanced immensily