fling has quit [Remote host closed the connection]
fling has joined #openscad
<JordanBrown[m]>
Hmm. Have to think about whether I'd want lookup to be object-capable too, so that you could use it to interpolate between {pos: [0,0], angle: 0} and {pos: [10,10], angle:90 }.
<JordanBrown[m]>
InPhase if you want to see some "what a strange language" stuff, look at the ways that Adrian abuses matrix operations.
<InPhase>
Who is Adrian?
<JordanBrown[m]>
Adrian Mariano. Works with Revar on BOSL2.
<InPhase>
And we could not make lookup object-capable without adding in a key function parameter.
<JordanBrown[m]>
I think I originally found the directory entry at Cornell and assumed he was still there, but this makes more sense.
<JordanBrown[m]>
For instance, here's his solution for calculating the bounding box from a set of points: https://bpa.st/JJSA
<JordanBrown[m]>
It uses a couple of relatively obvious functions not supplied - is_path, ident(), transpose().
<JordanBrown[m]>
But note that it never iterates across the list of points in userland.
<InPhase>
JordanBrown[m]: It looks like his current day job is probably developing classified satellite monitoring systems. (Reading between the lines.)
<InPhase>
Although he probably is not allowed to say that. :)
<JordanBrown[m]>
Could be. Never really talked to him about day job, other than that I believe he's a professional mathematician.
<linext>
i merged in the ability to import/include files into OpenSCAD WebAssembly: https://ibb.co/album/G3s2m2
JordanBrown has joined #openscad
<InPhase>
JordanBrown[m]: Yeah, his publications all jump around to various mathematical methods one would use for this, and his employer works on that genre of things.
<linext>
next i need to add a feature where stored files on the server get downloaded as a zip, unzipped, then imported
<JordanBrown[m]>
linext sounds cool...
milza has quit [Quit: milza]
<linext>
one thing the other customizers don't offer yet
<JordanBrown[m]>
InPhase but like I said, he abuses matrixes.
<linext>
since it's being imported into your web browser and not into my server, it's a bit safer
<InPhase>
JordanBrown[m]: Yeah, this is definitely how a mathematician would think about this problem. And, frankly, it's probably pretty efficient as that should vectorize things nicely.
<JordanBrown[m]>
My wife asked me to design a folding box. OK, straightforward enough since I already have an appropriate hinge. And it was a little OCD to animate the sides folding up from the as-printed position, because after all it lets me see how it fits together. But there really is no excuse for then animating flying the lid from its print location to on top of the box. So I'm going to resist.
<InPhase>
JordanBrown[m]: I sometimes do these sorts of things with numpy, where I'm trying to vectorize for big data, but I don't keep this part of my brain activated usually when doing OpenSCAD.
<JordanBrown[m]>
I never do that sort of thing. Almost all of my work is figuring out the best way to bolt N components together to achieve a goal.
<JordanBrown[m]>
It's why I tell people that I am a software engineer, *not* a computer scientist.
<JordanBrown[m]>
And they are usually very confused, because at the low levels that they've seen, computer science courses teach programming, not CS.
<InPhase>
I mostly picked up those mental modes in grad school for physics, where I repeatedly went back over matrix math until I had it intuitively locked in. There were inadequacies in my undergraduate coverage of pretty much everything linear algebra, so I had to patch it all up because I needed so much of it for stuff I was trying to do.
<JordanBrown[m]>
And in my opinion CS relates to what I do about like physics relates to building houses.
<InPhase>
Building tiny houses is apparently also what you do. ;)
<JordanBrown[m]>
Well, yes :-)
<Friithian>
how do I eigenstuff help
<InPhase>
linext: I saw a really cool feature on the online godbolt compiler where the C++ code can have #include <https://...url...>
<linext>
neat
<InPhase>
Perhaps something to consider.
<linext>
i think modern javascript can do that too
<linext>
does openscad accept URLs for import/include?
<JordanBrown[m]>
yes, JS can do all sorts of stuff like that.
<InPhase>
linext: It does not.
<JordanBrown[m]>
No, OpenSCAD can't, though we've been thinking about it as a library distribution mechanism.
<InPhase>
linext: That was one of those things we were discussing the other day, in terms of how we could do hacky library features.
<linext>
yea, sounds like PHP code
<JordanBrown[m]>
But you have to be *really* careful in JS, because that "include" could use a URL that causes your web site to take an action.
<Friithian>
free XSS
<JordanBrown[m]>
yes
<InPhase>
I cannot speak to the safety requirements for javascripting that right. But yes, do not do the bad things. Do the good things.
<JordanBrown[m]>
I would need to look at it carefully. I have had to deal with some of those things, but not enough to have fully internalized all of the issues.
<JordanBrown[m]>
But for instance...
<peepsalot>
JordanBrown[m]: 2*(x<.5?x:1-x)
<JordanBrown[m]>
Background: WebDAV is a set of conventions and HTTP extensions for using HTTP as a bidirectional file transfer mechanism, so that you can upload files, delete files, retrieve files, get lists of files, et cetera.
<peepsalot>
no function calls, and its correct: echo([for(x=[0:.05:1]) 2*(x<.5?x:1-x) ]);
<peepsalot>
J1A8427's formula gives wrong results
<JordanBrown[m]>
If you have a naïve WebDAV server that we both use, and I say "hey, go look at this file", you retrieve my file, its JavaScript runs in your browser as you, and goes and does WebDAV operations back to the server as you, and deletes all of your files.
<peepsalot>
... and uses 5 more chars
<InPhase>
4, because .5 needs to be 0.5 to make my head not scream.
<InPhase>
Reasonably compact though. :)
<JordanBrown[m]>
teepee's really is the best, though.
<peepsalot>
JordanBrown[m]: iirc builtin function lookup has a potential significant penalty since it searches scope parents recursively until at top level scope, and *then* checks the builtin scope
<JordanBrown[m]>
true
<JordanBrown[m]>
I don't happen to know whether those lookups are linear or hashed.
<peepsalot>
InPhase: "<J1A8427> x>.5?1-(.5-x)*2:x*2" had ".5" twice, so 6 chars if you're going by those rules :P
<JordanBrown[m]>
Hmm. In theory that could all be done at compile time. Well, except for the dynamic aspect of having to look at the topmost variable by that name to see if it's a function reference.
<InPhase>
asin(sin(180*x))/90 Also works!
<peepsalot>
lol
<JordanBrown[m]>
Ok, you're twisted.
<InPhase>
Yes, but I straightened myself out there before output.
<JordanBrown[m]>
But still, in theory the topmost variable could be determined at compile time, and then a builtin function lookup could be three direct references at runtime.
<JordanBrown[m]>
Or something like that.
<JordanBrown[m]>
Less than that. At compile time it could know what the topmost function by that name is, including whether it's a builtin, and it can know what the topmost variable by that name is, so at run time it only has to check that variable and then dispatch.
<JordanBrown[m]>
... All of that if, of course, we were routinely concerned about execution performance. Which we should be, but is generally hard to get excited about when render cost is usually several orders of magnitude larger.
<peepsalot>
every unique (scope,symbol) tuple could be represented with an index into a vector of virtual registers. then lookups would be much faster than multiple unordered_map lookups
<JordanBrown[m]>
yes, something like that.
<JordanBrown[m]>
though I think it can be as simple as offsets into a stack.
<peepsalot>
that would require an intermediate representation between AST and CSG though.
<JordanBrown[m]>
which, I guess, is exactly what you said.
J1A842735 has joined #openscad
<JordanBrown[m]>
I'm not sure that it would require a visible intermediate form; I think it might be possible to build up that intermediate form at parse time while building up the AST.
<JordanBrown[m]>
Or, rather, to build up that {scope, symbol} table at parse time.
J1A8427 has quit [Ping timeout: 260 seconds]
<peepsalot>
it would be more convenient I think if all symbols could represent values. Prerequisite: implement "module references", then convert all builtin functions and modules into `Value`s
<teepee>
craftinginterpreters has an implementation for that
<JordanBrown[m]>
If I was going to do OpenSCAD 2, the first thing I would do would be to eliminate the three separate namespaces.
<JordanBrown[m]>
But I think that's only a minor cost for this particular problem. At any given moment you can know, at compile time, what the topmost variable, function, and module is.
<JordanBrown[m]>
You probably have to know, in some comparable sort of way, what level each was declared at.
<JordanBrown[m]>
and then if the topmost variable is *not* a function reference, use the topmost function.
<JordanBrown[m]>
If the topmost variable *is* a function reference, then use it *if* it is above the topmost function.
<JordanBrown[m]>
Rearranging, if the topmost variable is a function reference and is above the topmost function, then use it, else use the topmost function.
<peepsalot>
i can't remember, how much would it hypothetically break things if we made *all* builtins into "function reference" and "module references"?
<JordanBrown[m]>
you need to ensure that saying "sin = 0;" does not break the sin() function.
<JordanBrown[m]>
and that if you say m=5 at one level, and then you say "module m() { ... }" at a higher(lower?) level, and then you say "m", you get 5, not the module.
<JordanBrown[m]>
being able to say "cube" and get a reference to the cube module requires looking all the way up the lexical stack for a variable named cube, and if there isn't one then looking all the way up the lexical stack for a module named cube, and then finally looking for a builtin.
<peepsalot>
JordanBrown[m]: make it a warning to override builtin function|module with a value of a different type? possibly even with some kind of annotation to ignore the warning
<JordanBrown[m]>
Life would be *much* nicer if it was all one namespace.
<peepsalot>
s/ignore/silence/
<JordanBrown[m]>
I would have to think about it, but I'm pretty sure that's not enough to address all of the issues.
<JordanBrown[m]>
There's also a syntactic ambiguity, unfortunately.
<peepsalot>
also maybe keep a backup duplicate __sin builtin, and reserve "__" prefix to readonly
<JordanBrown[m]>
yes, that's probably desirable. Or there are other techniques that could be used with objects.
<JordanBrown[m]>
the syntactic ambiguity is that you would really like to be able to invoke a module reference as
<JordanBrown[m]>
modrefexpr(args)
<JordanBrown[m]>
where modrefexpr is any expression that evaluates to a module reference.
<JordanBrown[m]>
so (cube)(10) should work.
<JordanBrown[m]>
or (transform)([2,2,2]) ...
<JordanBrown[m]>
And similarly for function references.
<JordanBrown[m]>
But then it turns out that (a)(b)(c)(d) is ambiguous.
<JordanBrown[m]>
It could be either a function a that takes argument b, returning a function that takes argument c, returning a module reference that takes argument d
<JordanBrown[m]>
or a module reference a with argument b, with a child that is a module reference c with argument d.
<peepsalot>
i don't think it can be ambiguous if you know the types of a,b,c,d going in though
<JordanBrown[m]>
but you don't.
<JordanBrown[m]>
module troublemaker(a,b,c,d) {
<JordanBrown[m]>
(a)(b)(c)(d);
<JordanBrown[m]>
}
<JordanBrown[m]>
if you were deciding which form it was at run time, you could, but we currently make that decision at parse time.
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<JordanBrown[m]>
or even
<JordanBrown[m]>
a = cond ? funcrefexpr : modrefexpr;
<peepsalot>
ah, yeah. i was gonna say something like you'd have to consider it an error to possibly assign a var to more than one of (function|module) types
<peepsalot>
but that would require recursively checking all callsites, which would mean some kind of weird lookahead that I don't even know if (our or any) parser can do
<JordanBrown[m]>
There are probably syntactic hackarounds, but ugh.
<JordanBrown[m]>
It might be possible to have a hackaround that says that you can't have a parenthesized modrefexpr as a direct child.
<JordanBrown[m]>
So (a)(b)(c)(d) would be the two-functions-and-a baby, er, module, and if you wanted the mod-arg-mod-arg variant you would have to say (a)(b) { (c)(d); }
<peepsalot>
teepee: bookmarked btw, thanks. looks very handy, will have to sit down and read it sometime when i'm less distracted
berndj has quit [Remote host closed the connection]
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #openscad
LordOfBikes has quit [Ping timeout: 268 seconds]
<InPhase>
JordanBrown[m]: Python does not make it an error to override built-ins. It's just stupid to do. Probably the most common error of this type is all the beginners who write list = [2, 3, 4];
<JordanBrown[m]>
I wasn't suggesting making it be an error to override builtins. I just want there to only be one namespace.
<InPhase>
Yeah, that would have been a much better idea.
<InPhase>
There are lists of libraries that would break with that though.
<JordanBrown[m]>
so you are free to have a local variable called cube, but don't expect to use the builtin.
<JordanBrown[m]>
Yep.
<JordanBrown[m]>
See above where I said something about "OpenSCAD 2".
<InPhase>
That would open a floodgate of questions about how much we're willing to change and break. :)
<JordanBrown[m]>
yes
<JordanBrown[m]>
maybe we could make it so you define modules like so:
<JordanBrown[m]>
... body ...
<JordanBrown[m]>
def mymod(args):
<JordanBrown[m]>
:-)
<InPhase>
I'm already leaning toward "we don't need modules".
<JordanBrown[m]>
we could define modules like so:
<JordanBrown[m]>
function mymod(args) { ... body ... }
ur5us has quit [Ping timeout: 268 seconds]
<JordanBrown[m]>
but yes, I would say that everything is a function, and if a function returns geometry at the top level, then that geometry gets added to the current CSG tree.
<JordanBrown[m]>
More precisely, you should be allowed to have an expression at the top level, and if the expression returns geometry, that geometry gets added to the CSG tree.
<JordanBrown[m]>
Also, I'd like to try something similar: if your expression returns anything *other* than geometry, the value gets written to the output log.
<JordanBrown[m]>
So there's no need for an "echo"; if you want to print something, just say it at the top level.
<JordanBrown[m]>
So it's a lot like Python and node.js's REPL, but all the time.
LordOfBikes has joined #openscad
<InPhase>
I like an explicit echo or print.
<JordanBrown[m]>
You're just used to it.
<InPhase>
Debugger struggle: "Where is this 2 output coming from?"
<JordanBrown[m]>
And such a scheme can't work in C or JS where nearly everything returns a value.
<JordanBrown[m]>
But in a language where, for instance, assignment doesn't return a value, there's a lot less of an issue.
<JordanBrown[m]>
But yeah, in that case it would be nice to be able to search.
<InPhase>
For this reason I like a stray value that doesn't belong there being an error of some sort.
<JordanBrown[m]>
Though in the IDE it could behave like a browser JS console, where each line also gets a reference back to the source.
<InPhase>
C and C++ do not actually do this well.
<JordanBrown[m]>
which "this"?
<InPhase>
int x = 5; x;
<InPhase>
Although there are warnings available for this now.
<InPhase>
The language itself says it's fine, but compilers have really beefed up available warnings so these things are caught better now.
<JordanBrown[m]>
Indeed.
<JordanBrown[m]>
Kind of the flip side of the debug problem you mentioned.
<JordanBrown[m]>
Gyroid sure seems like it must be slower than any of the other infill types, but aesthetically I really like it.
fling has quit [Remote host closed the connection]
fling has joined #openscad
<JordanBrown[m]>
InPhase you still up?
<InPhase>
Trying not to be. :) What's up?
<JordanBrown[m]>
check your email
<InPhase>
I mean, besides me.
<JordanBrown[m]>
and me
<JordanBrown[m]>
but it's less wrong for me than for you
<InPhase>
Nice. :)
<JordanBrown[m]>
Thought you might like it.
<JordanBrown[m]>
As it happens, it wasn't quite as complete as I thought; I'd forgotten to hook it up as valid input to render(). But that's just a couple of lines and the build should finish momentarily.
<JordanBrown[m]>
And there's a couple of different "print yourself" variations that aren't there yet.
<JordanBrown[m]>
But still, as I suspected it would it all fell together pretty easily.
<InPhase>
I'd like to see box(10); on a line by itself. And if o; on a line by itself worked, I'd like to see where it doesn't.
<InPhase>
We had theoretical discussions about the ambiguous cases. Now we could actually see where they hit for real.
<JordanBrown[m]>
I believe that as soon as I try to hook those into the syntax, Bison will complain.
<JordanBrown[m]>
But I should try anyway.
<InPhase>
Yep. Seeing the complaint even would be informative.
<InPhase>
Ultimately there's a solution for it all.
<JordanBrown[m]>
Sure.
<JordanBrown[m]>
Maybe tomorrow.
<JordanBrown[m]>
and the solution is OpenSCAD 2?
<JordanBrown[m]>
:-)
<JordanBrown[m]>
But for instance I think that the (a)(b)(c)(d) ambiguity is there for this syntax too.
<JordanBrown[m]>
And, as for module reference invocations, there are syntax hacks that could work around it, but yukc.
<JordanBrown[m]>
I should also pull in Revar's object() function.
<JordanBrown[m]>
Anyhow, g'nite.
<InPhase>
That's pretty redundant with the other variants.
<InPhase>
Unless you're just trying to assemble a mega-test-every-option build. :)
<JordanBrown[m]>
Well, that too, but I think it's a useful swiss-army-knife for constructing and editing objects.
castawayc has quit [*.net *.split]
ABSHK has quit [*.net *.split]
pbsds has quit [*.net *.split]
ABSHK has joined #openscad
castawayc has joined #openscad
pbsds has joined #openscad
guerdy has quit [Read error: Connection reset by peer]
guerdy has joined #openscad
guerdy has quit [Read error: Connection reset by peer]
guerdy has joined #openscad
Cadair has quit [*.net *.split]
Cadair has joined #openscad
fling has quit [Remote host closed the connection]
<J1A842735>
https://ibb.co/znF7BJf this time again .. these are made with linear_extrude() (stacked recursively)
ur5us has quit [Ping timeout: 256 seconds]
ur5us has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
ur5us has quit [Ping timeout: 268 seconds]
guerd87 has joined #openscad
guerd87 has quit [Quit: Leaving]
lastrodamo has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
epony has quit [Ping timeout: 268 seconds]
<InPhase>
JordanBrown[m], peepsalot: I woke up with a new entry for the code-golf championships: 2*min(x,1-x) in comparison to its tie with 1-abs(1-2*x)
<InPhase>
I think the min one is probably faster to reason about and understand.
fling has quit [Remote host closed the connection]
fling has joined #openscad
epony has joined #openscad
epony has quit [Ping timeout: 268 seconds]
epony has joined #openscad
qeed__ has quit [Quit: qeed__]
qeed has joined #openscad
<J1A842735>
why can't the export not just remember the last name i exported ..
<JordanBrown[m]>
J1A842735: Those are lovely. Are they a whole lot of linear extrudes, or just a few? It seems like if it's a whole lot, it might be just as easy to construct them as polyhedra.
<J1A842735>
( and i already had that module .. so it is just 1 line of code)
<JordanBrown[m]>
I will be interested to see what people come up with in terms of that kind of distortion when we have the render function that returns a polyhedron that you can then distort.
KimK_ has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
We were talking at one point about lights and the camera, and I had a thought.
<JordanBrown[m]>
What if lights and cameras were nodes in the tree? That would naturally give them positions and orientations, and they could have additional parameters. Multiple camera would be a new thing, but might be nice - maybe you would show multiple views, or maybe there would be an easy way to switch between views.
KimK has joined #openscad
<Scopeuk>
I guess multi cam is easy conceptually for the mesh (it's a 3d object in a 3d render engine after all) but perhaps not so much for preview
<JordanBrown[m]>
it's just N previews.
<InPhase>
JordanBrown[m]: It's an interesting notion.
<Scopeuk>
this is true, it does come "for free" in quite the same way the 3d stuff would though
<Scopeuk>
although if the lighting remains camera relative that is less of a concern
<InPhase>
I don't think it needs to be nodes in the tree for cameras, but it would be easy enough to extend the $vpr and so on notions to list form.
<InPhase>
The hard parts would be figuring out sensible gui upgrades for that which have a valuable workflow.
<JordanBrown[m]>
It was more the node-in-the-tree mental model than the multi-camera part that I thought was interesting. The multi-camera part fell out of the fact that it would be hard to insist that there was only one such node.
<InPhase>
Lighting however could absolutely end up part of a node in the tree.
<InPhase>
Something as simple as a lamp on the end of a swivel, for example.
<JordanBrown[m]>
I'm not sure what a swivel means in this context.
<InPhase>
A mechanical arm which could potentially be animated.
<InPhase>
Like a movable overhead desk lamp.
<InPhase>
i.e., justifying that you wouldn't want to hardcode it.
<JordanBrown[m]>
you mean so that the light itself would be visible in the camera, as opposed to just lighting up the model?
<peepsalot>
JordanBrown[m]: it only makes sense to have lights/cameras defined at the top level IMO. not sure how enforcing that would look
<InPhase>
JordanBrown[m]: We worked on that one in channel. I think it was peepsalot who worked out the code to make that light cone, to "fake" the effect of a light source.
<peepsalot>
ah yeah i remember that
<InPhase>
So if we had that on a swivel arm, we'd want it part of the model, and reflecting light off of other parts of the model. :)
<peepsalot>
but what does this mean? difference() { cube(); light(...); }
<InPhase>
peepsalot: It means you did something nonsensical.
<InPhase>
Light sources would not be geometry.
<InPhase>
It would be a different value type with positional placement.
<peepsalot>
maybe they should be annotations of some sort then?
<peepsalot>
rather than module-looking things
<InPhase>
But where that positional placement could be recursively at the end of a module chain.
<InPhase>
So this should make sense, with some sort of syntax not fully defined here: module LampHead() { DrawCone(height=10, width=10); translate([0, 0, 5]) light(brightness=2); }
<InPhase>
You want to be able to translate and rotate the LampHead and the light follows it.
<InPhase>
Because it is a part of it.
castaway has joined #openscad
<InPhase>
But how it is implemented is just it gets treated like a second type of thing produced, rather than part of the geometry, it just gets its positioning (and maybe directionality distribution, sizing, and/or coloring by some method?) from where it is in the model.
<InPhase>
Probably this isn't the highest need feature, but if we had all the cool things, that would be one of them and could make sense. :)
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<JordanBrown[m]>
(sorry, local interruption)
<JordanBrown[m]>
peepsalot "at the top level" isn't all that meaningful. As soon as you translate or rotate it, it's not at the top level
<JordanBrown[m]>
InPhase I hadn't really thought about including light sources in the image. Makes sense, seems almost orthogonal.
<JordanBrown[m]>
InPhase yes, position and orientation. Not sure if scaling or other transforms would be meaningful.
<JordanBrown[m]>
But a basic light might, for instance, point +Z from [0,0,0], and you could translate and rotate it as desired from there.
<JordanBrown[m]>
Similarly a basic camera.
<InPhase>
If you scale an object with a light source in it, then it would have to relocate the light source accordingly. Other aspects of scaling only make sense if light sources are given non-zero size.
<peepsalot>
yeah, i meant more like it doesn't make sense to be involved in CSG operations
<InPhase>
And if they are visible in the image, non-zero size will certainly be desired.
<InPhase>
For example, if you have a spherical light source primitive, you might want to stretch it out. :)
<JordanBrown[m]>
yes
<JordanBrown[m]>
peepsalot add it to the long list of nonsensical things to do. :-)
<InPhase>
In fact, one way to handle it is maybe to just make "light source" a property of a geometry object.
<InPhase>
Like color.
<InPhase>
"This thing glows too"
<peepsalot>
i don't think there's any simple way to render non-point light sources, without ray tracing
<InPhase>
Then you do your CSG, you get the colors of everything, some of them are light sources, and then you render with ray tracing with "pretty output" is pressed.
<JordanBrown[m]>
I think Unity distinguishes "things that glow" from "things that cast light".
<J1A842735>
didn't we already have a target variable for the camera when using command line?
<JordanBrown[m]>
Along some similar lines, I was wondering about having an "annotation" node. Technically it would just be a group() node, but you would be able to give it arbitrary named arguments, and those named arguments would be visible in the CSG export and, ideally, to exporters.
<peepsalot>
JordanBrown[m]: i mean, it probably does, but it also has all kinds of much fancier shaders that would know what to do with that. shadow mapping, ambient occlusion, etc.
<JordanBrown[m]>
And then I was wondering about doing a POV-Ray exporter that would consume annotation nodes to control textures and the ilk.
<InPhase>
J1A842735: Yes, there are 3 special variables for that.
<J1A842735>
would it be hard to make them usable within the GUI?
<InPhase>
J1A842735: I've written code to make animation use them.
<JordanBrown[m]>
The camera control variables?
<InPhase>
J1A842735: You can just set them from $t and the camera moves around in the display as your animation.
<InPhase>
So we basically already have that, for one camera.
<JordanBrown[m]>
Window/Hide Viewport Control
<JordanBrown[m]>
lets you control where the camera is.
<InPhase>
I think JordanBrown[m] was thinking about applications like parts where you want 3-axis views generated, and things like that.
<J1A842735>
this "=eye_x,y,z,center_x,y,z "
<JordanBrown[m]>
it's kind of backward from camera positioning, since it's more like the camera is in a fixed place and you're moving the model, but the end result is the same.
<JordanBrown[m]>
yes, you can do that, but it's a math and visualization nuisance.
<J1A842735>
the $vpt is controlling the target not the camera ..
<JordanBrown[m]>
You say pot-ay-to, I say pot-ah-to
<othx>
JordanBrown[m] linked to YouTube video "House model walkthrough" => 1 IRC mentions
<J1A842735>
there is just someone asking for this on reddit
<peepsalot>
for multicam would you just have it export separate pics for each cam, or would there be some way to define the layout of the camera views in a single viewport?
<JordanBrown[m]>
No idea.
<JordanBrown[m]>
Like I said, the original idea was that the camera was a node, to make it more integrated. Multi-camera fell out of the fact that it would be hard to require that there's only one such node.
<JordanBrown[m]>
From a UI perspective maybe there would be multiple view panes/windows, or maybe there would be a way to switch between cameras.
<JordanBrown[m]>
"way to switch between cameras" would be sort of akin to the current "view along axis" buttons.
<JordanBrown[m]>
though as I think about it, if you had multiple camera then you would *also* want to be able to rotate and translate the model while holding the cameras fixed.
<JordanBrown[m]>
J1A842735: was the redditor looking for simple camera positioning, or for flythrough animation?
<JordanBrown[m]>
I started to library-ize it, but didn't get very far.
<JordanBrown[m]>
But it would be better if it was turtle-style and you could move the camera through arcs.
<JordanBrown[m]>
https://bpa.st/JBDA is a useful snippet for debugging your route. It places a sphere with a nose where the camera is, so you can watch it from above.
califax has quit [Remote host closed the connection]
<JordanBrown[m]>
Looks like somebody has already supplied pretty much the same thing I did.
<JordanBrown[m]>
Another thing we might consider, that really shouldn't be all that hard, would be to have an alternate mode for the UI that has first-person-shooter controls.
J1A84273544 has joined #openscad
<JordanBrown[m]>
That is, move camera forward, rotate camera, translate camera.
califax has joined #openscad
<JordanBrown[m]>
You can do those things with the current UI, but it's hard.
<JordanBrown[m]>
So hard, in fact, that when I recently wanted to do it I gave up and brought in my fly-through stuff.
<JordanBrown[m]>
But it is time for me to go. Later.
<J1A84273544>
this is what i said .. the command line has these as "eye"
J1A842735 has quit [Ping timeout: 260 seconds]
<J1A84273544>
well not with relative translation
<InPhase>
I got distracted playing with $vpt, $vpt, and $vpd for animation. This made a neat effect. :) https://bpa.st/GKXA
<InPhase>
A few more functions would clean up some of that value redundancy, but I got to the point of the effect I wanted to see.
<JordanBrown[m]>
cool
<JordanBrown[m]>
later
<InPhase>
I suppose the next scales of generality would be specifying it all in one object list (because vectors of vectors of vectors are too much of a mess), and support to specify the type and scale of smoothing at the transitions, because smoother_step makes a sort of singular choice for you.
<InPhase>
Although one that works really well for the airplane.
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
Junxter has quit [Read error: Connection reset by peer]
Lagopus has quit [Ping timeout: 252 seconds]
RichardPotthoff has quit [Quit: Leaving...]
milza has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
RichardPotthoff has joined #openscad
TheCoffeMaker has quit [Ping timeout: 248 seconds]
epony has quit [Quit: QUIT]
TheCoffeMaker has joined #openscad
ali12341 has quit [Remote host closed the connection]
ali12341 has joined #openscad
ali12341 has quit [Remote host closed the connection]
ali1234 has joined #openscad
epony has joined #openscad
teepee_ has joined #openscad
teepee has quit [Quit: bye...]
teepee_ is now known as teepee
<JordanBrown[m]>
Next silly idea: have a way to tell the customizer "prompt the user for a file name here". The model might then use that file name as the target for an import("foo.stl") or import("foo.svg") or even import("foo.json").
<JordanBrown[m]>
This idea comes from my wife (who does not do 3D modeling) wanting to have me build something, where a primary component is a 2D design that she provides. It would be cool to just hand her a customizer-enabled model and say "here, plug your drawings into this".
<teepee>
why not, it's a bit similar to the "draw a polygon" feature of thingiverse customizer
<InPhase>
JordanBrown[m]: Well the customizer will already let you enter a string which you can then import.
<JordanBrown[m]>
But a file picker is better for this purpose.
<InPhase>
Yes.
<InPhase>
I would do that not as a popup, but as a special customizer setting in the comments which causes a file browser widget to appear in the customizer, which you then click on to pop up the browser.
<JordanBrown[m]>
Right.
<InPhase>
This sounds pretty reasonable to me.
<dalias>
sounds good to me too
<InPhase>
Just be careful to pick a good distinctive syntax.
<InPhase>
So much chaos has emerged from that customizer comment syntax being poorly thought out and questionably processed at times. :)
<JordanBrown[m]>
Changing subjects, when building OpenSCAD with cmake, isn't there a file that gets a build log?
<JordanBrown[m]>
InPhase allowing a bare expression at the top level leads to a large number of conflicts. (87 shift/reduce, 43 reduce/reduce.)
<JordanBrown[m]>
OTOH, allowing an expression in parentheses is clean, as long as we don't also try to allow module reference expressions in parentheses.
<InPhase>
Well it will need to come with an extra C++ function edit to do that disambiguation lookup procedure.
<JordanBrown[m]>
Which "it"?
<InPhase>
Oh wait, bare expression alone?
<InPhase>
Bare expression alone should be easy because we don't have one. But the combination items require a disambiguation.
<JordanBrown[m]>
Bare expression alone generates a big pile of conflicts.
<InPhase>
Like func(5); and mod(5); must be disambiguated out of the parser by a lookup procedure.
Sauvin has quit [Quit: Leaving]
<InPhase>
"obj;" should not conflict with anything if it maps to its own thing, because nothing currently looks like that.
<JordanBrown[m]>
Many of them have to do with the conflict between, e.g., "assert" as part of an expression and as a module-oid call.
<JordanBrown[m]>
Right, I did say "bare expression", not "bare variable reference".
castaway has quit [Ping timeout: 240 seconds]
<JordanBrown[m]>
And yes, I'm sure that f() and m() are one of the conflicts that it notices.
<InPhase>
Ah, I did not parse the distinction.
<InPhase>
(Pun half intended.)
<JordanBrown[m]>
Especially since, e.g., "f1() - f2();" could be either a module f1 with child expression "-f2()".
Sauvin has joined #openscad
<JordanBrown[m]>
That's a meaningless child expression, but if we're allowing naked expressions we don't know that at parse time.
<JordanBrown[m]>
or it could be a single expression with the results of one function subtracted from the results of the other.
<JordanBrown[m]>
which is also meaningless at the moment, but we don't know that at parse time.
<JordanBrown[m]>
And in the future maybe a-b would be equivalent to difference() { a; b; }.
<JordanBrown[m]>
restricting it to a "call" knocks it down to "only" 32 s/r and 3 r/r.
<JordanBrown[m]>
Some of which could undoubtedly be eliminated, because I'm sure that it is finding the expression-context {...} structures conflicting with the statement-context {...} structures, and at least the "pure geometry" and "hybrid" structures are really the same thing as the statement-level {...}.
<InPhase>
Can you work the other way and start adding in the simplest unambiguous syntaxes for it?