<nomike>
The design allows to specify a list of tuples for the cutouts. Each tuple consists of an angle and a x-axis position of a cutout. So it's a two dimensional array. I use a python script I wrote, which iterates over each parameter set in the customizer json and renders an STL.
<nomike>
I know, rendering a GUI element for a two-dimensional is not really possible, as it depends a lot on the meaning of the values, so I understand why this doesn't work.
<nomike>
But, is there a way to still specify the value in the .json file manually, so that the customizer could use it? My lay-persons approach of just adding the value as an array to the .json file obviously doesn't work, but I hope it brings across what I need.
<nomike>
Ahhh...wait. Damn you ADHD! I already asked something similar in the past, and totally forgot about that. I think I'm fine. Thanks anyway.
J24k5 has quit [Quit: Client closed]
J24k5 has joined #openscad
<InPhase>
nomike: I checked the log, and remember pointing you to the csv parser. :) But I also remember advising you about the overlap rule. You're still missing the overlaps in this design. :)
<nomike>
With overlap you mean preventing z-fighting, right?
<InPhase>
Oh, no, you do have them. They're just a little small for my display engine to catch them it seems. Raising your eps value fixes the preview for me.
<InPhase>
0.01 resolves like half, and 0.1 resolves the rest.
<InPhase>
So I guess the design is probably valid, just not previewing well.
<nomike>
Ah. OK. So the eps needs to be big enough. Good to know.
<InPhase>
Whenever it doesn't impact the design, I usually just make it 1, so there are no issues.
<InPhase>
I only use tiny values if the overlap is going to bump into something else.
<nomike>
Hmm....interesting point. I always tried to make it as small as possible, to not interfere (that's why I called it `epsilon`). But you're right. Most of the time , it doesn't influence the dimensions of the finished object at all, unless, s you said, it bumps into something else.
mmu_man has quit [Remote host closed the connection]
<InPhase>
I still don't understand the infrastructure behind all that, but it amuses me that the funcutils string library is finding practical abuses of its functionality.
J24k31 has joined #openscad
J24k5 has quit [Ping timeout: 256 seconds]
_whitelogger has joined #openscad
L29Ah has quit [Ping timeout: 264 seconds]
germ has quit [Ping timeout: 252 seconds]
germ has joined #openscad
misterfish has joined #openscad
L29Ah has joined #openscad
<J24k31>
InPhase any thoughts on making an oval gear - i was going to use recursion for teeth distribution or what would you use?
misterfish has quit [Ping timeout: 252 seconds]
Guest21 has joined #openscad
Guest21 has quit [Client Quit]
feep has joined #openscad
<feep>
hi
<feep>
I'm gonna try to (convince an AI to) add a feature to the language, and I'm wondering if there's any hope of it being merged or what other people think
<feep>
the idea is it adds a new object primitive, the "point". points have names and a vector value, and are transformed along with the rest of the geometry, but don't show up in the generated stl. instead, they can be referenced by name and, as opposed to variables, their value is the *transformed* point.
<feep>
transformed vector.*
<feep>
they can also be accessed as a property on modules.
<feep>
the idea is that afaict openscad has no good way to position objects relative to other objects, you have to do everything by manual math, this especially gets really annoying around rotations.
<feep>
points let you tag a location on an object and reference it *after* the transformation stack.
<InPhase>
J24k31: Hmm. An interesting question. I think the logical approach here is to create first some large number of oversampled points, form them into [perimeter_step, theta], then [cumulative_sum_perimeter_step, theta], then from this extract the numerical perimeter, divide by the desired number of gears, and use the interpolation features built into the lookup call to get the angle theta for the points
<InPhase>
in between each gear.
<InPhase>
J24k31: By combining oversampling with interpolation, this should give an extremely good approximation of the correct angular positioning of the start and stop theta values corresponding to each gear placement.
<InPhase>
J24k31: The other approaches I could think of would involve looking up some series expansions which describe the perimeter, but I think this ends up more overall work than just computing out the oversampled points, interpolating, and getting the values one needs.
<J24k31>
i thought about using a normal (circular) gear to cut them - but then the rotation of that need to change
<J24k31>
also the teeth profile need to change depending center distance
<InPhase>
J24k31: That approach would result in slow renders. But if you do it by point lists like this, you'll get resulting coordinates to anchor each tooth to, and then you can construct the gear additively. You will know your placements for everything.
<J24k31>
the outside will become more difficult ..
<InPhase>
To what extent do the teeth profiles really need to change?
<InPhase>
I suppose a bit of the curvature should be different.
<J24k31>
I probably could get away with a scaled center gear to make it oval .. not so much for the outside
<J24k31>
and the ellipse is the simplest shape for this .. which already has no formula to calculate the circumference
<InPhase>
I would break the problem down. Make a function to generate teeth of a given arc length s based on radial distance r, then just compute s and r from your final list of perimeter positions and thetas. Then you have your start and stop theta for each tooth, and a function to make teeth points of the right geometry, and you do a for loop and polygon it.
<teepee>
anchor points have been suggested and I think would be a useful addtion
<feep>
yay!
<feep>
lemme see how far I can get with just sonnet and no knowledge of the codebase.
<teepee>
it probably can't be just a point
<feep>
well it'd be useful to have normals too
<feep>
but not urgent for a mvp I think
<teepee>
I don't think it makes sense to leave that out actually
<teepee>
the suggested syntax is impossible though
<teepee>
assigning variables in an inner scope and using them later is breaking any current assumption, so there has to be some other way of doing that
<feep>
I don't see it as a variable.
<feep>
I mean, $variables are their own thing, right? This is more a property of the geometric context.
<teepee>
my idea would be starting with predefined anchor points and figuring out how to *use* those
<teepee>
once that step is clear, add way of defining new anchor points for custom objects
<teepee>
I would assume that needs the object PR to be clarified and integrated. this will give hopefully a number of base features needed
<feep>
ooh object pr. yeah I can see how that'd collide.
<feep>
and what you mean about scoping. points definitely have a whole different scoping than that.
<feep>
Maybe hide all the variables behind the `point` keyword?
<feep>
Ie. point p([10, 0, 0]); echo point.p
<feep>
to make it clear it's its own thing
<teepee>
if they are part of the geoemetry object, they would be automatically scoped and travel with the object itself, no need for a separate entity
<feep>
yep that's how sonnet is putting it down
<teepee>
I think guso78 used a matrix for describing an attachment "point" (place?)
<feep>
the point is more syntactic
<feep>
like, if `p` appeared as a toplevel name, it'd look like it was a variable and following variable scoping rules, and it'd collide with the object proposal aiui
<feep>
guso78: matrix makes sense also, you're basically exporting a subspace ... but it kind of seems like then you need a specific transform operator for "place the object at the origin of the subspace you can see from here"
<teepee>
do you have some time to help discuss and maybe even get some prototype going?
<feep>
teepee: I'm trying to prototype it with sonnet rn, I'll make a discussion pr as soon as (IF!) something works
<teepee>
it's one of the features I'd love to see myself, but I barely manage to do some tiny stuff
<teepee>
it might take quite some time to get something real going, but having the topics at least moving slowly forward would be great
<InPhase>
feep: Let me add this caveat... If you're trying a code change with AI, don't PR it unless it builds and does the thing. AI code generation can sometimes work on straightforward tasks, but for complicated tasks can have subtle bugs that make it useless and are as hard to track down as just doing the work from scratch.
<teepee>
like it's almost december and we probably want to do out scadvent again?
<feep>
InPhase: ..... lol
<feep>
are people doing that?
<feep>
that's hilarious
<InPhase>
feep: So we don't really want to end up with streams of "I made this change with AI but it doesn't quite work, so can you fix it?"
<feep>
"I have an AI and it made this do you want it" "did you try it" "no"
<feep>
InPhase: don't worry, if I'm opening a pr I'm taking responsibility for it.
<InPhase>
feep: More often what I've been seeing is people thinking that the AI got close, without understanding what the AI even did, and what the AI did was actually just chaos. :)
<teepee>
agreed, using an AI to actually write code is very much not acceptable
<feep>
I'm just using sonnet so I don't have to read thousands of lines of C++ header to learn. once I have a diff it'll be easier to understand what it actually did.
<teepee>
using it as a tool to help seems fine to me
<feep>
like... I can't read hundreds of thousands of kilobytes in seconds.
<InPhase>
feep: Okay. :)
<feep>
I am absolutely having it write the code :p don't worry, I'll go over it with a comb before pring anything
<teepee>
I assume it's also a topic that needs quite some talk and not even so much code at the beginning
<feep>
oh yeah
<feep>
I mean, the thing is really really eager to write code lol. I have to explicitly tell it to slow down and plan, plan, plan, and talk to me about it. I mean, it can do it, it just really wants to jump in and start putting code down XD not much training with big tasks.
<InPhase>
There are still apparently open legal questions of assigning a copyright to code produced by AI. This is not a specific problem per-se for a GPL'd project to have code in a portion without a copyright, as public domain code can be integrated. But I am not really prepared to push for a view here as I have doubts of it working particularly well in the first place on this type of project. :)
<feep>
yepyep. on the other hand, I think with a change that's working so closely with an existing codebase there's not much of a worry that it's copying snippets from somewhere else.
<InPhase>
Using it as a guide and for insights of what might need changed seems fine, although honestly I have doubts of that working too.
<feep>
I also have doubts, but I mean hey, the worst thing that happens is I'm out a few bucks.
<feep>
It's worth an afternoon for me.
<InPhase>
Ok. :)
<feep>
also it can read c++ compile errors better than me, which takes a lot of the pain out
<feep>
:P
<teepee>
work called, back in a bit.. hopefully
<InPhase>
In the event that you get anywhere, disclose clearly what role it ended up playing.
<feep>
absolutely
<feep>
## Disclaimer: AI Code
* feep
puts that on all his ai-written repos~
<InPhase>
I've distributed a few "This is off the top of my head. I did not run it." comments. But things I write off of the top of my head without running have had a much higher success rate for the people I give them to than code I've gotten from AI systems so far. ;)
<feep>
there's sort of a medium space of ~1000 line projects where it's very useful. openscad is honestly definitely too big for it, that's why I'm also skeptical
<InPhase>
Yeah. Cohesive reasoning caps out at about 100kB on most things available so far, and gets pretty weak across that full 100kB stretch when pushed to that limit.
<feep>
yep. my current strategy is to try and split things into two halves where I first give it a big dump of code and ask it to select which files it needs and then do a clean run with just those files
<feep>
aider is really nice for that, it has parsers for a bunch of languages so it can give the AI a sparse high-level map of functions and classes
snaked has quit [Ping timeout: 246 seconds]
Smeef has quit [Read error: Connection reset by peer]
<feep>
alright, I have advanced from "sonnet can do it!" to "how the hell *does* this code work anyways??"
<feep>
that's good progress~
<feep>
afaict the problem is that I wanted to have points be discoverable on nodes, but a context actually has no way to let me discover the tree of nodes that have already been generated. I'd have to add that, or the list of points at the current scope, to ScopeContext... but I can't find where we actually walk the ast.
<teepee>
I'm not sure that sounds right
<teepee>
AST is probably the wrong structure
<feep>
I mean, I have to hook in in the transformation from ast to nodes, because when they're nodes they already have to be cashed out, cause I want to be able to treat anchor values as constants.
<feep>
so I have to look at "the nodes that have already been created", but I can't find what drives the recursion
<feep>
this is a bit iffy because the feature does something that nothing else in the code does: react to *nodes themselves*.
<teepee>
I don't understand that. the anchor is constant for a node and needs to be transformed like the node when needed
<feep>
the problem is that the anchor may be needed to create another node.
<feep>
will* in fact.
<feep>
so for instance variables go in Context and are looked up from Context and this is fine because they don't change.
<teepee>
hence my feeling this first needs *thinking* not coding
<feep>
I mean, I had to start with coding so I could even know what to think about.
<feep>
like you have to write implementation before text if it's a new service, because you don't know what needs to happen yet and you need the code to tell you.
<feep>
test*
<feep>
(hence "write one to throw away")
<feep>
like, I can't think about openscad cause I don't know the code, now that I'm trying to understand why the first approach can't work I'm starting to understand it better.
<feep>
teepee: anyway, the big difference to variables is that anchors *change value* depending on where you look them up from.
<teepee>
so do coordinates of geomerty
<teepee>
*geometry
<feep>
yes. but geometry is too late.
<feep>
I can't, say, use properties of geometry in a range expression.
<teepee>
you need to collect transformations along the tree to find the final value
<teepee>
you can, but only in one direction of the tree
<feep>
well, for every variable. and I don't want the transformations "up" the tree, I want the transformations "down" the tree.
<feep>
for every anchor*
<feep>
anchors sort of propagate in the opposite tree direction of variables, lexically speaking.
TylerTork has joined #openscad
<teepee>
yes, same with geometry in general
<feep>
yes. again, if there wasn't the need to be able to treat properties of anchors as an expression, I'd immediately put it in geometry.
<teepee>
expression how?
<feep>
for instance you should be able to do `for(a = [point.a.x : point.b.x]) { }`
<TylerTork>
I've been noticing the openscad client for Windows seems to lose track of the screen location from time to time. I think there's some Windows resize or focus event that it's not intercepting, perhaps having to do with switching monitor configurations or changing which is the primary screen. The symptom is that when you click something in the
<TylerTork>
window, it acts as if you'd clicked higher or lower than you actually did. I can't reproduce it reliably, but if it's not a known issue I'll try harder to pin down the failure scenario. Is it a known issue?
<teepee>
TylerTork: I have not seen an issue for that. also I'm not sure it's something OpenSCAD controls
<teepee>
feep: right. that would only be possible by for example the object PR that allows assigning geometry to a variable
<teepee>
that basically changes the strict single tree process
<feep>
teepee: well with the anchor/point proposal as is and the code as it is right now, it still does work, but it means that points have to already be instantiated during `evaluate()`.
<feep>
which isn't even that hard because they're not affected by all that many nodes
<TylerTork>
teepee I'm very certain there's a way for the client to correctly handle Windows events so that this does not occur. I'll do some experiments to find the reproducible scenario. It's not a new issue -- I've noticed it from the start, several months back.
<feep>
but I can't find how to *get* the already-instantiated nodes *in* `evaluate()`; I don't think that information is accessible because so far it hasn't been needed.
<teepee>
TylerTork: if it's in Qt code, *we* have no way of changing it
<TylerTork>
teepee Let me put it this way. *I* have no way of changing it directly, but I can report it to the OpenSCAD developers -- and I will, once I have enough information to make a good report. Maybe the problem is inherent in a library you got from someone else, and maybe you can't fix it directly, but you can report it to the people who develop that
<TylerTork>
library. I'm going to do what I'm able to do to fix it, and I hope you, or whatever developer on the team seems best suited, will track the problem down so they can make a good report to whoever can actually fix it.
<teepee>
that's fine. due to lack of developers actually using Windows, it might be difficult, but we'll only know if we try
<feep>
Oh it's AbstractNode->children!
<feep>
I think step 0.1 of this PR is rewriting this to store the target in the Context rather than as a parameter on the instantiate calls.
<feep>
so then we can see "the current instantiation hierarchy and progress" in the Context instead of the callstack.
<teepee>
context *is* the call stack (of the openscad evaluation)
<feep>
right, but nodes are in the *actual* callstack.
<feep>
that's what I want. the callstack order of AbstractNode& targets.
<feep>
afaics that's like the one thing that isn't in Context, because until now it hasn't been *part* of the context, because declared nodes didn't have any effect.
<feep>
(on node generation)
<feep>
and the idea is then I can add the nodes for their anchors, basically asking them to preview me their transformations.
<feep>
ask*
<feep>
which works cause all the nodes that are *already generated* are completely defined ... and I want the anchors "from my perspective of them" anyway.
<teepee>
sort of, nodes are the result of the evaluation, the tree of geometry nodes connected via nodes representing the geometry operations
<teepee>
problem with preview of transformations is that it's only known once the full tree exists
<teepee>
so I believe the only way is to do that "resolve partial geomerty tree" as in the object PR and assign that to a variable
<teepee>
and that thing then can be used to both inspect geometry and also extra info as anchors
Junxter has quit [Read error: Connection reset by peer]
<feep>
teepee: yeah but no stop I actually want the *children* of the *currently being generated nodes*.
<feep>
I really think adding the current generating node to Context will fix everything!
<feep>
cause then I can just follow the hierarchy
<feep>
the one point it runs into issues is with modules. cause if it captures the generating node by reference then the module can see anchors of child nodes that were added after it was defined.
<feep>
so module a() { translate(anchor.b.position) sphere(1); } anchor b; a(); because `b` is a child of the RootNode.
<feep>
but that's such a weird edge case that I'm not sure I should even be worrying.
<feep>
and the simplest solution is to just cut off anchor lookup at module boundaries anyways.
TylerTork has quit [Ping timeout: 256 seconds]
<teepee>
hmm, that sounds like a bad restriction as it would cut libraries out of the game completely
<feep>
... downwards? I can never remember with trees.
<teepee>
thats what I mean, we need to first explore the possible combinations, I don't have a feeling yet what exact restrictions there are (and need to be)
<feep>
and what I'm saying is the best way to find out is to try and see what breaks! adventure!
<teepee>
so trying some examples is probably the way to go
<teepee>
yes, certainly adventure, but with a neat reward behind the end vo
<feep>
^^
<teepee>
*end boss
<feep>
if I can make this refactor work, we'll have one less problem in the way of my approach, and if not I'll learn something
germ_ has quit [Read error: Connection reset by peer]
germ_ has joined #openscad
misterfish has joined #openscad
mmu_man has joined #openscad
Guest39 has joined #openscad
Guest39 has quit [Quit: Client closed]
Guest91 has joined #openscad
<Guest91>
Hi How would I make a shape like this in openscad
<InPhase>
Guest91: I was slowed down by a typo. :( I was aiming for 3 minutes.
<Guest91>
thank you
<Guest91>
I'm new top openscad where do I put the library from it to be read by openscad on linux ?
<teepee>
Easiest is in File -> Show Library Folder
<teepee>
that folder is automatically used
<Guest91>
doesnt seem to do anything when I click it on it
<InPhase>
That makes it accessible to all designs. You can also always choose to copy it directly into the same directory as the file you're working on. This is ideal if you want to keep things self-contained.
<Guest91>
I am using a snap of openscad
<InPhase>
~/.local/share/OpenSCAD/libraries/ for Linux
<Guest91>
thanks
<InPhase>
Your snap must be blocking that file browser pop-up.
<InPhase>
That same info is in Help, Library Info
<InPhase>
You just have to scroll and hunt for it on that page.
<InPhase>
That's basically a text info-dump for people reporting bugs.
<Guest91>
interesting maybe because it is a snap it doesnt create ~/.local/share/OpenSCAD/libraries/ for Linux
<teepee>
ah, snap has no access to that folder
<InPhase>
Guest91: Well, go with same-directory for now I guess.
<teepee>
snap sees something like $HOME/snap/openscad/current/.local/share/OpenSCAD/libraries
<InPhase>
Ah, or that.
<InPhase>
Does that get wiped out when snap upgrades though? :(
<InPhase>
I notice the "current" in there, which I think is a symlink.
<Guest91>
just installed it though apt get so now have both versions snap and repository library works now for apt get
<InPhase>
Guest91: I'm usually using the AppImage for versions I don't build myself. There's no installing needed, and no such obstructions in the way.
<Guest91>
ok
<InPhase>
Guest91: You can grab them straight from the site and just execute an AppImage file as-is, no install needed. I stick them in /usr/local/bin and set a symlink to one of them like this: https://bpa.st/Z4SQ
<Guest91>
looks like they are both the same version anyhow apt get and the snap
<InPhase>
Guest91: Then I have an archive of many versions I can run. :)
<Guest91>
ah the app image seems much more upto date
<InPhase>
If you get the nightly release, it's a much much better version than the last release.
<InPhase>
We're talking 50 times faster for many models.
<Guest91>
cool
<InPhase>
Next release is pending some coats of paint, since there were so many big changes.
boots_ has joined #openscad
boots_ has quit [Client Quit]
<InPhase>
Guest91: So did you get the shape going?
<Guest91>
doing it now
<Guest91>
it worked thank you
<Guest91>
used the snap nightly build
<InPhase>
Cool. :)
<Guest91>
how do i increase the fidelity of my openscad render?
<Guest91>
i.e. increase the number of faces
<Guest91>
resolution
<InPhase>
Normally, putting $fa=1; $fs=0.4; at the top of your design.
<InPhase>
If you're talking about the example I just gave you, it's with that 0.4 in the in the PlotPolarFunction call, which you would lower to a smaller number. That calculates its resolution separately.
<Guest91>
higher resolution is a higher or lower number? what's the range
<Guest91>
?
<InPhase>
That 0.4, in both cases, is assuming a 0.4mm nozzle diameter for printing. It's usually meaningless to go below that value.
<InPhase>
But if you were using a 0.2mm nozzle, you might want to go down.
<Guest91>
ok thanks
<InPhase>
The $fa=1 is for large round objects, and represents the angular change step size of those.
<InPhase>
Usually 1 is a very good value. In rare cases of large round parts needing mechanical smoothness, you might tweak that, but often just for that one component.