arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
snakedLX has joined #openscad
snakedGT has quit [Ping timeout: 260 seconds]
rvt has joined #openscad
ferdna has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 264 seconds]
default__ has quit [Ping timeout: 264 seconds]
default__ has joined #openscad
pah has quit [Ping timeout: 260 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 260 seconds]
pah has joined #openscad
pah_ has joined #openscad
pah has quit [Ping timeout: 264 seconds]
pah has joined #openscad
pah_ has quit [Ping timeout: 264 seconds]
pah has quit [Ping timeout: 265 seconds]
pah_ has joined #openscad
pah_ has quit [Ping timeout: 245 seconds]
pah has joined #openscad
ur5us has joined #openscad
arebil has joined #openscad
default__ is now known as sublim8
ur5us has quit [Ping timeout: 245 seconds]
ur5us has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
ur5us_ has joined #openscad
lastrodamo has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
arebil has joined #openscad
mhroncok has joined #openscad
rvt has quit [Quit: rvt]
rvt has joined #openscad
rvt has quit [Client Quit]
<sublim8>
teepee: So, there's some good news and some bad news.
<sublim8>
I scrapped using the export code for looping through the geometry.
<sublim8>
Now I can get the points really fast (half a sec for the $fn=64 sphere).
<sublim8>
But, there is a catch.
<sublim8>
All meshes generated by primitive modules such as sphere, don't produce geometries with indexed vertices.
<sublim8>
they have
<sublim8>
duplicate vertices
<sublim8>
If i generate the indices myself we are back to being slow.
<sublim8>
Not as slow as before, but slower that 0.5 sec.
<teepee>
I don't know what that means in detail, it would be easier to go in steps via a PR as it would be possible to see what we are talking about
<teepee>
primitives produce the internal polyset data structure which is a bit ugly
<sublim8>
Yes. PolySets are vectors of polygons. Polygons are vectors of vertices.
<sublim8>
There are no indices.
<sublim8>
If we want to have indexed meshes to reduce vertex duplication we need to generate indices.
<InPhase>
sublim8: And what happens if you do: data = render() render() sphere(...);
<teepee>
yeah, when exporting meshes that's generated via a reindexer and IIRC there's even 2 different ones for different exports
<InPhase>
sublim8: As in, actually DO a render step.
<InPhase>
sublim8: Does that not clean it by passing through CGAL?
<sublim8>
Generating indices is slow because you compare every vertex with every other vertex.
<teepee>
I would assume that's producing either a polyset or a NEF
ur5us_ has quit [Ping timeout: 264 seconds]
<teepee>
so it might just pass on single object polysets, but I'm not sure
<sublim8>
You can not have render() render()
<sublim8>
render() as I implement it is a function
<InPhase>
sublim8: Well maybe put in a module layer. data = render() Foo(); module Foo() { render() sphere(...); }
<InPhase>
sublim8: The point being that there are things done during the geometry render.
<sublim8>
InPhase I'll try it and see.
<InPhase>
And maybe those things need to be done either always or conditionally depending on the target.
<sublim8>
What are the benefits of generating index meshes apart from saving some ram? The price we pay time wise is large for that gains.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<sublim8>
InPhase can you be a bit more specific?
<sublim8>
Btw, InPhase, Foo() { render() sphere(...); } would not produce anyting. render produces no visual output. It returns an object that is wasted in the Foo example.
<sublim8>
It goes out of scope.
<InPhase>
Wait, what?
<sublim8>
:S ...?
<InPhase>
You didn't break the regular render() call did you?
pah is now known as pa
<sublim8>
I think I remember you saying you didn't want visual output from render.
<InPhase>
The old render() still needs to produce visual output.
<sublim8>
If we want to keep the old functionality and add a new one that is kindof unrelated, isn't this trying to do too much with one thing?
<InPhase>
Well what you're doing is essentially creating a geometry literal.
<InPhase>
Normally one displays a geometry, but in your case it gets assigned to a variable instead as data that can be manipulated.
<InPhase>
The normal render() is under heavy use to instruct it to pass through CGAL. This introduces some computational overhead at the time of the render() call, but can speed up later things like preview gui navigation or some other aspects.
<teepee>
yep, render() as module, as statement, without the "xx = " assignment, needs to stay exactly as it is
<teepee>
the function version would produce the new logic
<teepee>
a reference could be the JSON import PR
<teepee>
at this point import is just a module, not a fuction
<teepee>
this PR implements import as a function returning a data object
<teepee>
at this point both share essentially no code at all
<InPhase>
I guess we glazed over that in our previous discussions.
default__ has joined #openscad
<default__>
Isn't the old functionality of render a bit unrelated with the new added functionality?
<teepee>
no, as the function likely needs to do most of the mesh generation logic too
<teepee>
maybe as option, but certainly in case the geometry is going to be inspected
<teepee>
now that does not mean it _has_ to use the exact same code, it could also use a couple of more lower level pieces and plug those together if that helps
sublim8 has quit [Ping timeout: 245 seconds]
<teepee>
I suspect the simplest case would be that function render could be a wrapper around module render
<teepee>
so function render = 1. call module render and internally remember geometry 2. extract info from geometry 3. return object data
sublim8 has joined #openscad
The_Jag_ has quit [Read error: Connection reset by peer]
<teepee>
in case you need that later sometime, that link is also in the topic
pah has joined #openscad
pah has quit [Ping timeout: 260 seconds]
<sublim8>
Had to take a lunch break. Back now.
<sublim8>
Well this is going to complicate things a bit, but I'll try to do it.
<sublim8>
Are there any other functions that are modules too?
ochafik has joined #openscad
<sublim8>
I either see a Builtins::init(name, new BuiltinFunction(&function_pointer),...) or a Builtins::init(name, new BuiltinModule(&function_pointer),...)
<sublim8>
never both
<sublim8>
let, echo, etc are specialized.
<sublim8>
I guess I'll have to specialize render too
<teepee>
the openscad2 proposal suggests those to be unified at some point, which is probably a good idea
<teepee>
but right now modules and functions are really 100% distinct even in namespace
<sublim8>
I know. It sounds like a huge change though.
<teepee>
yeah, not sure if that ever happens, we'll see, the general stragegy is very good
<teepee>
unifying behavior and implementing things separate
<teepee>
let the user combine instead of forcing a known list of options
<teepee>
the misinterpretation is that someone is actually writing something like OpenSCAD-2 from scratch
<sublim8>
Wasn't that initially the plan?
<teepee>
no
<sublim8>
Oh. See, I misinterpreted it too.
<teepee>
idea is to move into that direction, keeping backward compatibility as much as possible
<teepee>
and some parts are already implemented, like the function literals
<sublim8>
That's a far more difficult task than going from scratch. But I guess can be done incrementally.
<teepee>
in the end, not really
<teepee>
proof: python3
ochafik has quit [Remote host closed the connection]
<sublim8>
also true
<teepee>
yes, it's complicated, but writing from scratch is too, and after a while even that "new thing" is going to be legacy
ochafik has joined #openscad
arebil has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Ping timeout: 260 seconds]
<sublim8>
To be clear. You are not expecting render to be both a function and a module in the same context, right?
<teepee>
what do you mean by same context?
<teepee>
a = func();
<teepee>
assignment has an expression on the right side which can have functions
<teepee>
mod();
<teepee>
modules are statements on it's own
<sublim8>
right
<sublim8>
so when you see a "render" it's either a function on a module
<sublim8>
not both
<sublim8>
"or a module"
<teepee>
yes, it's one or the other depending on what the parser sees
<sublim8>
good
<teepee>
e.g.:
<teepee>
cube(); // module
<teepee>
a = cube(); // unknown function
<sublim8>
ok
<sublim8>
Ha. My function actually doesn't interfere with the module. Maybe it's because of the different syntax (the '@').
<sublim8>
I changed my function name from raindeer to render
<teepee>
yeah, that's quite possible
<sublim8>
So it works. Let me try now the example InPhase provided.
<teepee>
I believe the person getting something similar as prototype from the ancient thread I posted linked some git repo too, maybe there's some extra hints for the parser too
<sublim8>
Can you get me that repo link?
<teepee>
can't find it and the user seems to have no openscad repo clone :(
<teepee>
I thought I saw it, but looks like they just posted the user code side, no openscad code
<sublim8>
Ok, talk to you later then. btw, the nested example InPhase gave works as expected.
<teepee>
nice!
<sublim8>
But, wait. Should the render function produce visual output?
<sublim8>
the render module does.
<sublim8>
Should the function have aswell?
<sublim8>
InPhase?
<teepee>
no, not possible :)
<teepee>
modules implicitely return geometry
<teepee>
function can't at this point
<sublim8>
Well, I know. But what I don't know your expectations. Maybe you want the impossible :p
ochafik has joined #openscad
<teepee>
sure we do, and we want to be able to return geometry eventually too
<teepee>
but that's a separate topic for the future
<sublim8>
So, that means that for now we are fine. I'll work a bit on returning 2d geometry and fix the grammar.
<sublim8>
Then I'll do a PR.
<teepee>
yes, that would be great. it's sort-of half way of where we would wish to be but so far we did not move forward for years
<teepee>
so if we get this working, I think it's a good direction and should not block any newer more flexible options
<teepee>
meaning: cool stuff :)
<InPhase>
sublim8: Okay. If the nested example works, the point of that test was just to imply that you can make the non-nested version work by doing some of what the nested version does automatically.
<InPhase>
I'm glad that test works, since it shows a clear path to make it work in all cases.
<InPhase>
sublim8: I think for now it's perfectly sufficient to make it simply return the data for function. I don't see value to instantiating the geometry in a function call, and instead, I think that would have weird semantic consequences like making geometries inside of function calls.
<sublim8>
When I said nested I didn't mean the example with Foo only
<sublim8>
data = render() @ render() cube([10,10,10]) {}; // This works too
<sublim8>
(I'll get rid of the '@')
<InPhase>
Ok, good.
<InPhase>
And yeah, we should purge the @, but that's fine if it helps the initial tests.
<InPhase>
teepee will be able to advise on the syntax fixes to purge the @ once the PR goes up.
<InPhase>
So if you can't figure that part out, just post it and then revise.
<sublim8>
Ok. now working a bit on 2d shapes and some fringe 3d cases.
<sublim8>
after that I'll do the PR.
<InPhase>
For now, we can always make the geometry again with polyhedron and polygon. We can think about other syntactic sugar for this later.
ochafik has quit [Remote host closed the connection]
<sublim8>
Btw, as I said before, for now we get duplicated vertices.
ochafik has joined #openscad
<sublim8>
Because recalculating indices takes time.
<InPhase>
Doesn't render() clean those up?
<InPhase>
The module render()
<sublim8>
No
<InPhase>
Hmm.
<sublim8>
And primitives do not produce indices.
<sublim8>
We'll take another look later on
<InPhase>
But primatives passed through module render() result in indices?
<sublim8>
Aparently not.
<InPhase>
s/primatives/primitives/
<sublim8>
I'm looking at the result of the last examples I pasted here
<sublim8>
And I clearly see duplicates.
<InPhase>
Even for cube?
<sublim8>
How do I test for sure that render works as a module?
<sublim8>
I'll have to check the render() render() thing again
<sublim8>
I might have been mistaken when I said it works.
<InPhase>
This takes about 0.02s to preview: union() {sphere($fn=70, 10); translate([5, 0, 0]) sphere($fn=70, 10);}
<InPhase>
Slap render() in front of it, and it takes closer to 5s.
<InPhase>
The render delay grows as $fn goes up.
<InPhase>
Not the cleanest test, but the difference can be made arbitrarily large. :)
<InPhase>
You can test on an unaltered build so you know what those relative times should be for your system.
<Scopeuk>
InPhase I wonder if you could use the non manifold stl issue to confirm it
<Scopeuk>
csg diference previews fine, add render if goes through cgal and faceplants
<InPhase>
Scopeuk: Perhaps, but that's even less of a clean test. :)
<Scopeuk>
its messy but its a pretty observable answer
<Scopeuk>
it does work just tried it with something broken I had lying around
<InPhase>
I just tried it with something that throws a not manifold warning, and it doesn't throw the not manifold warning with render()
<InPhase>
So it's a bit unreliable.
<Scopeuk>
ok
<InPhase>
Possibly things that mis-render work, but we might not process the warnings properly for this step.
<Scopeuk>
yeh I was looking at the window rather than the log
<InPhase>
Oh, even worse. If you flush caches, preview with render() in there, and then render, it never even provides the warning, because it got eaten during the preview and then doesn't display because it's cached.
<InPhase>
That's a bug.
<Scopeuk>
I appologies for acidentally stumbling face first into a new issue
<Scopeuk>
:P
<InPhase>
I think I'll issue post that one for posterity.
ochafik has quit [Remote host closed the connection]
<teepee>
sorry, it's not new
ochafik has joined #openscad
ham5urg has joined #openscad
<sublim8>
Is there a way to invalidate my cache apart from relaunching openscad?
<teepee>
InPhase: there's a ticket from Michael I believe
<teepee>
design -> flush caches
<sublim8>
thx
<ham5urg>
I'm playing around with an experimental future of dotscad: http://paste.debian.net/1216942/ but I get an ERROR: Assertion '(v2 < leng)' failed: "collinear points" in file _convex_hull3.scad, line 103 Any clues what it meant?
<InPhase>
teepee: Oh. Let me see if that's the same. If so I'll close mine.
<Scopeuk>
ham5urg thats an assert in the library where the author wanted to perform and error check, it looks like its checking that the point is inside the expected length of points or similar from the outside
<InPhase>
sublim8: I think our current reasoning process is ahead of any comments in there, so keep on what you're doing. But, that'll be a ticket that can be closed by a successful PR.
<sublim8>
thx
<InPhase>
I still suspect we'll have to lock it down to let(), but I will attempt to abuse it when you get the PR up and see what happens to the edge cases that I think are going to violate scoping rules.
rvt has quit [Quit: rvt]
<sublim8>
yep
<InPhase>
I'm an advocate of imposing additional restrictions if needed to keep the scoping rules clean and pure, so that there are no unexpected surprises. But no more restrictions than are actually necessary to achieve this.
<sublim8>
data = render() @ render() { cube([10,10,10]); };
<sublim8>
But the extra render doesn't have any particular effect
<sublim8>
Not even time-wise. Because function render already uses CGAL to evaluate the geometry.
<InPhase>
sublim8: Did you confirm the time delay happens with that sphere example?
<sublim8>
If I only use module render yes.
<sublim8>
if I use function render it doesn't matter if there is an extra render
<InPhase>
Because it takes the long time either way?
<sublim8>
function render takes as much time as module render.
<sublim8>
yep
<InPhase>
This would be expected I suppose.
<sublim8>
yes.
<sublim8>
Now for the other part. About the indices.
<InPhase>
Exactly how many vertices are you getting out for cube?
<sublim8>
May I be looking for the vertex data on the wrong place?
<InPhase>
I'm still confused about this duplicate vertex thing.
<InPhase>
Surely we could not have been silly enough to put more than 8 vertices for a cube.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<sublim8>
you have 6 quads
<InPhase>
I could imagine someone messing up sphere, but cube is too simple to mess up.
<sublim8>
4*6 = 24 points
<sublim8>
cube() produces quads without indices
<InPhase>
Hmm.
<InPhase>
peepsalot: Do you have input here?
<sublim8>
sphere produces triangles
ochafik has joined #openscad
<sublim8>
but each triangle has it's own version of the shared vertex
<InPhase>
teepee: It looks like those will have different fixes. That's a cache precision issue, while the other one is preview not processing warnings.
pah has joined #openscad
<teepee>
ah, ok
<InPhase>
I'm assuming the warning is still generated internally by CGAL, as it should be the identical input to CGAL when run with the flushed caches at preview.
<InPhase>
Perhaps a more troubling case could be generated with a difference. But I'm more concerned about the missing warnings as they are helpful for the beginners who don't know these design rules. So eating them is setting up beginners for suffering. :)
<InPhase>
We don't get them as reliably as I'd like, but when we can get them, they should be captured and displayed. (And then ALSO preserved in the cache, like the other issue proposed.)
<sublim8>
So, I have render for 2d working like this:
<teepee>
at least in theory, not sure about all the code details
ochafik has joined #openscad
<sublim8>
In 3d you can return everything if points and indices. In there is no possible way to return two separate polygons in a single array. The polygon is defined as an array of points.
<sublim8>
What do you propose?
<sublim8>
if=in
<sublim8>
and In=if (OMG)
<sublim8>
Or, maybe I'm just tired.
<sublim8>
What do you propose I do when there are more than one polygons inside render?
ochafik has quit [Ping timeout: 260 seconds]
<sublim8>
Btw In=In 2d
<InPhase>
sublim8: I think teepee is talking about something else. It sounds like you're returning the paths, which is the natural internal representation of polygons like that.
<dalias>
in theory multiple polygons could be represented as a single array of points by terminating the first polygon with a point equal to the first point :-p
<InPhase>
dalias: Until they have holes.
<dalias>
inphase, that's just a reverse-orientation polygon :-p
<dalias>
the resulting geometry is the union of all forward-orientation polygons minus the union of all the reverse-orientation polygons :-P
<InPhase>
Which I think is the expected input of polygon's paths input, reverse ordering for the holes.
<dalias>
no that's actually not rigth >_<
<sublim8>
dalias, well yes you can have any convention you want and store anything in arrays.
<dalias>
i hate geometry :-p
<sublim8>
InPhase you are right
<sublim8>
The difference is ignored and I get the two squares.
pa has quit [Ping timeout: 260 seconds]
<sublim8>
That's what is provided by evaluating the Geometry object,
<sublim8>
Hmm
<sublim8>
not good
<sublim8>
But even if i could get the result of the difference. What would the output of that look like in vertices?
pah has joined #openscad
<sublim8>
And what good would that do? It wouldn't be possible to use it with polygon.
ochafik has joined #openscad
<sublim8>
btw as long as the topology of the object is preserved after all the operations. It works as expected.
<sublim8>
For example in 3d sphere, cube, cylinder, all have the same topology. A torus has a different topology.
<sublim8>
You cannot morph the one into the other.
<sublim8>
I could try to create a 3d object and return that I guess.
<sublim8>
Is that what we want?
<sublim8>
But that could be done by the user using linear_extrude and then passing it to render()
ochafik_ has joined #openscad
ochafik has quit [Ping timeout: 260 seconds]
ochafik_ has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
<InPhase>
sublim8: That's what you need to be able to reproduce.
ochafik has quit [Remote host closed the connection]
<InPhase>
sublim8: polygon is insensitive to the winding order of the negative pieces. I feel intuitively like maybe they should be backwards, but it doesn't seem to care at the input phase. I don't know if it flips them around internally, or if the libraries we use also don't care about the winding order for 2D.
<sublim8>
Oh, I read that when you have multiple paths, from the second and on are subtracted from the first.
<sublim8>
Hmm.
<sublim8>
I'
ochafik has joined #openscad
<sublim8>
I'll have to see if I can get any tips about the operations.
<sublim8>
In order to differentiate between having a union of two non touching polygons and a difference operation.
<InPhase>
It seems to keep flipping. And it's invalid for those lines to cross, because that causes non-manifold errors if you try to extrude it and merge it with other objects with CGAL.
<sublim8>
So odd indexed paths get subtracted from even indexed ones?
<InPhase>
I don't think it's that either. You can have two non-overlapping holes.
<InPhase>
I think it's shape aware.
<sublim8>
The manual doesn't explain the format well.
<sublim8>
So, if a path is contained within another it gets subtracted
<sublim8>
if that area has not yet been subtracted by an earlier path
<sublim8>
something like that
<InPhase>
Let's go with, if a path is contained within another, it gets the opposite sign.
<sublim8>
like doing boolean operations to the area
<InPhase>
xor explains it.
<sublim8>
right
<InPhase>
But I think it's done with positive negative internally.
<Joel>
Forgive me, I come from sketchup land, I think I'm doing some math wrong between shapes, anything like a ruler in the preview window I can use to verify distances?
<InPhase>
Joel: Is that related to smustard land?
<sublim8>
All the same. I'll just have to find a way to access this information.
<sublim8>
In order to produce correct paths.
<Scopeuk>
Joel the only ui measurement is the axis lines with the ticks at the moment
<InPhase>
Joel: View Orthogonal, View Show Crosshairs, and then hit the perspective buttons to axis-align your view. Then right click and drag around.
<InPhase>
Joel: The crosshair coordinates are displayed at the bottom of the window.
<Joel>
InPhase awesome, thanks
<InPhase>
Joel: And, yeah, that's totally not perfect. :) But it gets you close. Zoom in to improve resolution.
<InPhase>
If you double-click on part of anything that's displayed, it will center you on the coordinate you clicked on. This does not vertex lock, so you have to aim your clicks if you care about the vertices.
<InPhase>
The lack of vertex locks can be both a feature and a nuissance.
<sublim8>
Well, that was easier that I thought...
<sublim8>
I got it working :)
<sublim8>
All your snippets work.
<Joel>
I would honestly understand resistance to anything in the ui, like a measurement being added. Even if there was a measure() some day, that could be handy
<sublim8>
I'll change that "faces" to "paths" for 2d shapes
default__ has joined #openscad
sublim8 has quit [Killed (NickServ (GHOST command used by default__))]
default__ is now known as sublim8
ochafik has quit [Remote host closed the connection]
<InPhase>
sublim8: Excellent. :)
<InPhase>
Joel: I think it's more of a question of how exactly to do it, although there is broad agreement it would be nice.
<InPhase>
Joel: I do a lot of mechanical parts, and checking sizes is pretty important. I struggled a lot with measuring resulting sizes when I was first making my threading library.
<InPhase>
The calculations involved were just too complicated, so I needed to fact-check the outcomes.
<InPhase>
That said, I'm still not sure what sort of interface would have made my own work easier, let alone everyone else's.
<Joel>
InPhase sketchup made it pretty easy for what I did, just drag a tape between two points, with keyboard modifier to lock to an axis, though I'm not dealing with anything complicated
<InPhase>
An axis locking modifier might help.
<Joel>
I honestly would truly enjoy a meausre() too, or even a line() with some sort of dimension argument
<Joel>
would be nice to show dimensions on projects
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<Joel>
I truly love the captured in code nature of this project, my entire career is capturing crap in code people other wise point and click.
<InPhase>
Well sublim8 is working right now on giving us access to the points.
<InPhase>
That will facilitate arbitrary userspace calculations of distances between things.
rvt has joined #openscad
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
<Joel>
yay :)
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
rvt has quit [Quit: rvt]
default__ has joined #openscad
sublim8 has quit [Killed (NickServ (GHOST command used by default__))]
default__ is now known as sublim8
ochafik has quit [Remote host closed the connection]
pah_ has joined #openscad
pah has quit [Ping timeout: 260 seconds]
ochafik has joined #openscad
ochafik has quit [Ping timeout: 258 seconds]
pah_ has quit [Ping timeout: 260 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 245 seconds]
pah has joined #openscad
* sublim8
is furious about new github authentication requirements.
ochafik has joined #openscad
<InPhase>
sublim8: I vaguely remember something I wasn't using changed, but ssh keys are still working just fine.
<sublim8>
InPhase: Setting up ssh right now.
pah_ has joined #openscad
pah has quit [Ping timeout: 260 seconds]
<InPhase>
They're a nice way to work. Your account has a list of all the places you've authorized access, and you can simply delete the ones you want to remove.
<InPhase>
This is really nice when you're reusing a git account for personal and work, and you want to clean up access from all the work computers you no longer have. :)
mhroncok has quit [Quit: Leaving.]
<sublim8>
Well even though I successfully authenticate using ssh -T git@github.com, I still get the "Support for password authentication was removed on August 13, 2021. Please use a personal access token instead." message. This sucks.
Junxter has joined #openscad
<teepee>
yes, they switched off passwords, easiest is to generate a key and use that
<sublim8>
I'm trying to use the ssh key method which they state that will continue to support.
<sublim8>
But no luck.
<teepee>
what key did you generate? todays systems might be picky about what type of key
<teepee>
e.g. elliptic curves or big RSA keys are probably best
<sublim8>
rsa 4096
<teepee>
that should be fine
<teepee>
I think that's what I'm using too on github
<sublim8>
It connects with ssh -T git@github.com just fine
<sublim8>
I just can't push
snakedGT has joined #openscad
<teepee>
oh, then you probably have the https url still in the config file
<Scopeuk>
Why have a bot if you have to link yourself :p
ham5urg has quit [Ping timeout: 260 seconds]
<sublim8>
These CRLF git issues are killing me.
<Scopeuk>
I think there ks a setting for repo line ending but i might be mixing raw git and some of the ui clients
<sublim8>
git config --global core.autocrlf true
<sublim8>
Just did that. hope it works.
pah is now known as pa
rvt has joined #openscad
<Scopeuk>
teepee is it work enabling some of the automation/cimon there?
<Joel>
Without return variables, is there some way I can have multiple modules, 2x6x8, 2x6x12, etc. all take in a parameter of: [0,0,"10"] for example to signal I want it 10' long, and not have to copy the code that checks for a value of 10' and converts it to 120?
<Joel>
I guess just a generic module where I specify what size lumber I want in totality...
<Joel>
And then I can have shortcut functions into that function
<teepee>
Scopeuk: what do you mean?
<Scopeuk>
Thats sublim8 first pr so the ci needs approval to start
<Scopeuk>
Looks like some are going, i'm out of phase. Ignore me
<teepee>
ahh, yes, I think that's github action that need extra approval for the first PR
<Joel>
btw, view -> show edges/thrown together, enable me to see lines on butt joints. That qas a question I had yesterday
<Joel>
Am I limited to the cheat sheet? No other underlying DSL I can rely on? Wondering if I can split/regex, so if passed in 9'10", I want to split on ', strip off the ", and do some math
pah has joined #openscad
pa has quit [Ping timeout: 260 seconds]
<peepsalot>
<InPhase> peepsalot: Do you have input here?
<peepsalot>
in regards to anything particular? sorry I haven't been keeping up with the recent heavy discussion very well
<peepsalot>
for the warning cache issue, I guess we need the Geometry base class to hold optional<Warning/Error> message, or maybe a vector of them.
ur5us_ has quit [Ping timeout: 245 seconds]
<InPhase>
peepsalot: In regards to cube() generating quads without indices, leaving open the question of how to convert that to points and faces.
<InPhase>
peepsalot: TLDR, sublim8 is making a render() function that extracts points and faces, or points and paths, for computational-level use. We think we can design around all the messy scoping issues this time and actually make that work out okay.
<InPhase>
peepsalot: Also, bounding boxes and things like that.
<InPhase>
peepsalot: This is mostly working, but some of the built-in primitives were being cumbersome because they don't come in the right form. I pinged you because you seem to have poked that area more than the rest of us.
<peepsalot>
I guess the main issue is that Polyset is implemented very poorly. 3D geometries are just a list of polygons, and polygons are a list of points, so there's no indexing except temporarily when Reindexer runs
<peepsalot>
i'd like to eventually have it replaced with something using better data connectivity. whether that be OpenMesh or CGAL's SurfaceMesh (still not sure of the differences or pros/cons between those two)
<InPhase>
So for now Reindexer would be the tool to use to build a set of unique indexed vertices?
<InPhase>
Like in GeometryUtils::tessellatePolygon, except that for this purpose we don't need triangles?
rvt has quit [Quit: rvt]
<InPhase>
polyhedron calls do not need to be triangle tessellated at input, right? So we should be able to return the original quads if it's still in quad form by just using Reindexer to grab the indices, and build a list of lists of indexed faces?
<sublim8>
I was already able to index the meshes but it will slow down the acquisition of the data. I'm sure Reindexer will cause the same slowdown.
<InPhase>
sublim8: Reindexer looks very fast to use.
<InPhase>
That's just a hash map.
<sublim8>
You still need to check every vertex against every other vertex.
rvt has joined #openscad
<sublim8>
maybe
<InPhase>
It should be O(1) per vertex, and very fast.
pah has quit [Ping timeout: 260 seconds]
<sublim8>
You might be right.
<InPhase>
I think the problem before was you were doing the full tessellation, but we don't require that.
<sublim8>
No no, I changed that.
<InPhase>
Ok.
pah has joined #openscad
<sublim8>
I was getting the quads, indexed properly by me.
<sublim8>
But admittedly I was using a dumb way (std::find) to check vertices.
<InPhase>
I think the usage is spelled out in polyset-utils tessellate_faces, which has Reindexer<Vector3f> allVertices; and std::vector<std::vector<IndexedFace>> polygons; We'd need for this the same sort of loop, just aiming for nothing but filling those two variables and returning them.
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<InPhase>
Perhaps a new function can be added to polyset-utils to do this.
<InPhase>
I thought that might already exist hiding somewhere, but I guess not.
<InPhase>
Perhaps make the reference-parameter output variables a std::vector<Vector3f> and the std::vector<std::vector<IndexedFace>>, and just use Reindexer to do the fast calculation, then read it out and fill the vector.
<sublim8>
I don't know if you checked out any of my code yet. I was wondering is there a better place to put get_mesh_data() than in func.cc?
<peepsalot>
InPhase: when converting Polysets to Polyhedron or Nef, we have to tesselate faces so that input is guaranteed planar, due to CGAL's exact geometry restrictions
<InPhase>
sublim8: Not yet. I've been at work.
<InPhase>
peepsalot: In this case we're not aiming for internal use, but just returning numerical values that a user can plug into polyhedron.
<InPhase>
peepsalot: I assume polyhedron already calls tessellate, so we don't need to do that twice.
<peepsalot>
InPhase: also, I may be mixing up parts of code in my head. since we seem to have somewhat duplicated functionality of tesselation indexedfaces, Reindexer, and Grid3d all doing some kind of indexing
<peepsalot>
looks like Reindexer is only used during export of a couple 3d types
<InPhase>
Grid3d appears to reimplement Reindexer internally, yes.
<peepsalot>
ideally we should have a type that can be constructed more naturally/directly from polyhedron
<peepsalot>
points, faces
<peepsalot>
polyhedron() module i mean
<InPhase>
That would sure make sense.
<InPhase>
We should probably keep that separate from this particular PR since it's a big enough change as is. But it would make a lot of sense.
<InPhase>
I see room for refactoring clean-up now that you pointed to the right keywords.
<peepsalot>
the other requirement i would like to see is ability to iterated over connected faces/edges/points etc (what I meant when I mentioned data connectivity earlier). AIUI halfedge data structures provide that, and both SurfaceMesh and OpenMesh implement some form of that
<InPhase>
That would require each point to have a list of its faces, as well as each face having a list of its points. But that could be constructed. If it's used enough, the slightly increased construction and RAM cost could pay off.
<peepsalot>
InPhase: i don't think polyhedron itself automatically tessellates, its only forced during conversion to a CGAL geometry type
<InPhase>
peepsalot: But it's guaranteed this happens between user polyhedron and a CGAL call, right?
<peepsalot>
yeah
<InPhase>
Excellent. That's all that's needed to restrict the requirements on sublim8's code to being able to return the quad points as-is.
<InPhase>
That will keep it faster, and the point lists will be more pleasing on the primitives.
<InPhase>
data = render() cube(...); should really be giving back 8 vertices and 6 faces, or else people will be asking about this forever. :)
<InPhase>
sublim8: Is it clear to you how to use the Reindexer for this? peepsalot said enough that I have a picture of it now. I plan on looking over the PR code later this evening. (about 4-8 hours from now.)
<sublim8>
I'll figure it out.
<InPhase>
Ok.
<sublim8>
Also, sorry for some CRLF issues on this first commit. I enabled git auto CRLF handling after that.
<peepsalot>
polyhedron implementation defined in primitives.cc, creates a Polyset. then cgalutils.cc has CGAL_Nef_polyhedron *createNefPolyhedronFromPolySet(const PolySet &ps) which calls tessellateFaces
ochafik has quit [Ping timeout: 245 seconds]
<peepsalot>
there's also cgalutils-polyhedron.cc which converts between Polyset and non-nef Polyhedrons, which I guess doesn't tessellate. I can't remember what we use plain Polyhedron type for, it seems mostly just an intermediate type between Nef and Polyset.
arebil has joined #openscad
<Joel>
Wouldn't it be a bug that echo outputs the double quotes on a string? example: echo("example"), compared to say echo(1);
<Joel>
I wouldn't expect to get the quotes on a string..
<peepsalot>
all these conversions probably would be best to be cleaned up as converting constructors
<peepsalot>
InPhase: so there might still be some weird code path which could go from Polyset to Polyhedron to NefPolyhedron without tesselating faces, I can't immediately tell from looking at it right now
default__ has joined #openscad
sublim8 has quit [Killed (NickServ (GHOST command used by default__))]
<peepsalot>
Joel: echo basically prints the literal value of given to it, so eg. types can be differentiated here: echo(1,"2",3);
<InPhase>
peepsalot: Well there are none that used Reindexer. Some code to do it might be hiding somewhere else, re-rolling its own indexer.
<Joel>
peepsalot makes sense, behaves a lot like data::dumper, pprint, etc.
<InPhase>
peepsalot: Oh, found another place doing the same sort of logic. VBORenderer::create_surface, which has its own unordered_map. I checked for every unordered_map, and that was the only other one that seems to be this type of logic.
snakedGT has quit [Ping timeout: 260 seconds]
<InPhase>
peepsalot: It's slightly different, but appears to be tracking the same sort of thing.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
pah has quit [Ping timeout: 260 seconds]
<peepsalot>
The GL related code is kind of funky because of the way edges are rendered (or more specifically *not* rendered, for edges internal to a quad etc.). vertices can be indexed, but the vertex attributes, which include data about whether an edge is drawn, has to be duplicated for every triangle it is a part of
pah_ has joined #openscad
<peepsalot>
so a cube becomes 12 triangles, with 36 "unique" vertices
<peepsalot>
each vertex tells whether the edge opposite to it should be drawn or not, so that has potential to be different for each face a vertex belongs to
<Joel>
Really struggling to handle converting a string to interger. Notably 5'6" to 66. I've tried a for loop based on a search result, but it doesn't appear that a variable is valid to pass to a for loop. I've tried looping on the entire string, but I can't seem to find any way to append to a list.
<InPhase>
So if one can do that, one can do 5'6" even easier.
<InPhase>
The logic would be like that, but simplified greatly.
<Joel>
Yeah, I see the recursion
<InPhase>
I had to handle positives and negatives in two locations, and many mode locations to get before and after the decimal point, and exponents.
<InPhase>
Your modes there are feet, ', inches, and ", plus additional modes for white space if you want.
<InPhase>
So you just number the modes, increment them when you transition, and parse along until you get to the end.
<InPhase>
The key is to recurse with s the string, i the index being examined, m the mode, and x the value. The other values probably don't apply to you, unless you go wild with fractions.
<peepsalot>
probably simplest to strip whitespace before anything else. stripped = [for(ch = inputstr) if (ch != " ") ch];
<Joel>
I think you want to keep the whitespace, personally. telling 5'11/32" from 5' 1 1/32" and 5' 11/32" get's challenging without it
<Joel>
I'll play with let so I understand how it works, and refer to your shares InPhase. Thanks a ton!
<peepsalot>
ah, yeah if you're supporting fractions like that then whitespace is relevant
<Joel>
got it, so let only updates the variable inside it's scope.
<Joel>
thus the need for recursion, and calling ones self.
<peepsalot>
pre-processing / cleaning input as a general rule usually makes things a lot simpler in my experience. just not applicable in this case.
ur5us_ has joined #openscad
<Joel>
I mean, this would be so much easier if search would return the match, not where it matched :)
<Joel>
or there was a way to return portions of a string
<peepsalot>
see also the substr function in the link InPhase gave
<Joel>
shit. haha.
<Joel>
substr/split/join are all great. haha.
<InPhase>
split might make that much easier for you, yeah.
<InPhase>
I forgot there was a split right there.
<Joel>
Does this kind of stuff ever get built in?
pah_ has quit [Ping timeout: 260 seconds]
<Joel>
or is it based on some underlying library which needs to support it as well?
pah has joined #openscad
<peepsalot>
Joel: we were recently discussing adding a native str_to_number function, but support for fractions would be out of scope for that
snakedGT has joined #openscad
<peepsalot>
the core language doesn't get things added to it very often, we try to keep it the API lean and not too cluttered with seldom-used functions and modules, particularly if those are feasible to implement in userspace
pah has quit [Ping timeout: 260 seconds]
<Joel>
Makes total sense
<Joel>
Would be interesting to have a page dedicated to "community functions"
pah has joined #openscad
<InPhase>
Well, funcutils was our start at that. :)
<peepsalot>
in other news, i'm basically stuck on the mimalloc PR until we can get some mac devs/testers to give stack traces or something
pah has quit [Ping timeout: 260 seconds]
<peepsalot>
also I'm confused about the lgtm and CodeQL handling, I tried to exclude the submodule, but they both still seem to be counting it.
Junxter has quit [Ping timeout: 260 seconds]
<peepsalot>
teepee: any idea what should be done for those?
<Joel>
InPhase yeah I was thinking a link from the cheatsheet, I might have missed that.
pah has joined #openscad
<peepsalot>
there's a curated list of a few common libraries on the site: http://openscad.org/libraries.html we should probably add funcutils there too...
ham5urg has quit [Ping timeout: 260 seconds]
<peepsalot>
the cheatsheet is strictly a reference for builtins though