tag:blogger.com,1999:blog-3993498847203183398.post4963920686740304623..comments2021-02-28T13:17:58.266+00:00Comments on RevK<sup>®</sup>'s ramblings: Polygon library working?RevKhttp://www.blogger.com/profile/12369263214193333422noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3993498847203183398.post-77630956612861600162011-08-04T14:15:09.238+01:002011-08-04T14:15:09.238+01:00It's a lot simpler if you define your shapes i...It's a lot simpler if you define your shapes in terms of the sum of a set of convex primitives. The 'usual' way is to model solids is to perform solid geometry operations on a collection of convex hulls, with subtract operations making splits to produce a (hopefully) minimal set of convex hulls.<br /><br />There is a real industry application for machining machine tools (yes, software for designing and cutting machine tool cutting bits) that uses an approach like this. If you need slices you slice afterwards.<br /><br />Obviously, there are also drawbacks to such an approach, but in terms of difficult edge cases (no pun intended) there are fewer issues. The 2D poly library approach is very old school (and might end up being more efficient for simple shapes) but may not scale well to highly complex systems.<br /><br />As I implied in an earlier comment, if you're going to use float you need to understand intervals and floating point numerical stability issues. I'm not sure how you ended up doing repeated iterative subtractions though... There's obviously a point with floats where largeX +or- smallY == largeX but it's somewhat equivalent to the case in integers - see below.<br /><br />The advantage of integers is that when a number gets too small, it's zero, which is trivial to spot, and suddenly it's all very simple. With floats the value depends on the other being operated on, but on the up side your small values don't become meaningless, they can still be useful when compounded with other small values. I guess it's a no brainer that 64-bit integers contain more data than 32-bit floats. Or were you using wider floats than that? Doubles are definitely doing to be slower than integers unless you leverage the hardware well, but for what you're doing I'd have thought a 32-bit float would be more than adequate - used wisely.<br /><br />If you are careful about tracking what points should be co-located you can ensure that you never create holes or cracks, regardless of whether you use floats or integers. Cracks are something you really need to watch for and ensure that your algorithms cannot produce them because repeated processing can magnify them.<br /><br />I'd still say that if you're serious about performance then letting a graphics chip do floating point calculations is always going to be quickest, but it doesn't sound like you aren't really worried about performance at this stage - just want stuff to work.<br /><br />Solutions to automating the optimal positioning of a solid for 3D printing, and automated construction of support spurs or other rigging is interesting and ambitious. It's similar to design for injection moulding in some respects - the sort of thing that takes years of experience for a human to learn to do well. It will certainly be very cool if you can get some of that working reliably.<br /><br />Take a look at how something like Bullet physics works to optimize 3D collision tests and store 3D collision meshes. There might be some useful ideas in there. I'd say look at Havok, but you might find the source harder to come by.Peter Wakehttps://www.blogger.com/profile/05248033323228538051noreply@blogger.com