 | | | | | | |
| |
|
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 |
---------------------------------------------------------------
| | | | | | | | | | | | | | | | |
| |
|
Rui Martins wrote:
>
> 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.
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.
> 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.
You don't need to do that with LDraw files, except for writing any
text on the screen. :)
> 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 wasn't talking about display lists, and I don't think that the
discussion is going to lead to a single "0 CLIPPING ON" meta command.
The OpenGL drivers are not forced to do any optimizations in the display
lists, if they want they can just copy the same commands when you call
the list.
> 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 ?
I meant that you would have to use a glEnd(), call glFrontFace() and
then glBegin() again, which is much slower than having everything drawn
with a single call to glDrawElements().
> 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.
Not exactly, you have to lock the arrays to have the vertexes
transformed only once and you can't change any states (not even the
colors) while you have the arrays locked. Or if you are using a display
list and if who wrote the driver was smart enough then the vertexes will
be transformed once (but you can't assume that).
To use a vertex array you also need to have all vertexes indexed,
which is not the case of the DAT files and one of the reasons why I have
my own file format.
Leonardo
| | | | | | | | | | | | | | | | | | | | | |
| |
|
On Mon, 18 Oct 1999, Leonardo Zide wrote:
> Rui Martins wrote:
> >
> > 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.
>
> 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.
In fact you can, use as many as you like, but that it's not the goal.
if you read my previous mail, following this one I'am replying, you got
the ideia that no WINDING meta command is the ideia, if the .DAT is well
optimized.
If someone want's to, he can make a very heavy .DAT file, by doing
to many state changes, or even do state changes with no usefullness,
just to bog down the drawer program, we can' fight a bad behaved
builder. But in the other way, no one would see is files, no one likes
to wait too much.
>
> > 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.
>
> You don't need to do that with LDraw files, except for writing any
> text on the screen. :)
I new that, just giving a tip! ;)
> > 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 wasn't talking about display lists, and I don't think that the
> discussion is going to lead to a single "0 CLIPPING ON" meta command.
See my previous mail!
> The OpenGL drivers are not forced to do any optimizations in the display
> lists, if they want they can just copy the same commands when you call
> the list.
yes they are not forced to, but if they want to compete in the marked,
they have to strive for every bit of performance that they can squeeze
of their specific hardware.
So, we should always hope for the best, not the worst. because the worst
case has no solution on our side.
> > 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 ?
>
> I meant that you would have to use a glEnd(), call glFrontFace() and
> then glBegin() again, which is much slower than having everything drawn
> with a single call to glDrawElements().
Thank you, for reminding me that!
but I think that you are assuming that only tris or only quads, not
both, which is not the case. Because if you have both, then you would be
forced to do a glBegin/glEnd pair anyway, (but the glFrontFace could not
be needed if you didn't change the state)
---------------------------------------------------------------------
NOTE: this reminds me:
you should always pair the tris and the quads together so that
the glBegin/glEnd pairs are minimized.
---------------------------------------------------------------------
> > 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.
>
> Not exactly, you have to lock the arrays to have the vertexes
> transformed only once and you can't change any states (not even the
> colors) while you have the arrays locked. Or if you are using a display
> list and if who wrote the driver was smart enough then the vertexes will
> be transformed once (but you can't assume that).
Let's hope for the best!
> To use a vertex array you also need to have all vertexes indexed,
> which is not the case of the DAT files and one of the reasons why I have
> my own file format.
To Drawer program, can do this job of indexing.
But I know that it is difficult, when some programs put 2,0001 or
1,99998 instead of 2, for example, this could be a goal for improvement
in ldraw compatible editors.
( VI/NOTEPAD are the best for the JOB! 8)
-------------
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Rui Martins wrote in message ...
> On Mon, 18 Oct 1999, Leonardo Zide wrote:
>
> > Rui Martins wrote:
> > >
> > > 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.
> >
> > 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.
>
> In fact you can, use as many as you like, but that it's not the goal.
> if you read my previous mail, following this one I'am replying, you got
> the ideia that no WINDING meta command is the ideia, if the .DAT is well
> optimized.
>
> If someone want's to, he can make a very heavy .DAT file, by doing
> to many state changes, or even do state changes with no usefullness,
> just to bog down the drawer program, we can' fight a bad behaved
> builder. But in the other way, no one would see is files, no one likes
> to wait too much.
Wait a minute, you were not going to actually send winding state changes
to the graphics engine?
Simply keep track of the state yourself and send either vertices 1,2,3
or 3,2,1.
The part author can use as many WINDING CW/CCW as he likes
- it won't hurt performance a bit!
> > To use a vertex array you also need to have all vertexes indexed,
> > which is not the case of the DAT files and one of the reasons why I have
> > my own file format.
>
> To Drawer program, can do this job of indexing.
> But I know that it is difficult, when some programs put 2,0001 or
> 1,99998 instead of 2, for example, this could be a goal for improvement
> in ldraw compatible editors.
I have already done that. After reading a part into memory I index it.
It typically reduces the number of vertices and thus transformations
to 20-50%. However, as the math currently takes less than 10% of the
rendering time in L3, the total saving is only 2-5%
I don't think it is that difficult: a part may use 2.0001 or 1.99998 in
stead of 2, but not for the same vertex. If it did there would be gaps,
which of course should be fixed.
/Lars
> ( VI/NOTEPAD are the best for the JOB! 8)
vi rules! :)
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
"Lars C. Hassing" wrote:
>
> Wait a minute, you were not going to actually send winding state changes
> to the graphics engine?
> Simply keep track of the state yourself and send either vertices 1,2,3
> or 3,2,1.
> The part author can use as many WINDING CW/CCW as he likes
> - it won't hurt performance a bit!
Sure, that can be done but there's the "0 UNKNOWN" or "0 DOUBLE-SIDED"
case, and you'd have to send the triangles twice if you don't want to
change the state.
Leonardo
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Tue, 19 Oct 1999, Leonardo Zide wrote:
> "Lars C. Hassing" wrote:
> >
> > Wait a minute, you were not going to actually send winding state changes
> > to the graphics engine?
> > Simply keep track of the state yourself and send either vertices 1,2,3
> > or 3,2,1.
> > The part author can use as many WINDING CW/CCW as he likes
> > - it won't hurt performance a bit!
>
> Sure, that can be done but there's the "0 UNKNOWN" or "0 DOUBLE-SIDED"
> case, and you'd have to send the triangles twice if you don't want to
> change the state.
>
> Leonardo
That can be done, but you will probably suffer a performance hit,
because, most hardware, just use a bit, to keep track of the state.
Just minimize the use of the
0 CCW and 0 CW meta-commands, to boost performance.
When optimizing existent or new files, try do define all the polygons,
using the same winding (that's not hard to do), and if you think that
takes a lot of time, after creating the .DAT file, jut run one of those
utilities, that correct the file for you, preferably makeing then all
the default (CCW).
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Tue, 19 Oct 1999, Lars C. Hassing wrote:
> <SNIP>
> Wait a minute, you were not going to actually send winding state changes
> to the graphics engine?
> Simply keep track of the state yourself and send either vertices 1,2,3
> or 3,2,1.
NO,
I said that, to be used when optimizing the existent files, not when
rendering the optimized files.
> The part author can use as many WINDING CW/CCW as he likes
> - it won't hurt performance a bit!
I never said that !
> I have already done that. After reading a part into memory I index it.
> It typically reduces the number of vertices and thus transformations
> to 20-50%. However, as the math currently takes less than 10% of the
> rendering time in L3, the total saving is only 2-5%
I think that depends on the host processor that you have and your
specific graphics board (2D/3D) ;)
> I don't think it is that difficult: a part may use 2.0001 or 1.99998 in
> stead of 2, but not for the same vertex. If it did there would be gaps,
> which of course should be fixed.
> /Lars
I have seen some parts, with this tipical error.
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Rui Martins wrote:
>
> > I wasn't talking about display lists, and I don't think that the
> > discussion is going to lead to a single "0 CLIPPING ON" meta command.
>
> See my previous mail!
We both want the same thing, now we need to make everybody agree with
us :)
> ---------------------------------------------------------------------
> NOTE: this reminds me:
> you should always pair the tris and the quads together so that
> the glBegin/glEnd pairs are minimized.
> ---------------------------------------------------------------------
I sort first by color and then by line type. I have everything
pre-processed and I don't use glBegin()/glEnd() to render.
> > Not exactly, you have to lock the arrays to have the vertexes
> > transformed only once and you can't change any states (not even the
> > colors) while you have the arrays locked. Or if you are using a display
> > list and if who wrote the driver was smart enough then the vertexes will
> > be transformed once (but you can't assume that).
>
> Let's hope for the best!
From my personal experience, there's still a lot of people using the
old MS software renderer, it was written in 95 and never updated. Don't
expect much from that. :)
Leonardo
| | | | | | | | | | | | | | | | | | | | | | |
On Tue, 19 Oct 1999, Leonardo Zide wrote:
> Rui Martins wrote:
> >
> > > I wasn't talking about display lists, and I don't think that the
> > > discussion is going to lead to a single "0 CLIPPING ON" meta command.
> >
> > See my previous mail!
>
> We both want the same thing, now we need to make everybody agree with
> us :)
Great !
> <SNIP>
> From my personal experience, there's still a lot of people using the
> old MS software renderer, it was written in 95 and never updated. Don't
> expect much from that. :)
>
> Leonardo
Don't be pessimistic !
As soon as people see that their models render twice as fast, they will
start using the new features.
And a utility to make the optimization job easier would make a big
difference, to all the lazy people ;)
Don't worry I'm lazy too sometimes! 8)
Rui Martins
| | | | | | | | | | | | | | | | | | |
| |
|
Rui Martins wrote in message ...
> 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'.
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 of certified DAT files?
> 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.
No, but what is the sense in making winding correct and turn off clipping?
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
On Tue, 19 Oct 1999, Lars C. Hassing wrote:
> <SNIP>
>
> 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?
By candidate, I meant, someone could optiomize it, a place a
0 CLIPPING ON meta-command on it, and get some benefit.
If you use enable clipping, but you have no graphic primitives in your
file (assuming clipping is stryctly local), than you wouldn't gain
anything from this act.
> Would you require an unbroken chain of certified DAT files?
NO,
Every file is a closed unit, anynone can be certified or not, and you
can mix them (in a chain), that each one will be drawn/optimized for
itself, no dependent on previous files (in the chain).
The goal is, if this particular file is optimized, then everyone that
uses it will benefit, no matter if the one who uses it, is itself
optimized or not.
> <SNIP>
> > 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.
>
> No, but what is the sense in making winding correct and turn off clipping?
> /Lars
Prevent that some graphic librarys to DRAW erroneously, or not draw at
all, and also,
because with a correct winding, you know, (or can determine) the
orientation of the polygon (face)
Rui Martins
| | | | | | | | | | | | | | | | |
On Wed, 20 Oct 1999 10:36:25 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> On Tue, 19 Oct 1999, Lars C. Hassing wrote:
>
> > Would you require an unbroken chain of certified DAT files?
>
> NO,
> Every file is a closed unit, anynone can be certified or not, and you
> can mix them (in a chain), that each one will be drawn/optimized for
> itself, no dependent on previous files (in the chain).
That's not true. If a super-file is not certified, then there's no way to
tell if the subfile is normal or inverted. So when a file is referenced by
a non-certified super-file, it can't be clipped, even if the referenced
file is certified.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
On Wed, 20 Oct 1999, Steve Bliss wrote:
> > > Would you require an unbroken chain of certified DAT files?
> >
> > NO,
> > Every file is a closed unit, anynone can be certified or not, and you
> > can mix them (in a chain), that each one will be drawn/optimized for
> > itself, no dependent on previous files (in the chain).
>
> That's not true. If a super-file is not certified, then there's no way to
> tell if the subfile is normal or inverted.
This is a problem of the current design (the one beeing used now).
You didn't knew in the past, because you didn't have the 0 INVERT
meta-command. So you can only assume it' NOT inverted.
If for some reason, it is inverted, then the old .DAT file was wrong,
and should be corrected.
The NEW design, appeared, to speed things up, and also to solve some
problems, like this one.
You can't expect the new renders to be retro-compatible, but when in
retrocompatible mode, to provide the same NEW functionalities that they
were built for, as in the new design mode.
> So when a file is referenced by
> a non-certified super-file, it can't be clipped, even if the referenced
> file is certified.
>
> Steve
I would say, that an old file, should not use references with inverted
matrixes, or you won't be able to have a retrocompatible format.
but if you really, really, want this, you can inforce this on the
renderer:
/* for a specific reference in this file do */
if ((this file is NOT optimized) and
(this file has reference, with an inverted, matrix to another file))
{
ClIPPING commands should be ignored in all files referenced down
through this tree branch.
}
Now this is getting really backwards compatible. 8)
That one, was a tuff one!
Rui Martins
| | | | | | | | | | | | | | | | | |
| |
|
On Wed, 20 Oct 1999 15:05:37 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> You didn't knew in the past, because you didn't have the 0 INVERT
> meta-command. So you can only assume it' NOT inverted.
No. With current files, you don't know, so you can't assume anything.
> If for some reason, it is inverted, then the old .DAT file was wrong,
> and should be corrected.
No, inversions are common.
> You can't expect the new renders to be retro-compatible, but when in
> retrocompatible mode, to provide the same NEW functionalities that they
> were built for, as in the new design mode.
Right. So non-wound-up files can't be backface culled. I don't see what
you're getting at here.
> I would say, that an old file, should not use references with inverted
> matrixes, or you won't be able to have a retrocompatible format.
But we don't get to specify what the old files are allowed to look like.
We only get to deal with them as they are. :(
> but if you really, really, want this, you can inforce this on the
> renderer:
>
> /* for a specific reference in this file do */
> if ((this file is NOT optimized) and
> (this file has reference, with an inverted, matrix to another file))
> {
> ClIPPING commands should be ignored in all files referenced down
> through this tree branch.
> }
Nope. Whether the subfile's matrix is inverted or not, you can't assume
the intention was to invert the subfile. Or not.
> Now this is getting really backwards compatible. 8)
Yep. That's the most important requirement.
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | |
| |
|
On Wed, 20 Oct 1999, Steve Bliss wrote:
> On Wed, 20 Oct 1999 15:05:37 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
>
> > You didn't knew in the past, because you didn't have the 0 INVERT
> > meta-command. So you can only assume it' NOT inverted.
>
> No. With current files, you don't know, so you can't assume anything.
Sorry, you are right here. I allways think in some form of winding (CW
or CCW) so this one slipped me, once again sorry, you are right.
Can't assume nothing.
> > If for some reason, it is inverted, then the old .DAT file was wrong,
> > and should be corrected.
>
> No, inversions are common.
what I said was relative to my way of thinking, without the previous
sentence, doesn't old up.
Man, that was a lousy afternoon ! 8b
> > You can't expect the new renders to be retro-compatible, but when in
> > retrocompatible mode, to provide the same NEW functionalities that they
> > were built for, as in the new design mode.
>
> Right. So non-wound-up files can't be backface culled. I don't see what
> you're getting at here.
>
> > I would say, that an old file, should not use references with inverted
> > matrixes, or you won't be able to have a retrocompatible format.
>
> But we don't get to specify what the old files are allowed to look like.
> We only get to deal with them as they are. :(
>
> > but if you really, really, want this, you can inforce this on the
> > renderer:
> >
> > /* for a specific reference in this file do */
> > if ((this file is NOT optimized) and
> > (this file has reference, with an inverted, matrix to another file))
> > {
> > ClIPPING commands should be ignored in all files referenced down
> > through this tree branch.
> > }
>
> Nope. Whether the subfile's matrix is inverted or not, you can't assume
> the intention was to invert the subfile. Or not.
>
> > Now this is getting really backwards compatible. 8)
>
> Yep. That's the most important requirement.
Agreed.
Rui Martins
| | | | | | |
