teepee has quit [Remote host closed the connection]
teepee has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 268 seconds]
peeps has quit [Quit: Connection reset by peep]
califax has quit [Remote host closed the connection]
califax has joined #openscad
epony has quit [Remote host closed the connection]
<JordanBrown>
(Sorry, IRC isn't great for days when I'm not stuck at the keyboard...)
<JordanBrown>
teepee: for the model I'm thinking of, a CSG tree is created at expression evaluation time for the expression in question. Yes, it's possible to introspect the geometry. I don't know what customizing values would mean. Like all values in OpenSCAD, both the geometry and the ordinary-value contents
<JordanBrown>
Note that you could bury an object creation in a function, and that would get you all kinds of interesting effects - but, again, the CSG tree would be created at expression evaluation time, when the function is evaluated.
<JordanBrown>
would be immutable once created.
<JordanBrown>
Not, mind you, that I claim that have any idea how hard it is to make that all work right. But I'm not coming up with any real questions about the user-visible semantics.
<JordanBrown>
Actually, hmm. I do have one. If it returns a CSG tree, what do you do to get that CSG tree added to the model? Or if you render(csg_tree_object) and it (somehow) returns a polyhedron-like thing, what do you do to get that added to the model? Perhaps render() on either of those, as a module
<JordanBrown>
invocation, would add it to the model. But: that wou
<JordanBrown>
ld imply F6-style render on it, even when not necessary.
<JordanBrown>
Re-reading PR 3956 (data = render()), that suggests that you could call polyhedron on the rendered results, and that seems more or less sensible, but doesn't explain how you could preview a CSG tree.
<JordanBrown>
I've been fixating on the "creation" side, considered the introspection side to be relatively straightforward, but have not really considered the "turn it into model" aspect.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
ur5us has quit [Ping timeout: 255 seconds]
JordanBrown_ has joined #openscad
JordanBrown has quit [Ping timeout: 252 seconds]
peepsalot has joined #openscad
teepee has quit [Remote host closed the connection]
<J1A8465652943>
guess fast CSG getting a problem with too much data as seen for the 3mf export
teepee has quit [Quit: bye...]
teepee has joined #openscad
<J1A8465652943>
hmm also happens with normal render .. how odd
<J1A8465652943>
the pattern is rendered or not if i just change the order of the object arrangements ..
<J1A8465652943>
even if i remove the pattern from Part 3 then part 4 is rendered with the pattern.. when part 3 has a pattern part 4 stays blank.. these seems to be about the amount of data
fling_ has joined #openscad
fling has quit [Ping timeout: 268 seconds]
fling_ is now known as fling
epony has joined #openscad
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
fling has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee has joined #openscad
qeed__ has joined #openscad
qeed_ has quit [Ping timeout: 268 seconds]
<InPhase>
J1A8465652943: Rather than amount of data, there might be some sort of manifoldness issue generated that prevents top level union of them, and the fast-csg path drops one of the ones it can't merge.
<InPhase>
J1A8465652943: Which can happen even if they're not touching. :)
<J1A8465652943>
to my suprise it also got droped without fast CSG
<InPhase>
Could still happen for the same reason, although I also would have expected different behavior here.
<J1A8465652943>
and how can the order of objects (arrangements) make a difference .. So A left of B works but B left from A doesn't
<J1A8465652943>
or that the cube A influence the pattern of B .. i mean roof is involved in the pattern so i guess everything is possible Ü
<J1A8465652943>
And if i rendered B separately before then the union works.
SamantazFox has joined #openscad
SamantazFox has quit [Killed (NickServ (GHOST command used by SamantazFox_))]
SamantazFox_ has joined #openscad
ccox_ has joined #openscad
muesli8 has joined #openscad
To_Aru_Shiroi_Ne has joined #openscad
rawgreaze_ has joined #openscad
ecraven- has joined #openscad
obriencj has joined #openscad
Furor has joined #openscad
Scopeuk6 has joined #openscad
hrberg_ has joined #openscad
mj_ has joined #openscad
siege has quit [Killed (lithium.libera.chat (Nickname regained by services))]
obriencj is now known as siege
ecraven has quit [Ping timeout: 252 seconds]
zauberfisch has quit [Ping timeout: 252 seconds]
othx has quit [Ping timeout: 252 seconds]
rawgreaze has quit [Ping timeout: 252 seconds]
Scopeuk has quit [Ping timeout: 252 seconds]
ToAruShiroiNeko has quit [Ping timeout: 252 seconds]
Colere has quit [Ping timeout: 252 seconds]
ccox has quit [Ping timeout: 252 seconds]
TheCoffeMaker_ has quit [Ping timeout: 252 seconds]
pbsds has quit [Ping timeout: 252 seconds]
gknux has quit [Ping timeout: 252 seconds]
hrberg has quit [Ping timeout: 252 seconds]
e2k has quit [Ping timeout: 252 seconds]
Fleck has quit [Ping timeout: 252 seconds]
muesli has quit [Ping timeout: 252 seconds]
epony has joined #openscad
epony has quit [Client Quit]
crazy_imp has quit [Ping timeout: 252 seconds]
muesli8 is now known as muesli
Scopeuk6 is now known as Scopeuk
epony has joined #openscad
epony has quit [Changing host]
linext_ has quit [Remote host closed the connection]
<joseph_>
teepee: I've been working on assessing stability and test cases. With some simple tweaks I've gotten up to 83% of the CI tests passing. Of those that fail, all except one appear to be due to segfault. Hopefully the segfault is in the same place for all of them, so I only have to make one fix. I'll try to see if I can replicate it in the debugger
To_Aru_Shiroi_Ne has quit [Remote host closed the connection]
ToAruShiroiNeko has joined #openscad
<teepee>
joseph_: yeah there's a good chance it's not all totally different issues
<J1A8465652943>
teepee if #3087 / #4336 is usable - doesn't this make the use of modules redundant?
<J1A8465652943>
i assume if it works for variables - it could work for functions too
<teepee>
joseph_: I could not catch Sean yet, so I sent him an email regarding the timeline discussion
<teepee>
J1A8465652943: it does work for functions already
* teepee
cuddles Quassel-IRC for tab completion ;-)
<teepee>
I guess the answer is mostly yes, you could move all your code to the new syntax
<teepee>
of course for backward compatibility the old style modules/functions are probably not going away in the next century or so
<J1A8465652943>
i already can put objects in a function? what version?
<teepee>
no, you can pass around functions
<teepee>
you said "it could work for functions too" -> it already does
<J1A8465652943>
as literals you mean
<teepee>
or I misunderstood what you meant
<teepee>
well, sort-of
<J1A8465652943>
i thought to replace a module you need to call a variable with a value .. which only works for functions
<teepee>
stricktly speaking the definition is the literal and this you can assign to a variable
<teepee>
and you can pass around that value, if this still should be called a literal, I'm not sure, maybe function-object? lambda? closure?
<teepee>
f = function(x, y) x + y;
<teepee>
v = f(1, 2);
<teepee>
variable f has a value of type function, variable v has a value of type number
<teepee>
so probably we need a type for modules and maybe in addition objects
<teepee>
or maybe only objects covering the module case too
<teepee>
the original proposal only introduces objects that can have variables and geometry and essentially represent scripts
<teepee>
in literal form they are o1 = { the object literal; }
<teepee>
but they could also come in form of an external script o2 = import("o2.scad");
<teepee>
what's not clear is how to pass variables into that - basically for customization of those objects, as you can do with modules
<teepee>
the original proposal has some means but it's difficult to understand and therefor likely also a bit cumbersome to work with
N4buc0 has joined #openscad
<J1A8465652943>
but you can not call o1 with a value so this is fix and can't be changed .. like if o1 makes a cube - it is always a fixed cube
<J1A8465652943>
having same data structure would be already cool like in textmetrics
<teepee>
yes, that's what I meant with parameters for the object
<InPhase>
J1A8465652943: In theory you could write functions that create an object with geometry.
<InPhase>
Although we also spent a while in the past discussing attempts to merge objects and module literals. While I still feel like this seems like the right choice, I left those discussions still uncertain how exactly you structure that and hit the various use cases cleanly.
J1A8465652943 is now known as J1A84
<InPhase>
o1 = { the object literal; } This structure, for example, doesn't work nicely if you want parameters optional.
<J1A84>
however you call these things .. in the end it would be fine to access the variables of a module like module Test(value=5); echo(Test.value);
<InPhase>
o1 = (foo){ ... }; is kind of a mess.
<InPhase>
I'd prefer o1 = module(foo){ ... } but then it dictates that objects are o1 = module(){ ... };
<J1A84>
guess a module doesn't need to have a geometric object
<InPhase>
And here's the part that really trips it up. Of you have: o1 = module(x){ cube(x); }; And then you do o1(5); we agree you should get a cube(5); displayed. But do we want g1 = o1(5); ? i.e., geometry literals? This was an outstanding question I had before, but maybe the answer to that is instead just permitting data = render() o1(5);
<InPhase>
So if this is our approach to modules, then geometries inside of object literals don't make sense.
<InPhase>
There would effectively be no sensible syntax to access them if the access of geometry itself is via =render()
<J1A84>
or data=o1(5).poly;
<InPhase>
So one possibility is: o1 = module(x){ size=x; cube(x); }; is a module literal, o2 = { size=3; cube(size); } is also a module literal using syntax sugar for no parameters. And thus o2(); makes the cube(3); and data2 = render() o2(); gets the geometry data for that module literal.
<InPhase>
And both o1.size and o2.size are variable accesses in module literals, functioning like objects.
<InPhase>
This means that the only access we have to "geometries" is via their render data, and the other syntactical accesses are either to grab values or to instantiate geometries with or without parameters provided.
<InPhase>
Perhaps that provides a streamlined cleanliness but still a strong flexibility of use?
<InPhase>
I could not get to this mental space last time because data = render() was not on the table. :)
<J1A84>
just wonder if the mesh data is then data.points and data.faces / data.path
<InPhase>
Yeah, I think something like that was the conclusion on that PR discussion.
<InPhase>
I forget the exact syntax.
<InPhase>
Plus maybe some bounding box info?
<InPhase>
Ironically also an object literal, which would become a module literal in this proposal, but one without any geometry info in it. :)
<InPhase>
Or rather, without anything to render into a geometry.
<InPhase>
Except the info, which would then be processible with polyhedron.
n1essa has joined #openscad
<n1essa>
do y'all tend to work with everything centered or not? i've been doing centered but unsure if i'm just making things more difficult for myself
<teepee>
no, maybe it fits to say the most interesting point is going to [0,0,z]
<teepee>
e.g. depending on how that part is attached
<n1essa>
hmm, i'm not entirely sure what you mean (i'm still a beginner), but i'll try using not centered
<teepee>
ok, let me dig out the weather sensor case as example
<teepee>
so the round parts really want to go center
<teepee>
but that beam with the 3 holes where it's attached is centered at the main holes the 2 round cases screw on
<n1essa>
hmm ok
<teepee>
for me that has made things easier to align, others may have found different solutions, it could depend quite a bit on the design itself
<n1essa>
yea that makes sense
<teepee>
I suppose it's very much based on symmetry of the design, like that beam is only symmetric in one direction X but not the other Y
<teepee>
if it's centered on Z is probably not too interesting, I think I have it starting at Z = 0
<teepee>
but it might make sense to center on Z too
<InPhase>
n1essa: I develop all parts either centered on 0,0,0 or with a corner or surface touching 0,0,0, then I translate to place parts together into a hole. It's important to be somewhat near the origin for all components so that rotations do the right thing. :)
<InPhase>
s/together into a hole/together into a whole/
<n1essa>
ok yea that makes sense too thanks
<InPhase>
Sometimes it's more "ostensibly" centered at 0,0,0, like this I consider origin-centered because the radius of curvature of the tube is at the origin, so I can mentally track where it should go from that: rotate_extrude(angle=90) translate([10, 0]) circle(4);
<InPhase>
Even though technically the material isn't touching the origin. :)
<teepee>
right, rotation is a good point, as the easy default is always around 0,0,0
<J1A84>
centered or not is just a question of math .. if you change the size of a centered object it stays centered however if you need a relative position to a next object centered may cause more trouble as now all distances change.
<teepee>
true, in general it does not really matter where the object is, but formulas / parameter might be simpler / more convenient depending on the orientation
<teepee>
same with specifying radius vs. diameter, depending on use you end up with a lot of 2 * r or d / 2 :)
<Friithian>
oh no are we messing up r and d again
<J1A84>
or mix them up all the time and wonder why holes are too small and rings are too big
<teepee>
haha, that too
<J1A84>
sometimes i wish cubes also had an "r" option
<Friithian>
… cube radius?
<teepee>
inner or outer?
<Friithian>
excuse me while I go apologize to my middle school geometry teacher
<J1A84>
with cylinder($fn=4); you already have an r option for outer
<J1A84>
it is just when you have circles with radii and then centered squares .. also would be fun to define the center (and size) of a square by 4 radii
ur5us has joined #openscad
<J1A84>
that would make overlaps easy as you simply add the overlapp to the side
<J1A84>
size=[[0,10],[5,5]] would be centered on Y but not on x for a 10²
<J1A84>
-5 it should be ..
<J1A84>
hmm or just define 2 corners like a bounding box
<JordanBrown_>
InPhase, J1A84, teepee: I'd say that o1 = { whatever } yields o1 being of type object, with a schema that describes a CSG tree.
<JordanBrown_>
If there is a m1 = module(x) { whatever }; then m1 is of type module and you could say o2 = m1(123), which would again return o2 of type object, with a schema that is a CSG tree.
<JordanBrown_>
But you don't really need it because you can say f1 = function (x) { whatever }, combining the existing function-reference form with the { geometry } form described above.
<JordanBrown_>
That is, you can readily define functions (whether or not referred to through a variable of type function) that return objects that describe CSG trees.