<phryk>
build to 16+ hours yesterday, today i noticed i compiled the whole thing with the wrong python version as default. currently rebuilding and hoped it at least wouldn't recompile the compilers, but the damn thing just began building llvm /o\
<guso78>
building openscad in your place takes 16 hours ?
<Scopeuk>
you running gentoo? sounds like your building a lot of packages
<teepee>
ouch
<teepee>
that's even longer than the MXE windows builds that even start with compiling gcc :)
<phryk>
bulk package builder. prepares a package repository, so it compiles not only openscad, but the complete dependency graph. it also does the same for luadbi and musicpd, so that doesn't make it any faster either. :P
<teepee>
yeah, dependencies can be interesting, MXE has for example one branch OpenSCAD -> Qt -> PostgresDB-Driver -> Postgres :)
<phryk>
well, pretty sure postgres was already pulled in by luadbi because the only reason i build that myself is that the "official" freebsd package has no postgres support. :P
cbmuser_ is now known as cbmuser
zauberfisch has quit [Ping timeout: 252 seconds]
zauberfisch has joined #openscad
Alexer has joined #openscad
castaway has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
J23723533 has quit [Quit: Client closed]
J23723533 has joined #openscad
guso78 has quit [Quit: Client closed]
fling_ has joined #openscad
fling has quit [Ping timeout: 255 seconds]
fling_ is now known as fling
snaked has quit [Quit: Leaving]
YesMan has joined #openscad
L29Ah has left #openscad [#openscad]
L29Ah has joined #openscad
<lf94>
InPhase: could you give me a text file of how you'd like to see this integration of libfive
<lf94>
I know you explained it before but it'd be nice to have it in a bit more structured format x)
<lf94>
Going to hack on it tonight
YesMan has quit [Quit: Client closed]
J23723533 has quit [Quit: Client closed]
J23723533 has joined #openscad
zxrom has quit [Quit: Leaving]
brkp has joined #openscad
zxrom has joined #openscad
Petar has joined #openscad
<Petar>
I have a model that I have been editing in fusion 360. Its height is close to 100cm. I have exported it as an STL and opened it in openscad. I then ran a script to slice it into 100 1cm layers.
<Petar>
That script can be seen here, as well as how it looks once it's sliced up:
<Petar>
I then export an SVG file to open in inkscape.
<Petar>
My problem is that when I open the SVG in inkscape and measure a piece that should be fairly large, then it appears to only be about 1.5 cm tall/wide.
<Petar>
Any idea what may be going wrong or how I may be able to get the right scale in inkscape?
<Scopeuk>
is it possible inkscape is used 1 unit in svg as 1 cm, I believe openscad assumes 1mm, that would give you a 1:10 ratio which looks in the ballpark from your model
<Petar>
I guess if I make a 1mm ruler in the SVG, then I should be able to just scale the whole image so that 1mm fits into 1cm when I am creating the gcode for cutting
<buZz>
Petar: but your openscad is for 2D output, not 3D?
<buZz>
oh, its for a 2D CNC
<buZz>
if you have 100 2D shapes, and whole object it 100 layers, then doesnt matter what height the shapes are ,right?
<buZz>
just cut the 100 2D shapes out of 1cm material , and done?
<buZz>
assuming X and Y are accurate
<Scopeuk>
this is generating the 2d layers by taking slices of an stl with openscad. I think the size issue above is related to how the x and y dimensions come out, svg has no height, its a 2d format
<teepee>
perfect square(10) ~ 10mm = 1cm
L29Ah has left #openscad [#openscad]
<buZz>
Scopeuk: right, so what size does square(10); give you?
<buZz>
eh
<buZz>
nevermind :)
<buZz>
its 10mm wide :)
<Scopeuk>
it was tested and gave correct units, the documentation from inkscape suggests it does strange things with interpreting units for you
<buZz>
so likely its the scale from fusion?
<buZz>
if openscad output -> inkscape is correct, the issue must be elsewhere?
<Scopeuk>
assuming that the trivial case and a complex case correctly maps yes, Inkscape's docs suggest it applies quite a few rules to derive the final sizes
<teepee>
it should not as the SVG specifies: <svg width="10mm" height="10mm" viewBox="0 -10 10 10" xmlns="http://www.w3.org/2000/svg" version="1.1">
<teepee>
which should not leave any room for interpretation
L29Ah has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<InPhase>
lf94: From my accumulated piles of pre-existing thoughts and scraps of textfiles already stored, this is how I picture a libfive integration going: https://bpa.st/653A2
<InPhase>
lf94: Perhaps give it a look over, and if you have any thoughts / counterpoints let me know. I could post an issue with those thoughts if this will be helpful. I only didn't post one so far because I flagged it as speculative in my head, and didn't know anyone was actually interested in working on it.
<InPhase>
(Although I do think it would be a huge value.)
<lf94>
(my internet is terrible for some reason at making new connections for the past few weeks - taking awhile to load)
<InPhase>
lf94: Also note the code examples might not be perfect... Obviously I did not try running them. ;) But it's approximately how I picture in my head that those functions need to be structured to work out correctly.
<InPhase>
lf94: The typing for those built-ins is illustrated with the blend example, where each one returns a function reference of that type.
<lf94>
My first test-case is probably going to be my bolt SDF
<lf94>
(thing is still loading / attempting to connect lol.)
<lf94>
(it's crazy. I can video call or IRC, but as long as I get the initial connection)
<InPhase>
lf94: Those examples are the libfive examples from the libfive site, so there's an existing comparison point for them.
<lf94>
Nice
<lf94>
I suspect the most time consuming part of this is understanding openscad's architecture for its language
<lf94>
because now that ive done libfive bindings I pretty much know it inside-out...
<InPhase>
Yeah. I put the convexity as "might be needed", in part because I recommend doing it first without that, unless it's immediately obvious how you are supposed to do it.
<InPhase>
That's the sort of thing that could be patched in after a minimum viable product version runs.
<lf94>
Yeah. My plan of attack is: get an MVP up, let the openscad experts handle the rest :2
<lf94>
finally, it loaded
<InPhase>
I think we currently have no built-in modules that take a function literal as input. But parsing-wise that should be the same as taking any value.
<lf94>
the blend example: blending the blends. you just forgot to add the m parameter on the outermost one right
<InPhase>
We also have no built-in function literals yet, but my advice is to poke teepee about that question.
<lf94>
I forget if openscad has default parameters
<lf94>
er, default function arguments
<InPhase>
I suspect a built-in function literal is not hard, it's just that there's no example to copy and paste from.
<lf94>
function literal: you mean like blend = function(...) { ... } right
<InPhase>
Yes.
splud has quit [Ping timeout: 246 seconds]
<InPhase>
And yes, it appears the outer m is missing.
<InPhase>
This is why we need errors/warnings to program. ;)
<lf94>
Are you ok with making it a restricted function to sdfs only
<InPhase>
On the plus side, the example makes enough sense that you could spot that. ;)
<lf94>
so, libfive has a specific set of op codes
<InPhase>
What do you mean by restricted function?
splud has joined #openscad
<lf94>
I would think the best approach is to have some sort of "libfive function" similar to what you've shown: function(x,y,z), but its body can only have libfive supported features in it
<lf94>
I guess we'd still need regular function literals
<lf94>
to wrap around them
<lf94>
or maybe not
<lf94>
can't we do like what the rest of openscad does with models? assign the sdf to a variable
<lf94>
and then that can be re-used
<lf94>
agh, my head's already exploding :D
<lf94>
Trying to really make this as not overwhelming as possible
<lf94>
I forget if openscad has loops
<lf94>
I don't think we need generic function literals, just ways to define sdf functions specifically
<teepee>
I still would start with module primitives
<teepee>
it limits the possible feature set at first, but probably is much much easier to get a first result
<InPhase>
teepee: I don't see a working syntax for that, and suspect it will actually be much harder. But can you make a blend example using the syntax that you envision for this? https://libfive.com/examples/
<teepee>
I guess that means no blend in the first go
<lf94>
funion = sdf(a, b) min(a, b); fsphere = sdf(r) (x^2+y^2+z^2)-r; // x, y, and z are *always* defined in a sdf function
<InPhase>
I like the blend case because it's basically the simplest testcase for why we would want sdf in the first place. It's the "oh, can't do that with CGAL" example.
<lf94>
I'm with InPhase on that one: I want SDF in OpenSCAD because of CGAL limitations
<teepee>
then just lookup $blend in the CSG ops initially
<lf94>
InPhase: what do you think of that? using sdf() instead as a function declaration of sdfs :D
<InPhase>
lf94: I would not object to syntactic sugar that gives an implicit x,y,z. But if you do that, make sure the module sdf does not have the same name.
<lf94>
The thing is XYZ must "thread" through all functions so it makes since to make it implicit
<lf94>
since -> sense
<InPhase>
lf94: My advice would be to add that second though. What I showed can be done with existing syntax, so a first draft doesn't need it.
<InPhase>
lf94: Literally the only thing required for what I proposed is to implement that module. You can hand-code the fsphere function inside scad code for a first draft.
<lf94>
Does OpenSCAD's AST parser already support what you've suggested?
<InPhase>
lf94: Yes, completely.
<lf94>
*phew*, ok, that's great
<teepee>
parser yes, evaluation no
<lf94>
that's ok
<InPhase>
teepee: I'm using normal evaluation for the functions.
<InPhase>
teepee: The only thing missing is the sdf module implementation.
splud has quit [Ping timeout: 255 seconds]
<teepee>
we have no function evaluation inside a module yet, it would be great to have, and hopefully it's easy
<lf94>
well and function literals rigth?
<teepee>
but so far nobody knows
<teepee>
in the normal expression evaluation yes, in module instantiation no
<lf94>
no function literals should exist within the sdf module
<InPhase>
teepee: Well we can pass normal function references to custom functions. This would simply be a built-in that also takes a function reference. So yes, that part is missing.
<lf94>
should only be able to call
<teepee>
I assume it's easy or even trivial, but we won't be 100% sure until we have working code
splud has joined #openscad
<teepee>
yes, the module instantiation has no evaluation context I think
Petar has quit [Quit: Client closed]
<teepee>
so for closures it may need to grab one, or we keep it closure free first and use an empty context
<teepee>
I believe all the pieces are there, if they fit together to build what we need for this specific case, we need to try
<teepee>
all that would not be needed for a "simple" module based version
<InPhase>
My sense is that part will be reasonably straightforward with a little thinking and looking through the code. I imagine the implementation of the sdf module might be only 50-100 lines.
<teepee>
but if we can get this to work, it would be great and helpful for other scenarios too
<InPhase>
lf94: If you want to reserve the word sdf, then think about a good alternate name for that sdf module. Something compact but clear.
TheAssassin has quit [Ping timeout: 255 seconds]
<teepee>
it might be, yes
TheAssassin has joined #openscad
<lf94>
voxel() ?
<InPhase>
lf94: We currently have zero cases of keyword conflicts between the namespaces, and we should not introduce any. I suspect a future in which we try to remove or lessen the divide between these namespaces.
GNUmoon2 has quit [Ping timeout: 255 seconds]
<lf94>
mesh(), mmm
<InPhase>
mesh is better than voxel, but not specific enough.
<InPhase>
sdfmesh maybe
<lf94>
shrinkwrap B)
<InPhase>
:)
<lf94>
evalsdf, sdfeval
<InPhase>
sdfmesh is growing on me.
<InPhase>
Very short, types well, reads well, and it's clearer about what it does than my initial proposal of just "sdf".
<lf94>
how do you feel about underscores
GNUmoon2 has joined #openscad
<InPhase>
Personally I prefer to avoid them, but we have a lot of existing built-ins with underscores, so it would blend right in if you preferred sdf_mesh
<InPhase>
I would not really object to the underscore, and could work with that just fine.
<teepee>
passing it is trivial, but it needs to be processed somehow in a special way
<teepee>
looking at the example, the function processing would need to special case x y z
<teepee>
and map those to the libfive kernel, while evaluating the other stuff
<InPhase>
I assume the libfive kernel has a callback?
<InPhase>
lf94: What does that API expect?
<teepee>
the c++ api shows overloaded arithmetic operators
<InPhase>
I imagined some sort of callback, like a std::function that could take a lambda that would just evaluate it.
<lf94>
no, no call backs
<lf94>
*_render_mesh returns a libfive_mesh
<lf94>
it takes a libfive_tree
<InPhase>
What does a libfive_tree look like?
<lf94>
it's an opaque pointer
<InPhase>
Wait, this library expects a C++ object structure of nested mathematical operations written out as C++ objects to do the SDFs?
<InPhase>
No no no, this is a silly way to do this.
<InPhase>
Surely there is a more fundamental call available.
<InPhase>
We don't need to do C++ like it's scheme.
<lf94>
yes, that's the way to do it
<InPhase>
Within libfive there must exist a routine that works directly with a callable.
<teepee>
just think of it as scheme tree :)
<InPhase>
Like maybe somewhere within this Mesh::render taking an Evaluator.
<InPhase>
(Got to run out for a bit.)
<teepee>
nope, I don't think there that. there's an optimize function though which may generate that internally
<teepee>
I suppose it might be possible to just tansform our AST into the libfive tree directly
<teepee>
I'm not sure I like that much though as it would redefine the meaning of function names, but we'll see how that looks
<InPhase>
This sounds quite wasteful considering what libfive has to be doing underneath the hood.
<InPhase>
It's not going to be actually making use of these trees.
greenbigfrog has quit [Ping timeout: 255 seconds]
greenbigfrog has joined #openscad
<lf94>
teepee: that's basically my plan
<InPhase>
lf94: There is an Oracle class which is designed to be a tree element for externally defined functions as primitives in trees.
<lf94>
why not just map to the tree
<InPhase>
lf94: Perhaps the straightforward approach is to use this abstract base class to make a subclass, and then there are only a few functions to define such as evalPoint and a couple others.
<InPhase>
lf94: Because we might not HAVE a one-to-one mapping.
<lf94>
my C++ is too shitty
<lf94>
not sure why you'd say that
<lf94>
it's simple: you use the op codes available by libfive, written as openscad code (all which need reserved keywords)
<InPhase>
Do you see a full list of opcodes?
<lf94>
openscad then evaluates everything into a tree
<lf94>
yep, it's...
<lf94>
gah, appears no libfive on my desktop here
<lf94>
just search "OP_MAX" for example
<lf94>
OP_MIN
<lf94>
etc
<buZz>
that code from Petar is stuck in my head
<InPhase>
I don't want to invent an entirely separate restricted sublanguage within OpenSCAD. I want arbitrary functions to work so that we get normal flexibility. This is going to be important to users for consistency.
<buZz>
am i correct that openscad doesnt have 3D offset() yet?
<buZz>
for import .stls
<InPhase>
We don't want to leak the abstraction of the library into the language design.
<lf94>
min/max/atan2/etc can all be context specific
<lf94>
"if within an sdf function, evaluate to libfive tree objects"
<lf94>
the "combination" comes when you mesth.
<lf94>
after meshing, you can then use it with the regular openscad context
<lf94>
that was my plan
<InPhase>
This sounds like a bad idea for both maintainability and user experience. Even a single operation not working means it becomes a whole different sublanguage.
<lf94>
why would it not work?
<lf94>
how would max not work
<lf94>
A huge benefit to all this too is you can swap these types of systems out (mkeeter also has Antimony, MPR, and now Fidget)
<lf94>
Since they all operate on the op code principle
splud has quit [Ping timeout: 268 seconds]
<InPhase>
lf94: e.g., norm() and cross() don't exist.
<lf94>
I'm not sure you get the benefits of its tree optimization either when using the oracle
<lf94>
you can code those with the other opcodes
<lf94>
I had to do it for magnitude()
<teepee>
no, I would assume you need to wrap all subtrees that have no x/y/z into oracles to be processed by openscad evaluation
<InPhase>
There is also no ability to work with lists in these opcodes.
<lf94>
correct, you must generate a list
<lf94>
erm
<lf94>
generate the opcodes that would represent something operating on a list
<lf94>
the same "limitations" exist in curv as well
<lf94>
except curv doesnt do any optimizations, and output is generally worse, and takes much longer
<InPhase>
So to actually get all OpenSCAD functionality, we need to have it call into OpenSCAD.
<lf94>
To create a "list of spheres" you do [sphere(1),sphere(1),sphere(1)].reduce(union)
<teepee>
question is if that's a good idea
<teepee>
having function evaluation mixed
<lf94>
most likely not
<lf94>
curv kept it separate from its own language
<lf94>
curv and "subcurv"
<lf94>
subcurv was meant for defining shapes at the sdf level
<InPhase>
I could understand a slow evaluation in a callback making things slow (although using ANY sort of opcode tree is by default slow compared to straight calling of native code). But why would the output be worse with an oracle?
<lf94>
not sure why it would be, just my experience
<lf94>
so we're against the idea of defining sdfs in a "sublanguage of openscad" I take it
<InPhase>
That'd be extremely challenging to implement, hard to maintain going forward, and it will heavily restrict future changes.
<teepee>
I'm not sure that was said
<teepee>
mixing inside one sdf tree is maybe a bad idea
<teepee>
transcribing a full subtree might still need some explaination but might be ok
<lf94>
I would think that as long as you can use some common openscadisms inside the sdf module, it'd be ok
<teepee>
it's probably a matter of just trying it out
<teepee>
you can fully use the AST I think
<InPhase>
e.g., we have a side project working on optional Python integration. An obvious use-case is to do Python math. Maybe we have an imported function doing some numpy math, and toss some into an sdf function, and want to do an sdf_mesh. Now... we can't call it because it doesn't map to a libfive tree?
<teepee>
and transcribe it completely
<teepee>
the fun part is that the function names are not defined by openscad but by libfive opcodes
<lf94>
if you say call norm(), it doesnt have to fail if we implement norm() sdf function.
<InPhase>
As long as libfive is working with our evaluator, then EVERY change we make to OpenSCAD going forward is just one more feature we can use in sdfs.
<lf94>
otherwise, we should just give "norm not defined within sdf context"
<teepee>
yes, something like that
<lf94>
InPhase: that sounds super advanced to my tiny brain
<InPhase>
But it would be simpler. :)
<lf94>
also it goes against how libfive presents itself via its FFI
<lf94>
which I would assume is a hint it's not being used in the way intended
<InPhase>
Have you had an contact with the author of it?
<teepee>
not quite, as openscad does not know how to handle x/y/z operations
<lf94>
InPhase: contact: yep
<teepee>
so i'm not sure there's a safe way to assume all extensions in openscad can be visible
<InPhase>
teepee: What do you mean by that? That should be handled automatically by the returned function literals, right?
<teepee>
evaluation of x + 3 needs to be handled by libfive
<InPhase>
teepee: Nope.
<teepee>
yes, because x is the automatic sdf object, openscad does not know anything about that
<lf94>
^
<InPhase>
teepee: Libfive asks for the evaluation at (x,y,z), and the OpenSCAD evaluator returns the float.
<lf94>
x is the current point of evaluation as five traverses the space
<teepee>
I thought I've read there's no callback
<teepee>
so there's one from inside the mesh render?
<InPhase>
I think for CGAL alternatives, we're probably much better off sticking to looking at things like Manifold.
<teepee>
ok, cheating with the rounded union to show why it would be neat, but that's not required
<InPhase>
SDF approaches are so fundamentally different I don't think this mashes together well that way.
<teepee>
now you are a bit mean to implicitcad :P
<teepee>
which does not mesh, but sdf :)
<teepee>
well, it does at the end
<teepee>
nothing wrong it giving the full function power if that works out, but even without there's a number of features that can be quite useful in SDF world instead of mesh
<teepee>
specifically the rounded union
<teepee>
ok, so go go go lf94 :)
<teepee>
3 possible ways for an initial interface :D
guso78 has joined #openscad
<lf94>
not gonna lie I feel lost now :D
<InPhase>
Well you certainly can't do all 3.
<lf94>
The Oracle way is just not the way I've been using libfive
<InPhase>
lf94: Of course, because you weren't integrating it with an existing evaluator. :)
<lf94>
right
<InPhase>
But I'm reasonably sure it would be much faster to implement that way.
<lf94>
I feel you need more intimate knowledge of openscad's language, and that any of you could do it much faster than me :)
<InPhase>
It might be worth checking with the author of libfive though if you have a contact modality.
<InPhase>
It is possible that the Oracle feature is not the optimal way to call an external evaluator. The author might know a better way. That was what I found in a quick skim through the code.
<InPhase>
I think teepee's approach would require a lot of parsing changes.
<InPhase>
Or, something kind of different along that line.
<teepee>
nope, none at all I think
<teepee>
it would "just" traverse the AST of the function passed
<InPhase>
Well, some sort of elaborate transformation. And then it would be missing most of what sdfs do.
<InPhase>
It would basically just be a CGAL alternative.
<guso78>
One of the Key Features of sdf IS the easy ability create fillets
zxrom_ has joined #openscad
<guso78>
Teepee, thank you for merging
zxrom has quit [Ping timeout: 248 seconds]
snaked has joined #openscad
kintel has joined #openscad
snaked has quit [Remote host closed the connection]
<teepee>
kintel: heyho, nice web-demo, will we get the bump-mapping too? that looks fun
<kintel>
:)
<kintel>
Once we have a modern renderer, we should be able to do what we want
<kintel>
But the road there could be a bit windy
<teepee>
guso78 already played with textures but I don't know how in detail
<teepee>
even with just selectable shaders and no scad script support it would be cool
<guso78>
My Branch is available in GitHub and Working in Case anybody is interested ..
<kintel>
Anyway, with modern OpenGL, everything is a shader anyway, so once we kill immediate mode...
<guso78>
In my Version. There are 7 different Texturen available and you can Use any Folie in them.
<teepee>
that was for F6 meshes, or also for Preview?
J23723533 has quit [Quit: Client closed]
J23723533 has joined #openscad
<guso78>
Problem with the openscad Schäfers that glgs 1.2 is quite outdated
<guso78>
Teepee makes only Sense in preview
<teepee>
a nice mesh render shader is useful too
<guso78>
Any color an them ...
<teepee>
it would not be able to support different textures, but like overall bump-mapping for producing some global surface structure
<kintel>
we just need to ask for gl3+ contexts. working on it..
<teepee>
\o/
<kintel>
(however slowly, and one-handed..)
<teepee>
haha, and one eye open :D
<kintel>
Btw., does anyone have a recommended way of building and running C++ code under Windows these days
<teepee>
so good thing it's not twins?
<kintel>
-> needs WGL stuff working..
<kintel>
( I did end up installing Windows :/ )
<teepee>
msys2 should work reasonably well, I think that's what JordanBrown[m] is using
<teepee>
there's also someone maintaining a VS build as PR
<kintel>
Heh, I'd prefer not opening VS ;)
<teepee>
whew!
<guso78>
Vs is ?
<teepee>
visual studio (not code)
<guso78>
Ahhh
<teepee>
partially synonym for compiling using microsoft vc++
<guso78>
Its Maximum m$ 😁😁
<teepee>
I think they have community editions for pretty much anything by now
<JordanBrown[m]>
isma22: I don’t remember exactly why, but I ended up with my “wall” module taking an “openings” parameter to make windows, doors, et cetera.
<JordanBrown[m]>
Probably at least partially so that they were automatically aligned with the wall.
<kintel>
JordanBrown[m] Do you happen to have any experience setting up VS Code remote into a Windows box?
<InPhase>
lf94: See, already guso78 wants to bind python to the sdf feature. ;)
<InPhase>
Called it...
<teepee>
that's actually difficult for the function based versions
<InPhase>
The most predictable thing in the world: Wanting to combine all the features.
<lf94>
I mean of course
peeps[work] has quit [Quit: Leaving]
<guso78>
Teepee, i will do IT Like glsl. I will Compile a Compiled String from Python
<guso78>
Provider String from python
<lf94>
InPhase: honestly any of you could probably do the oracle approach much faster than me :)
peeps[work] has joined #openscad
<guso78>
I have this Auto correction ...
<guso78>
Hate
<teepee>
lf94: only in theory, assuming there's enough spare time :)
<InPhase>
lf94: If we were in a race, it is extremely likely you would finish before I got started.
<teepee>
lately I only manage a bit of chat now and then :)
<lf94>
you guys sure know how to motivate someone
<lf94>
:p
<teepee>
welcome to the real world :P
<lf94>
ive been here for a bit
<teepee>
but then, it helps to keep going :)
<teepee>
I know
<lf94>
"here" -> the real world x)
<lf94>
i was teasing
<InPhase>
lf94: Other than advice and guidance, my top OpenSCAD priorities are to do a proper reviewing of JordanBrown[m]'s object literals, and then to dig out my old code where I was trying to fix up that use/reuse/reuse efficiency bug and try to wrap that up into a PR.
<lf94>
im gonna spend like a night "trying" this and give up because it's going to be "there are too many cases to think of...." lol
<lf94>
that's why i wanted to take the opcode approach
<lf94>
it's super well defined
<lf94>
minus function literals
<InPhase>
lf94: I think a benefit of the Oracle approach is that it is going to be a loooot simpler, since you will have almost nothing to do on the OpenSCAD side.
<teepee>
than do that
<InPhase>
lf94: Everything you're unfamiliar with will be made much easier.
<teepee>
maybe we want to try both eventually :)
<InPhase>
It is possible it's the wrong approach. I've certainly made advice mistakes before. But that I think will be the simplest draft. And maybe it works beautifully.
ur5us_ has joined #openscad
<lf94>
In theory, I can see it working nicely
<InPhase>
If it does not work beautifully, at least there's a starting reference point from which to build other approaches.
<lf94>
I worry about practice: some weird openscad code with the sdf feature that just crash the program
<InPhase>
Well, OpenSCAD will have one job: Return a float to libfive.
<lf94>
I'll spend a night trying the oracle approach
<lf94>
surely it wont take longer than that
<lf94>
openscad encouters sdf() -> run the oracle, run the mesher, convert libfive_mesh to openscad mesh
<InPhase>
The only problem you'll have to address is finding an appropriate float to return if OpenSCAD generates undef or a value other than a float. But it looks like libfive already knows what to do about nan, because there were comments about that even in the Oracle class header.
<guso78>
Oracle approach is Guessing a Point and find Out if its good?
<teepee>
wouldn't that be run mesher which calls the oracle repeatedly ?
<InPhase>
guso78: The "Oracle" approach is to feed libfive an evaluation of one element that says "Call this OpenSCAD function evaluation to find the float value for the sdf".
<InPhase>
s/evaluation/evaluation tree/
<InPhase>
For the first evaluation only...
<guso78>
OK thanks for your Info
<InPhase>
in my sentence
<InPhase>
English challenges. Need more tea.
<teepee>
aww, no debian package
<InPhase>
teepee: For libfive?
<teepee>
yep
<InPhase>
Well, it's gpl. I guess we could bundle it for debian purposes.
<InPhase>
Oh, correction. Mozilla Public License v2.
<teepee>
incompatible with gpl-2 but we essentially are gpl-3 anyway
<InPhase>
The caveat is to not copy and paste content from the GPL code into the MPL code.
<InPhase>
Up through to "If a project wishes to do this, and not to allow others to use their version of this file under the MPL, the project can indicate its decision by deleting the MPL headers described in Exhibit A of the license and replacing them with the standard notice recommended by the (L)GPL. Copyright notices indicating authorship of the file should be retained." Although we do not intend to become
<InPhase>
maintainers of libfive. This would only be about how to package it up.
<teepee>
confusing, it's listed as incompatible but you can create combined work
<InPhase>
For regular builds we should use a git submodule like the standard modern method.
<lf94>
teepee: the mesher takes a libfive_tree, so no
<lf94>
unless libfive_evaluator can be an oracle
<teepee>
the oracle is an opcode
<lf94>
ah right
<lf94>
then yes :)
<teepee>
so I assume the tree to be passed would be only that single opcode
<lf94>
yep
<lf94>
it's kind of weird / cyclic to think about
<lf94>
in my head imagine all this being like 20 lines of code
<lf94>
not sure why
<teepee>
an initial version might be
<lf94>
code to detect "sdf" module, oracle code to evaluate said sdf, and then libfive_mesh to openscad mesh tranlation
<lf94>
am I missing anything
<teepee>
yes, and evaluate would be "create new empty context, define x/y/z or whatever the oracle gets as input, call evaluate and hope a float comes back"
<teepee>
more things might be needed to capture outside variables
<InPhase>
lf94: I wouldn't be surprised at 50-100, but most of that should be fairly simple filler.
<lf94>
yessir
<lf94>
yes exactly
<lf94>
something like that
<InPhase>
lf94: And let's be honest, probably 2-3 hours trying to get libfive to work on all the other platforms after you submit the PR and find out which ones it didn't pass the CI build on. ;)
<InPhase>
But working locally should be a lot easier.
<lf94>
oh I only care to get an MVP on linux ;p
<InPhase>
And by then it's up as a PR, and we can advise on solution paths to that part.
<InPhase>
Most of that will be submit, wait for a build run, go, "What? Why?" and then a few more minutes to figure out the next thing to try.
<InPhase>
After throwing enough wet noodles, they will all start sticking to the wall.
<lf94>
yeah, im mostly doing this because openscad is a massive stone in the code cad space, I really want code cad to grow further
<lf94>
I really like my js + libfive bindings
<InPhase>
Even if this ends up slow, it will still almost certainly outperform minkowski for the cases we would most need it.
<lf94>
and when Fidget is done, the next iteration of libfive, I'll be able to effortlessly switch over
<lf94>
yes exactly
<lf94>
also you'll be able to do organic objects
<lf94>
even if slow
<InPhase>
Yep.
<InPhase>
And we could think about performance later.
<InPhase>
If the oracle is slow, then I bet it's only slow because of our eval process. Then we just need a jit.
<lf94>
yes, that's why it'd be slow
<lf94>
libfive does heavy operation optimization
<lf94>
that's its thing
<InPhase>
But I think there's a very good chance it's not meaningfully slower than libfive directly. We have a modest interpreter overhead, but it shouldn't be too different from the base level of what libfive is doing on evaluations.
<lf94>
you can use the output optimized tree as shader code
<InPhase>
I don't know what its optimization approach actually does though.
<lf94>
it will be quite slow. when you have to operate on 30000x30000x30000 "cells" because you picked a 300x300x300 region and 0.1 resolution, it becomes slow very fast.
<InPhase>
Well most of those should not need to be operated on.
<lf94>
It uses quad trees and "tape optimization" to reduce the number of operations per-cell
<lf94>
but it cannot perform the tape optimization if you do not use its op codes
<lf94>
Fidget takes this even further
<InPhase>
If your distance function is 200 at the top left corner, you should have a pretty big space you don't have to evaluate.
guso78 has quit [Quit: Client closed]
<lf94>
Yes, but when you have an object that requires high resolution, you cant avoid it
<lf94>
as in
<lf94>
you'll already do perfect bounding volume, and it'll still be slow
<InPhase>
I mean empty space can be skipped.
<lf94>
yep
<lf94>
I just mean that the empty space case is not the problem :p
<InPhase>
And large internal volumes. Assuming it's doing the smart things, which it looks like it is with those interval type calls.
<lf94>
I realized if I could get a mesh union code thing, I could render pieces of my SDFs into meshes at different resolutions and union them together when they've meshed
<InPhase>
Well, I have a lot of experience calculating surfaces within OpenSCAD using very complicated highly nested OpenSCAD functions. And I can tell you it almost never even gets close to a second to evaluate, even if I really crank up the resolution really high.
<InPhase>
So as long as most of the calculations are somewhat near the surface under consideration, it's going to go lightning quick, even evaluating through the OpenSCAD functions.
juri__ is now known as juri_
zxrom has left #openscad [Leaving]
Scopeuk has quit [Quit: Ping timeout (120 seconds)]
Scopeuk has joined #openscad
teepee_ has joined #openscad
Lagopus has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
snaked has joined #openscad
Lagopus has quit [Remote host closed the connection]
Lagopus has joined #openscad
splud has joined #openscad
ur5us_ has quit [Ping timeout: 248 seconds]
Lagopus has quit [Read error: Connection reset by peer]