very interesting :)

[roadie]

just read some of thg, and saw this in the newest article:

With DirectX 8, some primitive processing has been introduced to the API, notably higher-order primitives, but so far there has been limited uptake from game developers. This could possibly be due to the fairly limited implementations available with DX8, but more likely it's because there is little hardware out there currently that accelerates this functionality. ATI's new series of cards promise to open up higher-order primitives to the games programmer under the name of "truform," but Nvidia seems unimpressed, so for now, the jury's out.

One thing is for certain, in the future you can be sure that this area of the API is going to increase in size and importance. Displacement maps, anybody? Displacement maps, anybody?

sounds promising

[TdB]

Displacement maps

hmm!
the gf3 can do that throgh pixelshader/vertexshaders.

[Rimfaxe]

Haig ?

What do you think about this? Is this important for you? (kidding)


Well, it sounds great but what does it do?

[TdB]

it is a kind of bumpmapping, but with REAL bumps.
instead of faking bumps with fancy per-pixel-lightning, it adds additional geometry by reading the displacement map, and build the bumps with additional polygons.
Afaik it can also be used to compress geometry, a displacement map uses less memory than a buttload of polygons.

[Nappe1]

Originally posted by TDB
hmm!
the gf3 can do that throgh pixelshader/vertexshaders.

of course it can do it, but it is a slow as a hell doing it and needs cpu to some parts.

we are talking about truly Hardware implementation. that means basically this: to able to do DX9 displacement mapping, chip must be able to use bitmaps on displacing of vertexes and also card must be able to modify (argh.. cannot remember right term..) mesh according to the bitmap and that GF3 cannot do.

Displacement maps can be used in many ways. but I like most the idea making huge height fields to generate beautiful landscapes in real time in hardware.

anyone remember game called 1NSANE? well, there you can see main idea. now game pre generates the mesh from the topographical card before the game starts, but with Displacement mapping that could be done in real time from that single topographical bitmap! and totally on the chip.

EDIT:

Originally posted by TDB
it is a kind of bumpmapping, but with REAL bumps.
instead of faking bumps with fancy per-pixel-lightning, it adds additional geometry by reading the displacement map, and build the bumps with additional polygons.
Afaik it can also be used to compress geometry, a displacement map uses less memory than a buttload of polygons.

well, again I didn't read the whole thread. TDB that was said better than I could.
It is true that it can also used to compress geometry. But what Displacement Mapping (and all kind of Hardware based tesselation) needs is calculation power. T&L unit has to be fast. another thing what Displacement Mapping needs is BANDWIDTH and lot's of it. At least DMap must placed to in to fastest memory, because tesselation unit has to access every single pixel in Bitmap to get "Heights" calculated. And I don't think nowadays DDR memory is fast enough for that and all that other stuff moving at the same time on data bus.

so they must have massive amount of Bandwidth to consume if/when their next chip has Displacement Maps.

[TdB]

of course it can do it, but it is a slow as a hell doing it and needs cpu to some parts

i didn´t know that it was slow, i haven´t really seen a gf3 do it

Displacement maps can be used in many ways. but I like most the idea making huge height fields to generate beautiful landscapes in real time in hardware.

reminds me of "magic carpet"(old game), you could make your own height maps for that game, and you could alter/destoy the landscape runtime, don´t know 1nsane though.

so they must have massive amount of Bandwidth to consume if/when their next chip has Displacement Maps.

are you talking about edram? (ram embedded on chip)I thought that was for framebuffer/z-buffer only, and that you would need additional normal ram for textures, etc...
and that the dmaps would be in normal memory, because too much edram would make the chip too big

of course they could use some other tech, i can´t think of...

[roadie]

of course the relevence to matrox is that they gave a presentation to microsoft or somebody about the displacement mapping. i believe this will appear in matrox's next card, and it is going to be ever, very powerful

[K6-III]

Hope is still there. Not sure for how much longer, though.

[Nappe1]

Originally posted by TDB

are you talking about edram? (ram embedded on chip)I thought that was for framebuffer/z-buffer only, and that you would need additional normal ram for textures, etc...
and that the dmaps would be in normal memory, because too much edram would make the chip too big

of course they could use some other tech, i can´t think of...

yep. I am talking about the eDRAM and it will need additional ram on board because with a nowadays tech you can barely get 6-14 Megs to chip and that's not suffient for nowadays use.

well, afaik you can use eDRAM for many purposes on the chip, but usually it has been primarily used for frame buffer, because there are the worst bottleneck at the moment.
for example on bitboys implementation, when using resolutions that don't use all eDRAM for frame buffer (1024x768x32bpp and 32 bit Z without FSAA for example) or when your frame buffer does not fit at all to eDRAM, you still have few megs left. And that can be used as additional texture memory or even as texture cache.

Also you must remember that IF frame buffer is embedded on the chip, only textures are on on board memory and there is much more bandwidth available. (because if we are using memory on the chip only, it doesn't use at all on board memory bandwidth.)

and we even don't know yet how Matrox has done the chip.

but this really looks good.