Hello,
I've been looking at options for displaying large terrains quickly and
efficiently, and come across some performance data that is the reverse of
what I would expect.
I've looked at

1) Immediate mode glBegin, glVertex etc
2) Immediate mode with arrays glVertexPointer, glDrawElements etc
3) VBO objects, glBindBufferARB etc


VBOs (3) seems to be incredibly slow, whereas (1) seems slightly faster
than (2) - this is completely reverse behaviour than what I've always been
led to believe! (should be slower->123->faster surely?)

I've ruled out how I use glEnableClientState() - I get the same bahaviour
whether I turn it on for the terrains polygons, or leave it on all the time.
All my data is aligned as floats or doubles.
I'm at a complete loss as to what's going on.


if (file->use_vbo)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB,file->vxbuffers[BUFFER_VERTEX]);
glVertexPointer(3,GL_DOUBLE,0,NULL);
if (texture)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB,file->vxbuffers[BUFFER_UV]);
glTexCoordPointer(2,GL_FLOAT,0,NULL);
}

}
else
{
glVertexPointer(3,GL_DOUBLE,0,file->vertex_buffer.Items());
if (texture)
glTexCoordPointer(2,GL_FLOAT,0,file->uv_buffer.Items());
}

unsigned int *inx=...
glDrawElements(mode,count,GL_UNSIGNED_INT,inx);

"Makhno" <root@127.0.0.1> wrote in message 
news:yJudnaeSXph97E_ZRVnysw@bt.com...
> Hello,
> I've been looking at options for displaying large terrains quickly and
> efficiently, and come across some performance data that is the reverse of
> what I would expect.
> I've looked at
>
> 1) Immediate mode glBegin, glVertex etc
> 2) Immediate mode with arrays glVertexPointer, glDrawElements etc
> 3) VBO objects, glBindBufferARB etc
>
>
> VBOs (3) seems to be incredibly slow, whereas (1) seems slightly faster
> than (2) - this is completely reverse behaviour than what I've always been
> led to believe! (should be slower->123->faster surely?)
>
> I've ruled out how I use glEnableClientState() - I get the same bahaviour
> whether I turn it on for the terrains polygons, or leave it on all the 
> time.
> All my data is aligned as floats or doubles.
> I'm at a complete loss as to what's going on.
>
>
> if (file->use_vbo)
> {
> glBindBufferARB(GL_ARRAY_BUFFER_ARB,file->vxbuffers[BUFFER_VERTEX]);
> glVertexPointer(3,GL_DOUBLE,0,NULL);
> if (texture)
> {
> glBindBufferARB(GL_ARRAY_BUFFER_ARB,file->vxbuffers[BUFFER_UV]);
> glTexCoordPointer(2,GL_FLOAT,0,NULL);
> }
>
> }
> else
> {
> glVertexPointer(3,GL_DOUBLE,0,file->vertex_buffer.Items());
> if (texture)
> glTexCoordPointer(2,GL_FLOAT,0,file->uv_buffer.Items());
> }
>
> unsigned int *inx=...
> glDrawElements(mode,count,GL_UNSIGNED_INT,inx);
>
>
>
>


>
>
>

It's very possible that 1 can be faster...It can well be faster than a naive 
2, which doesn't have the correct async control unless you use the "VAR & 
fence" extensions. (GL_NV_vertex_array_range and GL_NV_fence)
[http://www.delphi3d.net/articles/viewarticle.php?article=varfence.htm]

Some off the cuff ideas;

  0) are you sure that you are accurately timing OpenGL ? That is, are you 
taking a average draw rate over a fairly large number of frames ?

 1) How do you build the VBO's ? 
(glBufferDataARB(... --->GL_STATIC_DRAW_ARB<---) , I hope ? Or memory-mapped 
?
Are you *sure* you aren't loading the buffer into VRAM every draw time ?

 2) Try #1 and #2 with Display Lists just for laughs. They could be 10x 
faster that way. Not that that explains (3).
       But, if (1) in a display list is slower, or not much faster, then you 
probably aren't geometry limited at all, but rather fill- or texture-fetch- 
rate limited, in which case vertex acceleration methods won't help you much.

  3) try floats for coordinates. Doubles are a waste of memory and may be 
the root cause of the problem. It's unlikely that your card internally does 
doubles anyway. Since you only build the VBO's once (right?), a CPU convert 
to floats is just a one-time hit.

-jbw 

> It's very possible that 1 can be faster...It can well be faster than a
> naive 2, which doesn't have the correct async control unless you use the
> "VAR & fence" extensions. (GL_NV_vertex_array_range and GL_NV_fence)

Radeon 9000 card.

> Some off the cuff ideas;
>
>  0) are you sure that you are accurately timing OpenGL ?

I can count seconds between the frames with my VBO implementation. I do not
need to time it to know it's slow.

> 1) How do you build the VBO's ?
> (glBufferDataARB(... --->GL_STATIC_DRAW_ARB<---) , I hope ? Or
> memory-mapped ?


> Are you *sure* you aren't loading the buffer into VRAM every draw time ?

Quite sure.

> 2) Try #1 and #2 with Display Lists just for laughs. They could be 10x
> faster that way. Not that that explains (3).

I will.

>       But, if (1) in a display list is slower, or not much faster, then
> you probably aren't geometry limited at all, but rather fill- or
> texture-fetch- rate limited, in which case vertex acceleration methods
> won't help you much.

Is it possible it is something to do with glDrawElements being called for
each triangle?

>  3) try floats for coordinates.

It appears you are correct, using floats does indeed speed up the VBO until 
it is at least as fast as (1) was, possibly faster.

I'm using doubles because I hope that some day graphics cards will truly use
64-bit doubles. For certain applications this is needed as single-precision
float become quite inaccurate at 100km or so.

Does anybody know of any new cards that use doubles? For verticies as well 
as depth buffer?

Makhno wrote:
> glVertexPointer(3,GL_DOUBLE,0,NULL);
> 

"double"? There's your problem. The hardware
can't work with doubles so the driver has
to do something horrible to get arrays to
work. Converting doubles to floats in
immediate mode is cheap by comparison.



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

"Makhno" <root@127.0.0.1> wrote in message 
news:BPCdnfmuI_3AC0_ZRVnyhQ@bt.com...
>> It's very possible that 1 can be faster...It can well be faster than a
>> naive 2, which doesn't have the correct async control unless you use the
>> "VAR & fence" extensions. (GL_NV_vertex_array_range and GL_NV_fence)
>
> Radeon 9000 card.
>
>> Some off the cuff ideas;
>>
>>  0) are you sure that you are accurately timing OpenGL ?
>
> I can count seconds between the frames with my VBO implementation. I do 
> not
> need to time it to know it's slow.
>
>> 1) How do you build the VBO's ?
>> (glBufferDataARB(... --->GL_STATIC_DRAW_ARB<---) , I hope ? Or
>> memory-mapped ?
>
>
>> Are you *sure* you aren't loading the buffer into VRAM every draw time ?
>
> Quite sure.
>
>> 2) Try #1 and #2 with Display Lists just for laughs. They could be 10x
>> faster that way. Not that that explains (3).
>
> I will.


Still might be interesting to see even tho the VBO problem is solved...


>
>>       But, if (1) in a display list is slower, or not much faster, then
>> you probably aren't geometry limited at all, but rather fill- or
>> texture-fetch- rate limited, in which case vertex acceleration methods
>> won't help you much.
>
> Is it possible it is something to do with glDrawElements being called for
> each triangle?


  That would be a heck yes. Immediate mode is faster than doing that!


>
>>  3) try floats for coordinates.
>
> It appears you are correct, using floats does indeed speed up the VBO 
> until it is at least as fast as (1) was, possibly faster.
>

  aha.


> I'm using doubles because I hope that some day graphics cards will truly 
> use
> 64-bit doubles. For certain applications this is needed as 
> single-precision
> float become quite inaccurate at 100km or so.

Well, maybe so, but consumer graphics cards won't be doing that soon, so you 
need to refactor your app.
24-bit fixed point depth buffer seems to be pretty entrenched at this point. 
Don't need more for games, so,
don't bet on a game card having more any time.

>
> Does anybody know of any new cards that use doubles? For verticies as well 
> as depth buffer?
>
>
> 

>>> 2) Try #1 and #2 with Display Lists just for laughs. They could be 10x
>>> faster that way. Not that that explains (3).
>>
>> I will.
>
> Still might be interesting to see even tho the VBO problem is solved...

I will try an have a look, but architecturally, it a hard thing to do as my
terrain is a scene graph with multiple LoDs; At what level in the hierarchy
should I turn commands into lists?

>> Is it possible it is something to do with glDrawElements being called for
>> each triangle?
>
>  That would be a heck yes. Immediate mode is faster than doing that!

Unfortunately, each triangle could potentially have a different texture and
other settings (colour, material, culling, depth bias etc), which makes it
difficult to get any command to draw more than one triangle at a time.

Now I'm using floats, VBO are noticeably faster, but not considerably, than
immediate mode.

>> I'm using doubles because I hope that some day graphics cards will truly
>> use 64-bit doubles. For certain applications this is needed as
>> single-precision float become quite inaccurate at 100km or so.
>
> Well, maybe so, but consumer graphics cards won't be doing that soon, so
> you need to refactor your app.
> 24-bit fixed point depth buffer seems to be pretty entrenched at this
> point. Don't need more for games, so, don't bet on a game card having more
> any time.

Which is annoying, as even if the card was x4 expensive, we'd still buy it
if it natively handled doubles, as it would solve a lot of our problems with
large terrain areas.

Thansk for your help - my previous reply was a little peeved as I had been
up to 2am figuring out my VBO problem.

>>>> 2) Try #1 and #2 with Display Lists just for laughs. They could
>>>> be 10x faster that way.

Though they appear to be running slightly faster once compiled, the actual 
compilation slows the application down, and there's no way I can do this in 
advance due to the size of the terrain.

Moving slowly across the terrain helps a bit, but this would sacrifice my 
engine's capability for marginal (if any) performance gain. 

Makhno wrote:
>
> I will try an have a look, but architecturally, it a hard thing to do as my
> terrain is a scene graph with multiple LoDs;
> 

LODs are _almost_ a waste of time on modern cards
- most cards can now process a triangle per clock
cycle which is usually much more then the rasterizer
can handle (ie. the bottleneck isn't vertices)

It might be worth it for really big terrains which
page to/from disk but with well organized VBOs the
number of triangles is pretty much irrelevant. The
latest cards will handle hundreds of millions of
triangles per second, no problem.


> Which is annoying, as even if the card was x4 expensive, we'd still buy it
> if it natively handled doubles, as it would solve a lot of our problems with
> large terrain areas.
> 

I don't think that's going to happen any time soon.
Floats are good enough for 3D graphics and switching
to doubles would eat up an awful lot of silicon.

If you're having accuracy problems on big terrains
you need to chop the terrain up into tiles, translate
each tile to the origin, then put an inverse transform
into the modelview matrix when you render the tile.
This will fix any problems with floating point
precision. The tiles also come in handy for culling.



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
> Though they appear to be running slightly faster once compiled, the actual 
> compilation slows the application down, and there's no way I can do this in 
> advance due to the size of the terrain.
> 
> Moving slowly across the terrain helps a bit, but this would sacrifice my 
> engine's capability for marginal (if any) performance gain. 
> 

Sounds like you're moving into the sort of areas
that big machines are designed to handle but PCs
are bad at.

If your terrain is paging to disk then you need
to allocate each level of detail in a separate
address space in shared memory. Then you need
a second process which tracks the position of
the viewer and guesses which bits of memory
are going to be needed "soon" and touch them
so they get paged in. This stops judders in
the main process.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

>> Moving slowly across the terrain helps a bit, but this would sacrifice my 
>> engine's capability for marginal (if any) performance gain.
>
> If your terrain is paging to disk then you need
> to allocate each level of detail in a separate
> address space in shared memory.

It's not paging - all verticies from the entire world are loaded into VBOs.
It is drawing only what the viewer sees, and placing into displays lists 
those things he is about to see (takes too long to put the whole world into 
a display list).

> Then you need
> a second process which tracks the position of
> the viewer and guesses which bits of memory
> are going to be needed "soon" and touch them
> so they get paged in. This stops judders in
> the main process.

The 'paging' in this case appears the be the construction of the display 
list, which a second thread will not help. 

>> I will try an have a look, but architecturally, it a hard thing to do as 
>> my
>> terrain is a scene graph with multiple LoDs;
>>
>
> LODs are _almost_ a waste of time on modern cards
> - most cards can now process a triangle per clock
> cycle which is usually much more then the rasterizer
> can handle (ie. the bottleneck isn't vertices)

Sorry but that is completely wrong. Perhap you misunderstood what LOD is? 
Replacing part of the scene with a simpler version when it is a long way 
away will very much increase performance.

> It might be worth it for really big terrains which
> page to/from disk but with well organized VBOs the
> number of triangles is pretty much irrelevant.

I'd like to think so too, but my card says otherwise.

> If you're having accuracy problems on big terrains
> you need to chop the terrain up into tiles, translate
> each tile to the origin, then put an inverse transform
> into the modelview matrix when you render the tile.
> This will fix any problems with floating point
> precision. The tiles also come in handy for culling.

Depends how this is implemented. The coordinates of the viewer would have to 
be constantly adjusted to be relative to the tile being observed for this to 
work. Not a big deal (I already do that) but what if the viewer is sitting 
across two tiles?

Makhno wrote:
> Perhap you misunderstood what LOD is? 

No, I know what Level Of Detail is.

>> It might be worth it for really big terrains which
>> page to/from disk but with well organized VBOs the
>> number of triangles is pretty much irrelevant.
> 
> I'd like to think so too, but my card says otherwise.
> 

What card is it?


>> This will fix any problems with floating point
>> precision. The tiles also come in handy for culling.
> 
> Depends how this is implemented. The coordinates of the viewer would have to 
> be constantly adjusted to be relative to the tile being observed for this to 
> work. Not a big deal (I already do that) but what if the viewer is sitting 
> across two tiles?
> 

No, the viewer position is always in world
coordinates (usually stored as doubles) ,only
the terrain tiles have a local coordinate system
to avoid accuracy problems when rendering.

The idea is that when you get close to a terrain
tile the translation in the tile coordinate system
cancels out the translation due to the viewer's
position. The net result is small numbers going
down the graphics pipeline.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
> It's not paging - all verticies from the entire world are loaded into VBOs.
> It is drawing only what the viewer sees, and placing into displays lists 
> those things he is about to see (takes too long to put the whole world into 
> a display list).
> 

I hope you're not creating display lists from
your VBOs.... that would defeat the purpose of
making VBOs in the first place.

PS: If you're only going to use one thing, use
VBOs. Display lists are ok for a quick hack but
VBOs are more rewarding in the long term.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

> I hope you're not creating display lists from
> your VBOs.... that would defeat the purpose of
> making VBOs in the first place.

That was what I was doing - I was under the impression that's what jbwest
was requesting I do. Specifically, the glDrawElements calls are placed in
display lists (as well as texture switches etc).

Seems to work anyway - except the compile times are too long.

> PS: If you're only going to use one thing, use
> VBOs. Display lists are ok for a quick hack but
> VBOs are more rewarding in the long term.

Personally, I found VBOs easier to use from a coding perspective. Plus I can
just 'throw money at the problem' to solve it - I noticed a 1Gb graphics
card on ebuyer, which can be used SLI.

> What card is it?

Currently using Radeon 9000, because that's what's on my laptop. But there's
no upper limit for the final product, because in the final application both
the processor and graphics card will be stressed.

> No, the viewer position is always in world
> coordinates (usually stored as doubles) ,only
> the terrain tiles have a local coordinate system
> to avoid accuracy problems when rendering.

If the viewer and the world are in different coordinate systems, how can
they interact?

> The idea is that when you get close to a terrain
> tile the translation in the tile coordinate system
> cancels out the translation due to the viewer's
> position. The net result is small numbers going
> down the graphics pipeline.

The errors on two large floating point numbers do not cancel. That's the
whole problem.

Suggest you render a small model, at put it a long way from the origin, say
500e3, using a translation matrix, as you suggested.
Place a camera next to it, and then move them both along an axis. You will
find the model appears to vibrate. This is entirely due to floating point
errors in the graphics card, or somewhere on the way to it.

Makhno wrote:
> I can just 'throw money at the problem' to
 > solve it - I noticed a 1Gb graphics
> card on ebuyer, which can be used SLI.
> 

In that case get yourself one of these:

http://www.nvidia.com/page/quadroplex.html


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
>> What card is it?
> 
> Currently using Radeon 9000, because that's
 > what's on my laptop.

Well there you go...you can't compare an old
laptop card with a new graphics card. On the
newest cards the vertex transforms are basically
free.

> If the viewer and the world are in different coordinate systems, how can
> they interact?
> 

That's up to you - the wage earning programmer...  :-)

>> The idea is that when you get close to a terrain
>> tile the translation in the tile coordinate system
>> cancels out the translation due to the viewer's
>> position. The net result is small numbers going
>> down the graphics pipeline.
> 
> The errors on two large floating point numbers
 > do not cancel.

The point is that there's no errors to cancel
when you do it that way.

> Suggest you render a small model, at put it a long way from the origin, say
> 500e3, using a translation matrix, as you suggested.

Ok.

> Place a camera next to it

....and when you combine the model translation
matrix with the camera translation matrix the
two big translations will cancel out and you'll
be left with a *small* translation.

> You will find the model appears to vibrate.

Have you actually tried it?  I have...

PS: You might have to do the matrix thing in
double precision on the main CPU.

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

fungus

can you point me to a place where I can find a cg program that does
terrain on the gpu? My present LOD pops and all that and I want to
dump it as soon as possible.

thanks

joe

On Fri, 04 Aug 2006 03:10:18 +0200, fungus <umailMY@SOCKSartlum.com>
wrote:

>Makhno wrote:
>> glVertexPointer(3,GL_DOUBLE,0,NULL);
>> 
>
>"double"? There's your problem. The hardware
>can't work with doubles so the driver has
>to do something horrible to get arrays to
>work. Converting doubles to floats in
>immediate mode is cheap by comparison.

"Makhno" <root@127.0.0.1> wrote in message 
news:w_OdnYBQP79oO07ZRVnyrQ@bt.com...
>> I hope you're not creating display lists from
>> your VBOs.... that would defeat the purpose of
>> making VBOs in the first place.
>
> That was what I was doing - I was under the impression that's what jbwest
> was requesting I do. Specifically, the glDrawElements calls are placed in
> display lists (as well as texture switches etc).
>
> Seems to work anyway - except the compile times are too long.
>
>> PS: If you're only going to use one thing, use
>> VBOs. Display lists are ok for a quick hack but
>> VBOs are more rewarding in the long term.
>
> Personally, I found VBOs easier to use from a coding perspective. Plus I 
> can
> just 'throw money at the problem' to solve it - I noticed a 1Gb graphics
> card on ebuyer, which can be used SLI.
>
>
>
>
>

 I meant that since your immediate mode stuff was faster than VBO's, to put 
the immediate mode inside a display list.
By immediate mode I meant glBegin...glEnd, not a one-triangle-per 
glDrawElements.

But, since VBO's are now running about as fast as immediate mode +/-, you 
may not see much of an improvement, although you might as a VBO only +/- as 
fast as immediat emode indicates a problem,
Display Lists certainly do have disadvatages of compile time and added 
memory load. (although VBO's do too, to some extent), but they can be 
dramatically faster sometimes when you can't use VBO's effectively.  You can 
maybe avoid some memory load by using mapped VBO's

-jbwest

> In that case get yourself one of these:
>
> http://www.nvidia.com/page/quadroplex.html

Not that much money. Anyway, after some bad experience with dodgy drivers on
this extreme high-end stuff, I've decided that off-the-shelf is better. Tend
not to find bugs in some lesser-used OpenGL areas, like eg Select Buffers.

>> Currently using Radeon 9000, because that's
> > what's on my laptop.
>
> Well there you go...you can't compare an old
> laptop card with a new graphics card. On the
> newest cards the vertex transforms are basically
> free.

Well, I'll give it a go, but excuse me for being sceptical about free
performance.

>> The errors on two large floating point numbers
> > do not cancel.

In one dimension, the object is at coordinate x whereas the viewer is at
x+1. On floating point numbers with limited precision, it is not always the
case that

(x+1) - (x) = 1    when x is large.

It will be a number around one, or in the worst case 0.

So a camera viewing an object at one meter away will appear to be vibrating
(or the object will).

>> Suggest you render a small model, at put it a long way from the origin,
>> say 500e3, using a translation matrix, as you suggested.
>> Place a camera next to it
>
> ...and when you combine the model translation
> matrix with the camera translation matrix the
> two big translations will cancel out and you'll
> be left with a *small* translation.

How so? The point is that this small left-over translation is corrupted.

>> You will find the model appears to vibrate.
>Have you actually tried it?  I have...

As have I. If yours did not vibrate, then either you did it wrong or I want
to know the name of your graphics card.

> PS: You might have to do the matrix thing in
> double precision on the main CPU.

What you're suggesting is similar what I said earlier - in the above
example, rather than taking the (x+1) and the (x) and letting the graphics
card work them out, you are either

1) identifying the equation and removing the x's from it (my suggestion)
2) doing it in double precision on the CPU (your suggestion)

(2) appears to defeat the objective of having a graphics card in the first
place, whereas (1) is quite complex if consider that the terrain consists of
multiple tiles each positioned with its own transform. In addition to
shifting the viewer's coordinates by the inverse transform of the closest
tiles' coordinates, we would also have to work out the other tiles
transformations into the viewers (and the closest tiles') coordinate system.
Besides from being complex, it could affect performance too.
Not saying its impossible - but difficult, with diminishing returns.

If graphics cards did 64-bit at least for vertices, this problem would go
away - until we start modelling spacecraft in the solar system in a
coordinate system centered on the Sun.....

> I meant that since your immediate mode stuff was faster than VBO's,
> to put the immediate mode inside a display list.
> By immediate mode I meant glBegin...glEnd, not a one-triangle-per
> glDrawElements.

Ok, but I think VBOs are the fastest, and as fungus suggests, I will try it
on a more recent machine, perhaps that will bring out the difference more
clearly.

> Display Lists certainly do have disadvatages of compile time and added
> memory load. (although VBO's do too, to some extent),

My VBOs load 10s of mb of vertices in no time at all. It's definately using
the graphics card because I delete them from memory afterwards.

> but they can be dramatically faster sometimes when you can't use VBO's
> effectively.
> You can maybe avoid some memory load by using mapped VBO's

What is a mapped VBO?

fungus wrote:

> PS: You might have to do the matrix thing in
> double precision on the main CPU.

The worst thing that can happen is, that moving the camera will
result in a jittering view, but no holes in the geometry and
such stuff.

But if you're a smart guy, you don't store a huge terrain in a
large heightfield anyway, virtual address space on 32 bit
platforms is 2GiB, so you will tile anyway to not waste precious
RAM. Make the tiles dimensions so that their borders match whole
numbers (i.e. integers) in the terrain coordinate system. That
way you can enumerate tiles error free (integers have no error
like floating point numbers). Each tile has it's own origin to
which it's faces are related to. Upon rendering you perform a
major transformation for each tile and you put it that way, that
the closest tile will be closest to the global origin (in terms
of transformation). That way the view-part of the modelview
transformation will always be small compared to the rest of the
world so that the jitter in camera movement is neglectible.

Wolfgang Draxinger
-- 

Makhno wrote:
> it is not always the case that
> 
> (x+1) - (x) = 1    when x is large.
> 

Correct, that's why I'm proposing you rearrange
it to this:

(x - x) + 1



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
> 
> Ok, but I think VBOs are the fastest, and as fungus suggests, I will try it
> on a more recent machine, perhaps that will bring out the difference more
> clearly.
> 

You might like to watch the third video on this page:

http://www.ati.com/developer/gdc_video.html


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

> Make the tiles dimensions so that their borders match whole
> numbers (i.e. integers) in the terrain coordinate system. That
> way you can enumerate tiles error free (integers have no error
> like floating point numbers).

They are converted to floating point numbers inside the card. This does not
help!

> Each tile has it's own origin to
> which it's faces are related to. Upon rendering you perform a
> major transformation for each tile and you put it that way,

The tiles are not simply translated, there is a matrix involved. The Earth
is curved.

Makhno wrote:

>> I meant that since your immediate mode stuff was faster than VBO's,
>> to put the immediate mode inside a display list.
>> By immediate mode I meant glBegin...glEnd, not a one-triangle-per
>> glDrawElements.
> 
> Ok, but I think VBOs are the fastest, and as fungus suggests, I will try
> it on a more recent machine, perhaps that will bring out the difference
> more clearly.
> 
>> Display Lists certainly do have disadvatages of compile time and added
>> memory load. (although VBO's do too, to some extent),
> 
> My VBOs load 10s of mb of vertices in no time at all. It's definately
> using the graphics card because I delete them from memory afterwards.
> 
>> but they can be dramatically faster sometimes when you can't use VBO's
>> effectively.
>> You can maybe avoid some memory load by using mapped VBO's
> 
> What is a mapped VBO?

You can map your VBO into client space, meaning you have a pointer through
which you can directly access it bytewise.

Rolf Magnus wrote:
> Makhno wrote:
> >>
>> What is a mapped VBO?
> 
> You can map your VBO into client space, meaning you have a pointer through
> which you can directly access it bytewise.
> 

ie. The VBO is in shared RAM, not on the graphics card.
It's faster to update but slower to render.



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

fungus wrote:

> Rolf Magnus wrote:
>> Makhno wrote:
>> >>
>>> What is a mapped VBO?
>> 
>> You can map your VBO into client space, meaning you have a pointer
>> through which you can directly access it bytewise.
>> 
> 
> ie. The VBO is in shared RAM, not on the graphics card.

Why can't it be on the graphics card? I would actually have expected it
there.

> It's faster to update but slower to render.

Wouldn't that depend on the GL_BUFFER_USAGE you specified when creating the
buffer?

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:5PZAg.11628$6D6.9509@news.ono.com...
> Makhno wrote:
>> it is not always the case that
>>
>> (x+1) - (x) = 1    when x is large.
>>
>
> Correct, that's why I'm proposing you rearrange
> it to this:
>
> (x - x) + 1

You are missing the point.  Makhno's example has
to do with *already computed numbers* (x) and
(x+1).  You do not have the luxury of "factoring"
and rearranging terms.

You also missed Makhno's point about level of detail.
It does not matter if it takes 1 cycle to draw a triangle.
If you have a mesh of 1 million triangles that is far
away, and if that mesh covers 1 pixel, then you have
wasted a lot of cycles on overdraw of that pixel.  With
level of detail, your goal is to have an approximately
constant number of triangles that cover a pixel, regardless
of where in space the mesh lives.

Even with VBOs and large VRAM, level of detail for terrain
is still useful to save cycles to be used for drawing
everything else in your virtual world.

--
Dave Eberly
http://www.geometrictools.com

Makhno wrote:

>> Make the tiles dimensions so that their borders match whole
>> numbers (i.e. integers) in the terrain coordinate system. That
>> way you can enumerate tiles error free (integers have no error
>> like floating point numbers).
> 
> They are converted to floating point numbers inside the card.
> This does not help!

It helps, since prior to converting the tile's vertices
coordinates to floating point (integer + float) you first do a
integer arithmetic operation to place the tile the viewing point
is closest to in the virtual origin. That way the larger view
transformation error only affects the farther tiles.
 

> The tiles are not simply translated, there is a matrix
> involved. The Earth is curved.

You can assume the earth being locally flat. If you want to tile
a sphere you can't use longitude/latitude coordinate system
anyway (it would mess up at the poles). A popular approach
(AFAIK also done in MSFS) is to start from a tetraeder or any
other sphere approximating polyhedron, subdividing the triangles
into smaller triangles and shifting the new vertices to be
equidistant to the middle. That way you can address each
triangle by a n-element vector, following the nodes similair to
a quad tree. Element 0 can have 4 different values for a
tetraeder, the other elements have 3 possible values. At some
resolution you stop that subdivision scheme and switch to
isometric heightfield grid data. That way you can integer
address the tiles. Upon rendering you assume the closest tile
(rendering a planet the tile that intersects with the
planet-center to viewpoint line) being the local/virtual origin
and calculate your transformation from there. That way you can
keep the numbers within a tile small while covering a large
range. But it must be emphased that any error in data
representation and view transformation only affects the
resolution of the camera position/movement.

Wolfgang Draxinger
-- 

Dave Eberly wrote:
> "fungus" <umailMY@SOCKSartlum.com> wrote in message 
> news:5PZAg.11628$6D6.9509@news.ono.com...
>> Makhno wrote:
>>> it is not always the case that
>>>
>>> (x+1) - (x) = 1    when x is large.
>>>
>> Correct, that's why I'm proposing you rearrange
>> it to this:
>>
>> (x - x) + 1
> 
> You are missing the point.  Makhno's example has
> to do with *already computed numbers* (x) and
> (x+1).  You do not have the luxury of "factoring"
> and rearranging terms.
> 

Yes you do. You translate each terrain tile
to the origin then re-apply a translation when
you render it (the point of this is to increase
the accuracy of the vertex coordinates).

When you apply the camera transform to the
modelview matrix it cancels the translation
for the tile, that's the "(x-x)" part (the
numbers won't be exactly the same but they'll
have the same magnitude). What's left over
will be accurate as a float, no need for doubles.


> You also missed Makhno's point about level of detail.
> It does not matter if it takes 1 cycle to draw a triangle.
> If you have a mesh of 1 million triangles that is far
> away, and if that mesh covers 1 pixel, then you have
> wasted a lot of cycles on overdraw of that pixel.

I wouldn't say I "missed" that but the emphasis on
LOD has definitely shifted in the last few years.

All the old "adaptive terrain" algorithms, etc.,
are now totally obsolete as far as I'm concerned.
GPUs are now so fast that any CPU interaction
whatsoever just slows things down.

If triangles are culled (because of backfacing
or because they don't cover any pixels) then the
newest GPUs can reject then at a rate of *billions*
of triangles per second. That's monstrous.

Much better to just cull the tiles which are too far
away to be useful and draw a really simple version
of the terrain underneath so there's something visible
in the holes. To avoid popping, fade the terrain tiles
in/out as you approach them.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

>But it must be emphased that any error in data
> representation and view transformation only affects the
> resolution of the camera position/movement.

Ah - so despite this complex piece of transforming we're really no closer to
a solution.

> When you apply the camera transform to the
> modelview matrix it cancels the translation
> for the tile, that's the "(x-x)" part

It does not cancel!

> All the old "adaptive terrain" algorithms, etc.,
> are now totally obsolete as far as I'm concerned.
> GPUs are now so fast that any CPU interaction
> whatsoever just slows things down.

I'll believe it when I see it.

> Much better to just cull the tiles which are too far
> away to be useful and draw a really simple version
> of the terrain underneath so there's something visible
> in the holes. To avoid popping, fade the terrain tiles
> in/out as you approach them.

So, suppose you have an aircraft at 30,000ft - quite a typical altitude. The
pilot can see out to around 350km before the curve of the Earth takes the
terrain away.
If you have terrain vertices every 30m or so, you will find

1) This is a lot of vertices
2) This is a lot of faces

The vertices may not fit on the graphics card, and if they do (there's a lot
of memory available these days) there's a tremendous number of triangles to
draw. Are you telling me that a modern graphics card can do this? Because I
know you're wrong.

Makhno wrote:
>> But it must be emphased that any error in data
>> representation and view transformation only affects the
>> resolution of the camera position/movement.
> 
> Ah - so despite this complex piece of transforming we're really no closer to
> a solution.
> 

A translate is "complex"?



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
>> When you apply the camera transform to the
>> modelview matrix it cancels the translation
>> for the tile, that's the "(x-x)" part
> 
> It does not cancel!
> 

It does!


>> Much better to just cull the tiles which are too far
>> away to be useful and draw a really simple version
>> of the terrain underneath so there's something visible
>> in the holes. To avoid popping, fade the terrain tiles
>> in/out as you approach them.
> 
> So, suppose you have an aircraft at 30,000ft - quite a typical altitude. The
> pilot can see out to around 350km before the curve of the Earth takes the
> terrain away.
> 
> 1) This is a lot of vertices
> 2) This is a lot of faces
> 

Ummm...try reading that again....

When you're at 30,000 feet you'll just see the
"simple version of the terrain". When you fly
downwards the detail will appear, but it's
simple distance culling, not multiple LODs
or adaptive terrain.

> Are you telling me that a modern graphics card can do this?

Nope. I'm saying that fancy/complex LOD algorithms*
are mostly a waste of time on those cards. Keep it
simple, let the GPU do its thing.


[*] ie. Anything which uses the main CPU to modify
the terrain data in real time.

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

>> 1) This is a lot of vertices
>> 2) This is a lot of faces
>>
>
> Ummm...try reading that again....
>
> When you're at 30,000 feet you'll just see the
> "simple version of the terrain". When you fly
> downwards the detail will appear, but it's
> simple distance culling, not multiple LODs
> or adaptive terrain.

Where does this "simple version of the terrain" come from?
That's a LOD in my book.

>> Ah - so despite this complex piece of transforming we're really no closer
>> to
>> a solution.
>>
>
> A translate is "complex"?

Not just one - but everything must be translated/transformed when dealing
with the current tile. You need the inverse transform as well - imagine for
example trying to test for the intercept of a line with a face in a tile.
First the line must be converted to the coordinates of the tile - this will
require inverting the matrix representing the tile's transform.
It's possible, but it requires a lot of work both to implement and for the
CPU to do. The viewer is no longer in a simple coordinate system anymore,
but one of many different coordinate systems specified by the inverses of
the terrain tiles' transform matrices.

Makhno wrote:
>
> Are you telling me that a modern graphics card can do this?
> 

Read this:

http://tinyurl.com/ff5m4

[I know it mentions D3D based but the exact same
principles apply in OpenGL, just substitute indexed
VBOs where you see "vertex streams"]

Slide 11: "I�ve never seen a game which is vertex-throughput 
limited at interesting resolutions on modern hardware"

Slide 12: If you use the vertex caches nicely you
can get *free* triangles out of the chip.

Slide 13: Triangle setup: *never* a bottleneck...

etc., etc.


You have to throw your preconceptions out of the
window when you think about using these cards.
If you do it right you can get 1,000,000,000
triangles/sec passing through the transform
stage.



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
>>> Ah - so despite this complex piece of transforming we're really no closer
>>> to
>>> a solution.
>>>
>> A translate is "complex"?
> 
> Not just one - but everything must be translated/transformed when dealing
> with the current tile. You need the inverse transform as well - imagine for
> example trying to test for the intercept of a line with a face in a tile.
> First the line must be converted to the coordinates of the tile - this will
> require inverting the matrix representing the tile's transform.

Yep.

> It's possible, but it requires a lot of work both to implement and for the
> CPU to do.

Huh? A matrix inverse which only needs to be done
once, then transforming a line on a 4GHz CPU.

> The viewer is no longer in a simple coordinate system anymore,
> but one of many different coordinate systems specified by the inverses of
> the terrain tiles' transform matrices.
>

It's not terribly hard to do.

Besides, you don't have a choice. It's either that
or terrain wobble.

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:mf4Bg.11650$6D6.11630@news.ono.com...

Makhno wrote:
> it is not always the case that (x+1) - (x) = 1  when x is large.

fungus wrote:
> Correct, that's why I'm proposing you rearrange it to this:
> (x - x) + 1

I wrote:
> You are missing the point.  Makhno's example has
> to do with *already computed numbers* (x) and
> (x+1).  You do not have the luxury of "factoring"
> and rearranging terms.

fungus wrote:
> Yes you do. You translate each terrain tile
> to the origin then re-apply a translation when
> you render it (the point of this is to increase
> the accuracy of the vertex coordinates).
>
> When you apply the camera transform to the
> modelview matrix it cancels the translation
> for the tile, that's the "(x-x)" part (the
> numbers won't be exactly the same but they'll
> have the same magnitude). What's left over
> will be accurate as a float, no need for doubles.

Makhno's statement is abstracted to:  Subtraction of
large floating-point numbers can lead to catastrophic
cancellation.

Your suggestion of "factoring" the numbers and rearranging
terms to avoid the problem shows that you do not understand
the abstraction.

Despite my attempt to help you correct your failure to
understand the abstraction, you respond with yet
something else that shows your inability to formulate
a logical and deductive argument.

Makhno's statement is true, a fact you learn in basic
computer science, and easy to verify with simple
programs.  Your argument is *not* a counterexample
to "The floating-point difference y-x can have significant
error".  It is an argument to *avoid* arriving at the
expression y-x in the first place.  Yet your posts continue
with the tone that you have a counterexample.

fungus wrote:
> All the old "adaptive terrain" algorithms, etc.,
> are now totally obsolete as far as I'm concerned.
> GPUs are now so fast that any CPU interaction
> whatsoever just slows things down.

This is neither my experience nor Makhno's (based on
his tone in the posts).  Assuming that the vertex data
is stored in VRAM (i.e., transferred once across the
AGP bus [or whatever bus you have]), the performance
issue amounts to comparing the costs of:
(1) Compute the index array dynamically (compute LOD
    information on the CPU) and send the index array
    across the bus each frame.  Draw the N triangles
    implied by this index array.
(2) Send the entire index array once across the bus.
    Draw the M triangles implied by this index array,
    where M is much larger than N.
You are claiming that the cost of (2) is always smaller
than the cost of (1).  I disagree.

> If triangles are culled (because of backfacing
> or because they don't cover any pixels) then the
> newest GPUs can reject then at a rate of *billions*
> of triangles per second. That's monstrous.

And what is the relevance?  I mentioned that without
LOD you can have 1 million triangles covering a single
pixel.  You overdraw a large number of times.  On
average you expect about half of your triangles to be
back facing.  So the GPUs reject 0.5 million triangles
and draw the other 0.5 million triangles that cover that
one pixel.  If LOD reduces the triangle count to, say, 10
triangles covering the pixel, then it does not matter how
fast the GPU can back-face cull.

--
Dave Eberly
http://www.geometrictools.com

"Dave Eberly" wrote
> 
> Makhno's statement is true, a fact you learn in basic
> computer science, and easy to verify with simple
> programs.  Your argument is *not* a counterexample
> to "The floating-point difference y-x can have significant
> error".  

IIRC Sterbenz Lemma says that if two floating point y and x
satisfy

    .5f * x <= y <= 2.f * x

then the floating point difference 

    y (-) x == y - x

is exact.

otherwise the error is small compared to the result.

lev

Makhno wrote:
>
> Where does this "simple version of the terrain" come from?
> That's a LOD in my book.
> 

The simple terrain is always drawn - it never
switches off. The tiles are either visible/not
and drawn over the top of it.

That's not an LOD in my book.  :-)


nb. You draw the simple terrain last. Another
thing these graphics cards are very good at is
drawing polygons which fail the depth buffer
test.

Disclaimer:   Maybe this scheme won't work, I
didn't get around to trying it yet because I
don't have the luxury of a no-limits graphics
card. OTOH I see no reason why it shouldn't
work and a simple "render-only" test shouldn't
take too long to try - certainly a lot less
time then GPU-based terrain morphing code.

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
> 
> 1) identifying the equation and removing the x's from it (my suggestion)
> 2) doing it in double precision on the CPU (your suggestion)
> 
> (2) appears to defeat the objective of having a graphics card in the first
> place

No, because (2) doesn't transform the vertices
on the CPU, it just uses the CPU to comput the
modelview matrix as accurately as possible (and
glLoadMatrix() is very cheap in my experience).



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

Makhno wrote:
> Because I know you're wrong.
> 

OF COURSE there's a limit to what you can do. :-)

What I'm saying is that the goalposts have moved
so far in the last year or so that text-book
graphics theory is now obsolete in this situation.

The same thing happened to triangle strips. It used
to be gospel-truth that triangle strips were essential
for best performance. Now it's the opposite - strips
are slower than sending individual triangles*.


[*] Assuming you're doing everything right.

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

fungus wrote:
> 
> the goalposts have moved...
> 

OTOH, if you're doing any amount of coding on
your laptop then the difference in performance
is going to be annoying.... :-)

(Maybe some sort of load-balanced thing would
work - make a list of the nearest tiles and
draw tiles from the list for XX ms).

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

> OTOH, if you're doing any amount of coding on
> your laptop then the difference in performance
> is going to be annoying.... :-)

Actually, I'm quite impressed with the Radeon 9000. I've seen other cards do
better things, but it seemed to be a robust investment that is 'good
enough'. Runs FarCry alright.

> Disclaimer:   Maybe this scheme won't work, I
> didn't get around to trying it yet because I
> don't have the luxury of a no-limits graphics
> card.

I don't think anybody on Earth has the luxury of a no-limits graphics card.
Personally, I'd prefer the no-limits credit card.

"L.N.Myshkin" <inter@wc.net.invalid> wrote in message 
news:fLhBg.64197$zy5.1226506@twister1.libero.it...
> IIRC Sterbenz Lemma says that if two floating point y and x
> satisfy
>
>    .5f * x <= y <= 2.f * x
>
> then the floating point difference
>
>    y (-) x == y - x
>
> is exact.
>
> otherwise the error is small compared to the result.

You are talking about relative error.  Although you might
be content with a small relative error, sometimes this
can produce very wrong results in computational
geometry.  An example that comes to mind is computing
the distance between two line segments, each segment
specified by its two endpoints.  You can create a
configuration where the distance between the two
segments is nearly zero, the floating-point algorithm reports
a distance of nearly zero, but the floating-point computation
of the nearest points on the segments is grossly wrong.
The reporting of distance nearly zero is courtesy of the
small relative error.  The incorrect reporting of closest
points shows that the small relative error is not a guarantee
that everything else works in your algorithms.

--
Dave Eberly
http://www.geometrictools.com

Makhno wrote:
> 
> Actually, I'm quite impressed with the Radeon 9000. I've seen other cards do
> better things, but it seemed to be a robust investment that is 'good
> enough'. Runs FarCry alright.
> 

FarCry has a neat Terrain algorithm. You can
see how it works in the editor if you switch
to wireframe mode.



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

fungus wrote:

> FarCry has a neat Terrain algorithm. You can
> see how it works in the editor if you switch
> to wireframe mode.

FarCry's Terrain algorithm is okay

But playing the game it reminded me a bit of my Terragen File
Renderer hack I wrote within 12 hours or so (actually I didn't
plan to write a terrain renderer, it just happend *G*). QT_terr
has no material or lighting system (need's an external texture
file) shows horrible clipping errors, and is doing everything in
pure OpenGL immediate mode. But you may have a look at it. The
IMHO worst problem in the code is, that it create T-sections in
the geometry, leading to flickering edges. But as it was never
meant to be a real terrain engine I never invested the time to
add a recursive subdivision stage to prevent those T-sections.
Heck I was even too lazy to add user controls to fly through the
terrain, though it would have been easy to add it.

Nevertheless, you may have a look at it
http://home.mnet-online.de/wdraxinger/terrain.html

Wolfgang Draxinger
-- 

"Dave Eberly" ha scritto 
> "L.N.Myshkin"
> > IIRC Sterbenz Lemma says that if two floating point y and x
> > satisfy
> >
> >    .5f * x <= y <= 2.f * x
> >
> > then the floating point difference
> >
> >    y (-) x == y - x
> >
> > is exact.
> >
> > otherwise the error is small compared to the result.
> 
> You are talking about relative error.  Although you might
> be content with a small relative error, sometimes this
> can produce very wrong results in computational
> geometry.  An example that comes to mind is computing
> the distance between two line segments, each segment
> specified by its two endpoints.  You can create a
> configuration where the distance between the two
> segments is nearly zero, the floating-point algorithm reports
> a distance of nearly zero, but the floating-point computation
> of the nearest points on the segments is grossly wrong.
> The reporting of distance nearly zero is courtesy of the
> small relative error.  The incorrect reporting of closest
> points shows that the small relative error is not a guarantee
> that everything else works in your algorithms.

I was just observing that when cancellation occurs in a 
floating point difference, that operation is exact.

The result is smaller in absolute value than its operands, and 
all previously accumulated errors become relatively more 
significant, but the difference, per se, is exact.

What I found questionable was asking for counterexamples to

"The floating-point difference y-x can have significant
error".  

because if you start from inaccurate operands, you have the same 
problems as with the exact difference, whereas if you have exact 
operands then the error is no more significant than it is for the 
floating point sum.

"Makhno" <root@127.0.0.1> wrote in message 
news:bJqdnfVKuJRWe07ZRVnyrg@bt.com...
>> I meant that since your immediate mode stuff was faster than VBO's,
>> to put the immediate mode inside a display list.
>> By immediate mode I meant glBegin...glEnd, not a one-triangle-per
>> glDrawElements.
>
> Ok, but I think VBOs are the fastest, and as fungus suggests, I will try 
> it
> on a more recent machine, perhaps that will bring out the difference more
> clearly.
>
>> Display Lists certainly do have disadvatages of compile time and added
>> memory load. (although VBO's do too, to some extent),
>
> My VBOs load 10s of mb of vertices in no time at all. It's definately 
> using
> the graphics card because I delete them from memory afterwards.
>
>> but they can be dramatically faster sometimes when you can't use VBO's
>> effectively.
>> You can maybe avoid some memory load by using mapped VBO's
>
> What is a mapped VBO?
>
>
>
>
"glMapBuffer and glUnmapBuffer: These functions lock and unlock buffers, 
allowing data to be loaded into them or relinquishing control to the server. 
A temporary pointer is returned as an entry to the beginning of the buffer, 
which also maps the buffer into client memory. OpenGL is responsible for how 
this mapping into the client�s absolute memory occurs. Because of this, 
mapping must be done for a short operation, and the pointer is not 
persistent and should be stored for further use."


It maps the VBO VRAM directly into your address space (ideally).

-jbw

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:gz0Bg.8774$MA3.1802@news.ono.com...
> Rolf Magnus wrote:
>> Makhno wrote:
>> >>
>>> What is a mapped VBO?
>>
>> You can map your VBO into client space, meaning you have a pointer 
>> through
>> which you can directly access it bytewise.
>>
>
> ie. The VBO is in shared RAM, not on the graphics card.
> It's faster to update but slower to render.
>
>

I don;t think the above is necessarily true. It ideally IS VRAM, memory 
mapped into your system (VRAM is almost always memory-mapped into system 
address space anyway, really)... it's just another way of doing a "put" or 
"get" into/from the VBO.

-jbw


>
> -- 
> <\___/>
> / O O \
> \_____/  FTB.    For email, remove my socks.
>
> In science it often happens that scientists say, 'You know
> that's a really good argument; my position is mistaken,'
> and then they actually change their minds and you never
> hear that old view from them again.  They really do it.
> It doesn't happen as often as it should, because scientists
> are human and change is sometimes painful.  But it happens
> every day.  I cannot recall the last time something like
> that happened in politics or religion.
>
> - Carl Sagan, 1987 CSICOP keynote address
> 

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message 
news:558dq3-1gb.ln1@darkstargames.dnsalias.net...
> fungus wrote:
>
>> PS: You might have to do the matrix thing in
>> double precision on the main CPU.
>
> The worst thing that can happen is, that moving the camera will
> result in a jittering view, but no holes in the geometry and
> such stuff.
>
> But if you're a smart guy, you don't store a huge terrain in a
> large heightfield anyway, virtual address space on 32 bit
> platforms is 2GiB, so you will tile anyway to not waste precious

Correction: Application virtual address space on 32-bit systems (like Linux) 
is 4GiB. Refuse to accept clunky Windows limitations, from the "scarey 
smart" crowd, who, by the way, have also done it to 64-bit systems!


> RAM. Make the tiles dimensions so that their borders match whole
> numbers (i.e. integers) in the terrain coordinate system. That
> way you can enumerate tiles error free (integers have no error
> like floating point numbers). Each tile has it's own origin to
> which it's faces are related to. Upon rendering you perform a
> major transformation for each tile and you put it that way, that
> the closest tile will be closest to the global origin (in terms
> of transformation). That way the view-part of the modelview
> transformation will always be small compared to the rest of the
> world so that the jitter in camera movement is neglectible.
>
> Wolfgang Draxinger
> -- 
>

 

jbwest wrote:
>> ie. The VBO is in shared RAM, not on the graphics card.
>> It's faster to update but slower to render.
>>
>>
> 
> I don;t think the above is necessarily true.
> 

Yes...my mistake. I think if you make the buffer
"write only" then it should be as you say.

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

An article on this
http://www.gamasutra.com/features/20020712/oneil_01.htm