Subject:
|
Re: Voting Open for LCAD Parts Update 2000-01
|
Newsgroups:
|
lugnet.cad.dev, lugnet.cad.dev.org.ldraw
|
Date:
|
Thu, 13 Apr 2000 16:46:11 GMT
|
Reply-To:
|
rui.martins@link.STOPSPAMMERSpt
|
Viewed:
|
31 times
|
| |
|
|
First I would like to point out, that some of the renderings I supplied
specifically represent quads in GREY and tris in WHITE, and some have all the
polys edge lines (the intrinsic edges) drawn, to be able to see the tesselation
applyed.
On Wed, 12 Apr 2000, John VanZwieten wrote:
> > > The voting page can be found at:
> > > <http://www.ldraw.org/download/updates/voting/datvote.html>
> >
> > I have been able to test only a few parts iet, but here are my findings:
> >
> > - [flowers.dat]
> > [...SNIP...]
> > http://is-sv.link.pt/~rmsm/lego/vote2000/flowers.png
>
> Superimposed polys are allowed, AFAIK. Maybe not the most elegant solution,
> but they render fine.
Yes, they have been allowed until now, because as you say, parts with
superimposed polys render fine, as long as both parts have the same color, which
is generally the case.
I'm against superimposed polys, and I would like to propose to discourage their
use, because there are some major drawbacks:
-First it's NOT considered good modeling practive (NOT used in B-reps).
-Second, this type of superposition generates overdraw, which is what we are
trying to avoid with the BFC spec, because it slows down the renderer.
-third, because the polys are superimposed on each other, this usually means
that there will be some more points (geometry) to be processed, which also slows
down the renderers.
- last it's NOT difficult to avoid in most of the parts we have.
Also in a small part (like the petal) which may be denselly used, and because
they also require a lot of polygons to be defined, due to their round form, this
part in particular should NOT use superposition of polys.
(Imagine studs which had overdraw)
(If possible we should correct the parts wich have this problem, but this is
probably a huge task)
> > [...SNIP...]
>
> I've never heard a complaint about "too small tris." Is this problem unique
> to your renderer? It doesn't seem to be a problem with L3Lab.
It has nothing to to with my renderer, it displays the fine (tris where drawn
white).
This is just a rule of tumb to follow, due to error round off which happens in
every discrete implementation (arithemetic precision, pixels, etc)
If we have the area of the polys similar to the average area, than this problems
will surelly be minor, also in average it will balance the effort spent by the
renderer to draw each poly.
In the petal case it may even reduce the poly count, since it can be tesselated
in a radial configuration, reusing some points (remember my sugestion for the
4-4disk.dat primitive ?).
I think some guidelines for correct modelling should be made, and I will help to
do this if needed, or maybe I can even do it and then show it to the ldraw
comunity for comments/addition/deletions.
P.S.
It's a lot more difficult to correct already made parts, especially if you are
NOT the author, so we should strive to make them correct, in every sence
possible, at first try, mainly because the author is available, and because it's
easyer than later trying to correct them, when the need arises.
See ya
Rui Martins
|
|
Message has 1 Reply:
Message is in Reply To:
73 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
|
|
|
|
