Hacker News Reader

Comment by scrumper | Hacker News Reader

This looks pretty great, I'll play with it. Can you explain this from the Readme?

Unfortunately, it's difficult to compute the joint formed at the boundaries of these combined shapes, so sufficient texturing is needed on the original solids for a decent result.

What is hard about computing the joint? Why does texturing help? My question is from a perspective of curious ignorance, not arrogance (i.e. me saying "don't be silly, it's easy.")

View on HN

The texturing just helps your eye "fill in the gaps." As far as difficulty, I just don't know of a general way to do it. The only thing that comes to mind is some sort of iterative approximation or something.

If I understand correctly, we want to compute co-edges here. I believe there are algorithms to do this, I know SketchUp has this feature [1]; also Gmsh [2]; and I remember seeing Blender plugins that do the same thing (can't seem to find them now...) (edit: Actually Blender does this without plugins: "Join" 2 intersecting objects, use the "Intersect" feature, and it will generate and select the exact co-edges.)

[1] https://www.google.com/search?tbm=isch&q=site:http:%2F%2Fper...

[2] https://help.sketchup.com/en/article/3000100 (last figure and text in the section "Subtracting one solid from another")

unless you're dealing with sufficiently large integers computing the intersect between a line and a plane with any robustness is impossible on modern computers with float or double. sometimes when you intersect meshes that have nearly coplanar faces, the intersection might shoot vertices near some infinity because of division inaccuracy.

Yes that makes sense. Thanks.

Sufficiently large integers (and FP numbers too) are directly supported by Go's standard library: https://golang.org/pkg/math/big/

Would symbolic arithmetic help with that? Of is that just too slow a priori?

Reply on news.ycombinator.com