To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 3127
3126  |  3128
Subject: 
Re: Several replies to CLIPPING / WINDING
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 18 Oct 1999 16:26:45 GMT
Reply-To: 
RUI.MARTINS@stopspamLINK.PT
Viewed: 
550 times
  
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



Message has 2 Replies:
  Re: Several replies to CLIPPING / WINDING
 
Rui Martins wrote in message ... (...) 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 (...) (25 years ago, 19-Oct-99, to lugnet.cad.dev)
  Re: Several replies to CLIPPING / WINDING
 
(...) We both want the same thing, now we need to make everybody agree with us :) (...) I sort first by color and then by line type. I have everything pre-processed and I don't use glBegin()/glEnd() to render. (...) From my personal experience, (...) (25 years ago, 19-Oct-99, to lugnet.cad.dev)

Message is in Reply To:
  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)

15 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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR