Subject:
|
Re: Parts as volumes (instead of surfaces)
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Wed, 10 Apr 2002 16:55:07 GMT
|
Viewed:
|
265 times
|
| |
|
|
In lugnet.cad.dev.org.ldraw, Damien Guichard wrote:
> Stud4 primitive could be convex-decomposed just as Ring4 primitive is today.
So stud4 would be decomposed into 16 trapezoidal prisms? That sounds
like a fair amount of mark up.
> 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 convex-decomposed with just tetrahedrons and pyramids (4,5 points
> respectively). Just as a quad replaces 2 triangles, a pyramid replaces 2
> tetrahedrons. Only the BFC-ed base face (triangle or quad) has to be
> displayed. The vertex is only for volume definition.
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
polygon).
So how can this convex-decomposion be accomplished, except by fairly
extensive information into the part files?
> So a simple cube requires 6 pyramids but is not slower to display (6 quads,
> 3 BFC-ed) than current "box.dat" that already requires 6 quads (also 3
> BFC-ed) without providing any collision capability.
Err, isn't a simple cube already convex? Why decompose it?
> Is this legacy of James Jessiman or just illusion ?
I think the latter. But I'm not really seeing what you mean here.
> Can you give reference to Eric Olsen solution?
Sorry, it was a demonstration he gave some of us awhile ago, of
BrickDraw3D in an early stage of development. He'd move a part around
the screen, and it would jump over other pieces already on the screen.
Going back to your earlier question:
> > Anyway, the remaining problem is that most (if not all, including Brick 2 x
> > 4) ldraw parts are not convex but concave. Is there any simply mean to
> > extend BFC with metacommands that split ldraw parts in convex subpart? Does
> > the topic deserve the effort? Any interest at all? Just an idea to see what
> > reply.
I don't understand how BFC would apply, unless you mean to add an extra
meta-point for every polygon, to convert it to a volume. But it would
be more efficient, in terms of collision-detection, to specify an
entirely separate set of collision-volumes. There would be fewer
volumes, and they could ignore patterns, and etc.
Steve
|
|
Message has 2 Replies:
 | | 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 (...) (22 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 (...) (22 years ago, 10-Apr-02, to lugnet.cad.dev.org.ldraw)
|
Message is in Reply To:
| | 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 (...) (22 years ago, 9-Apr-02, to lugnet.cad.dev.org.ldraw)
|
11 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
