GeForceFX and displacement mapping?

[Testiculus Giganticus]

More or less. Suffice to say that IMO DM is not meant to replace bump-mapping as far as characters go(yet). It is great for terrain, but you can`t do really detailed stuff in an acceptable way(again yet).DM is a good tech
but it still needs to advance, because it is still in its infancy.

 

[DemoCoder]

TRUFORMâ„¢ 2.0
2nd generation N-Patch higher order surface support
Discrete and continuous tessellation levels per polygon
Displacement mapping

http://www.ati.com/products/pc/radeon9700pro/specs.html

And? There are multiple displacement map specs in DX9, this tells me nothing. Like, can it do adaptive tesselation with non-presampled displacement maps?

The current method that they expose in DX9 can be done on any 3d card with a vertex shader.

Moreover, this doesn't tell me if they are doing it in HW or using a software fallback. Maybe they are using a software fallback and performance/quality will suck. NVidia had a software fallback for HOS and got rid of it in the DeviceCaps because it killed performance in some fallbacks. It was better to tell the game that it didn't support HOS then to let performance be dogged.

We don't know if ATIs implementation works and can be realistically used extensively in real world games.

 

[Kristof]

I was thinking about this pre-sampled type of dispacement mapping, can't it be trivially converted into a second input stream. So you have the normal input stream of vertex position, normal and tex coords, and then you have a second stream (upto 16 are supported these days IIRC) which simply contains the "displacement data". All you'd have to do is adapt the vertex shader to select this secondary stream as input for the displacement mapping.

IMHO the pre-sampled type is pretty useless, it won't work with adaptive tesselation and is horibly limited. I would not even call this displacement mapping since as far as I can see this can be hacked easily using a secondary stream and some conversion work on the CPU. ONly snag I see is if you'd try to use render to texture and use that output data as the input, but then again that sounds quite complex to accomplish with the weird indexing structure of the pre-sampled mapping type.

Any ideas on this ?

Anyone think Matrox will release DX9 driver soon so we can play with this, the current DX8 hack is not actually something I'd want to touch just to play around with it.

K-

 

[Hyp-X]

More or less. Suffice to say that IMO DM is not meant to replace bump-mapping as far as characters go(yet). It is great for terrain, but you can`t do really detailed stuff in an acceptable way(again yet).DM is a good tech
but it still needs to advance, because it is still in its infancy.

Why'd you want to replace it?

DM extends bump-mapping (normal-mapping actually).

In fact you have to use normal-maps to get correct lighting with DM.

 

[Testiculus Giganticus]

To a certain extent, you are correct.

 

[DemoCoder]

Yes Kristof, I believe that is exactly the case. The vertex index is used as "texture coordinate" (not really) to grab a pre-sample which is then used to perturb the vertex position. No tesselation.

This can be done quite easily by a vertex shader as you suggest. You could also pack a low-res displacement map into the constant registers. There's many ways to do it, but the result is basically the same.

If this is what ATI means by Displacement Mapping in their PR, then IMHO it's deceptive advertising. Minimally, you'd atleast have to be able to do what Matrox does I think to quality for "real" displacement mapping.

Perhaps the NVidia rep answered too truthfully and should have said something like "Yep! It can be done via CineFX shaders!" or some such.

 

[demalion]

Yes Kristof, I believe that is exactly the case. The vertex index is used as "texture coordinate" (not really) to grab a pre-sample which is then used to perturb the vertex position. No tesselation.

This can be done quite easily by a vertex shader as you suggest. You could also pack a low-res displacement map into the constant registers. There's many ways to do it, but the result is basically the same.

If this is what ATI means by Displacement Mapping in their PR, then IMHO it's deceptive advertising. Minimally, you'd atleast have to be able to do what Matrox does I think to quality for "real" displacement mapping.

Do you have some reason other than to address the attack on the nv30's reported lack of displacement mapping to suggest that this is the case? Since you are working with the R300 now, I wouldn't be surprised, but it would be nice if you went into it in a bit more detail.

Perhaps the NVidia rep answered too truthfully and should have said something like "Yep! It can be done via CineFX shaders!" or some such.

You are on a slippery slope of trying to equate a lack of a displacement mapping as directly stated by nVidia to a lack of a demonstration of displacement mapping in a demo. This does not mean you are wrong in some of your sentiments, but the reasoning does look pretty convoluted to me.

I will mention again that ATI has directly stated adaptive tesselation since you mentioned that earlier.

It is of course possible that these statement are incorrect or misleading in the absence of a full demonstration of the capability, but it does not seem a reasonable assumption to make simply because of nVidia's comment.

 

[DemoCoder]

Well, there is no public documentation about what the R300 hardware is ultimately capable of, so speculation of existence of features in the absense of evidence is incorrect. Until there is evidence, any hypothesis of the positive existence of such a feature is unsupportable.

All we can go on is what is publically exposed: in documentation and in ATI's own drivers and release notes, and none of them state the existence of non-presampled displacement mapping.

Yes, I have a R9700 PRO, but I can't write a displacement mapping example because the driver reports that it doesn't support it!

It all boils down to whether ATI really included a texture sampling unit in their vertex pipeline/tesselation unit. If they didn't, the best you will be able to do is pre-sampled displacement mapping which requires that adaptive tesselation be turned off

And any DX8/9 card can do pre-sampled displacement mapping by using multiple vertex streams and a vertex shader.


I am only pointing out in this thread that f*nb*ys latching onto a single feature difference (at this point unproven) and elevating it to high importance is absurd. One group can latch onto DM, another can latch onto PS2.0_Extended, and another could latch onto FP CubeMaps or 128-bit vs 96-bit. These arguments are silly and don't matter for 99% of the people or developers.

These cards are mindnumbing complex and contain hundreds of features, and latching onto a few feature differences isn't going to prove anything.

No card is going to support every DX feature available, and no card supported every DX8 feature in HW either.

 

[demalion]

I am only pointing out in this thread that f*nb*ys latching onto a single feature difference (at this point unproven) and elevating it to high importance is absurd. One group can latch onto DM, another can latch onto PS2.0_Extended, and another could latch onto FP CubeMaps or 128-bit vs 96-bit. These arguments are silly and don't matter for 99% of the people or developers.

What I didn't quote makes a lot more sense out of your position (for me), but what I did quote is where my confusion came from. The difference is that we were expecting displacement mapping on the nv30 and apparently (I agree with the emphasis on that sentiment) we didn't receive it...none of the other functionality you mention is the same in that regard. That is why it does not take being a "fanboi" to be surprised and disappointed. Except for that sentiment, I really have nothing to dispute about your position as you have established it now.

These cards are mindnumbing complex and contain hundreds of features, and latching onto a few feature differences isn't going to prove anything.

Welll, I think it would be nice for displacement mapping to be included going forward so we could expect adoptation alongside other "DX 9 features". It seems (to the level of functionality Matrox has demonstrated) a distinct feature with interesting applications. If it is only nVidia not supporting this, which seems to be the most reasonable interpretation of ATI's (the link to the presentation I provided) and nVidia's (the statement quoted here that I agree may be a miscommunication) statements, it is a clear reason to be disappointed in nVidia. That is not to say it isn't too early to to be sure this is the right interpretation, but it doesn't strike me as unreasonable at all to be concerned about its lack in the nv30 and try to verify it, which is what you are criticizing as "ATI fanboi" behavior.

No card is going to support every DX feature available, and no card supported every DX8 feature in HW either.

That just sounds like an excuse. If the nv30 doesn't support this, this is disappointing. If the R300 doesn't (though we really don't have the same indication that this is the case right now...you keep mentioning the status of the beta drivers as if that is as significant as a direct statement from the vendor), well that is disappointing as well. It is that simple. The difference is we dont' have the statement from ATI stating flatly that it doesn't.

That said, I keep wondering if the ATI people are still at work, out socializing, can't speak on this issue for some reason, or (seeming to me incredibly unlikely) none of them can provide a clear answer.

 

[Sabastian]

I guess all we have is this quote from Hercules site. Displacement Mapping being a part of DX9 prolly has something to do with the fact that we haven't heard much of it.


http://us.hercules.com/products/showpage.php?p=55&b=0&f=1

"-Full DirectX® 9 & OpenGL® hardware accelerator
-Movie-quality 3D images provided by ATI’s latest 3D technology

-innovations:

SMARTSHADERâ„¢ 2.0: programmable Pixel Shaders 2.0 & Vertex shaders 2.0
TRUFORMâ„¢ 2.0 and DX9 Displacement Mapping"

Supposedly this is a sample of Dirsplacement mapping done on the Radeon 9700 pro.

http://us.hercules.com/images/3DP9700PRO/samp_with_displacement_mapping.jpg

 

[Sabastian]

Well, there is no public documentation about what the R300 hardware is ultimately capable of, so speculation of existence of features in the absense of evidence is incorrect. Until there is evidence, any hypothesis of the positive existence of such a feature is unsupportable.

All we can go on is what is publically exposed: in documentation and in ATI's own drivers and release notes, and none of them state the existence of non-presampled displacement mapping.

Yes, I have a R9700 PRO, but I can't write a displacement mapping example because the driver reports that it doesn't support it!.

Again I think that the matter here is that Microsoft hasn't released DX9. Trueform 2 supports displacement mapping and since displacement mapping is a part of DX9 you won't see any driver support yet.. that just makes too much sense though?

http://www.extremetech.com/article2/0,3973,388811,00.asp

"TruForm 2.0 also supports displacement mapping"

"This feature is exposed via DirectX 9, and ATI is exposing it in OpenGL with an extension, although ATI is hopeful that this feature will be incorporated into the core API in a near-term future version."

And any DX8/9 card can do pre-sampled displacement mapping by using multiple vertex streams and a vertex shader.

Yes but they look more like this...

http://us.hercules.com/images/3DP9700PRO/samp_without_displacement_mapping.jpg

As opposed to this..

http://us.hercules.com/images/3DP9700PRO/samp_with_displacement_mapping.jpg

These cards are mindnumbing complex and contain hundreds of features, and latching onto a few feature differences isn't going to prove anything.

No card is going to support every DX feature available, and no card supported every DX8 feature in HW either.

While I am not going to argue that you are wrong here because indeed they are complex. I am personally interested in seeing Displacement Mapping being supported I think it is “coolâ€￾ if you like. On other(Not all of course.) features I am likely less interested... not all features of DX being equal of course.

 

[Doomtrooper]

Displacement mapping is very cool, just look at some of Matrox Demos..anyone that thinks its not a usefull feature needs their head examined...BTW nice pics Sabastian, they do show how Models can be enhanced alot with DM.

 

[DemoCoder]

Let's just say that I am awaiting clarification from ATI on the exact nature of the displacement mapping they support. If it is pre-sampled displacement mapping only, then I consider it as not true displacement map.

To support real displacement mapping, they need a texture sampling unit in the tesselation unit/vertex shader. If it is faked with a vertex stream and pre-sampled index, it doesn't quality as real DM IMHO.

 

[Sabastian]

Heh, seems this news travels fast...

21 November - Nvidia Strongly Dislikes Curved Surfaces: No Displacement Mapping Support in the GeForce FX


We were very astonished when Nvidia decided to turn off the parametric surfaces (or RT-patches in the DirectX parlance) support in their GeForce3 drivers a year ago. When asked why, Nvidia officials told that the support of curved surfaces should be turned off because several game developers implemented ATI’s TruForm technology in their games and the software decided that the GeForce3 accelerators also supported the N-Patches, whereas the GPU just tried to emulate them through RT-patches causing the performance to drop dramatically. Since the higher order surfaces are not used widely these days, their support is not something the end-users can take any advantages of, we forgot about this fact shortly after it had been revealed.

The higher order surfaces are here to allow game-developers to create very complex 3D-models without using too many triangles. There are many approaches of creating HOS surfaces, however, there are only two of them on the consumer market: RT-Pathes and derivatives and N-Patches in different incarnations. RT-Patches require control points definition over a surface at the stage of creating a model. Another way to achieve complex models and environments is to utilise N-Patches and its derivatives that calculate the control points on-the-fly. Since the latter were introduced by ATI, Nvidia said that they were not going to implement this in their own chips.

What is even more interesting is that they decided not to support Displacement Mapping technology from DirectX 9.0 due to unknown reason, according to sources. Maybe because the approach is based on the notorious N-Pathes?

Microsoft wants IHVs to support Displacement Mapping and points it out in every document they issue in regards DirectX 9.0. Both ATI Technologies’ RADEON 9700/9500 VPUs and Matrox Graphics’ Parhelia 512 graphics processor support the Displacement Mapping.

I now wonder if Displacement Mapping is “must be†function of the DirectX 9.0. If it is, Nvidia may not be able to claim the DirectX 9.0 full hardware support for the GeForce FX VPU.

http://www.reactorcritical.com/#l1270

Does the GeForce FX Support All the DirectX 9.0 Features?
Posted 11/20/02 at 7:36 pm by Anton

We told you numerous times that NVIDIA’s GeForce FX graphics processor supports all the features provided by Microsoft DirectX 9.0 API and even beyond. Mostly due to their unique capabilities in vertex and pixel shaders, the Santa Clara, California-based graphics chip developer can boast with the CineFX architecture that should bring Hollywood to your personal computer. Apparently, we now doubt that NVIDIA really supports all the necessary DirectX 9.0 capabilities in hardware: according to our friends from Reactor Critical web-site, the GeForce FX also known as the NV30 graphics processor does not support Displacement Mapping.

As we know from our Matrox Parhelia Review, hardware displacement mapping support is a long-time dream of software developers who wanted to correctly display bump mapped models without making them too complex by describing each bump in a separate set of polygons. According to Microsoft, displacement mapping is based on the N-Patch approach introduced by ATI a year ago, hence, have almost nothing to do with NVIDIA’s RT-patches implemented in the GeForce3 GPU. Competing products, such as Matrox Parhelia, ATI RADEON 9700 and RADEON 9500 support the displacement mapping in hardware. Furthermore, NVIDIA does not seem to like curved surfaces very much at all: they turned off parametric surfaces support in the GeForce3 drivers due to compatibility issues a year ago, so, currently NVIDIA does not seem to support any higher order surfaces.

At this point I do not know if the displacement mapping is needed to be strictly supported by hardware in order to declare “DirectX 9.0 compatibilityâ€. If it is, NVIDIA will not be able to claim that the GeForce FX VPU is 100% DirectX 9.0 compatible.

http://www.xbitlabs.com/news/story.html?id=1037838967

 

[OpenGL guy]

Displacement mapping is very cool, just look at some of Matrox Demos..anyone that thinks its not a usefull feature needs their head examined...BTW nice pics Sabastian, they do show how Models can be enhanced alot with DM.

Yes, DM can look cool, but how is it useful for developers? How does one do collision detection on a displacement mapped object? What about stencil shadows? I'm not saying these problems cannot be solved, but it does require some effort to solve them. For example, if you want to do projected stencil shadows, a la Doom 3, then the software would have to compute the vertices generated by the displacement map anyway, so there would be no geometry compression and you might as well just have a finer mesh to begin with.

So far, I've been impressed by how displacement maps can look, but I don't see any real advantage in a gaming environment, especially when it comes to collision detection.

 

[DemoCoder]

Can't any of the ATI employees here comment on the real deal? Is DM switched off in the ATI DX9 drivers because it isn't implemented yet, or because the hardware only supports pre-sampled displacement maps?

The R300 is a publically released chip and shipping to end users now, there should be some documentation about the actual level of support available in the HW for these features, beyond the whitepapers which don't really tell us what the HW actually does.

 

[Sabastian]

Displacement mapping is very cool, just look at some of Matrox Demos..anyone that thinks its not a usefull feature needs their head examined...BTW nice pics Sabastian, they do show how Models can be enhanced alot with DM.

Yes, DM can look cool, but how is it useful for developers? How does one do collision detection on a displacement mapped object? What about stencil shadows? I'm not saying these problems cannot be solved, but it does require some effort to solve them. For example, if you want to do projected stencil shadows, a la Doom 3, then the software would have to compute the vertices generated by the displacement map anyway, so there would be no geometry compression and you might as well just have a finer mesh to begin with.

So far, I've been impressed by how displacement maps can look, but I don't see any real advantage in a gaming environment, especially when it comes to collision detection.

So from what I am reading hear you don't think that DM is a worthwhile implement for developers to pursue? ... How disappointing.

 

[3dcgi]

Ati is giving a lecture in March at the Game Developer's Conference. So we'll at least find out more then.

http://www.cmpevents.com/GDx/a.asp?option=C&V=11&SessID=684

 

[Humus]

Yes, DM can look cool, but how is it useful for developers? How does one do collision detection on a displacement mapped object? What about stencil shadows? I'm not saying these problems cannot be solved, but it does require some effort to solve them. For example, if you want to do projected stencil shadows, a la Doom 3, then the software would have to compute the vertices generated by the displacement map anyway, so there would be no geometry compression and you might as well just have a finer mesh to begin with.

So far, I've been impressed by how displacement maps can look, but I don't see any real advantage in a gaming environment, especially when it comes to collision detection.

It's very useful for developer and is very high on my wish list. Collision detection will probably not be much of a problem. On a terrain you can use the very same texture to compute the height of the current posistion of where the guy is. On a character you'll probably approximate the guy with a cylinder or set of simple shapes, like most developers do already. If you use it as a replacement for bumpmapping you don't really need to change you collision detection at all.
Also, you can use shadowmapping instead of shadow volumes.

 

[WaltC]

Yes, DM can look cool, but how is it useful for developers? How does one do collision detection on a displacement mapped object? What about stencil shadows? I'm not saying these problems cannot be solved, but it does require some effort to solve them. For example, if you want to do projected stencil shadows, a la Doom 3, then the software would have to compute the vertices generated by the displacement map anyway, so there would be no geometry compression and you might as well just have a finer mesh to begin with.

So far, I've been impressed by how displacement maps can look, but I don't see any real advantage in a gaming environment, especially when it comes to collision detection.

Well, the answer as far as collision detection is simple--a lot of 3D games don't have a lot of collisions going on (CRPG's, adventures, etc.) to worry about that particular aspect and indeed in almost all "state-of-the-art" 3D games today the background terrain (& foreground) are fixed and immutable--and DM can do wonders with terrain. Or would you basically say that anything having to do with n-patches is virtually useless? I think it's amazing, actually, what creative people can do when you provide the tools. I don't know how many times I've heard programmers say, "What they've done here is something I never thought about when writing my code--it's incredible," etc., ad infinitum.