Lets compare terrain engines

Lets compare terrain engines

Post by Vladimir Kajali » Sat, 12 Feb 2000 04:00:00



Hi All.

I have made terrain renderer and want to be sure
that my algorithm is fast enough comparing
with other engines/algorithms.
( I mean ROAM like renderers, quad/bin trees . . . )

I know there are many implementations and
I will be glad if someone also interested in comparing.
If you algorithm has commercial value and you
do not want to publish it you can make a simple demo.
The main problem here is how to create equal conditions
in different demos.

If somebody intrested I can continue my thought.

Vladimir

 
 
 

Lets compare terrain engines

Post by Lucas Ackerma » Sat, 12 Feb 2000 04:00:00



> Hi All.

> I have made terrain renderer and want to be sure
> that my algorithm is fast enough comparing
> with other engines/algorithms.
> ( I mean ROAM like renderers, quad/bin trees . . . )

> I know there are many implementations and
> I will be glad if someone also interested in comparing.
> If you algorithm has commercial value and you
> do not want to publish it you can make a simple demo.
> The main problem here is how to create equal conditions
> in different demos.

> If somebody intrested I can continue my thought.

> Vladimir

hi Vladimir.  you should check out http://www.vterrain.org for a good
comparison of various terrain algorithms and some implimentation specs
and details.  very good site.

fyi, I implimented ROAM for Genesis3D over the summer, my full source et
all is available at  http://www.gameznet.com/genesis/genscape/ if you're
interested.  development is ongoing (it needs lots of extra stuff to
really be useful for a game developer, but the renderer is pretty much
done).  it's pretty fast internally as far as ROAM goes, but the
bottleneck is in the G3D drivers (lots of extra vertex copying and
unnecessary stuff), so making it faster in G3D won't up the frame-rate
(unless i rewrite the G3D drivers, which i am not interested in doing).
i'll eventually port it to OpenGL where I think I can probably make it 2
or 3x faster.  it currently gets roughly 30fps on a p3 500,  128mb ram
(should run well with a lot less), and TNT2 Ultra (v770).  thats on a
512x512 floating-point heightfield, with a 2048x2048 texture (split up
into lots of small 256x256 ones), running with an active mesh of 3000
visible triangles.  if i double the triangle calls made to the driver,
without changing the rest of the work, the fps cuts in half - which
basically shows that the drivers are the bottleneck and it is mainly
geometry-limited.  in normal operation, performance vs triangle-count is
roughly linear.  double tri count, halves the fps, and vice versa.  i
wont know the real limit of my implimentation until i port it to GL and
rewrite a lot of it.

just for kicks, i thought i'd mention that I just got a job working
under Mark Duchaineau (one of the original ROAM authors) for the summer
at LLNL, doing graphics research on supercomputers.  pretty neat!  my
current research is on adapting ROAM for arbitrary geometry and portal
rendering, you can see it here if yr interested:
http://ladrmqp.sourceforge.net/

-Lucas

 
 
 

Lets compare terrain engines

Post by Anders Modé » Sun, 13 Feb 2000 04:00:00


The IRMA algorithm in Gizmo3D can be used for arbitrary geometry. It is
faster than The ROAM algorithm. In version 0.96 you will get 28 bytes per
height value for the internal structure wich gives you a very fast renderer
but that require som extra memory.

In version 0.97 we will problably have a caching system ready for the
terrain to eliminate the memory requirements...

/Anders
http://www.linux3d.net/gizmo3d/



> > Hi All.

> > I have made terrain renderer and want to be sure
> > that my algorithm is fast enough comparing
> > with other engines/algorithms.
> > ( I mean ROAM like renderers, quad/bin trees . . . )

> > I know there are many implementations and
> > I will be glad if someone also interested in comparing.
> > If you algorithm has commercial value and you
> > do not want to publish it you can make a simple demo.
> > The main problem here is how to create equal conditions
> > in different demos.

> > If somebody intrested I can continue my thought.

> > Vladimir

> hi Vladimir.  you should check out http://www.vterrain.org for a good
> comparison of various terrain algorithms and some implimentation specs
> and details.  very good site.

> fyi, I implimented ROAM for Genesis3D over the summer, my full source et
> all is available at  http://www.gameznet.com/genesis/genscape/ if you're
> interested.  development is ongoing (it needs lots of extra stuff to
> really be useful for a game developer, but the renderer is pretty much
> done).  it's pretty fast internally as far as ROAM goes, but the
> bottleneck is in the G3D drivers (lots of extra vertex copying and
> unnecessary stuff), so making it faster in G3D won't up the frame-rate
> (unless i rewrite the G3D drivers, which i am not interested in doing).
> i'll eventually port it to OpenGL where I think I can probably make it 2
> or 3x faster.  it currently gets roughly 30fps on a p3 500,  128mb ram
> (should run well with a lot less), and TNT2 Ultra (v770).  thats on a
> 512x512 floating-point heightfield, with a 2048x2048 texture (split up
> into lots of small 256x256 ones), running with an active mesh of 3000
> visible triangles.  if i double the triangle calls made to the driver,
> without changing the rest of the work, the fps cuts in half - which
> basically shows that the drivers are the bottleneck and it is mainly
> geometry-limited.  in normal operation, performance vs triangle-count is
> roughly linear.  double tri count, halves the fps, and vice versa.  i
> wont know the real limit of my implimentation until i port it to GL and
> rewrite a lot of it.

> just for kicks, i thought i'd mention that I just got a job working
> under Mark Duchaineau (one of the original ROAM authors) for the summer
> at LLNL, doing graphics research on supercomputers.  pretty neat!  my
> current research is on adapting ROAM for arbitrary geometry and portal
> rendering, you can see it here if yr interested:
> http://ladrmqp.sourceforge.net/

> -Lucas

 
 
 

Lets compare terrain engines

Post by Lucas Ackerma » Sun, 13 Feb 2000 04:00:00



> The IRMA algorithm in Gizmo3D can be used for arbitrary geometry. It is
> faster than The ROAM algorithm. In version 0.96 you will get 28 bytes per
> height value for the internal structure wich gives you a very fast renderer
> but that require som extra memory.

> In version 0.97 we will problably have a caching system ready for the
> terrain to eliminate the memory requirements...

> /Anders
> http://www.linux3d.net/gizmo3d/

    Ok Anders, I'm afraid I am going to have to call you on this one.  Time and
time again I have seen you post and talk about "IRMA," and the only conclusion
I can come to is that you do not know what you're talking about.  This is not
meant as a personal attack in any way, I'm sure you are a very nice guy, but we
need to get some facts straight.

Quote:> The IRMA algorithm in Gizmo3D can be used for arbitrary geometry.

    This is a new one - how so?  Could you model a building or a quake-like
level with it?  "arbitrary geometry" does not just mean any heightfield, it
means any geometry.

Quote:> It is faster than The ROAM algorithm.

    Are you still working under the assumption that the original ROAM algorithm
is O(n^2) ?  My implimentation is O(n).  The dual-queue system is certainly not
easy to make fast, but if you have the skills and patience it can really
scream.  I do no sorting of any kind and only a once-thru, linear, top-down
search of the queues each frame.
    I haven't seen IRMA run anything even resembling 'fast.'  It requres sooooo
much memory, that it drags my system to a near-standstill (and my box is no
slouch, 128mb ram should be PLENTY for a fast terrain algorithm).  A normal
ROAM implimentation needs to additionally store only 1 byte/heightfield-element
if you use variance tables (assuming local vertical changes within a
diamond-patch are less than 255).

    Finally, I challenge the assumption that IRMA is ROAM at all.  The whole
point of ROAM is to make the *optimal* mesh update with every split & merge,
which you yourself told me that IRMA does not do because it only considers the
parent & children of each active triangle when making split/merge decisions for
that triangle, instead of choosing the triangle with the most or least error
from the split/merge queues of the entire active mesh triangle set.  This is
clearly *not* optimal, because it only optimizes the mesh with extreme locality
and not globally.

    Please don't take all this the wrong way.  I'm not trying to start a flame
war, I just want to debate your claims.  I've spoken to many people about
terrain engines, and those I know who have seen your work agree that you make a
lot of assumptions which you never back up.
    Your algorithm may very well do certain things better or at least
differently, but noone can tell because it runs very slowly on most people's
systems, and the test-case you provide is terrible.  A repeated
continuously-undulating red&purple parametric surface is *not* "terrain" in any
sense of the word.  It would be a very very poor test of *any* LOD-terrain
algorithm, because it does not show any sharp details near or far, and the
curvature of the surface is continuous.  How can anyone tell how well your
algorithm optimizes the mesh if the mesh looks the same everywhere?  To put it
simply, they can't, and using this as your test case really makes it look very
poor.  I suggest you find some real terrain to test with, be it the Grand
Canyon or Mt. Everest or whatever, so long as it has 1) some flat areas, 2)
areas of sharp high-detail, and 3) clearly shows your algorithm's ability to
optimize the terrain mesh under different viewing conditions.
    I should also suggest that you find a new name for your terrain algorithm,
but this is, of course, up to you.  Calling your system "Improved RoaM
Algorithm", IRMA, only hurts your credibility when nobody can tell if it is
improved or not (because of the poor test case), and because it is obviously
not ROAM to begin with.  Many people borrow some parts of ROAM (like the mesh
structure & split/merge operations), or any algorithm for that matter, but
don't use all of it because it does not completely suit them.  It is fine to do
so, and is very commonly done, but you shouldn't call it ROAM because it isn't.

    Again, this is not meant to be an attack on your person or your skills.  I
just want to help.  If you clarify these issues it will be better for everyone,
yourself included.

-Lucas

 
 
 

Lets compare terrain engines

Post by Vladimir Kajali » Sun, 13 Feb 2000 04:00:00


Quote:> hi Vladimir.  you should check out http://www.vterrain.org for a good

Yes I know this really useful site, but it not compares implementations.
Of course I can try all published implementations but it will take a long
time.
And nobody except author can run it at maximum efficiency.

Quote:> fyi, I implimented ROAM for Genesis3D over the summer, my full source et

I tryed you demo, works ok. But something is not ok.
In my demo when I look in to the sky and no landscape polys in view frustum
I got up to 300fps, but in your demo I got about 80.
( pII333-128-TNT2U )
I think it's not drivers fault.

Quote:> (should run well with a lot less), and TNT2 Ultra (v770).  thats on a
> 512x512 floating-point heightfield, with a 2048x2048 texture (split up
> into lots of small 256x256 ones), running with an active mesh of 3000

I trying 1024x1024 heightfield / 4096x4096 texture now.
(The main problem is how to generate/edit this huge texture)

Quote:> just for kicks, i thought i'd mention that I just got a job working
> under Mark Duchaineau (one of the original ROAM authors) for the summer

cool

Vladimir

 
 
 

Lets compare terrain engines

Post by Lucas Ackerma » Sun, 13 Feb 2000 04:00:00


Quote:> I tryed you demo, works ok. But something is not ok.
> In my demo when I look in to the sky and no landscape polys in view frustum
> I got up to 300fps, but in your demo I got about 80.
> ( pII333-128-TNT2U )
> I think it's not drivers fault.

    what causes this is the framerate display.  the routine used to output the
fps is part of G3D, where you just enable/disable it, but it's very slow.  it's
not part of my code.  each individual character in that display is sent as a
seperate bitmap or polygon (dont remember how exactally it's done), but it is
quite slow.  you can disable it in gstest.exe by pressing 'f' while it is
running.  if you fly over the landscape while doing this, there is quite a
visible speedup.  if you look away from the terrain (like at the sky), and the
fps display is disabled, i think you then get the 300+ fps you should be
getting.  i can't give you hard evidence, because of course with the fps
display disabled you cant get a real fps count, but i've done some test cases
myself which demonstrate that this is what's causing that 80fps framerate
limit.
    here's a little experiment.  look up at the sky, and hold down the 'f' key
so the fps display turns on and off repeatedly (once per frame).  now,
accordingly, the fps counter should say the fps is 1/2 what it used to be,
because it is only measuring every other frame, but takes as many measured
frames into account, which means it takes 20 frames (instead of the 10
measured) for that time to pass.  so the fps counter should be 1/2 right?  but
by turning the fps display on and off, the rendering load is decreased, so the
fps is higher.  on my system, it goes from 100 (with display), to 300 or 400,
with the display flickering.  and that count is 1/2 what it'd be without the
flicker and without display.  rendering nothing, the math works out.
    if you turn on that G3D fps display in _any_ Genesis3D program, it'll hurt
the fps.  especially on something with a high framerate (like looking at an
empty sky), where those characters alone make a big difference.
    in short, its not a problem with the terrain algo, its just a side effect
of using G3D for fps display.

-Lucas

 
 
 

Lets compare terrain engines

Post by J » Mon, 14 Feb 2000 04:00:00


On Sat, 12 Feb 2000 23:12:07 +0200, "Vladimir Kajalin"


>> hi Vladimir.  you should check out http://www.vterrain.org for a good

>Yes I know this really useful site, but it not compares implementations.
>Of course I can try all published implementations but it will take a long
>time.
>And nobody except author can run it at maximum efficiency.

>> fyi, I implimented ROAM for Genesis3D over the summer, my full source et

>I tryed you demo, works ok. But something is not ok.
>In my demo when I look in to the sky and no landscape polys in view frustum
>I got up to 300fps, but in your demo I got about 80.
>( pII333-128-TNT2U )
>I think it's not drivers fault.

Sounds like your limited to the refresh rate of your monitor (80Hz).
It would be interesting to see if Lucas uses more than one back
buffer, or if the FPS follows your refresh rate.

-jason

 
 
 

Lets compare terrain engines

Post by Anders Modé » Mon, 14 Feb 2000 04:00:00


Ohh ! That hurt !

Sorry if I offended you by stating some things about the algorithm....

Now for some answers.

I have been working with the algorithm since the last time you said it
sucks. I know the previous version required A LOT of memory. The intention
was only to show how the algorithm works. I beleive it required about 80
bytes per height field value. (Sorry for this once more). The current
version requires 28 bytes so there is a little performance gain there. Newer
versions will use disk caching to cope with memory requirements.

Now back to some other facts. The ROAM algorithm as far I understand ( I
must tell you I am no pro on this one.) require you to do a time consuming
split/merge queue sorting. This is the part I have removed in the algo. The
algo contains links between different patches that makes the sorting on the
fly. Even if I do the compare locally, I know there is nothing outside the
local interest that affects the merge/split ( because of the linking
hierarchy is always properly sorted ). Therefore I claim that I am able to
do the ROAM (perhaps look alike) split/merge without queue sorting.

Bad Examples !
Yes again I must agree with you. The examples you have seen is continous
height fields. These are not good to measure the performance of the
algorithm. I must explain to you that the example in the dist is there to
show how easy it is to do your own height field presenter. Not to perform
benchmarks on.

I have a small sample written by another person that shows a DEM map
presented instead. This is however not written by me so I can not distribute
the source code. I will hower take some time to write my own heighfield
loader and show you some samples.

The thing I stated about arbitrary geometry is still true. the
gzParametricGeometry is clearly a base class for parametric surfaces. As
long as you can define surfaces as parametric one, you can use the
gzParametricGeometry class. My assumption when I said arbitrary geometry is
that most surfaces can be a defined as parametric surfaces ( Nurbs, bezier
etc..). Even if two paches are used to glue non continious surfaces
together, the algo take care of this. Multiple non continious paches can be
"patched" together to form a surface...

Lukas! Again I must appologize if I offended you like this in public by
stating some of my believes about my algorithm !

/Anders



> > The IRMA algorithm in Gizmo3D can be used for arbitrary geometry. It is
> > faster than The ROAM algorithm. In version 0.96 you will get 28 bytes
per
> > height value for the internal structure wich gives you a very fast
renderer
> > but that require som extra memory.

> > In version 0.97 we will problably have a caching system ready for the
> > terrain to eliminate the memory requirements...

> > /Anders
> > http://www.linux3d.net/gizmo3d/

>     Ok Anders, I'm afraid I am going to have to call you on this one.
Time and
> time again I have seen you post and talk about "IRMA," and the only
conclusion
> I can come to is that you do not know what you're talking about.  This is
not
> meant as a personal attack in any way, I'm sure you are a very nice guy,
but we
> need to get some facts straight.

> > The IRMA algorithm in Gizmo3D can be used for arbitrary geometry.

>     This is a new one - how so?  Could you model a building or a
quake-like
> level with it?  "arbitrary geometry" does not just mean any heightfield,
it
> means any geometry.

> > It is faster than The ROAM algorithm.

>     Are you still working under the assumption that the original ROAM
algorithm
> is O(n^2) ?  My implimentation is O(n).  The dual-queue system is
certainly not
> easy to make fast, but if you have the skills and patience it can really
> scream.  I do no sorting of any kind and only a once-thru, linear,
top-down
> search of the queues each frame.
>     I haven't seen IRMA run anything even resembling 'fast.'  It requres
sooooo
> much memory, that it drags my system to a near-standstill (and my box is
no
> slouch, 128mb ram should be PLENTY for a fast terrain algorithm).  A
normal
> ROAM implimentation needs to additionally store only 1

byte/heightfield-element

- Show quoted text -

Quote:> if you use variance tables (assuming local vertical changes within a
> diamond-patch are less than 255).

>     Finally, I challenge the assumption that IRMA is ROAM at all.  The
whole
> point of ROAM is to make the *optimal* mesh update with every split &
merge,
> which you yourself told me that IRMA does not do because it only considers
the
> parent & children of each active triangle when making split/merge
decisions for
> that triangle, instead of choosing the triangle with the most or least
error
> from the split/merge queues of the entire active mesh triangle set.  This
is
> clearly *not* optimal, because it only optimizes the mesh with extreme
locality
> and not globally.

>     Please don't take all this the wrong way.  I'm not trying to start a
flame
> war, I just want to debate your claims.  I've spoken to many people about
> terrain engines, and those I know who have seen your work agree that you
make a
> lot of assumptions which you never back up.
>     Your algorithm may very well do certain things better or at least
> differently, but noone can tell because it runs very slowly on most
people's
> systems, and the test-case you provide is terrible.  A repeated
> continuously-undulating red&purple parametric surface is *not* "terrain"
in any
> sense of the word.  It would be a very very poor test of *any* LOD-terrain
> algorithm, because it does not show any sharp details near or far, and the
> curvature of the surface is continuous.  How can anyone tell how well your
> algorithm optimizes the mesh if the mesh looks the same everywhere?  To
put it
> simply, they can't, and using this as your test case really makes it look
very
> poor.  I suggest you find some real terrain to test with, be it the Grand
> Canyon or Mt. Everest or whatever, so long as it has 1) some flat areas,
2)
> areas of sharp high-detail, and 3) clearly shows your algorithm's ability
to
> optimize the terrain mesh under different viewing conditions.
>     I should also suggest that you find a new name for your terrain
algorithm,
> but this is, of course, up to you.  Calling your system "Improved RoaM
> Algorithm", IRMA, only hurts your credibility when nobody can tell if it
is
> improved or not (because of the poor test case), and because it is
obviously
> not ROAM to begin with.  Many people borrow some parts of ROAM (like the
mesh
> structure & split/merge operations), or any algorithm for that matter, but
> don't use all of it because it does not completely suit them.  It is fine
to do
> so, and is very commonly done, but you shouldn't call it ROAM because it
isn't.

>     Again, this is not meant to be an attack on your person or your
skills.  I
> just want to help.  If you clarify these issues it will be better for
everyone,
> yourself included.

> -Lucas

 
 
 

Lets compare terrain engines

Post by Vladimir Kajali » Tue, 15 Feb 2000 04:00:00


Hello Anders.

I see you have a very big experience in ROAM like programming.
Can you point me to any realy fast implementation of terrain engine ?
I do not need sources, I only want to see something faster than my engine.
Or can I send to you my demo and you will tell me what you think.

Vladimir

 
 
 

Lets compare terrain engines

Post by Aelit » Wed, 16 Feb 2000 04:00:00




Quote:> Hello Anders.

> I see you have a very big experience in ROAM like programming.
> Can you point me to any realy fast implementation of terrain engine ?
> I do not need sources, I only want to see something faster than my
> engine.

Speed isn't all that important - what matters is quality at an
acceptable framerate.  Being able to render more triangles per second
helps of course - but being able to render more important triangles
helps as well.

What looks better, 10,000 triangles with no LOD whatsoever or 3,000
triangles with block-based simplification or 1,000 triangles with
vertex-simplification?  Thats the question - concerning triangles at
least.

I don't do vertex based LOD yet - I use block based refinement and it
works fine and I really doubt if the per vertex priority calculation
and the loss of large triangle strips actually outweight the decreased
per vertex error.

Per vertex LOD surely creates better triangles (perhaps twice as good
according to Hughe Hoppe), but if it cuts my triangle output in half -
it is a poor decision - it will actually reduce quality.

I am currently running about 30,000 triangles at 30fps and it looks
great - mountains looked curved - I have no need for per vertex LOD
right now.

I don't simplify an initial grid either - I generate my grid on the fly
from a fractal model - so my system is a little different.

As far as speed of the actual run-time priority management system - I
haven't even clocked it yet - but it doesn't seem to be taking up much
time.  I use two priority ques right now - a minheap for splits and a
maxheap for merges - it reorders the whole heap every frame - but thats
fast because my heaps are small - they contain whole blocks and not
individual vertices (between 200-1500 blocks, depending on available
texture memory and block texture size).  Reordering these heaps takes O
(n) time and is fast in practice because it doesn't use pointers -
simple shifts and adds move up and down the tree.

So in the end, quadtree block LOD is far better - easier to program and
faster.  Plus it allows texture LOD - I simply create a unique texture
for each quadtree block - you can't do that with a TIN or vertex
splitting model.  Texture LOD is as, if not *more* important than
vertex LOD.  It allows high quality (ray-tracing quality) per pixel
lighting, infinite detail with fractal/procedural textures, etc.

So quadtrees are the optimal solution.

Quote:> Or can I send to you my demo and you will tell me what you think.

> Vladimir

--
-Aelith

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Lets compare terrain engines

Post by Vladimir Kajali » Wed, 16 Feb 2000 04:00:00


Quote:> 20,000 vertices - which is 30,000 triangles.  I am not using triangle

It's very fast for continous LOD.
Can you show a demo of you engine?

Vladimir

 
 
 

Lets compare terrain engines

Post by Aelit » Thu, 17 Feb 2000 04:00:00




Quote:> > 20,000 vertices - which is 30,000 triangles.  I am not using
triangle

> It's very fast for continous LOD.
> Can you show a demo of you engine?

> Vladimir

I still have alot of work to do before I am ready to show off a demo.
There are still some slight edge cracking problems, I need to work on
color textures, and most importantly - I need to do alot of
optimization.

Right now it is spending half of its time optimizing the scene each
frame, which leaves only half of the CPU time for displaying vertices.
(when the scene is fully optimized the frame rate goes up as a
result).  Thats fine, but I am not even creating color textures yet,
just a height map and then a light map from that.  I need to create a
couple of color textures as well, and thus I must optimize to squeeze
that into the same time frame.

The vertex and texture popping artifacts are also pretty unpleasant - I
would need to clean those up before I release a demo.

I am thinking of fixing up these problems and then releasing
screenshots and a simple demo by the end of the month.  The simple demo
will not allow arbitrary camera motion - it will just pan the view at a
fixed rate.

Then later on, after optimization and geomorph and texturemorphs, I
could release a demo allowing you to fly or run around the landscape
(it does that right now, but I don't want the progressive scene
optimization to be so obvious - in fact, I wouldn't want it to be
noticeable at all).

I wouldn't want to show it off before its ready.

--
-Aelith

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Lets compare terrain engines

Post by Marc Hernand » Tue, 22 Feb 2000 04:00:00


: > I have made terrain renderer and want to be sure
: > that my algorithm is fast enough comparing
: > with other engines/algorithms.
: > ( I mean ROAM like renderers, quad/bin trees . . . )

        I also implemented ROAM but I have since dropped it.  I now have
fixed sized plates at which I do different levels of detail depending on
distance or somesuch.  
        I am getting 60-80 fps (60 is worse-case) on an Athlon 550 TNT2.  
It should be around 2.5 million triangles per second on that processor or
~48000 triangles per frame.
        It supports dynamic terrain modification and arbitrary meshes on
the plate (for say dungeon entrances or such with dynamic LOD on those
also).  Streaming from disk will be fairly as it is sector based.
        I can bias the LOD down a level and get even more speedup on
slower machine.  I also have another LOD level to implement.  I
dynamically strip the outer plates into bigger areas for efficient
processing.  
        It does pop a bit currently.  I have a simple arcade game I am
implemented around it that I will be releasing soon.

: i'll eventually port it to OpenGL where I think I can probably make it 2
: or 3x faster.  it currently gets roughly 30fps on a p3 500,  128mb ram
: (should run well with a lot less), and TNT2 Ultra (v770).  thats on a
: 512x512 floating-point heightfield, with a 2048x2048 texture (split up
: into lots of small 256x256 ones), running with an active mesh of 3000
: visible triangles.  if i double the triangle calls made to the driver,
: without changing the rest of the work, the fps cuts in half - which
: basically shows that the drivers are the bottleneck and it is mainly
: geometry-limited.  in normal operation, performance vs triangle-count is
: roughly linear.  double tri count, halves the fps, and vice versa.  i
: wont know the real limit of my implimentation until i port it to GL and
: rewrite a lot of it.

 
 
 

Lets compare terrain engines

Post by Vladimir Kajali » Tue, 22 Feb 2000 04:00:00


Hi Marc.

Quote:> It does pop a bit currently.  I have a simple arcade game I am
> implemented around it that I will be releasing soon.

Can you show me a demo of your terrain renderer now ? (not while game)

Quote:> It should be around 2.5 million triangles per second on that processor or

I have 200 000 triangles per second, but never seen something faster.

Vladimir