GNUmoon has quit [Write error: Connection reset by peer]
califax has quit [Read error: Connection reset by peer]
GNUmoon has joined #openscad
califax has joined #openscad
abff has quit [Read error: Connection reset by peer]
abff has joined #openscad
JordanBrown has quit [Quit: A fine is a tax for doing wrong. A tax is a fine for doing well.]
JordanBrown has joined #openscad
marcus has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 258 seconds]
marcus has joined #openscad
<JordanBrown>
InPhase: with respect to multi-material support and the "data = render() ..." feature... the guy that made that comment is a known troublemaker. Best to watch out for anything he sayd.
GNUmoon has joined #openscad
<JordanBrown>
But also: that recommendation was only with respect to the schema for the data object returned by the feature. Adding that bit to the schema won't cause the underlying render to divide the model up by material. It only means tha when and if the underlying render *is* taught to divide the model
<JordanBrown>
object.
<JordanBrown>
up, there will be a way to represent it in the data
abff has quit [Read error: Connection reset by peer]
abff has joined #openscad
J1A843175 has joined #openscad
J1A8431 has quit [Ping timeout: 252 seconds]
abff has quit [Read error: Connection reset by peer]
abff has quit [Read error: Connection reset by peer]
abff has joined #openscad
LordOfBikes has quit [Ping timeout: 268 seconds]
paddymahoney has quit [Quit: Leaving]
snaked has joined #openscad
abff has quit [Read error: Connection reset by peer]
abff has joined #openscad
LordOfBikes has joined #openscad
<InPhase>
peepsalot: I don't know how they achieved that level of stability. I've never seen multi-stage scissor extenders stable like that. They are typically super wobbly.
<InPhase>
peepsalot: But the dynamics are really impressive. If you got good enough bed adhesion, that could really do some impressive curved surface prints.
<InPhase>
That's also enough flexibility to almost eliminate the notion of printing with supports. (Again if bed adhesion were really good.)
<InPhase>
You can do curved surfaces by altering the print head angle as well, but changing the direction of gravity opens up a few other options.
<InPhase>
JordanBrown: And yeah, leaving space for that was the good insight. It will surely take some substantial effort to figure out how to handle multimaterial support. It will probably also require some CGAL support or else this is going to get very challenging.
<InPhase>
My current mental model is that we cannot mark surfaces by color as preview does, but must mark volumes, except that attached multimaterial components must share exact vertices and not almost exact vertices.
<InPhase>
I want to eventually see OpenSCAD produce a mesh output for a rod with a gradient such that the gradient is a series of cylinders, each adjacent with shared vertices to its neighbor, and each cylinder with a label designating the fractionof two colors such that a slicer can extrude a ratio of two filaments into a mixer chamber.
<InPhase>
Alternatively maybe an RGB label is appropriate, and we just rely on the slicers to interpret this in terms of the available filaments.
<InPhase>
Or maybe that'll need to be CMYK.
<InPhase>
Some sort of standards are needed. But either way, it's a project. What's important now is to be ready for this and to not paint ourselves into a corner where this gets too hard or breaks anything, because it's going to be super important.
<JordanBrown>
I prototyped a set of functions and modules that would DTRT with color. Without looking at it to remind myself, I believe you would use functions to build up a color-annotated CSG tree, and there was a module that would build it. It could either do all of the colors, for preview[*], or you could
<JordanBrown>
tell it which color to do and it would just give yo
<JordanBrown>
u those parts.
<JordanBrown>
[*] Except that since it tends to use a lot of polyhedra with perfectly matching faces, the z-fighting is awful.
<JordanBrown>
So for instance it knows that the color of difference(a,b) is the color of a.
<JordanBrown>
I think the color of intersection(a,b) is the color of a.
<JordanBrown>
For union(a,b) the color of a-b is a, the color of b-a is b, and the color of intersection(a,b) is, I think, a.
<JordanBrown>
Ah, as I look at it, the way that the coin came down for intersection(a,b) and for the common part of union(a,b) was that they were the color of b. Last paint wins.
marcus has quit [Remote host closed the connection]
<JordanBrown>
Hmm. Maybe I fixed that preview z-fighting problem by slapping in render()s.
<JordanBrown>
It only knows how to do cubes, but that's the easy part.
<JordanBrown>
Does anybody know of a paste service that does *both* text *and* images?
<InPhase>
Github gist maybe?
<JordanBrown>
Does not seem to handle images, at least not cut-and-pasted.
<InPhase>
There is still z-fighting if you zoom the camera inside of one of the cubes.
<JordanBrown>
If you put the camera inside a model, you get what you deserve.
<InPhase>
Ah. I don't actually use it, but I thought it did.
<InPhase>
lol
<InPhase>
Well yes.
<JordanBrown>
Anyhow, the idea is fairly simple, but I suspect that the processing time goes up dramatically with the complexity of the model.
<JordanBrown>
It could also be smarter about the color of negative objects, and the color of the second object in a union in its role as a negative object. That would reduce the explosion.
<JordanBrown>
Does it make sense? ISTM that we could, if we wanted to, do something similar internally.
<InPhase>
I'm getting a little too sleepy for 138 lines to make sense.
<JordanBrown>
Sorry.
<InPhase>
Perhaps another day. :)
<JordanBrown>
The most interesting stuff is likes 50-89, which is where it implements polyhedra, union, intersection, and difference.
<JordanBrown>
But as you say, another day.
<JordanBrown>
As Scarlett said, tomorrow is another day.
paddymahoney has joined #openscad
TheAssassin has quit [Ping timeout: 258 seconds]
TheAssassin has joined #openscad
abff has quit [Read error: Connection reset by peer]
<othx>
J1A843175 linked to YouTube video "Feeling Good - Nina Simone (1965)" => 1 IRC mentions
ur5us has quit [Ping timeout: 264 seconds]
abff has quit [Read error: Connection reset by peer]
abff has joined #openscad
abff has quit [Read error: Connection reset by peer]
othx has quit [Ping timeout: 250 seconds]
othx has joined #openscad
qeed_ has quit [Ping timeout: 244 seconds]
qeed has joined #openscad
sinvet has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
paddymahoney has quit [Ping timeout: 250 seconds]
paddymahoney has joined #openscad
paddymahoney has quit [Remote host closed the connection]
lastrodamo has joined #openscad
fancsali[m] has quit [Quit: Bridge terminating on SIGTERM]
t-paul[m] has quit [Quit: Bridge terminating on SIGTERM]
M6piz7wk[m] has quit [Quit: Bridge terminating on SIGTERM]
Killy has quit [Quit: Bridge terminating on SIGTERM]
one-star-chef has quit [Quit: Bridge terminating on SIGTERM]
Cadair has quit [Quit: Bridge terminating on SIGTERM]
pa has quit [Ping timeout: 268 seconds]
Cadair has joined #openscad
teepee_ has joined #openscad
pah has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
pah has quit [Ping timeout: 265 seconds]
pah has joined #openscad
ur5us has joined #openscad
Notkea has joined #openscad
one-star-chef has joined #openscad
fancsali[m] has joined #openscad
M6piz7wk[m] has joined #openscad
Killy has joined #openscad
t-paul[m] has joined #openscad
mikolajw has joined #openscad
aiyion has quit [Ping timeout: 258 seconds]
aiyion has joined #openscad
la1yv_j has quit [Ping timeout: 268 seconds]
la1yv_j has joined #openscad
<gbruno>
[github] kwikius opened issue #4351 (Feature request : Extend array syntax to allow indices to be generally accessible via '.' syntax by allowing optional names for elements) https://github.com/openscad/openscad/issues/4351
<gbruno>
[github] kwikius edited issue #4351 (Feature request : Extend array syntax to allow indices to be generally accessible via '.' syntax by allowing optional names for elements) https://github.com/openscad/openscad/issues/4351
<J1A843175>
for what does is the var.a var.b var.w var.r notation used?
<J1A843175>
and w,a all reference var[3] while r and x is var[0] and b or z is var[2]
<J1A843175>
also var.xyz or var.rab works wxyz is 3,0,1,2 but you can't mix wxyz with abr
<J1A843175>
ah it is rgba ..Ü
<teepee>
yep
Guest53 has joined #openscad
<teepee>
I'm not sure it's a good idea to open yet another discussion on arrays to make them like objects
<Guest53>
Too late. arrays already use dot syntax
<teepee>
no contradiction there
<teepee>
the existing stuff is partially there for ages, that's true, the swizzling is new and may want some small extension
<teepee>
that has nothing to do with naming positions which will cause all sorts of issues for example when concatenating vectors
<Guest53>
In the proposal only the first name is valid. concatenating arrays representing 3d points second x would be ignored anyway, so no change
<teepee>
echo(concat([x = 3], [x = 3]));
<teepee>
now what?
<Guest53>
ECHO: [3, 3]
<teepee>
and both are named x now?
<teepee>
well, bad example on multiple levels
<teepee>
echo(concat([s = 3], [t = 4]));
<teepee>
echo(concat([s = 3], [s = 4, t = 5]));
<teepee>
so that should continue to give [3, 4, 5] I suppose
<teepee>
.s is now ambigious
<Guest53>
Yes but only first x is found. any later are anonymous
<Guest53>
.s == 3 ( first looked up)
J1A843175 is now known as J1A84
<teepee>
but what's the benefit if there's a different data structure covering that already and implementing this would mean no vector optimization ever again
<J1A84>
if ambigious is detected it need to end with an error or warning
<Guest53>
A warning I think
<J1A84>
also because [1,3,2] can be var.xzy ↦ [1,2,3]
<Guest53>
much better documentation
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
<Guest53>
accessible by name
<J1A84>
But isn't there already a thread with creating data structures with names
ur5us has quit [Ping timeout: 264 seconds]
<Guest53>
quite a few...
<J1A84>
so if you have [a=2,x=5]. this would be [2,5] what while var.x normaly wuld be 2 .. it now is 5 .. this is problematic
<J1A84>
so this need to be limited to 2 or more character names
<J1A84>
oh no .. 5 or more
<J1A84>
var.rgba and var.xyzw already exist
<Guest53>
ar = [1,2,3];b = ar.zyx; echo(b.x);
<J1A84>
yes .x is always var.[0] this need to be constant
<Guest53>
still is
<J1A84>
ar=[a=1,b=2,..., x=24]; now ar.x would be 24 - how "still is" is meant?
<Guest53>
ar[0] already has x x at [n] can only be accessed by array syntax
<Guest53>
got to goo Bye..
Guest53 has quit [Quit: Client closed]
<J1A84>
br=ar; what is now br.x ?
<teepee>
before diving into strange side effects, the question I have first is "why?"
<teepee>
if there's no reason other than "because we can" I'd vote for covering the object stuff :)
abff has joined #openscad
<J1A84>
didn't the object also result in an array constant so object x =(x=1) would be called as x.x
snaked has quit [Quit: Leaving]
<teepee>
yes, but it's more like a dictionary, not a vector
pah is now known as pa
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
p3ck has joined #openscad
<InPhase>
We can reserve the option of adding a dictionary, but we don't need to hammer it into lists.
<InPhase>
Dictionaries would not be too hard to make on their own. Certainly they'd be simpler than our object proposal.
<InPhase>
And I have a userspace dictionary implementation already that we can hold ourselves over with until the right approach to dictionaries is sorted out.
<InPhase>
I think of the swizzling as more like list is a special built-in object and has some special member access variables predefined.
<InPhase>
They have a role primarily because we did not settle on details of a slicing feature, and partly because this is a geometry language rather than a general language, so accessing coordinates and coordinate pairs is a very common need.
<InPhase>
Or maybe the primarily is the other way around, depending on some subjective choices of values. :)
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
tachoknight has joined #openscad
Guest40 has joined #openscad
Guest40 has quit [Client Quit]
<teepee>
yep, that's what I'm thinking too. it seems to make sense to have both vector (with compact memory allocation) and map/dictionary/object whatever it's called with key/value pair access
<teepee>
the only interesting question is if we should mix the geometry stuff into that, or keep it separate, I still like the overall strategy of unifying things in the openscad2 proposal
abff has quit [Read error: Connection reset by peer]
abff has joined #openscad
<InPhase>
I think the geometry and object strategy that evolved recently in this channel is really on-point to what we need. Unfortunately I got busy this past week into the weekend and did not keep up on that massive github discussion about it. I'll reinject myself as soon as I get a chance, check on what was written out, and try to make sure these notions are documented well. But I really think we're on
<InPhase>
track now to a self-consistent approach that is sensible, useful, non-disruptive, and in alignment with the language style with the geometry/object integration.
<InPhase>
Certainly my own perspective on this evolved a lot in the last week from the discussions, and it resolved all of the confusions and concerns I previously had.
monkeybusiness has joined #openscad
<teepee>
I'm not sure the github discussion is going anywhere or even is held in the place it belongs
<teepee>
maybe it would help to get that document JordanBrown is working with to some more obvious place
<gbruno>
[github] kwikius closed issue #4351 (Feature request : Extend array syntax to allow indices to be generally accessible via '.' syntax by allowing optional names for elements) https://github.com/openscad/openscad/issues/4351
* teepee
shakes head
<InPhase>
teepee: Yeah, I promised JordanBrown I'd edit it, and didn't get around to it yet. I will strive to find an evening this week.
<teepee>
would it be an option to put that into a github wiki page?
<InPhase>
teepee: That was my initial thought of what to do with it, but JordanBrown already had the google doc started. What is the location again of those wiki pages for longer OpenSCAD proposals?
abff has quit [Read error: Connection reset by peer]
<InPhase>
I should probably bookmark that, as I never seem to find it or remember it. :)
<JordanBrown>
teepee, InPhase - I'm happy to move that Google doc somewhere else. I just wanted something that was structured as an evolving document, rather than as a discussion. (Of course, there would probably be a discussion that controlled the evolution.)
<teepee>
I'm just not clear about the access rights for the wiki, I believe it's pretty much open for editing, I'm seeing only a "restrict to users with push access" and that's not checked
epony has quit [Remote host closed the connection]
epony has joined #openscad
la1yv_a has joined #openscad
la1yv has quit [Ping timeout: 252 seconds]
la1yv_a is now known as la1yv
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
qeed_ has joined #openscad
qeed has quit [Ping timeout: 265 seconds]
<teepee>
joseph_: how is it going? with the current timeline we have 3 weeks + 1 week "final submission". is that working?
<teepee>
one interesting topic from Dougs proposal was that his objects were supposed to replace the include/use mess
<JordanBrown>
I would have to read through that again.
<JordanBrown>
They certainly have the potential for helping substantially with namespace issues.
<teepee>
although I did implement most of that logic, I'm still not sure I fully understand all the details, it does seem a bit awkward, but it's very nice from unification perspective
<teepee>
e.g. having a more unified view on lists, modules, functions
<JordanBrown>
BTW, a trick: when you edit a github comment, there's no e-mail notification. If you want to edit a comment (rather than just adding another comment that amends), and want e-mail notification, you can add a new comment describing the edit, then after the e-mail notification goes out delete that
<JordanBrown>
new comment to keep the record clean.
<teepee>
yeah, that could be useful if too many comments make things hard to follow
<JordanBrown>
The module/function distinction is arguably unfortunate. Offhand I don't know of any other modern language that retains that distinction. Especially unfortunate is that functions are in many ways written in a different language.
<JordanBrown>
Whether lists and objects/dictionaries/associative-arrays can reasonably be merged, not sure. With OpenSCAD's built-in shortcuts for vec2/vec3 and colors, probably not.
<JordanBrown>
Did you have a chance to look at the glossary that I proposed in #3087?
<teepee>
maybe even mars would help. what was that, like 45 minutes extra or so?
<teepee>
but then breathing is also nice :)
<JordanBrown>
Yeah, just looking that up. ~38m
<teepee>
only vaguely remembering that nice feature from a 3 book series on mars I read quite some time ago
<teepee>
now they sell christmas stuff already and there goes the idea of reading a book or two this summer :/
<teepee>
as for CSG tree, I think it might be useful to remember that CSG != mesh in the general case
<JordanBrown>
Yes. And thank you for reminding me of the word "mesh"; I've been using various other phrases for the triangle-based object that comes out of a render.
<JordanBrown>
Pluto is 6d9h. Everything else is much less than 24h, or much more.
<teepee>
for the render case that's ok as I suppose for that scenario we will always have the mesh
<teepee>
but it would be cool to keep the door open for partial trees running with a different engine like SDF
<JordanBrown>
I don't know anything about that.
<teepee>
and/or keeping the info at top level for things like STEP export, even if that will be limited to stop at hull() and other mesh enforcing nodes
<teepee>
quite comprehensive list of definitions
<teepee>
one more coming to mind, as we already allow lexialy scoped closures / captures or whatever those would be called
<JordanBrown>
Yeah, I don't know the exact behavior there. My assumption at the moment is that everything would be a direct analog to the behavior with function literals and function references.
<JordanBrown>
But since we seemed to have at least one person who did not understand the distinction between "module" and "object", it seemed good to try to nail down some terminology. Especially given the overloading of the word "object".
<teepee>
yeah, object is probably a bad name, I don't have any better though
<teepee>
bad in the sense that everyone expects something different already :)
<JordanBrown>
yes
<JordanBrown>
But I see a clear distinction between a module or function, and either kind of object: modules and functions are executable subprograms, and objects of either kind are immutable data values.
<JordanBrown>
You can't execute or evaluate an object, and you can't look inside a module or function. (Or if you can, it is to see things like the list of arguments - introspection on the *definition* of the module or function, not on the results of evaluating it.)
<JordanBrown>
Time to go back to pretending to work.