Subject:
|
Re: Parts as volumes (instead of surfaces)
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Wed, 10 Apr 2002 19:25:01 GMT
|
Viewed:
|
367 times
|
| |
|
|
In lugnet.cad.dev.org.ldraw, Steve Bliss writes:
> 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
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 order convex volumes as cubes much
simplify decomposition, you can not remove tetrahedron for hill cases.
Because it the most atomic volume and can not be built using cubes.
Damien
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
