teepee has quit [Remote host closed the connection]
teepee has joined #openscad
LordOfBikes has quit [Ping timeout: 258 seconds]
default__ has joined #openscad
sublim8 has quit [Ping timeout: 265 seconds]
LordOfBikes has joined #openscad
ccox has joined #openscad
snakedGT is now known as snaked
The_Jag has joined #openscad
ccox has quit [Ping timeout: 244 seconds]
The_Jag_ has quit [Ping timeout: 264 seconds]
ccox has joined #openscad
<af>
peepsalot: Hi, I'm trying to understand the solution you gave me for an oval cylinder with differing radii. I'm unable to understand what the second scale call does (scale([1, ry1/rx1])).
<InPhase>
af: An oval is just a squished circle.
<af>
InPhase: yes, but the linear_extrude's scale should take care of squishing it, no?
<InPhase>
af: Presumably the inner circle was radius rx1, then scale scales x to the same (by 1) and scales y to ry1/rx1 of the old value, so the size of the y radius is now: (ry1/rx1)*rx1 --> ry1
<InPhase>
linear_extrude would then be for the z-dimension.
<af>
My understanding is that the scale in the linear_extrude takes care of the scaling along x and y axis as the extrusion is built up
<af>
Oh wait, the second scale is for the base, duh
<af>
Never mind, thanks
<InPhase>
That scale inside of linear_extrude is setting the dimensions at the top, relative to the dimensions at the bottom.
<af>
yeah
<af>
gotcha
<af>
A more general question I have, is, how to set slices consistently? I am building up pieces for my model as I go along and setting the slices via $fs and $fa in each piece. Is there a global setting to just make them highly refined?
<af>
ah never mind I can just set $fa and $fs globally
<af>
I should get my morning coffee first I guess
linext has quit [Read error: Connection reset by peer]
snaked has quit [Ping timeout: 244 seconds]
pah has quit [Ping timeout: 244 seconds]
pah_ has joined #openscad
snaked has joined #openscad
pah_ has quit [Ping timeout: 244 seconds]
paddymahoney has quit [Ping timeout: 244 seconds]
pah has joined #openscad
pah_ has joined #openscad
pah has quit [Ping timeout: 244 seconds]
ccox has quit [Remote host closed the connection]
pah_ has quit [Ping timeout: 244 seconds]
pah has joined #openscad
pah_ has joined #openscad
pah has quit [Ping timeout: 260 seconds]
ferdna has quit [Quit: Leaving]
snaked has quit [Read error: Connection reset by peer]
snaked has joined #openscad
luissen has quit [Ping timeout: 264 seconds]
NoGare[m] has quit [*.net *.split]
pie__ has quit [*.net *.split]
Taneb has quit [*.net *.split]
ndim has quit [*.net *.split]
fardog has quit [*.net *.split]
Ekho has quit [*.net *.split]
ndim has joined #openscad
pie_ has joined #openscad
Taneb has joined #openscad
fardog has joined #openscad
NoGare[m] has joined #openscad
Ekho has joined #openscad
luissen has joined #openscad
ur5us has joined #openscad
ccox has joined #openscad
JakeSays has joined #openscad
rvt has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
ccox has quit [Remote host closed the connection]
arebil has joined #openscad
mhroncok has joined #openscad
snakedGT has joined #openscad
snaked has quit [Read error: Connection reset by peer]
lastrodamo has joined #openscad
ccox has joined #openscad
aiyion has quit [Ping timeout: 276 seconds]
aiyion has joined #openscad
ccox has quit [Ping timeout: 244 seconds]
stefanct has quit [Ping timeout: 246 seconds]
pah_ is now known as pa
pa has quit [Changing host]
pa has joined #openscad
stefanct has joined #openscad
linext has joined #openscad
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
<sublim8>
The 'at' symbol was needed for solving a parsing ambiguity. I can probably get rid of it. But also it makes sense. Because you are directing a function at a module.
<teepee>
I see, not the biggest issue with the @ but I really would like to keep that free for potential annotation extensions
<teepee>
even though there's no decision of actually using that :)
<sublim8>
I have implemented this mechanism for any built in function. I can probably let user functions access the module later.
<teepee>
but I guess lets first focus on the main feature
<teepee>
lol, we really have all those cache misspellings that are showing up in the console window?
<sublim8>
I also have a parsing issue that only lets me have a module with a child_statement after the '@', but I can solve that aswell.
<teepee>
what's an echo(data); doing in the let?
<sublim8>
lol
<sublim8>
no that's some debugging in my part
<sublim8>
don't judge me :p
<teepee>
oh, that debug should already exist I thought, e.g. with --debug=<CppFileNameWitoutExtension>
<teepee>
right, so it's bounding box min/max/center
<sublim8>
Sure. I can add stuff.
<teepee>
I'd say we get the behavior right first before deep diving into features
<sublim8>
I'll see what I can do with imports
<teepee>
bounding box is a good start
<sublim8>
I haven't tested my implementation thoroughly yet. With recursions and such.
<teepee>
just for completeness, the echo(data) should not give a warning inside the body of let
<sublim8>
that
<sublim8>
That is a let issue
<sublim8>
not my issue
<teepee>
or it could be in data = echo() render() @ ...
<InPhase>
sublim8: Nice. :)
<teepee>
yes, just mentioning the slightly unusual behavior, yes, it has nothing to do with your changes
<InPhase>
I'll let teepee advise on the syntax patches, but it's excellent that's working already. :)
<sublim8>
teepee echo is a module
<teepee>
oops, data = echo(data) render() ...
<teepee>
nope, it's both
<teepee>
well, actually it's not really a function, it's an expression that can be chained like let()
<sublim8>
data is undefined that way
<sublim8>
yes
<teepee>
oh, right, it outputs before calling the function
<teepee>
special request from nophead to be able to debug endless recursion issues :)
<teepee>
data should still be set inside the let body, but the echo output is undef
<sublim8>
yes
<sublim8>
the user can just do a _ = echo(data), inside the let and be done with the warning
<teepee>
yep, that works too
<sublim8>
(can you see the underscore? my client doesn't show it)
<teepee>
yes, fine here in quassel
<teepee>
actually I was thinking if we can reserve the underscore for this kind of feature :)
<sublim8>
afterall it's his fault for using an echo inside a let :p
<sublim8>
to access module information passed to user functions?
<teepee>
yeah, putting it into the body works without the tricks
<teepee>
no, _ as "dummy" variable
<teepee>
like you can also use it twice without warning
<sublim8>
aha
<teepee>
or maybe as no-op in case we ever get structured binding
<teepee>
(a, _, b) = [1, 2, 3];
<teepee>
a = 1; b = 3;
sublim8 has quit [Remote host closed the connection]
sublim8 has joined #openscad
<sublim8>
wth. I changed my irc client to be able to see underscores and all hell broke loose.
<sublim8>
nice going HexChat.
<teepee>
how?
<sublim8>
HexChat froze.
<sublim8>
Killed it and relaunched it.
<sublim8>
After connecting to the server it froze again.
<teepee>
oh, hmm, quassel is surprisingly stable :)
<sublim8>
I managed to change the font again quickly before it froze.
<sublim8>
I'll check it out.
<teepee>
it allows even client/server install, but I'm not using that, ZNC on a raspi is even better :)
<sublim8>
Back to passing modules to functions. Do you think there is value in implementing it for user functions?
<sublim8>
What would the user function do with a module?
<teepee>
at some point yes
<teepee>
but we don't know what a module woould be in that context
<sublim8>
Exactly.
<Scopeuk>
teepee i ended up making the jump from smuxi + znc to the lounge and quite liked it thus far (was mostly limited by android IRC clients being rubbish)
<sublim8>
Probably an object with some information.
<teepee>
there's a design document giving an interesting option, but it's not fully clear how that works
<teepee>
Scopeuk: ah, I've seen The Lounge, but not really tried it. so far I rarely need mobile access, so if I'm not home, I just tunnel via SSH to znc
<Scopeuk>
ahh my "about the house" machine is an android tablet
<sublim8>
I'll have to dive into that document.
<sublim8>
Now I think I'll try to get the vertices in render.
ccox has joined #openscad
<sublim8>
That will be fun.
ccox has quit [Ping timeout: 265 seconds]
<InPhase>
Vertices in render is going to open up so many options.
<InPhase>
s/in/from/
<InPhase>
Arbitrary userspace deformations become calculable, even if potentially difficult.
<sublim8>
Yep
<sublim8>
Working on it right now.
<InPhase>
For now I think we'll need to formally leave the ordering of vertices and faces undefined, as there is no clear ordering that we can guarantee. But at least they will all be there.
<InPhase>
So probably just dump out whatever CGAL provides. Then there remains an option to define it later if someone comes up with a better set of guarantees.
SebastianM has joined #openscad
SebastianM has quit [Quit: Bye]
ochafik has quit [Remote host closed the connection]
stefanct has joined #openscad
ochafik has joined #openscad
Guest7459 has quit [Quit: Client closed]
<teepee>
that said, for review purpose it would be nicer to split the changes in some smaller PRs, not dump everything in 2 month :)
ochafik has quit [Remote host closed the connection]
<InPhase>
Agreed. This is a big enough change that any niceties not critical to the core function should be separated.
teepee has quit [Remote host closed the connection]
ccox has joined #openscad
teepee has joined #openscad
ccox has quit [Ping timeout: 260 seconds]
ochafik has joined #openscad
<sublim8>
Got the vertices. Right now without indices (duplicating the vertices). Next I'll give an option to get them with either indices or with without (vertex duplication).
<sublim8>
minus a 'with'
<InPhase>
I think it's best to not add options to render() if it can be avoided.
<InPhase>
Just always give them. There's no significant extra cost.
<sublim8>
Well, it depends on the mesh size.
<sublim8>
It can be quite expensive for large meshes.
<InPhase>
You want the interface to be as simple as possible for the desired features. And rendering itself will always take far more time and memory than the return of the vertices.
<sublim8>
Maybe give an option to _not_ populate the vertices and make giving everything the default?
<sublim8>
Not even that?
<InPhase>
I think not even that.
<sublim8>
"giving everything by default"
<InPhase>
It's most certainly an added complexity that amounts to a micro-optimization.
<InPhase>
CGAL will take something like 100 times the RAM just to prepare those values.
<sublim8>
Well, ok. It is a small detail.
<sublim8>
Less work for me.
<InPhase>
Yep. And every future maintainer. :)
<InPhase>
We can optimize it out later if there's an edge case where this is wrong.
<sublim8>
Then what should I do with the vertices? Give only indexed vertices or dump them all (with duplicates)?
<InPhase>
Are there duplicates?
<InPhase>
I expected no duplicates and all are indexed with faces in a 3D object.
<InPhase>
2D should have no faces, but should simply be an ordered list around the loop.
<InPhase>
Or wait, no. The 2D has a different structure so it has holes, but I've forgotten it.
<sublim8>
If I give both indices and vertices there are no duplicates.
<InPhase>
For the user facing parts I think we should call these points and faces.
<InPhase>
It would be nice for the language and format to match up with polyhedron.
<InPhase>
The user should be able to take this output and throw it right back into polyhedron and get the object back.
<InPhase>
Likewise for polygon points and paths.
<teepee>
we can still explore if we can pass a function the determines what is returned
<teepee>
not as first step though
<InPhase>
teepee: Do you think data.points and data.paths if 2D, but data.points and data.faces if 3D?
<teepee>
yeah, I guess first idea would be to make it compatible to what polygon/polyhedron take
<sublim8>
Will not support "triangles" since it's deprecated.
<teepee>
yep, setting 2 variables would be confusing
Joel has joined #openscad
<Joel>
Newbie questions probably, would love links to the relevant docs to read. Can you define components in a file, then combine them all? like 2'x4'x8' and 4'x8'x3/4", and pull them into a project called "Shed"?
<teepee>
Joel: I'm not sure what you mean exactly, but the general way of structuring things is to define modules in one file "module component(param) { ... }" and then import those into the main project via "use <component.scad>"
<sublim8>
Now I'll try to fix the syntactic need for curly brackets in the module following '@'
<sublim8>
render() doesn't suffer from the scope because the module it targets is always defined
<sublim8>
from the scope issue
ccox has quit [Ping timeout: 260 seconds]
<sublim8>
teepee thanks for pressuring towards a better solution.
<sublim8>
I like this much better.
<sublim8>
You too InPhase.
niyawe has quit [Quit: niyawe]
niyawe has joined #openscad
<InPhase>
sublim8: It's looking excellent. :)
<InPhase>
But wait. That last one was done without a let.
<sublim8>
Thanks :)
<sublim8>
Yes as I said above. Now the module that is being referenced is always defined.
<sublim8>
It doesn't suffer from the scope issue that the named group had.
<sublim8>
You can still enforce evaluation order with let if needed.
<InPhase>
Well we're going to have to run that through the ringer with some of the self-referential dynamic variable issues. I think there will be problems.
<sublim8>
For sure.
<sublim8>
Getting the vertices though is not free.
<sublim8>
From what I'm seeing.
<sublim8>
I have to loop through all of them and create many VectorType objects.
<InPhase>
It shouldn't take much more time than getting max and min, as those need the vertices anyway. On the simple objects, yes, but on anything that needs computational geometry done that will dominate.
<InPhase>
However the simple objects are not the key use case for this.
<InPhase>
One already knows the points and dimensions of those.
<sublim8>
Max and min are already calculated and readily available by the Geometry object. I don't loop through the vertices for that.
<sublim8>
Yep
<sublim8>
And it's not like we are changing the usual workflow of openscad
<Joel>
teepee makes sense, I'll look up the use docs
<sublim8>
I expect getting the vertices and doing stuff with them to be a special thing.
<Joel>
If you import pieces of a house, "foundation", "walls", "roof", can you specify where to join these objects? Or are you expected to have a drawWalls() method, inside of walls.scad, that takes coordinates?
pa has quit [Ping timeout: 265 seconds]
ochafik has quit [Remote host closed the connection]
pah has joined #openscad
ochafik has joined #openscad
ochafik has quit [Ping timeout: 260 seconds]
<Scopeuk>
Joel generally you set your 0,0,0 positions to make assembly easier. in that example I would expect wall/roof to take some parameters to set dimensioned however
<Joel>
Scopeuk I'm interested in learning how to make assembly flexible i guess. How to join any three shapes, from three different files, on a given coordinate, and go in a given direction
<Joel>
I'll play some, see what I can pull off
<sublim8>
InPhase sadly the time required to get the vertices is really noticeable. For a sphere($fn=32, 10) for example. I get the bounding box data in 0.012 seconds while if I also request the vertices the operation completes in 2.400 sec.
<sublim8>
And that's a small mesh. I really think we should consider an option.
<sublim8>
The bottleneck is the objects created for the openscad type system. There's no way getting around that.
<sublim8>
should I split the functionality to two modules?
<sublim8>
Get the bounding box in a bounding_box, measure, metrics what have you module and a separate render that gets the mesh data?
<Scopeuk>
Joel not yet
<Joel>
Scopeuk ok, interesting.
<Scopeuk>
thats what sublim8 is currently working on implementing (the other discussion happening here)
<Joel>
Thinking through how I could rotate a shape, like if I have a function that generates a rectangle, then a method that could rotate it for me, I need some way of telling which way to rotate it, based on the rectangle passed in
<Joel>
Obviously, I can do it for a known shape passed in, just not an unknown shape.
<Joel>
Gotta say, really impressed and in love with openscad so far
<Scopeuk>
Joel I'm struggling to visualise what you are trying to describe there.
<Joel>
Scopeuk Generic piece of lumber, Like a 2x4. I want to on the fly orient it. long way up, long way left right, long way forward back, for example
<Joel>
I was just hoping to write code around the shape so I don't have to remember initial orientation, before rotating it
<sublim8>
create a module
<Joel>
sublim8 I've done that, but what if you don't know starting orientation?
<Scopeuk>
Joel you can pass an orientation string and put some if's in the module
<teepee>
you can declare functions returning extra data
<Joel>
teepee oooo awesome, hints on what to check the docs for?
<teepee>
there's a forum discussion about that lately, let me find the key post
<Joel>
function literals?
<sublim8>
teepee: On the render subject. What do you think about splitting the functionality in two? As I said above? Returning the vertices is much slower than just returning the bounding box.
<Joel>
teepee no worries, I will read through, thanks!
<sublim8>
(I really have to start reading what I'm writing :p)
snakedLX has joined #openscad
<teepee>
sublim8: that's why I was thinking if we can pass in a function to take care of that decision
<teepee>
but there's no code doing that as of now, so there's a couple of big question marks
<sublim8>
Pass a function where?
<sublim8>
pass a function to a function?
<teepee>
render(get_points);
<teepee>
render(get_bounding_box);
snakedGT has quit [Ping timeout: 244 seconds]
<sublim8>
why not use parameters?
<teepee>
because with parameters you can only get what's defined in code
<teepee>
with a function you could leave it to the user to get all faces that are horizonal
ccox has joined #openscad
<sublim8>
I can't even begin to imagine how that would work.
<sublim8>
the function the user passes is interpreted scad language.
<teepee>
right now you have a function that has the geometry as input and a data object as output
<sublim8>
It has no access to vertex data if I don't provide it
<sublim8>
If I do provide it, it takes time.
<sublim8>
go on...
<sublim8>
Creating the data object what takes time.
<teepee>
now if you write 2 functions that have same input parameters and same type of return, you can pretty much exchange those
<teepee>
lets just use a scad only example with data
<sublim8>
I'm listening...
ccox has quit [Ping timeout: 260 seconds]
pah has quit [Ping timeout: 244 seconds]
pah_ has joined #openscad
<sublim8>
But I should let you know that the costly part is getting the data from the Geometry, CGAL_Nef_polyhedron objects to a VectorType, so that they can be available to the openscad interpreted language.
<sublim8>
How could the interpreted language function affect what is hardcoded in C++? The vertex data is either there or not.
<Scopeuk>
I wonder how much speed up that might see with the minimaloc stuff that's being played with?
<InPhase>
sublim8: 2.4s doesn't make sense for grabbing the vertices on sphere($fn=32, 10). There must be something going wrong in that.
<sublim8>
Right?
<InPhase>
It's what, on the scale of 1000 points?
<sublim8>
teepee ok, that's function pointer type mechanism.
<teepee>
yes similar to that
<InPhase>
The time to render a sphere is much less than that, and the time to do operations on 1000 element lists in OpenSCAD is much much less than that.
<sublim8>
1000 faces, 512 points to be exact.
<sublim8>
1020 faces
<teepee>
now you could implement as calc(algo = "add"); which would only allow the fixed defined calculations
<teepee>
when passing a function, it separates things as calc() does not need to know about what the function does
<teepee>
the only contract is what data is passed in and what comes out
<InPhase>
sublim8: Can you measure with $fn=64?
<sublim8>
the interpreted language does not have raw access to the vertices
<teepee>
no, but render() is c++
<InPhase>
sublim8: If it scales with point count, that will take 2.4*4 seconds to do $fn=64. If there's some algorithmic efficiency problem going on, it might scale larger.
<sublim8>
$fn=64 is 4092 faces, 2048 points. It takes 10.580 sec
<InPhase>
That's very long per point...
<teepee>
maybe some type conversions going on with the vectors
<sublim8>
I will try to see if I can batch allocate the VectorType objects and see what happens.
<teepee>
a pull request could show the code :)
<sublim8>
Object allocation is probably the cause.
<InPhase>
A full 5ms per point, meaning about 17 million cpu clock cycles per point. :)
<InPhase>
That's an eternity.
<sublim8>
true
<sublim8>
But there is no "algorithm" it's just looping through the points and adding them to a VectorType.
<InPhase>
Allocation is on the scale of hundreds of nanoseconds at most.
<sublim8>
The only thing I can do is to batch allocate
<InPhase>
Can you comment out the part that loops and adds them to the VectorType? It will function wrong and return 0 points, but that's okay for this test.
<sublim8>
openscad objects might do more stuff. I'm not sure.
<sublim8>
I have a parameter for render that indicates if I should forego the loop
<InPhase>
Certainly not 17 million stuffs. This has to be an error somewhere.
<sublim8>
It does what you say. with $fn=64 the time is 0.022 sec
<InPhase>
Does it skip any other steps?
<sublim8>
Hmmm
<sublim8>
I know what might be the problem.
<InPhase>
Okay, good. :) I believe your hoensty. But I have trouble believing the numbers.
<InPhase>
s/hoensty/honesty/
<sublim8>
Apart from allocations there might be something else.
<sublim8>
I basically copied some code from the export functions to access the vertices and there might be a call to tesselate the polygons to triangles. If that's the case THAT would be it.
<InPhase>
Ah.
<InPhase>
Especially if you're doing that in a loop.
<sublim8>
It's not as if I have completed the work. I had noticed it and had it on the backlog to remove it.
<InPhase>
Sure.
<sublim8>
There are more things that are not done eg. 2D shapes
<InPhase>
Also, that would explain why you're getting a different facet count than me. I see 962 for sphere($fn=32, 10)
<sublim8>
For sure.
<teepee>
yes, it's probably way too early looking at optimizations
<sublim8>
hehe
<InPhase>
2.4s vs 0.02s is not optimization though. That's error checking. :)
<sublim8>
true that
<sublim8>
I hope tomorrow to have a PR ready.
<InPhase>
Excellent. I'm excited to try it out.
rvt has quit [Quit: rvt]
<sublim8>
Not that I need to make excuses but keep in mind that the first time I laid eyes on openscad source code and CGAL was four days ago.
<Joel>
difference(cube([1.5, 5.5, 96]), cube([1.5, 5.5, 48])); - I would expect the first cube to be half the length, to actually be 48 long, but in this case, I see no cube at all. What stupid thing am I doing?
<Joel>
InPhase trying to make heads or tails of it, because yeah, the above in the correct syntax, still shows no differences
snakedLX has quit [Ping timeout: 244 seconds]
<Joel>
InPhase thanks, that was the cluebat.
<sublim8>
InPhase, that's how I roll :p . Not that I can't be as dumb as a bag of brick (that's a 'b') sometimes. Thanks for saying so.
<sublim8>
Tomorrow you'll have a chance to gaze upon my atrocities, hehe.
<Joel>
if it possible to leave/show joints where objects connect? If I connect two rectangles, to make a longer rectangle, any way to have the lines stay there showing two rectangles butted together?
<sublim8>
Joel. Not sure but, have you tried the "Show edges" button? (It's the last icon on the right under the preview area).
ccox has joined #openscad
<Joel>
sublim8 just tried it, does not show butted shape lines
<sublim8>
As far as preview goes you can color them to distinguish them.
<sublim8>
color("red") cube(...);
<InPhase>
Joel: If they align perfectly and are the same size, the faces will merge on a render. If you offset ever so slightly, then render, then go to View, Wireframe, you'll see the merge points in the wireframe model: cube(5); translate([4.99, 0.001, 0.001]) cube(5);
<InPhase>
Swap 0.001 back to 0, render, wire frame, and the middle dots are gone.
<Joel>
Final last dumb question of the day, is there any button I'm not finding to re-set the view point?
<sublim8>
Magnifying glass icon?
<Joel>
view->view all does it
<Joel>
ah, as does the mangifying glass, thanks sublim8
<InPhase>
A good habit is the double-whammy of the rotate-reset button, then the magnifying glass in a box, in that order.
<InPhase>
Rotate-reset is the circular arrow.
mhroncok has quit [Quit: Leaving.]
<Joel>
oo very handy, thanks InPhase
pah_ is now known as pa
pa has quit [Changing host]
pa has joined #openscad
snakedLX has joined #openscad
snakedGT has joined #openscad
snakedLX has quit [Ping timeout: 260 seconds]
lastrodamo has quit [Quit: Leaving]
dalias has quit [Ping timeout: 252 seconds]
dalias has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]