<InPhase>
The eval of those geometries is done and over with before CSG export happens. It's that staged evaluation concept I was saying we needed, actually manifest.
<sublim8>
Oh
<sublim8>
peepsalot it's empty
<sublim8>
is that good? :p
<peepsalot>
cache keys are basically substrings of that CSG tree, so not very good :P
<InPhase>
peepsalot: Well it's separately entered I think.
<sublim8>
It is being cached though.
<InPhase>
The user just never gets to see that part.
<teepee>
that's strange, it should have the polyhedron
<InPhase>
I hope empty did not mean the polyhedron was missing. :)
<sublim8>
I did some testing outputting strings whenever something entered the cache or was found and I think it gets properly cached.
<sublim8>
Someone else should check too.
<sublim8>
Wait a sec.
<sublim8>
Should render produce visual output when used as a function?
<InPhase>
sublim8: Maybe update your PR with your new work, teepee can stare the bison in the eyes, and we can attempt to abuse it.
<InPhase>
sublim8: Nope, no visual output when used as a function.
arebil has joined #openscad
<sublim8>
hehe, ok.
<sublim8>
Good that's how it is right now.
<InPhase>
sublim8: But a polyhedron call using the results of the render function should show up in the CSG tree.
<sublim8>
Even If I only use the module in render and not draw it afterwards?
<InPhase>
sublim8: Also, the userspace deformed sphere is awesome. That's exactly the sort of killer ap for this.
<teepee>
if there's just the a = render() and some echo() it's correct that the CSG tree is empty
<teepee>
with an extra polyhedron using the data, the polyhedron should show up
fling has joined #openscad
<teepee>
(building the PR just now :)
<sublim8>
Oh ok. Let me try and draw the polyhedron after render and see.
<sublim8>
Yep now it appears
<InPhase>
I need to grab lunch and head into a meeting, but I'm looking forward to playing with this later. Some fun things have become possible.
<sublim8>
ok, cu later InPhase.
<sublim8>
my polyhedron was sphere($fn=200, 10);
<InPhase>
I hope we can make use of this for the next advent calendar. :)
<sublim8>
CSG tree has: sphere($fn = 200, $fa = 12, $fs = 2, r = 10);
fling has quit [Remote host closed the connection]
fling has joined #openscad
<sublim8>
hehe
<teepee>
oh, looks like someone managed to build via VisualStudio
<sublim8>
heresy :p
<t4nk_freenode>
lol
<teepee>
nope PR
<sublim8>
pushed the changes.
<t4nk_freenode>
I had no idea windows was still a thing in this day&age
<InPhase>
Alas, still.
<sublim8>
As far as I am concerned it's not.
rvt has quit [Quit: rvt]
<JakeSays>
so when is this render as a function going to land? :)
<sublim8>
It's pretty much complete. It's up the the devs.
<JakeSays>
i'm gonna abuse it
<sublim8>
to accept it or provide guidance for changes.
<sublim8>
Please don't. It's sensitive :p
<teepee>
you can try the current state with the automatically built AppImage
<peepsalot>
sublim8: As a general rule, it should be possible to Export CSG(File -> Export -> Export as CSG), close openscad, open up the saved .csg file and get the same results as the original scad
* JakeSays
needs a piza
<JakeSays>
with two z's
<JakeSays>
the last .1% of rendering takes forever
<sublim8>
Doesn't everybody?
<sublim8>
The 0.1%? That's were all the good stuff happens.
<JakeSays>
so now we need a way to save the output of render() as a function to a text file
<sublim8>
peepsalot good to know.
<sublim8>
JakeSays that's easy. Maybe export in json so that it can be loaded by the new import json function?
<JakeSays>
json.. yuk
<JakeSays>
i was thinking more like .scad
<InPhase>
JakeSays: No text file writing...
<InPhase>
JakeSays: It must stay a "safe" language.
<JakeSays>
i don't understand how that would make it unsafe
<InPhase>
One way to do that is to make sure outputs are user-directed. A general programming language would compromise trusted sharing of scad files.
<JakeSays>
i dont understand what that means
<JakeSays>
so how do i go about persisting the output of render()?
<sublim8>
JakeSays: The output of of render() is boundingbox, points and faces (or paths in case of 2d). How would it be saved in scad? Just write out the array in text?
<JakeSays>
sublim8: basically, yes. the point is to be able to re-use the rendering w/o having to re-render constantly
<sublim8>
Are you planning to abuse it so much that you will not want to run render() twice?
<teepee>
use file based persistent cache - once it's finished and merged
<JakeSays>
teepee: how does that help?
<sublim8>
Can be done. But has to be managed. Not to fill up disk space.
<JakeSays>
sublim8: well, i assume render will re-render each time i press F5?
<sublim8>
yes
<JakeSays>
yeah so that's hundreds of time
<JakeSays>
i just want a way to capture the output to a file and then remove the render() call
<JakeSays>
and massage the file by hand, etc
<JakeSays>
er, hundreds of times
<sublim8>
What do you think would be the best way to do this?
<sublim8>
It's like you want to export the result in stl and import it.
<sublim8>
what would be the difference?
<sublim8>
From doing it in render that is.
<sublim8>
Or rather 'with' render().
<JakeSays>
i want to iterate over the points
<sublim8>
in openscad?
<JakeSays>
basically i want to render() an outline, and then use those points to place objects along a path
<JakeSays>
yes
<JakeSays>
well, yes and no
ochafik has quit [Ping timeout: 265 seconds]
<sublim8>
You could export to stl. And use data=render() import();
<sublim8>
To load it every time.
<JakeSays>
i can't hand edit an stl
<sublim8>
So you need a text file?
<JakeSays>
yes
<sublim8>
InPhase seems to have an issue with text files.
<teepee>
the point is just that there's not going to be a write("filename", ...);
<sublim8>
What about exporting objects in arrays, in .scad files?
<sublim8>
that would be a write() function...
<sublim8>
teepee because of security concerns?
<teepee>
not in the language, but there could be some other export function
<JakeSays>
what's the solution then, if no write function?
<JakeSays>
well, at this point i don't think the bounding box is all that necessary
<teepee>
just for the geometry that seems not needed, but as discussed before, it could extend the data with things specific to the imported format
<JakeSays>
right
<JakeSays>
the bounding box would be easy enough to calculate from the point data
<sublim8>
I mean, should I do it on this feature branch?
<teepee>
it's probably better to get one thing sorted first
<sublim8>
ok
<teepee>
at least for me it's otherwise difficult to get everything covered :)
<sublim8>
Sure.
<teepee>
switching to a different project at work does not help with spare time
<sublim8>
I understand.
<sublim8>
I don't know if you had a chance to look at data-render it is actually a small piece of code.
rvt has joined #openscad
<sublim8>
But it does touch some inner parts of openscad and should be considered carefully.
<teepee>
only first glance of the diffs, the very important part is how it interfaces from user side
<teepee>
we do have quite some test cases, while those are probably not covering everything, they should spot regressions
<sublim8>
Is there a better suited place for me to put the get_mesh_data() function that I use to get the vertices? I don't if func.cc is the best place for it.
<sublim8>
+know
<JakeSays>
bah. i really need a faster 3d printer
<sublim8>
I'm building a voron 2.4 :)
<dalias>
most printers are fast if you just figure out what's keeping them from running fast :)
<sublim8>
That's actually the reason I made render(). I needed to do some modifications to voron parts. Hehe.
<sublim8>
dalias true.
<dalias>
yeah a voron 0 can print a 10 minute benchy with good quality but an ender 3 can print a 17 minute one with good quality and meanwhile stock settings have it taking 2+ hours :-p
<JakeSays>
wow. it'll take almost 3 minutes to reach PLA temp
<sublim8>
That's ok
<sublim8>
Initial and Ambient temperature play a huge part too
<JakeSays>
they would be the same, wouldn't they?
<sublim8>
It depends. But probably yes.
<JakeSays>
from a cold start they would have to be
<sublim8>
yep
<sublim8>
What can you do... a large plate is difficult to heat up.
<sublim8>
But worth it.
<JakeSays>
i can work on my patience. lol
<sublim8>
hehehe
<sublim8>
You could always have a second printer for smaller parts that heats up faster.
<JakeSays>
nah. i can deal with 3 minutes
<sublim8>
True.
<dalias>
my printer takes 0s to reach pla bed temp because pla bed temp is 20°C :-)
<JakeSays>
it's 70c
<sublim8>
It dependes on the printing surface
<sublim8>
PLA sticks easily
<sublim8>
ABS is a nightmare.
<JakeSays>
you must use a different pla than me.
<JakeSays>
i can't get it to stick on anything unless it's heated to 70c
<sublim8>
It depends on the printing surface material.
<sublim8>
Really? I've heard that some people don't even use a heated bed for it.
<sublim8>
Have you tried glass? Kapton tape? PEI?
<JakeSays>
glass, yes
<JakeSays>
and aluminum
<JakeSays>
friend of mine uses the reverse side of a glass mirror. says it works perfectly
<sublim8>
Really?
<sublim8>
That's interesting.
<JakeSays>
yeah. he swears by it
<JakeSays>
that's going to be my next experiment
<sublim8>
It rougher and might create larger surface for adhesion.
<sublim8>
's
<sublim8>
It's ceramic isn't it?
<JakeSays>
i'm actually not sure
<sublim8>
I normally print on glass. Normaly PETG.
<sublim8>
I've chipped some mirrors
<JakeSays>
i have a spool of petg. it worked great for small parts, but i couldn't get a larger one to stick
<sublim8>
But ABS peals off while printing on glass.
<sublim8>
It needs a bit higher temperature
<sublim8>
80 degress celcius
<sublim8>
rather that 70 or 60
<sublim8>
than
<sublim8>
And it sticks like a **er :p
<sublim8>
It will break you mirror before unsticking. You gotta let it cool down.
<JakeSays>
abs?
<sublim8>
I can only print it on Kapton tape
<sublim8>
And not perfectly
<sublim8>
I occasionally get some warping
<sublim8>
Also, 105 to 110 degrees C
<sublim8>
Haven't tried PEI
<sublim8>
They say it's a good surface material to print on
<sublim8>
The best way for abs to stick from what I've heard is to dissolve a bit of it with acetone and cover your bed with it.
<sublim8>
Then let it dry.
<JakeSays>
that makes sense
<sublim8>
Haven't tried it but people swear by it.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
rvt has joined #openscad
rvt has quit [Quit: rvt]
rvt has joined #openscad
default__ has joined #openscad
sublim8 has quit [Killed (NickServ (GHOST command used by default__))]
default__ is now known as sublim8
snakedGT has joined #openscad
snaked has quit [Ping timeout: 260 seconds]
<InPhase>
JakeSays: On outputting data, I think there is a valid reason to have formatted output for console runs, or maybe even a separate tabbed window at the bottom where we have console and the error log which collects formatted output in a way that can be saved separately.
<InPhase>
s/console runs/terminal runs/
<InPhase>
I wish we renamed that console window so we'd stop colliding on these terms.