USER FORUM
(you are viewing a thread; or go back to list of threads)
Another geometry library (by Paul)
Not sure of the value, but these links came up after a comment about the lack of good open source lib for trimmed NURBS:
https://github.com/SINTEF-Geometry/GoTools
https://github.com/SINTEF-Geometry/SISL
https://github.com/SINTEF-Geometry/GoTools
https://github.com/SINTEF-Geometry/SISL
(no subject) (by Jonathan Westhues)
SINTEF gets mentioned from time to time. Last I checked, they don't implement Boolean operations on shells bounded by trimmed NURBS surfaces (i.e., the hard thing). I'm not aware of any other free code that does except OpenCASCADE.
(no subject) (by Paul)
@Jonathan
After researching this several times, I'm realizing just how hard it is. None of the existing solutions (commercial included) provide exact representations. How did you come to understand it well enough to write what's in SolveSpace? I would say it's one of the hardest practical problems out there.
After researching this several times, I'm realizing just how hard it is. None of the existing solutions (commercial included) provide exact representations. How did you come to understand it well enough to write what's in SolveSpace? I would say it's one of the hardest practical problems out there.
(no subject) (by Jonathan Westhues)
SolveSpace represents curves and surfaces in a form equivalent to NURBS, by their rational polynomial parametric equations. That can represent a lot of geometry exactly, but not everything (for example, not the general intersection curve of two cylinders). When no exact representation of that form exists, SolveSpace approximates. This is the same approach that commercial libraries (Parasolid, Solids++, etc.) take.
The problem isn't so much hard as messy. There's just a lot of cases, and a lot of work to test that you've covered them all. As far as I know, the highest-quality commercial libraries get their robustness mostly from exhaustive enumeration of special cases, or trying multiple differently-broken algorithms until something works, and less from anything that's mathematically interesting in isolation.
The problem isn't so much hard as messy. There's just a lot of cases, and a lot of work to test that you've covered them all. As far as I know, the highest-quality commercial libraries get their robustness mostly from exhaustive enumeration of special cases, or trying multiple differently-broken algorithms until something works, and less from anything that's mathematically interesting in isolation.
(no subject) (by EvilSpirit(Alexey Egorov))
I was very surprised when I figured out the fact what the current CAD software works with non-exact representations. This is kind of madness keep using this approaches. My dream is to change this in future. I think NURBS was a good idea many years ago, but using the exact representation is the future which must to come.
(no subject) (by Paul)
I guess Jonathans answer makes sense. That's close to how I viewed the problem - too many special cases or complex data structures for the same reason.
I've been contemplating what EvilSpirit said for some time. My old hobby ray tracer handles CSG operations on arbitrary quadrics and a 3 parameter torus (major and 2 minor radii). It uses an exact representation but implicit surfaces have their own issues, like it's harder to generate a tool path or bisect something. How do you make a fillet when the edge is defined as the intersection of 2 implicit surfaces? Cubic splines are awesome, but when you revolve them you get an arbitrary 6th order surface - and there are no closed form solution for solving 6th order equations.
The film industry has just gone with subdivision surfaces, and that seems great for everything. Everything but making perfectly round holes and gears an things that are important in machinery. Any yet CAD software can represent a hole perfectly but not the curve where it intersects the surface it's cut through in all cases.
The problem of representing useful shapes is hard. Or perhaps a better way to describe it would be inelegant.
I've been contemplating what EvilSpirit said for some time. My old hobby ray tracer handles CSG operations on arbitrary quadrics and a 3 parameter torus (major and 2 minor radii). It uses an exact representation but implicit surfaces have their own issues, like it's harder to generate a tool path or bisect something. How do you make a fillet when the edge is defined as the intersection of 2 implicit surfaces? Cubic splines are awesome, but when you revolve them you get an arbitrary 6th order surface - and there are no closed form solution for solving 6th order equations.
The film industry has just gone with subdivision surfaces, and that seems great for everything. Everything but making perfectly round holes and gears an things that are important in machinery. Any yet CAD software can represent a hole perfectly but not the curve where it intersects the surface it's cut through in all cases.
The problem of representing useful shapes is hard. Or perhaps a better way to describe it would be inelegant.
(no subject) (by EvilSpirit(Alexey Egorov))
I am not saying what I know how to done it. I am just thinking about it. I beleive what we can do the exact quadratics, isn't it? Can we just use 5*5 beziers for representing such curves?
(no subject) (by Jonathan Westhues)
https://pdfs.semanticscholar.o...eeb80a9f1e9b8f0e40d2870802.pdf
"A trimming curve is typically a degree-three NURBS curve defined in the parameter domain of a NURBS surface. The image of such a trimming curve on a bicubic patch (i.e., the curve on the bicubic patch in R3 that the trimming curve maps to) is degree ≤ 18 and algebraic genus zero. However, a generic intersection curve of two bicubic surfaces is degree 324 in R3 and algebraic genus 433. Hence, intersection curves can only be approximated by parametric trimming curves."
"A trimming curve is typically a degree-three NURBS curve defined in the parameter domain of a NURBS surface. The image of such a trimming curve on a bicubic patch (i.e., the curve on the bicubic patch in R3 that the trimming curve maps to) is degree ≤ 18 and algebraic genus zero. However, a generic intersection curve of two bicubic surfaces is degree 324 in R3 and algebraic genus 433. Hence, intersection curves can only be approximated by parametric trimming curves."
(no subject) (by EvilSpirit(Alexey Egorov))
Oh, I knew this paper. But... degree 324? seriously... ?
(no subject) (by Jonathan Westhues)
(no subject) (by NIPA)
Here is a paper with a mention of complexity with calculating offsets
http://citeseerx.ist.psu.edu/v...7113&rep=rep1&type=pdf
http://citeseerx.ist.psu.edu/v...7113&rep=rep1&type=pdf
Post a reply to this comment: