 | | Parts as volumes (instead of surfaces)
|
|
It has been said that, with ldraw parts, we have the geometry of TLG bricks. This is rather optimistic. Because geometry would be CSG descriptions that allow much more (although slower) than quads and triangles. CSG descriptions allow part collision (...) (23 years ago, 6-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
[ XFUT lugnet.cad.dev ] (...) What's "CSG descriptions"? (...) But they aren't (as you also write). Still, you are probably correct that BFC information in the LDraw parts can be used for collision detection. (...) I think it deserves further (...) (23 years ago, 7-Apr-02, to lugnet.cad.dev.org.ldraw, lugnet.cad.dev)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) Wow, good questions. We know that some collision detection is already practical - Eric Olsen demonstrated that over a year ago. But decomposing LDraw parts into convex objects, that would be a trick. Each external box 5 (or pair of box 5's) (...) (23 years ago, 8-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
If you're interested, take a look at my old Rayshade libraries that made the bricks from scratch using CSG. I'm especially fond of the L3G0 40-tooth technic gear. I've thought it would be nice to have "bounding boxes" for the bricks, for collision (...) (23 years ago, 9-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) Stud4 primitive could be convex-decomposed just as Ring4 primitive is today. More generally, just as any LDraw surface is convex-decomposed with just triangles and quads (3,4 points respectively), I guess any LDraw volume can be (...) (23 years ago, 9-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) I like the idea of CSG. Unfortunately I can not invest time in Rayshade and alternate ray-tracers. I know they can have attractive features but I am more a POV user. I must impose some limit to my (already too high) diversification. Of course, (...) (23 years ago, 9-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) So stud4 would be decomposed into 16 trapezoidal prisms? That sounds like a fair amount of mark up. (...) Nod, true. But I'd rather decompose a 1x1 brick into 6 volumes (4 walls, 1 top and the stud) than 46 (one volume for each surface (...) (23 years ago, 10-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) That was only bounding boxes (minus the studs). The piece in question was matched against all other pieces, any pieces in a line above or below were put into a list. In case one of them intersected the piece in question, a new place would be (...) (23 years ago, 10-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) Well, I can have a twisted mind sometimes. I know these moments when the best idea today, will just be plain stupid tomorrow. Thanks to Eric Olson for more precision: he used bounding boxes, not collisions. Also I still think, whereas higher (...) (23 years ago, 10-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) Maybe I'm missing a technical distinction, but it seems he used bounding boxes *for* collision detection, as opposed to using exact volumes. (...) True. My point was, marking up the LDraw part files for volume decomposition would either: a) Be (...) (23 years ago, 11-Apr-02, to lugnet.cad.dev.org.ldraw)
|
| |
| | Re: Parts as volumes (instead of surfaces)
|
|
(...) "marking up" would be better done by machine algorithm, and would encompass the Connection Point proposal at the same time. It would indeed yield a separate definition of the parts. A lot of high-end CAD programs read polygons (like we have) (...) (23 years ago, 11-Apr-02, to lugnet.cad.dev.org.ldraw)
|
