<othx>
J1A84656529 linked to YouTube video "Four Dimensional Maths: Things to See and Hear in the Fourth Dimension - with Matt Parker" => 1 IRC mentions
<J1A84656529>
the 3D klein bottle is a 4D object
qeed_ has joined #openscad
qeed has quit [Ping timeout: 268 seconds]
gunnbr_ has joined #openscad
fling_ has joined #openscad
fling has quit [Remote host closed the connection]
<JordanBrown>
Does anybody happen to know whether STL import internally turns the triangle soup into a {points, faces} list like polyhedron uses?
<JordanBrown>
(Don't do research - I can do that - I just wanted to know whether anybody knew off the top of their head.)
<JordanBrown>
I'm just wondering how hard it would be to do a "must visit each edge once in each direction" test. On polyhedra, it should be pretty easy. I'm wondering how hard it would be on STL import.
<InPhase>
Without checking, I know that the conversions have been made pretty easy anyway.
<InPhase>
Converting back and forth is done all throughout the fast-csg path.
<InPhase>
I tried to reason out the logic behind that test you mentioned, but I couldn't see it.
<InPhase>
Also I think it's probably inadequate even if it holds, as this misses all the self-intersection issues.
<JordanBrown>
Do you mean "what test am I proposing", or "why is it useful"?
<InPhase>
Both.
<JordanBrown>
In a 2-manifold polyhedron with the faces consistently wound, if you walk around each face, you will visit each edge twice, once in each direction.
<JordanBrown>
If you *don't* visit each edge twice, it's not 2-manifold or it's not wound consistently.
<JordanBrown>
If there's an edge that you only visit once, the polyhedron is incomplete, not closed.
<InPhase>
Oh, face walks.
<JordanBrown>
If you visit an edge more than twice, it's not 2-manifold.
<JordanBrown>
If you don't visit in both directions, it's not consistently wound.
<InPhase>
I was trying to imagine a continuous path through the edges, and kept failing. ;)
<JordanBrown>
And yes, it's not a complete test for polyhedron correctness. But it catches a lot - in particular, mis-wound faces - and is fast and easy.
<InPhase>
Then yeah, that catches I suppose everything BUT self-intersection, right?
<JordanBrown>
I should note that I'm not a very strong geometry guy.
<InPhase>
Sometimes you have absurdities like a vertex in the middle of an edge on the other side, but this will catch that as well as it won't have two on the edge.
<JordanBrown>
But yes, it wouldn't catch self-intersections. Nor would it catch degenerate faces.
<InPhase>
Or zero-area faces I suppose.
<JordanBrown>
Wouldn't that be a subset of "degenerate faces"? :-)
<JordanBrown>
Actually, wouldn't that be exactly "degenerate faces"?
<JordanBrown>
And yes, it would catch trying to have two edges on one side but only one edge on the other side.
<JordanBrown>
I tried to do that once. I was a little surprised, but not very, that it didn't work.
<JordanBrown>
I think I was trying to do something akin to what "surface" does, and tried to form the bottom as a single square. Doesn't work so good.
<InPhase>
I found a thesis talking about them, which is typically a good way to get a formal definition of a topic like this: "We say that a polygon is degenerate if it contains a pair of adjacent edges that are collinear. A polyhedron is degenerate if it contains a degenerate face or if it has a pair of adjacent faces that are coplanar."
<InPhase>
Next is to parse it.
<JordanBrown>
OK, that makes sense. It does include some cases that I might not have included.
<InPhase>
Well, we actually want degenerate faces then sometimes.
<JordanBrown>
Frequently.
<InPhase>
But degenerate triangles will be exactly zero width.
<InPhase>
I mean, area.
<JordanBrown>
yes
<InPhase>
So in the stl case, this is true.
<JordanBrown>
They seem detectable.
<JordanBrown>
But can they just be dropped out of the polyhedron?
<JordanBrown>
Hmm. For instance, can a degenerate triangle be used to join three "real" triangles?
<InPhase>
Well, dropping them will turn one triangle into a quad.
<InPhase>
Or you'd have to split it into two triangles.
<JordanBrown>
I don't follow.
<InPhase>
If you have a degenerate triangle that you want to remove, one side is two edges, the other side is connected to one edge. The side that was connected to one edge would have that as one part of a triangle, so when you go to replace that with the two edges it now has 4 edges.
<JordanBrown>
Ah. Yes, that's exactly the case I was thinking of when I asked about using a degenerate triangle to join three triangles.
<InPhase>
But it should be straightforward to split the middle point again.
<JordanBrown>
First you have to recognize the case.
<JordanBrown>
How much trouble do degenerate triangles actually cause us? I don't think I've had any trouble with them, but then again I don't do much with importing STLs.
<InPhase>
I've seen people with the issue.
<InPhase>
CGAL gets mad sometimes.
<teepee>
zero area triangles are a pretty good bet to make cgal barf
<teepee>
the "normal" way to solve that is what meshlab calls "Remove T-Vertices by Edge-Flip"
<teepee>
sadly there's code for fixing meshes but the person doing that prefers to not help openscad just advertising their own stuff on our mailing list
<teepee>
I don't know if the license is selected to not work with openscad intentionally, maybe not, but I have no desire for more discussions
<teepee>
joseph_: oh, I did not notice the github project changes yet. interesting
<teepee>
joseph_: as for the timeline change we just need to discuss the change itself which seems to be possible in 2 week steps - that then would need to be setup by the org admin which is Sean from BRL-CAD
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
fling has quit [Remote host closed the connection]
fling has joined #openscad
<JordanBrown>
What's the easiest way to grab a copy of somebody else's PR sources?
<teepee>
click on the branch and pull that repo probably
<teepee>
or use what github suggests for merging which is creating a local branch based on master and then bull in the other code
fling has quit [Remote host closed the connection]
fling has joined #openscad
<JordanBrown>
I've never used git checkout. Reading.
<teepee>
checkout "-b" is create new branch
<teepee>
sadly they don't suggest those commands if you don't have write access to the repos
<JordanBrown>
One wonders how checkout -b differs from git branch.
<JordanBrown>
(perhaps combined with other steps)
<teepee>
I think it just combines the switch to master in the case above
<teepee>
so it's not just "use the current state"
<JordanBrown>
I like the "clone the repo the PR is based on" answer.
qeed has joined #openscad
qeed_ has quit [Ping timeout: 260 seconds]
<JordanBrown>
I'm wondering how hard it would be to take the render-as-function stuff and turn it into the idea I had that would combine that with object creation syntax.
<JordanBrown>
thus: obj = { a = 4; b = 5 };
<JordanBrown>
or: obj = { cube(10); }
<JordanBrown>
would be the same sort of thing.
<JordanBrown>
{ ... } in an expression would have all of the same capabilities as regular syntax, and would return both the list of values defined and the geometry defined.
<JordanBrown>
Probably returning the geometry as a CSG tree, and then having render(CSG_tree_object) return some kind of rendered output.
<JordanBrown>
Foo. That repo doesn't build for me. (And it looks like maybe it doesn't build for the CI stuff either.)
<teepee>
that is mostly the object idea, it's just not fully clear how to handle some details
<JordanBrown>
I like the idea of combining the "dictionary" aspect of objects and the "geometry" aspect, primarily because it could use a unified syntax that matches "ordinary" syntax.
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<JordanBrown>
Syntactically, I think it would be simple. One of the cases for "primary" would be '{' inner_input '}'.
<InPhase>
JordanBrown: This is the git_pull_request script I use like "git_pull_request 4333". It's a weird structure maybe, but it wiggles around most of the edge cases I kept stumbling into. https://bpa.st/2J3A
<JordanBrown>
You might consider the "-e" option.
<InPhase>
For which part?
<JordanBrown>
sh -e
<JordanBrown>
script fails if any command fails
<JordanBrown>
avoids the need for the && chain
<JordanBrown>
I keep considering having all of my scripts use -e, to avoid cases where something in the middle unexpectedly fails and the rest try to operate on bad data.
<InPhase>
I'm usually nuanced about the continuations. It just happens to all fit into a chain on that one.
<JordanBrown>
sure
<InPhase>
Especially with temp file cleanup.
<JordanBrown>
Hmm. I haven't tried doing very much in -e mode, so have little practical experience with it. It seems like trap 'cleanup stuff' 0 would be the answer.
<JordanBrown>
Or just accept that since mid-script failures are bugs, cleanup won't be tidy. Sometimes, in fact, you don't want cleanup to be tidy when you run into a bug, because you don't want forensic evidence deleted.
<JordanBrown>
I now understand why I have never used git checkout... I started using git after git switch and git restore were added, and for whatever reason learned them instead.
<JordanBrown>
Now all I have to do is to internalize the relationship between "git pull" and "git fetch"...
jimusmallard has joined #openscad
<InPhase>
pull is fetch and merge
<JordanBrown>
yeah, I just read that and I've probably read it six times before. Like I said, I need to internalize it.
<JordanBrown>
I need to remember it.
<JordanBrown>
it doesn't help that I have used git a couple of times a month for the last two years, and Mercurial almost daily for the last >10 years. They are very strongly similar, but have key differences.
<InPhase>
I find git a chaotic mess. I make myself scripts and rituals like that so I can stop thinking about the chaos.
<JordanBrown>
yes, I've gotten some of that impression.
<JordanBrown>
I have to mentally map that "hg histedit" is approximately the same as "git rebase -i upstream/master". Or something like that.
<InPhase>
I never actually tried mercurial. In your opinion is it something we should all be using instead of git?
<JordanBrown>
and I do not yet fully understand what "staged" and "the index" mean.
<JordanBrown>
WRT Mercurial vs git... not sure. Mercurial is definitely simpler, but I suspect that's tied to having less functionality.
<JordanBrown>
Critically, git has the market share. The existence of github is a compelling reason for using it.
<InPhase>
Yes, github is definitely the driver of git usage.
<JordanBrown>
If there was an equally-popular hghub... don't know.
<InPhase>
And I use it primarily because of the clear market share presence.
<JordanBrown>
Yep.
<InPhase>
But I also consider it a chronic powder-keg risk in team environments.
<InPhase>
Oh, and this one was wonderful. On a work project, I got a bunch of commits from someone who didn't work for us anymore, and didn't have access to the repository. I thought this was ridiculous, and it took me a long time to track down what happened. It turned out one person who DID have access used a different work laptop, which had ~/.gitconfig setup with the former worker's name and address. But
<InPhase>
the person who actually made the commits had access. It's just that git doesn't care about any of this, so it marked the commits as from this other person, and github went and slapped them on that former worker's user page as new commits they made to a project they never had access to and never touched. All because an email was set wrong in a config file.
<InPhase>
What does traceability even mean when crap like that happens by accident?
<JordanBrown>
I use Mercurial in a large environment - hundreds of engineers, tens of thousands of files, millions of lines of source. But it's also a highly structured environment with restricted access to the primary repo, and gatekeepers who are not shy about backing things out if they are malformed.
<Scopeuk>
Git has no per,issions system
<Scopeuk>
That all has to be bolted on top with how you manage access
<InPhase>
Scopeuk: Yeah, and then they're not even connected up. And it's not even possible to connect them up because of fundamentals of git design.
<Scopeuk>
Subversion is old school and has its own issues but that is an area it excells
<InPhase>
So we're left with "version control" with no idea who really did what.
<Scopeuk>
You could put in a precommit hook for does machine user match repo user and throw a warning I guess
<Scopeuk>
Easy to overide though
<InPhase>
Scopeuk: And fails when a branch contains elements from more than one author generated before the push.
<InPhase>
Scopeuk: Like you could never fork and push it as a new commit then.
<InPhase>
I mean, as a new repository.
<Scopeuk>
I guess the reason there are so many systems like github etc which bolts on top and enforces a bunch of stuff like this for you
<InPhase>
But it doesn't, and can't. :)
<Scopeuk>
I guess git is version control not config control or change control
<Scopeuk>
InPhase yes and no, it can't stop you using git to bypass what it's doing but tying repos to user accounts improves some of it
<Scopeuk>
I guess only for merge and not commit
<InPhase>
Well if you push a merge instead of through the interface, not even for those.
<InPhase>
All it really restricts is essentially "only these people can edit the repository".
<Scopeuk>
Yeh, it can only protect you until you bypass it
<Scopeuk>
That's the only hard limit
<Scopeuk>
This is one of the things I'm not keen on with git
<InPhase>
Which basically means it does its one job of putting some control on versions in collaborative development pretty poorly.
<Scopeuk>
Version control is "never forget" the meta data around that, traceability as you nicely put it earlier is really moving into change control and config control which git doesn't do
<Scopeuk>
Who changed what and why all has to be external, which sucks a bit
<Scopeuk>
I've worked with systems at the other extreme where I can't even lock a file for changes untill I have a wall of supporting docs, evidence and approvals in place
<InPhase>
Hence I mostly consider git a fragile code sharing tool with some history, requiring a lot of trust and team discipline, and requiring a whole separate system for backups.
<Scopeuk>
There is definitely. A happy medium a dn I agree completely ensure that the change was made by the right author is up there
<Scopeuk>
InPhase agreed
<InPhase>
And I think I understand how this happened. Linus's design goal was "I don't want to mess up the code history on my own computer when I get patches", and thus it was based around the premise that one person has access to his computer, and that his computer would contain the most important copy of the repository.
<InPhase>
So collaborative development with a central figure. :)
<InPhase>
Thus all the trust was assigned manually, and it was never designed for servers.
Guest40 has joined #openscad
<Guest40>
I downloaded the Windows x64- bit but have not installed because the file hashes don't match what is posted on the website.
<teepee>
which specific version? release or snapshot?
<Guest40>
2021.01
<Guest40>
32-bit version hashes match but the 64-bit do not
<teepee>
looks ok to me, what's not matching?
<teepee>
both 256 and 512 seem to match with the files I just downloaded
jimusmallard has quit [Remote host closed the connection]
<peeps>
there are a many other validation/repair functions, but I think those I linked are some of the more general, straightforward ones
<peeps>
Also many of the CGAL operations list preconditions, so if one in particular is failing you can check its preconditions which should be more-or-less a list of functions you can call on that geometry to validate it
<joseph_>
teepee: In order to figure out how long my coding period should be extended, it would be good to confirm which issues should be addressed by the end of GSoC and which ones will be worked on afterwards. My proposal scope was only on the F6 render, so things like pink back faces should be left for later
<teepee>
joseph_: and it makes sense to not change scope much, the idea of the timeline changes would be just for cover things happening alongside
<teepee>
I'm seeing 3 main areas 1) get things stable / find and fix bugs 2) maybe make the user workflow a bit easier 3) find a solution for the test case runs
<teepee>
but you can propose what to look at and in what order so it works best for you
<JordanBrown>
peeps I was thinking more of polyhedron(), and import() was an afterthought. But you're right, using CGAL functions would be better, as long as they are cheap.
<InPhase>
Presumably also CGAL will reliably know its own expectations, even if they change.
<JordanBrown>
But right now I think I will try to look at object-creation syntax, because I sort of started that project with textmetrics() and should try to contribute to finishing it.
<teepee>
it's not so much the syntax, it's the behavior that is not clearly defined
<JordanBrown>
Which aspects?
<teepee>
when is the geometry generated, based on that... is it possible to introspect the geometry, is there a way to customize values (neatly solving issues with include<>/use<>)