The OpenGL State Machine

The OpenGL State Machine

Post by Julian Thom » Fri, 31 Jan 1997 04:00:00



Hello,

I am designing a rendering engine that I can use to render using OpenGL,
Direct3D or (Win32) Glide. At the moment I am trying to design an
architecture where I can have a common interface between by game engine
code and then use either one of the rendering solutions.

So my initial idea is to take construct a list of triangles that make up
my scene, the textures they use, the cameras used (ie support for more
than 1 player), the lights in the scene, and amy other global effects eg
maybe fog levels.

I need to design the kind of structure I want to use that could be
processed by either one of my renderers as efficiently as possible..

Obviously with OpenGL using this approach will require quite a few
OpenGl State Machine changes eg (glEnable calls) for the different
triangles in the scene.

What I wanted to know was... what is the performance hit of constantly
changing GL rendering States... do I want to keep these changes to a
minimum by cleverly grouping (nice sort algorithm)  similar triangles
together (despite possibly being in quite different parts of the scene).

Any comments would be appreciated.

Julian

DJI

 
 
 

The OpenGL State Machine

Post by Julian Thom » Fri, 31 Jan 1997 04:00:00


Hello,

I am designing a rendering engine that I can use to render using OpenGL,
Direct3D or (Win32) Glide. At the moment I am trying to design an
architecture where I can have a common interface between by game engine
code and then use either one of the rendering solutions.

So my initial idea is to take construct a list of triangles that make up
my scene, the textures they use, the cameras used (ie support for more
than 1 player), the lights in the scene, and amy other global effects eg
maybe fog levels.

I need to design the kind of structure I want to use that could be
processed by either one of my renderers as efficiently as possible..

Obviously with OpenGL using this approach will require quite a few
OpenGl State Machine changes eg (glEnable calls) for the different
triangles in the scene.

What I wanted to know was... what is the performance hit of constantly
changing GL rendering States... do I want to keep these changes to a
minimum by cleverly grouping (nice sort algorithm)  similar triangles
together (despite possibly being in quite different parts of the scene).

Any comments would be appreciated.

Julian

DJI

 
 
 

The OpenGL State Machine

Post by jeff bigg » Fri, 31 Jan 1997 04:00:00


Hello,

        I am currently porting a simulation written in IRIS GL to OpenGL.  The
simulation was implemented with multiple windows that allow rendering a
scene view, an IR view, etc.  I am wondering, if I would get better
performance implementing one window with multiple viewports?  Any hints
or suggestions would be greatly appreciated!  Thanks!

Mary Frey

205-876-9159

 
 
 

The OpenGL State Machine

Post by Tom Rya » Fri, 31 Jan 1997 04:00:00




Quote:> Hello,

> I am designing a rendering engine that I can use to render using OpenGL,
> Direct3D or (Win32) Glide. At the moment I am trying to design an
> architecture where I can have a common interface between by game engine
> code and then use either one of the rendering solutions.

Julian,

Since 3DfX is going to be fully supporting OpenGL, why bother with the
Glide driver at all? From the looks of GLQuake, their OpenGL implementation
is going to scorch.

-Tom Ryan, SciTech Software, Inc.

 
 
 

The OpenGL State Machine

Post by Brian Hoo » Fri, 31 Jan 1997 04:00:00



> What I wanted to know was... what is the performance hit of constantly
> changing GL rendering States... do I want to keep these changes to a
> minimum by cleverly grouping (nice sort algorithm)  similar triangles
> together (despite possibly being in quite different parts of the scene).

State changes with almost ANY graphics API are going to be variable in
expense.  Glide has fairly lightweight state changes, but if you change
state every triangle you'll still see a MASSIVE performance problem.
With OpenGL and D3D, state changes like a texture map selection can
often do REALLY slow things behind your back, e.g. page a texture from
system memory into frame buffer memory.

D3D is even worse, because you end up having to put OP_STATE_DATA stuff
right in the middle of your execute buffer, meaning you get lots of one
trianglie OP_TRIANGLE_LISTs.  Bad idea.

Your best bet is to sort your incoming geometry by material, and batch
these into material groups.  At the head of each material group you set
state once, then you turn around and render all the triangles.  With D3D
this lets you put your OP_STATE_DATA at the top of your execute buffer,
then do an N-triangle OP_TRIANGLE_LIST afterwards.  With OpenGL, you do
your GL calls at the very top, then go from there.  With Glide, you do
it just like OpenGL.

So, the m*is to try and minimize state changes for ALL the APIs you
are using.

Brian
--
+-----------------------------------------------------------------+

+  WK Software, http://www.veryComputer.com/                         +
+  Consultants specializing in 3D graphics hardware and software  +
+ --------------------------------------------------------------- +
+  For a list of publications on 3D graphics programming,         +
+  including Direct3D, OpenGL, and book reviews:                  +
+      http://www.veryComputer.com/;              +
+-----------------------------------------------------------------+

 
 
 

The OpenGL State Machine

Post by Brian Hoo » Fri, 31 Jan 1997 04:00:00



> Julian,

> Since 3DfX is going to be fully supporting OpenGL, why bother with the
> Glide driver at all? From the looks of GLQuake, their OpenGL implementation
> is going to scorch.

Glide exists today, a full OpenGL conformant driver from 3Dfx does not.
Glide exposes a LOT of 3Dfx-specific functionality; depending on the
driver 3Dfx pursues (ICD or MCD), they may not be able to expose these
key features in hardware.

Finally, Glide is a very simple rasterization layer, and it sounds like
Julian has his own transformation engine already, so Glide is a simple
"drop in" API.

Supporting Glide is typically VERY trivial for most game developers.

Brian
--
+-----------------------------------------------------------------+

+  WK Software, http://www.wksoftware.com                         +
+  Consultants specializing in 3D graphics hardware and software  +
+ --------------------------------------------------------------- +
+  For a list of publications on 3D graphics programming,         +
+  including Direct3D, OpenGL, and book reviews:                  +
+      http://www.wksoftware.com/publications.html                +
+-----------------------------------------------------------------+

 
 
 

The OpenGL State Machine

Post by Brandon Van Ever » Sat, 01 Feb 1997 04:00:00




Quote:

> What I wanted to know was... what is the performance hit of constantly
> changing GL rendering States... do I want to keep these changes to a
> minimum by cleverly grouping (nice sort algorithm)  similar triangles
> together (despite possibly being in quite different parts of the scene).

The hit is enormous.  Don't do it frequently.

Cheers,
--
Brandon J. Van Every       |  Free3d: old code never dies!  :-)
                           |  Starter code for GNU Copyleft projects.
DEC Graphics & Multimedia  |

 
 
 

The OpenGL State Machine

Post by Mark Kilga » Sun, 02 Feb 1997 04:00:00


|>
|>   I am currently porting a simulation written in IRIS GL to OpenGL.  The
|> simulation was implemented with multiple windows that allow rendering a
|> scene view, an IR view, etc.  I am wondering, if I would get better
|> performance implementing one window with multiple viewports?  Any hints
|> or suggestions would be greatly appreciated!  Thanks!

In general, if you can, it is faster just to change the viewport
(probably changing your modelview and projection matices as well
to render the different view).  Here's the general rule:

  o  Switching viewports - cheap

  o  Switching windows but keeping the same OpenGL rendering context - less cheap

  o  Switching to a different rendering context - fairly expensive

Of course, this can very with how your OpenGL is implemented.  The
rules above apply when hardware must be context switched.  If everything
is software, they all could be pretty cheap since you don't need to
switch out hardware state.

I hope this helps.

- Mark

 
 
 

The OpenGL State Machine

Post by Julian Thom » Tue, 04 Feb 1997 04:00:00




> > Julian,

> > Since 3DfX is going to be fully supporting OpenGL, why bother with the
> > Glide driver at all? From the looks of GLQuake, their OpenGL implementation
> > is going to scorch.

> Glide exists today, a full OpenGL conformant driver from 3Dfx does not.
> Glide exposes a LOT of 3Dfx-specific functionality; depending on the
> driver 3Dfx pursues (ICD or MCD), they may not be able to expose these
> key features in hardware.

> Finally, Glide is a very simple rasterization layer, and it sounds like
> Julian has his own transformation engine already, so Glide is a simple
> "drop in" API.

> Supporting Glide is typically VERY trivial for most game developers.

> Brian

Yes I am in agreement,

1. Tom - It does look like the fully mature 3dfx implementation of
OpenGL will be pretty cool.

2. Brian - I am in agreement also, I don't see a glide implementation as
being a real coding trial, I think it should be fairly straight forward.
Also there could be a few nice tricks I could do using glide specific
features. And i know that 3dfx users would appreciate a glide only
version of software even if there is only a slight boost to an ogl
implementation.

Julian

 
 
 

The OpenGL State Machine

Post by cigdem cim » Fri, 07 Feb 1997 04:00:00


: Hello,

:       I am currently porting a simulation written in IRIS GL to OpenGL.  The
: simulation was implemented with multiple windows that allow rendering a
: scene view, an IR view, etc.  I am wondering, if I would get better
: performance implementing one window with multiple viewports?  Any hints
: or suggestions would be greatly appreciated!  Thanks!

: Mary Frey

: 205-876-9159

 I work on UNIX environment with OpenGL and I did a project using multiple
viewports.Its performance was good enough in SUN workstations. Also I believe
that it works very efficienty any computer.

I have no idea about IRIS, then if you explain its meaning, may be I can
help you more.
        Cigdem CIMEN

 
 
 

1. OpenGL state machine

Hi!
When I looked at the OpenGL state machine diagram it said that normals
are multiplied with the transpose of the modelview matrix. It seems very
intuative that the normals should get the rotated in the opposed
directions of the camera but since the transpose of a matrix is the
inverse of that matrix if it contains only rotations I quess that this
step only multiplies the normals by the upper 3x3 matrix or the first 3
rows. Is this correct?

Best regards,
/Michael Andersson

2. Font Weight?

3. way to restore the opengl state machine?

4. Need Lotus Freelance Graphics

5. Opengl state machine ?

6. SCRATCH DISK IS ALWAYS FULLL !!!

7. OpenGL as State Machine.

8. drawing a state machine

9. Program for drawing finite state machines?

10. ANN: ZMECH v0.2.1 (IPAD-Pro derived: Interative state machine development tool)

11. restoring machine state

12. State Machine script parser