to load maps and models in my engine so far, i have read the file i wanted,
and stored it all into a array.
then i looped trough that array every time in the DrawGLScene function.
this i kinda slow.

so, my question is, is it faster to create a display list, and then call it
in DrawGLScene function?

thnx.


--
ivan
-

sure it's faster, that's what display lists are for, but it's not the real
end of it, before gambling arpund with display lists, you should consider
using the glDrawVertexArray functions, because when you already have
everything in your array, then you can simply use vertex arrays to draw
everything, this is even one step faster than display lists, because you
don't need to call a glBegin or glVertex3f all the time, you are also able
to transform your vertices, you have stored, when you do not use locked
vertex arrays, but when you want to apply a texture to you object, you will
probably have to resort your texturecoordinates, because now you have only
one indexarray for both, the vertices and the texture array, i'm sure you
can find a lot about that on google or gamedev.net

"Ivan" <-MAKNI-ivan.sovic1@zg.tel.hr> schrieb im Newsbeitrag
news:bteqcq$mj$1@ls219.htnet.hr...
> to load maps and models in my engine so far, i have read the file i
wanted,
> and stored it all into a array.
> then i looped trough that array every time in the DrawGLScene function.
> this i kinda slow.
>
> so, my question is, is it faster to create a display list, and then call
it
> in DrawGLScene function?
>
> thnx.
>
>
> --
> ivan
> -
>
>
>

Ivan wrote:
> to load maps and models in my engine so far, i have read the file i wanted,
> and stored it all into a array.
> then i looped trough that array every time in the DrawGLScene function.
> this i kinda slow.
> 
> so, my question is, is it faster to create a display list, and then call it
> in DrawGLScene function?
> 

Yes, it's probably faster, and display lists are easy
to use (it would have taken you about two minutes
to try it out...!)

Maybe better for you would be vertex arrays - see
glDrawArrays(). When you get them working it's easy
to then move the arrays to video card memory, and
that's where you get the real performance.


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    Why isn't there mouse-flavored cat food?

"fungus" <openglMY@SOCKSartlum.com> wrote in message
news:Q4DKb.2421103$uj6.5894645@telenews.teleline.es...
> Ivan wrote:
> > to load maps and models in my engine so far, i have read the file i
wanted,
> > and stored it all into a array.
> > then i looped trough that array every time in the DrawGLScene function.
> > this i kinda slow.
> >
> > so, my question is, is it faster to create a display list, and then call
it
> > in DrawGLScene function?
> >
>
> Yes, it's probably faster, and display lists are easy
> to use (it would have taken you about two minutes
> to try it out...!)
>
> Maybe better for you would be vertex arrays - see
> glDrawArrays(). When you get them working it's easy
> to then move the arrays to video card memory, and
> that's where you get the real performance.
>
>

Could you recommend which would be better for my application, call lists or
vertex arrays?
I have a game which is basically a spruced-up version of the classic Galaga.
I have made my own basic file format which I convert from lightwave .obj
files.  My format contains the vertex data and all normals (I average these
out in my converter for smooth surfaces).  Then I have all the material info
including textures/env reflections.
At the moment I use display lists - when I load an object, I cache it and
create the display list so I can load my objects with one function
(returning the call-list).  Do you think vertex arrays would be faster?
A typical model has around 30-50 vertices with 60-90 faces (quads).  I am
attempting to move around 80 of these on-screen (I also have background
images, starfields, and text displayed).  Would I be better to use vertex
arrays?
Thanks
Allan

Allan Bruce wrote:
> 
> Could you recommend which would be better for my application, call lists or
> vertex arrays?
> I have a game which is basically a spruced-up version of the classic Galaga.
> I have made my own basic file format which I convert from lightwave .obj
> files.  My format contains the vertex data and all normals (I average these
> out in my converter for smooth surfaces).  Then I have all the material info
> including textures/env reflections.
> At the moment I use display lists - when I load an object, I cache it and
> create the display list so I can load my objects with one function
> (returning the call-list).  Do you think vertex arrays would be faster?

I think you're worrying about this much too early in
the development process.

The most important rule for writing a fast program is:

Write the program first, *then* if it's too slow find
out how to make it faster. Only when it's *all* working
will you be able to know where the bottlenecks are, and
this is where you should attack. Anything else is wasted
time and effort.

Thus speaks the master.

> A typical model has around 30-50 vertices with 60-90 faces (quads).  I am
> attempting to move around 80 of these on-screen (I also have background
> images, starfields, and text displayed).  Would I be better to use vertex
> 

For such a tiny amount of polygons it probably makes no
difference how you do it. If I were you I'd use display
lists simply because they're easier to program and you
appear to have them working.


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    Why isn't there mouse-flavored cat food?

so far, but to answer your question, vertex arrays are the fastest way to do
in most cases, from 10000 polys upwards it should be your choice, and with
around 90*80 polys that you want to draw this would be near that border ,
you can still get a really god framerate, my good athlon 800 with a geforce
still gives me over three hundred frames with 5 objects drawn with vertex
arrays and around 10000 polys and my physics engine enabled, which is based
on real physics laws, and that probably takes a lot away ;) btw, with
display lists I only had about 180 fps.

"fungus" <openglMY@SOCKSartlum.com> schrieb im Newsbeitrag
news:kfGKb.2423213$uj6.5905213@telenews.teleline.es...
> Allan Bruce wrote:
> >
> > Could you recommend which would be better for my application, call lists
or
> > vertex arrays?
> > I have a game which is basically a spruced-up version of the classic
Galaga.
> > I have made my own basic file format which I convert from lightwave .obj
> > files.  My format contains the vertex data and all normals (I average
these
> > out in my converter for smooth surfaces).  Then I have all the material
info
> > including textures/env reflections.
> > At the moment I use display lists - when I load an object, I cache it
and
> > create the display list so I can load my objects with one function
> > (returning the call-list).  Do you think vertex arrays would be faster?
>
> I think you're worrying about this much too early in
> the development process.
>
> The most important rule for writing a fast program is:
>
> Write the program first, *then* if it's too slow find
> out how to make it faster. Only when it's *all* working
> will you be able to know where the bottlenecks are, and
> this is where you should attack. Anything else is wasted
> time and effort.
>
> Thus speaks the master.
>
> > A typical model has around 30-50 vertices with 60-90 faces (quads).  I
am
> > attempting to move around 80 of these on-screen (I also have background
> > images, starfields, and text displayed).  Would I be better to use
vertex
> >
>
> For such a tiny amount of polygons it probably makes no
> difference how you do it. If I were you I'd use display
> lists simply because they're easier to program and you
> appear to have them working.
>
>
> --
> <\___/>          For email, remove my socks.
> / O O \
> \_____/  FTB.    Why isn't there mouse-flavored cat food?
>
>

"fungus" <openglMY@SOCKSartlum.com> wrote in message
news:kfGKb.2423213$uj6.5905213@telenews.teleline.es...
> Allan Bruce wrote:
> >
> > Could you recommend which would be better for my application, call lists
or
> > vertex arrays?
> > I have a game which is basically a spruced-up version of the classic
Galaga.
> > I have made my own basic file format which I convert from lightwave .obj
> > files.  My format contains the vertex data and all normals (I average
these
> > out in my converter for smooth surfaces).  Then I have all the material
info
> > including textures/env reflections.
> > At the moment I use display lists - when I load an object, I cache it
and
> > create the display list so I can load my objects with one function
> > (returning the call-list).  Do you think vertex arrays would be faster?
>
> I think you're worrying about this much too early in
> the development process.
>
> The most important rule for writing a fast program is:
>
> Write the program first, *then* if it's too slow find
> out how to make it faster. Only when it's *all* working
> will you be able to know where the bottlenecks are, and
> this is where you should attack. Anything else is wasted
> time and effort.
>
> Thus speaks the master.
>
> > A typical model has around 30-50 vertices with 60-90 faces (quads).  I
am
> > attempting to move around 80 of these on-screen (I also have background
> > images, starfields, and text displayed).  Would I be better to use
vertex
> >
>
> For such a tiny amount of polygons it probably makes no
> difference how you do it. If I were you I'd use display
> lists simply because they're easier to program and you
> appear to have them working.
>
>

The game is nearing completion, and it doesnt always run at its full 60 fps
on my machine, although I am running at 1280*1024*32.  I think it should be
able to do this easily.  I think by using vertex arrays I may get a small
improvement.  I also think that my texturing is slowing the frame rate.  If
I have textures around 256*256 then it runs quite slow, but having them all
64*64 and a few at 128*128 then it runs respectfully.
If there is anybody who would like to test it out to comment on the speed
then I will happily provide a link to the binary.
Thanks
Allan

"Christian Goltz" <g4e@gmx.net> wrote in message
news:btffcq$6gog8$1@ID-219823.news.uni-berlin.de...
> so far, but to answer your question, vertex arrays are the fastest way to
do
> in most cases, from 10000 polys upwards it should be your choice, and with
> around 90*80 polys that you want to draw this would be near that border ,
> you can still get a really god framerate, my good athlon 800 with a
geforce
> still gives me over three hundred frames with 5 objects drawn with vertex
> arrays and around 10000 polys and my physics engine enabled, which is
based
> on real physics laws, and that probably takes a lot away ;) btw, with
> display lists I only had about 180 fps.
>

That sounds like a good improvement, now to suss out how to do vertex
arrays.
Does anybody have a good online tutorial about them? I didnt see one on
NeHe.
Thanks
Allan

Allan Bruce wrote:

> 
> The game is nearing completion, and it doesnt always run at its full 60 fps
> on my machine, although I am running at 1280*1024*32.  I think it should be
> able to do this easily.  I think by using vertex arrays I may get a small
> improvement.  I also think that my texturing is slowing the frame rate.  If
> I have textures around 256*256 then it runs quite slow, but having them all
> 64*64 and a few at 128*128 then it runs respectfully.
> 

Maybe texturing is your bottleneck, not vertex transfer.

Are you sorting your polygons by texture? Graphics card
makers are always telling us that switching textures is
expensive.



-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    Why isn't there mouse-flavored cat food?

Allan Bruce wrote:

>>still gives me over three hundred frames with 5 objects drawn with vertex
>>arrays and around 10000 polys
> 
> 
> That sounds like a good improvement, now to suss out how to do vertex
> arrays.
> Does anybody have a good online tutorial about them? I didnt see one on
> NeHe.

It might not work out for you. Vertex arrays work best
when the arrays are really big.


PS: How are you drawing the starfield, etc.?


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    Why isn't there mouse-flavored cat food?

"fungus" <openglMY@SOCKSartlum.com> wrote in message
news:d3IKb.2424097$uj6.5907579@telenews.teleline.es...
> Allan Bruce wrote:
>
> >>still gives me over three hundred frames with 5 objects drawn with
vertex
> >>arrays and around 10000 polys
> >
> >
> > That sounds like a good improvement, now to suss out how to do vertex
> > arrays.
> > Does anybody have a good online tutorial about them? I didnt see one on
> > NeHe.
>
> It might not work out for you. Vertex arrays work best
> when the arrays are really big.
>
>
> PS: How are you drawing the starfield, etc.?
>
>

I am drawing the background images (nebulae etc.) as large quads and the
starfield is a random 3d space of quadrics.

"fungus" <openglMY@SOCKSartlum.com> wrote in message
news:%0IKb.2424077$uj6.5907582@telenews.teleline.es...
> Allan Bruce wrote:
>
> >
> > The game is nearing completion, and it doesnt always run at its full 60
fps
> > on my machine, although I am running at 1280*1024*32.  I think it should
be
> > able to do this easily.  I think by using vertex arrays I may get a
small
> > improvement.  I also think that my texturing is slowing the frame rate.
If
> > I have textures around 256*256 then it runs quite slow, but having them
all
> > 64*64 and a few at 128*128 then it runs respectfully.
> >
>
> Maybe texturing is your bottleneck, not vertex transfer.
>
> Are you sorting your polygons by texture? Graphics card
> makers are always telling us that switching textures is
> expensive.
>
>
>

During my conversion from lightwave to my own format, I am ensuring that all
the polys with the same material are called at once, to save the same
material being loaded up more than once within the same object, e.g. if I
were drawing a car, then I would only need to call a material once for the
all bodywork.
I suppose since each object has around 4 materials, and I have around 80 of
these on-screen then that is 200-300 texture swaps per frame.  This sounds
like it could be a bottleneck.

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message
news:btgi6s$r2k$1@news.freedom2surf.net...
>
> "fungus" <openglMY@SOCKSartlum.com> wrote in message
> news:%0IKb.2424077$uj6.5907582@telenews.teleline.es...
> > Allan Bruce wrote:
> >
> > >
> > > The game is nearing completion, and it doesnt always run at its full
60
> fps
> > > on my machine, although I am running at 1280*1024*32.  I think it
should
> be
> > > able to do this easily.  I think by using vertex arrays I may get a
> small
> > > improvement.  I also think that my texturing is slowing the frame
rate.
> If
> > > I have textures around 256*256 then it runs quite slow, but having
them
> all
> > > 64*64 and a few at 128*128 then it runs respectfully.
> > >
> >
> > Maybe texturing is your bottleneck, not vertex transfer.
> >
> > Are you sorting your polygons by texture? Graphics card
> > makers are always telling us that switching textures is
> > expensive.
> >
> >
> >
>
> During my conversion from lightwave to my own format, I am ensuring that
all
> the polys with the same material are called at once, to save the same
> material being loaded up more than once within the same object, e.g. if I
> were drawing a car, then I would only need to call a material once for the
> all bodywork.
> I suppose since each object has around 4 materials, and I have around 80
of
> these on-screen then that is 200-300 texture swaps per frame.  This sounds
> like it could be a bottleneck.

There is no general recipie for optimal performance since its usually both
depending on the scene your rendering and on the hardware/drivers your
using. Also your program might be cpu-bound, fillrate limited, geometry
limited or a combination of all these.

But here are some things I have found that often (but unfortunately not
always) improves performance:

1. Profile your program. Find out where its actually spending most time,
then consentrate your efforts on improving these parts of your program.
(Turn of vertical sync when profiling).

2. Try to roughly sort the rendering in a way that minimizes all state
changes and OpenGL calls, not only texture binds but everything. Do you
really have 200-300 unique textures? or is it only say 50-100 unique
textures where many is shared between different objects, in that case you
should try rendering the scene in a way that you only have to call glBind
one time for each texture. Texture binding is usually the most expensive
call.

3. If you have not already done so then implement some sort of view frustum
culling.

4. Order your polys so that polygons that share vertices get rendered in
order or use strips. Also in your import filter detect and discard
degenerated polys and if you use arrays detect and merge shared vertices
(this depends on what 3D package was used to create the models. I dont know
about lightwave but I have found 3DS-MAX to often include lots of junk and
redundancy  in exported 3d models).

5. Take a look at extensions that allows you to store geometry in AGP or
video memory, detect them at run time and use them if they are available. I
have seen everything from 5 to 200% performance improvement using such
extensions (depending on scene).

6. Render opaque objects in roughly front to back order (dont waste cpu time
to sort every poly, do this at a higher/object level).

7. Ask your self if there is anything you do each frame that could have been
precalculated at loading time.


If anyone have additional tips I would love to hear about them :-)

--
Stig

> > During my conversion from lightwave to my own format, I am ensuring that
> all
> > the polys with the same material are called at once, to save the same
> > material being loaded up more than once within the same object, e.g. if
I
> > were drawing a car, then I would only need to call a material once for
the
> > all bodywork.
> > I suppose since each object has around 4 materials, and I have around 80
> of
> > these on-screen then that is 200-300 texture swaps per frame.  This
sounds
> > like it could be a bottleneck.
>
> There is no general recipie for optimal performance since its usually both
> depending on the scene your rendering and on the hardware/drivers your
> using. Also your program might be cpu-bound, fillrate limited, geometry
> limited or a combination of all these.
>
> But here are some things I have found that often (but unfortunately not
> always) improves performance:
>
> 1. Profile your program. Find out where its actually spending most time,
> then consentrate your efforts on improving these parts of your program.
> (Turn of vertical sync when profiling).

How do I do this? I have never done anything like it before.  Do I need
special software for this? I am using VC7

>
> 2. Try to roughly sort the rendering in a way that minimizes all state
> changes and OpenGL calls, not only texture binds but everything. Do you
> really have 200-300 unique textures? or is it only say 50-100 unique
> textures where many is shared between different objects, in that case you
> should try rendering the scene in a way that you only have to call glBind
> one time for each texture. Texture binding is usually the most expensive
> call.

What I am doing just now is creating a display list for each unique texture
then calling it when required.  This means that I have one display list that
may potentially be used for 100 different objects.  I did this to save
texture memory.  During the compiling of my display list, I use these GL
calls:

// select ARB texture
glActiveTextureARB(GL_TEXTURE1_ARB); // activate reflection ARB
glEnable(GL_TEXTURE_2D); // activate the selected ARB

// set texture mode
glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB_EXT, GL_BLEND);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_EXT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);
glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);
glEnable(GL_TEXTURE_GEN_S);
glEnable(GL_TEXTURE_GEN_T);

// set texture bits
glTexImage2D(GL_TEXTURE_2D,
  0,
  3,
  mBmpReflect.bmWidth,
  mBmpReflect.bmHeight,
  0,
  GL_BGR_EXT,
  GL_UNSIGNED_BYTE,
  mRefBits);

// set ARB texture
glActiveTextureARB(GL_TEXTURE2_ARB);
glEnable(GL_TEXTURE_2D); // activate the selected ARB

// set texture mode
glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB_EXT, GL_BLEND);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_EXT);
glBindTexture(GL_TEXTURE_2D, mTextures[2]); // make a different texture
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);
glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glTexGenfv(GL_T, GL_OBJECT_PLANE, lTcoords); // auto coords
glTexGenfv(GL_S, GL_OBJECT_PLANE, lScoords);
glEnable(GL_TEXTURE_GEN_S);
glEnable(GL_TEXTURE_GEN_T);

// set texture bits
glTexImage2D(GL_TEXTURE_2D,
  0,
  3,
  mBmpTexture.bmWidth,
  mBmpTexture.bmHeight,
  0,
  GL_BGR_EXT,
  GL_UNSIGNED_BYTE,
  mTexBits);


>
> 3. If you have not already done so then implement some sort of view
frustum
> culling.

Can you explain this more? I think you mean "dont render what you dont see".
If this is the case, then it wont matter for my game as everything is seen
at once, there is very little overlapping of 3d objects.

>
> 4. Order your polys so that polygons that share vertices get rendered in
> order or use strips. Also in your import filter detect and discard
> degenerated polys and if you use arrays detect and merge shared vertices
> (this depends on what 3D package was used to create the models. I dont
know
> about lightwave but I have found 3DS-MAX to often include lots of junk and
> redundancy  in exported 3d models).

This is an idea, I think Lightwave is quite user friendly for creating
strips.  If not, does anyone know of an algorithm that may help?

>
> 5. Take a look at extensions that allows you to store geometry in AGP or
> video memory, detect them at run time and use them if they are available.
I
> have seen everything from 5 to 200% performance improvement using such
> extensions (depending on scene).

This sounds good, do you have any links?

>
> 6. Render opaque objects in roughly front to back order (dont waste cpu
time
> to sort every poly, do this at a higher/object level).

I had a look at NeHe for this, but couldnt find anything.  I dont think it
will make any difference for my game as there is no overlapping of objects
(or very little anyway).  If I do do this then it will require quite a major
re-design of my basic engine, but if it needs it then I am willing.

>
> 7. Ask your self if there is anything you do each frame that could have
been
> precalculated at loading time.

I dont think there is but I will have a look - I suppose I could find this
out while doing the profiling tests?

>
>
> If anyone have additional tips I would love to hear about them :-)
>

Thanks very much for the ideas
Allan

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message
news:bth3ca$1dg$1@news.freedom2surf.net...
> > 1. Profile your program. Find out where its actually spending most time,
> > then consentrate your efforts on improving these parts of your program.
> > (Turn of vertical sync when profiling).
>
> How do I do this? I have never done anything like it before.  Do I need
> special software for this? I am using VC7

I think profiling is included with VC7, at least it was with VC6. Try
searching the online help files for explanation about how to use this. It
makes it possible to run the program and on exit get a report on how much
time is actually spent in different parts of your code. This makes it easy
to find the real bottlenecks in your program, they are often not the same as
you would guess yourself.

> >
> > 2. Try to roughly sort the rendering in a way that minimizes all state
> > changes and OpenGL calls, not only texture binds but everything. Do you
> > really have 200-300 unique textures? or is it only say 50-100 unique
> > textures where many is shared between different objects, in that case
you
> > should try rendering the scene in a way that you only have to call
glBind
> > one time for each texture. Texture binding is usually the most expensive
> > call.
>
> What I am doing just now is creating a display list for each unique
texture
> then calling it when required.  This means that I have one display list
that
> may potentially be used for 100 different objects.  I did this to save
> texture memory.  During the compiling of my display list, I use these GL
> calls:
> [snip - code sample]

Sounds ok, but it was not exactly what I was asking for.

What I meant was; do you do it like this (pseudo code):

    for x=first to last object {
        set material used by x;
        render geometry in object x;
    }

or like this:

   for x=first to last material {
       set material x;
       render all  geometry using material x;
   }

The second method should be much faster if you have materials potentially
used by 100 different objects (fewer state changes). I usually just keep an
updated linked list for each material pointing to the geometry used by it.

> > 3. If you have not already done so then implement some sort of view
> frustum
> > culling.
>
> Can you explain this more? I think you mean "dont render what you dont
see".
> If this is the case, then it wont matter for my game as everything is seen
> at once, there is very little overlapping of 3d objects.

Yes, frustum culling is about "dont render what you dont see" but I was not
thinking about what you dont see because it is overlapped by another object,
that is usually called occlusion culling and is a much more complex problem
to solve.

I was thinking about "dont render what you cannot see" because the camera is
not pointing that way. It might be behind you or something, in most games
50% or more of the scene is usually not seen at the same time unless you are
high up in the air and looking down or something.

To do frustum culling (search on google and you will find plenty of
examples) I usually build up a hierarchy of bounding boxes using a structure
like quadtree, octree, rtree etc that makes it possible to very fast
eliminate objects that is completely out side the view frustum (view frustum
defines whats visible to the camera). I usually dont care to test down to
complete polygon level because modern 3D cards are so fast it's often takes
a longer time to do testing on polygon level than just to render the
partially visible objects anyway, this of course would be highly scene
dependent.

In my experience most cases you should expect something like 20-50%
performance gain when done correcly. Of course in the worst case - camera
high, looking down on the complete scene its actually a bit slower because
of the extra culling code, but this is usually not the case in 3D games like
first person shooter, car-race etc. Its of course important to use good
programming thecniques that makes the culling code fast.

Creating a fast and efficient frustum culling can be quite difficult but its
usually worth it. Also the problem is very much related to collision
detection wich often is very important in games.

If your program is basically a 2D game (everything seen from above) then you
can just ignore frustum culling.

> > 4. Order your polys so that polygons that share vertices get rendered in
> > order or use strips. Also in your import filter detect and discard
> > degenerated polys and if you use arrays detect and merge shared vertices
> > (this depends on what 3D package was used to create the models. I dont
> know
> > about lightwave but I have found 3DS-MAX to often include lots of junk
and
> > redundancy  in exported 3d models).
>
> This is an idea, I think Lightwave is quite user friendly for creating
> strips.  If not, does anyone know of an algorithm that may help?

Source code and explanation here: http://www.codercorner.com/Strips.htm
I have used this code several times. (Thanks Pierre!) This code is very
general and should be easy to integrate with the code you already have.

You can also find example code at developer.nvidia.com but they tend to
bloat their example code so much its a pain in the ass to pick out the bits
your interesting in. ATI probably have something too, but I have not
checked.

> > 5. Take a look at extensions that allows you to store geometry in AGP or
> > video memory, detect them at run time and use them if they are
available.
> I
> > have seen everything from 5 to 200% performance improvement using such
> > extensions (depending on scene).
>
> This sounds good, do you have any links?

The official ARB version is called ARB_vertex_buffer_object, its fairly new
(a year or something, dont remember exactly) but is implemented in most
current drivers.

Tutorial here or search google for "VBO tutorial" or
ARB_vertex_buffer_object
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=45

It's important (at least if you want your program to run on most 3d cards)
that you test extension strings during run time to see if this extension is
available and only use it if it is, since not all graphic cards support
this.

> > 6. Render opaque objects in roughly front to back order (dont waste cpu
> time
> > to sort every poly, do this at a higher/object level).
>
> I had a look at NeHe for this, but couldnt find anything.  I dont think it
> will make any difference for my game as there is no overlapping of objects
> (or very little anyway).  If I do do this then it will require quite a
major
> re-design of my basic engine, but if it needs it then I am willing.

In that case its probably not important, also its usually only a great
performance improvement if you are fill rate limited and have a certain
degree of overlap. To find out if your fill rate limited, just make your
rendering windows smaller and watch the framerate, if it increases
dramaticly then your probably fill rate limited.

> > 7. Ask your self if there is anything you do each frame that could have
> been
> > precalculated at loading time.
>
> I dont think there is but I will have a look - I suppose I could find this
> out while doing the profiling tests?

I dont think profiling would tell you much about this, I was more thinking
about if there is any way you could structure your data differently to save
time during each frame (sorting when loading for instance) or if you were
doing some calculations each frame that really only need to be done once
during loading.

I hope you find some of this usefull.

--
Stig

<snip>

>
> Sounds ok, but it was not exactly what I was asking for.
>
> What I meant was; do you do it like this (pseudo code):
>
>     for x=first to last object {
>         set material used by x;
>         render geometry in object x;
>     }
>
> or like this:
>
>    for x=first to last material {
>        set material x;
>        render all  geometry using material x;
>    }
>
> The second method should be much faster if you have materials potentially
> used by 100 different objects (fewer state changes). I usually just keep
an
> updated linked list for each material pointing to the geometry used by it.

I am using the first method because I am building a display list of the
objects as they are loaded.  I agree the second one is probably far quicker,
but I would have to make a major overhaul of my code for it to do this.
Using the profiler has helped a fair bit btw, the game now runs happily at
60fps.  I was wasting time during my lighting code.

<snip>

> Source code and explanation here: http://www.codercorner.com/Strips.htm
> I have used this code several times. (Thanks Pierre!) This code is very
> general and should be easy to integrate with the code you already have.

Thanks - I will read through this.

>
> You can also find example code at developer.nvidia.com but they tend to
> bloat their example code so much its a pain in the ass to pick out the
bits
> your interesting in. ATI probably have something too, but I have not
> checked.
>
> > > 5. Take a look at extensions that allows you to store geometry in AGP
or
> > > video memory, detect them at run time and use them if they are
> available.
> > I
> > > have seen everything from 5 to 200% performance improvement using such
> > > extensions (depending on scene).
> >
> > This sounds good, do you have any links?
>
> The official ARB version is called ARB_vertex_buffer_object, its fairly
new
> (a year or something, dont remember exactly) but is implemented in most
> current drivers.
>
> Tutorial here or search google for "VBO tutorial" or
> ARB_vertex_buffer_object
> http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=45
>

Thanks again, this will be very useful

<snip>

> I hope you find some of this usefull.
>

Very, thanks a lot for your help.
Would you be interested to see my game in development? If so, email me.
Thanks again
Allan