I just noticed that FOG sample from DX 6.1 SDK does a terrain demo with fog enabled... its pretty fast. And, it *does* use DrawIndexedPrimitive(). You may wanna look at that sample Andrew.

- prauppl

I´ll try to implement the DrawIndexedPrimitive-Calls ...and I hope, that the engine will be faster as without it

By the way: I´ve tested my engine without texturing, without animating water and without objects (or something else), but it wasn´t faster as the normal version! So I think, the reason of this slowness is the DrawPrimitiv ();

Look at my current code:
(just for example!)

This draws a landscape with 20*20 fields (400 polys)

for (int i=0; i<20; i++)
{
for (int a=0; a<20; a++)
{
SetTexture ();
DrawPrimitve (ThePolygon);
Calc_Something ();
}
}

As you see, this ist very slow ...
But I hope, the engine wil be faster with Draw-Primitive

Cya,
-Andrew

------------------
-------------------------
Andrew
Lead Programmer
UNITED BYTES, GERMANY
andy@unitedbytes.de
-------------------------

Is that drawing one poly at a time?

That's gonna slow you down big time, especially with you setting the texture every time.

Try drawing all of them at once, or just a subset of the whole terrain.

Hmm ...this sounds good, SomeGuy! But how should I do that?

-Andrew

------------------
-------------------------
Andrew
Lead Programmer
UNITED BYTES, GERMANY
andy@unitedbytes.de
-------------------------

As I said before, I have almost no experiance with terrain rendering, and I am actually just learning 3d graphics, but I may be able to give some advice from a logical standpoint. Try sorting the polygons into groups by texture, or material, depending on what suits you, and then call the SetTexture() once per group, followed by a DrawIndexedPrimitive(). This should speed up the rendering significantly. You seem to already have a system of breaking down the terrain into cells, or groups of polygons, and I assume this is so that you arn't rendering the whole terrain every frame, and I think that you can preserve that. Instead of rendering the polygons, just add them to the index list for the correct texture. The DrawIndexedPrimitive() call can pass all the vertices in the terrain (it's just one pointer) but for each call, only pass the index list that corresponds to the appropriate texture.

It makes sense in my head, but maybe I didn't write it clear enough. Let me know what you think.

Also, I am trying to set up a group of people on ICQ that are developing 3d graphics. I could certainly use others advice, and would I think many people are in the same spot...so why not band together (at least on ICQ) and help each other out. My ICQ UIN is 10076314, so please send me a message, and let me know if your intersted.

Hi,

grouping the polygons by textures is not so easy in my engine as you might think
I´m drawing ALL polygons in the radius of the current player position.

e.g: DrawAllInRadius (Player.x, Player.y, Radius15);

This draw all polys in radius of 15.
So it´s difficult to sort polygons in groups
each time a new position is reached!
Any comments or improvements?

-Andrew

------------------
-------------------------
Andrew
Lead Programmer
UNITED BYTES, GERMANY
andy@unitedbytes.de
-------------------------

First thing in that post that sticks out at me is that you seem to be drawing each polygon individually with its own DrawPrimitive and SetTexture calls. This is a horribly inefficient way of doing things. Direct3D will be doing so much state changing I'm surprised you're even getting the frame rade you stated. You should definitely group all polygons with the same surface properties together and render them all in a single call to DrawPrimitive (or DrawIndexedPrimitive). I can give you some ideas for a few ways of doing this.

I. Associate a separate list of polygons/vertices with each unique material in your scene and use two passes when you render. On the first pass you copy the polygons being rendered into the appropriate polygon list and on the second pass you render all the polygon lists. There are a few ways this can be improved to make it more efficient.

II. Simply make your terrain use one big texture. Actually, you could break this texture up evenly into smaller textures so that they can be loaded into memory as needed. This method can solve a couple of little problems. First, all polygons of a single texture will be adjacent to each other, so it will be easy to render them all at the same time. Second, you can take better advantage of indexed drawing since shared vertices will not need separate texture coordinates for different textures.

III. Optimize your terrain database so as to group all polygons of a similar texture. You could then iterate through all the lists when rendering which will result in all similar polygons being rendered together.

Hope I was able to provide you with some ideas to get you going on improving that terrain engine.

Hi there,

I´ve written a landscape-engine with Direct3D. But it´s too slow!! There are
only 800-1000 polys one time on the screen. Not more! How can I speed up the whole thing?
How do Quake or Halflife the rendering?

------------------
-------------------------
Andrew
Lead Programmer
UNITED BYTES, GERMANY
andy@unitedbytes.de
-------------------------

Another possible reason, I see you use big polys and many cards get slower the bigger the polys become. In the radius you draw the polys, it shouldn't be such a big problem to sort them. Just sort all polys in the radius, maybe store them in another small vertex list and render them this way. It's a bit waste of memory, but the engine should become faster.

CU

------------------
Skullpture Entertainment
#40842461