Subject:
|
Several replies to CLIPPING / WINDING
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 18 Oct 1999 12:51:43 GMT
|
Reply-To:
|
Rui.Martins@link!stopspam!.pt
|
Viewed:
|
407 times
|
| |
|
|
R> If you keep changing states (turning backface culling on/off or
R> changing front faces from CW to CCW) very often, you'll get a *slower*
R> rendering in OpenGL (don't know about D3D). And remember that in a
R> couple of months nVidia's GeForce chip will be out and everybody will
R> be able to have hardware T&L, making rendering much faster if done in
R> the right way.
Well, the ideia is to minimize the state change, but if you have to make
some, that is not so drastic. On some hardware, some state/option
changes, force a flush in the hardware buffers, which breaks up the
pipeline & eventually hurts performance, but this is not the case.
NOTE: in a optimized .DAT file I hope to see only one meta
command: " 0 CLIPPING ON", I will explain later!
One nasty case is to mix 2D & 3D rendering, every time you change from 2D
to 3D rendering, in every hardware available, it forces a flush, and
performance will probably drop significantly.
In our case, changing state of :
- CLIPPING, only assigns to state variable which controls how the
flow of processing occurs, i.e. do clipping processing or don't.
this only tells the driver, to filter or NOT to filter the polygons
which are sent to the hardware. The only change in performance is if
you don't turn on clipping, every polygon will be sent to the hardware,
if you do turn it on, only the possibly visible polygons are sent.
- WINDING, only assigns to state variable which controls which clipping
test is considered non visible, negative or positive face normal
relative to the eye view. Or eventually to swap the order in witch the
vertex are sent to the hardware. There is no drawback here either.
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
R> I put in WINDING UNKNOWN because it explicitly states that the winding
R> is unknown (and probably bad). This way, you can effectively disable
R> clipping for a particular section of (unchecked) code, without having
R> to force clipping back on at the end of the code. This is a good
---------------------------------------------
CLIPPING & WINDING are local to each file, so this has no usefullness.
R> thing, because clipping may have been off before the questionable
R> section.
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
R> Isn't a CLIPPING tag redundant?
R>
R> Programs should always clip when drawing an opaque part, and never clip
R> when
R> drawing a transparent part.
Someone already answered this one, but keep in mind that only 100%
opaque and solid objects can be optimized for clipping. There are some
exceptions, special cases, that I will refer later.
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
R> What I meant to stress was, that you cannot say subfile references are
R> compliant unless the orientations (inside/outside-ness) of the subfiles
R> are known.
That's correct, but I will explain this together with other things later.
bare with me.
R> >Having said that, I do agree that the primitives should get the first
R> >attention, because those files get used more than any others. ;-)
That's wright, the more used a file is, the greater inpact of it's
optimization.
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
R> > Do you know the reason why?
R> > The change-state-calls could cost a little overhead, but don't they
R> > just set some flags?
R> > And these flags would just cause negating an orientation test?
R>
R> I once asked the same question :) Most OpenGL drivers have part of the
R> rendering code create at runtime instead of having if/else statements
R> for all the possible flags. When you change the state, the driver has
R> to rebuild the code again and that takes time, and I guess that it has
R> to finish processing all the triangles sent to it before but I'm not
R> sure.
I think that what you are referring is "display lists", which in fact
are controlled by your program, which you are responsible to optimize.
So this is not very relevant, even because an optimized part will be
loaded an kept in a display list for further reference, an also because
an optimized .DAT file will have an unique meta command "0 CLIPPING ON"
I will explain later!
R> Another problem is that you have to send the elements in a slower way
R> to be able to change the culling parameters. If you don't believe me
Never heard that one! ;)
Could someone enlighten me ?
R> take a look at the optimization section of any OpenGL book, it will say
R> that the first thing you should avoid are state changes and the second
R> thing to do is use vertex arrays.
This depends on what changes you change.
But the use of vertex arrays is the wait to go, because it reduces the
amount of floating point math, because usually an object shares several
vertexs between several polygons.
Ex:
A cube has 8 vertex and 6 faces
if you supply the vertex with faces, you will supply
6 x 4 = 24 vertexs
if you supply the vertex, and then the faces with references to
the vertexS you will supply
8 vertex and 24 references
which will enable the driver to process 8 vertex instead of 24,
all the calculations are made 8 times and then used 24 times.
NOTE: excluding the view & model matrixs
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
R> > If a certified part-file can turn clipping on, then any certified
R> >file can use clipping. Where's the difference between a certified
R> >part, and any other certified file?
R>
R> Parts are objects with obvious orientation. You are not in doubt what
R> is inside/outside of a part!
R> However, consider the 4-4cyli.dat. Even if its orientation was defined
R> and it was certified, you could not use that info for clipping
Not quite! Remember the special cases I refered!
You could, because if you assume that this is a building block used to
make parts, which are solid (i.e. closed) than this can be clipped.
R> if it was not referenced from a certified part, i.e. a part that have
R> gone through considerations whether to use INVERT or not.
Optimizations are local to each specific file (.DAT).
R> Because the orientation of parts is natural and intuitive, certified
R> parts would be the right place for enabling clipping.
Also, NOT only, primitives also.
every .DAT file which has tris or quads is a candidate for CLIPPING.
R> And it would be safe and legal to do so, because rendering programs
R> keep track of transformation-inversions.
R>
R> You can of course enable clipping in your model, but it wouldn't
R> have any effect unless you have tris or quads in your model.
Touche'.
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
R> >>Hm, isn't WINDING a local directive, that shouldn't be passed on?
R> >
R> >Ergg, you're right. That seems to be a shortcoming (for us) of the
R> >CLIPPING/WINDING approach -- there's nothing to clearly indicate that
R> >a file is certified. The presence of a WINDING meta-statement *could*
R> > be taken as a clear indication that the file has been checked (or
R> > not-checked,in the case of 0 WINDING UNKNOWN).
I see no usefulness, for WINDING UNKNOWN, it is either CCW or CW, if
it's NOT one of this than it is incorrect (possibly bow-ties), should be
drawn erroneously so that peoplw would correct them
R> Yes, and since it
R> seems that most people want to split certification in
R> two tasks (winding of tris/quads in current file, and possible
R> inversion of subfiles) we would perhaps even need two certified-tags!
Nope, certification relates only to the fact that you can do clipping or
not, based on winding, and vertex order correctness (not winding).
R> I agree with Gary Williams that the CLIPPING is somewhat redundant.
R> CLIPPING ON/OFF could be accomplished by WINDING CW/UNKNOWN.
R> The CLIPPING is "syntax sugar", not a functional requirement.
That hurts! :( :| :) I'm ok now
No that is not the case, because as I have already said, an optimized
.dat file will have only the meta command "0 CLIPPING ON" [1]
The fact that winding is correct does not necessarily allow you to due
clipping. It's required by clipping, but WINDING (CCW/CW) does not
imply clipping.
<SNIP>
R> I believe the presence of WINDING/CLIPPING makes a part certified.
Assuming [1], if that was a country flag (i.e a flat object, not solid)
then you couldn't do 'clipping', so you would need a meta command to know
if the file as already been checked:
examples:
0 WINDING CHECKED
0 WINDING OK
0 OPTIMIZED
0 CHECKED
or whatever agreed. but something, if you wan't to keep track of all
checked files.
R> If some sections of the part has not been checked yet, it can be
R> indicated by WINDING UNKNOWN or CLIPPING OFF around the sections.
R> /Lars
I 'am for the CLIPPING OFF method, because as explained above, there is
no usefullness for WINDING UNKNOWN.
by around I suppose:
0 CLIPPING OFF
some tris/quads
0 CLIPPING ON
To see all that I refer as "I explain later", see my next Mail.
Rui
---------------------------------------------------------------
| Rui M. S. Martins Software Engineer Rui.Martins@Link.pt |
|---------------------------------------------------------------|
| 351 1 3100063 There is no Place Like $HOME |
---------------------------------------------------------------
|
|
Message has 2 Replies:
 | | Re: Several replies to CLIPPING / WINDING
|
| (...) I understand that you would be allowed to have as many "0 CCW"/"0 CW" lines as you want. This will hurt performance and of course, it would be better if you could use only 1 call per part. (...) You don't need to do that with LDraw files, (...) (25 years ago, 18-Oct-99, to lugnet.cad.dev)
| | | Re: Several replies to CLIPPING / WINDING
|
| Rui Martins wrote in message ... (...) I am trying to find out when to actually start clipping. You say "every .DAT file which has tris or quads is a candidate for CLIPPING", but when can a program use that info? Would you require an unbroken chain (...) (25 years ago, 19-Oct-99, to lugnet.cad.dev)
|
15 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
