GeForceFX and displacement mapping?

[demalion]

If there's still any doubt, I sent an email to ATi asking about this and got it confirmed that the 9700 does NOT support any other form of DM than presampled.

Pretty disappointing then. Poor Matrox...if they hadn't taken so long and/or had a PS/VS 2.0 functional part on the market they'd be sitting pretty.

Looks like the arrival of "adaptive" (efficient) displacement mapping is pretty far away with the only card supporting it so far being the Parhelia (maybe P10 if it can manage it quickly enough, but that isn't a floating point part yet either).

Bleh. *spanks ATI forum members collectively*

 

[DemoCoder]

Thanks Humus.

It's not the end of the world tho. You can still get adaptive tesselation + procedural displacement mapping. Just pick an algorithm for your terrain or "bumpy displacement" and encode it procedurally. Many RenderMan displacement shaders are written this way, like every RM shader I've seen that has to do with 'threads' or 'bevels' uses proceduralism.

ATI would still hold the edge here, since both NVidia and ATI can do the procedural displacement map, but ATI's would look more smooth when n-patches are turned on.

BTW, does ATI support render-to-vertex buffer?

 

[Humus]

BTW, does ATI support render-to-vertex buffer?

It can't see anything preventing it. It's just a matter of defining an interface for that functionality. I suppose you wont see a direct glBindTextureAsVertexArray() function, but depending on how WGL_ATI_float_buffer defines glReadPixels() operations on floating point buffers it may be possible to just glReadPixels() from a pBuffer directly to the pointer returned by glMapObjectBufferATI(). If they relax the clamping behaviour of glReadPixels on float buffers it should work. There's no spec publicly available though so I can't say this is the case.

 

[bdmosky]

Well, isn't it about time ReactorCritical or HardOCP or some other rumor monging site picked up on this and blasted ATI for not being "100% Directx 9 compliant." The FUD that spread from the Geforce FX announcement on this issue was ridiculous.

 

[Typedef Enum]

I don't know if anybody knew this or not...But there is a title that supports DM right now...Earth and Beyond.

To the best of my knowledge, the only board that supports it is the Parhelia, and it does work in DX8.

Here's a little skinny from one of Matrox's employees:

Ok now here's the surprise, so you got a Parhelia and you got one feature which everyone is talking about, yes you guessed it, Displacement Mapping. Well i'm happy to say that Earth & Beyond is the first title to support Displacement Mapping on Parhelia. No you don't need DX9 to run it. An easy way to check for it, look at the geometry on planet surfaces, it doesn't pop up, why cos Displacement Mapping is turned on when you run it on Parhelia

There's an interesting thing about how/why it works in DX8...

 

[Kristof]

IMHO this whole discussion of being compliant to DX9 or not is largely irrlevant. As far as I know no hardware was every released that completely supported a DX release.

For example EMBM (Perturbed UV) has been available for a long time and was released with DX6 but it took ages before NVIDIA adopted it (GF4 IIRC) so does that mean that the GF1/2/3 were not compliant ? As far as I know most companies call their product compliant if they have a driver that supports the API. If some caps or texture formats are missing they don't really care.

All we really need to worry about is compliance to PS and VS versions. And that would be the basic versions not the elemts that can be capped. Is R300 PS2.0 and VS2.0 ? Yes, do they support every feature available ? Probably not. Is NV30 PS2.0 and VS3.0 ? Yes, do they support every feature available ? Again probabaly not.

There is a whole washlist of elements that can be capped in DX9 and Displacement Mapping, NPatches and a lot of other things are on this list.

In the end the standard VS and PS levels are what you should worry about since thats what most games will end up supporting. NV30 supports some elements that extend PS and VS to a level somewhere between 2.0 and 3.0, but unfortunatly they do not match 3.0 which means that NV30 will be stuck in the 2.0 path - if games ever support 2.0 and 3.0 paths.

with DX8.1 we got 1.0, 1.1,1.2,1.3 and 1.4 versions an it was a mess, this time MS opted for 2 levels 2.0 and 3.0 and there are caps which can stretch from 2.0 almost all the way to 3.0. You could say that 3.0 is equivalent to a fully capped 2.0 with some extra extensions (like dynamic branching in the PS).

But anyway you can safely ignore the whole compliance talk since AFAIK there won't be hardware that completely supports all caps of a new DX release. R300 (NV30) is probabaly not even "completely" DX8 compliant since they do not expose any HOS caps (RT and other patches).

And IMHO Displacement Mapping runs the risk of being another EMBM... something really kewl and powerfull but held back by awfull naming. VS3.0 displacement mapping is where things get interesting since its really is a vertex texturing capability where a complete dependent read can be executed from the VS, essentially its like being able to access "any" value inside a texture map from the VS. As long as we keep calling this "displacement mapping" developers will incorrectly assume that this is all you can do with it, just like they assumed that all EMBM was just bumpmapping while it was a full dependent texture read. Anyway enough ranting about poor API functionality naming strategies

K-

 

[Nappe1]

Kristof:
reason why EMBM lived on just a BumpMapping is that originall EMBM was just an example on Pyramid3D Hardware refence guide about using it's microcode programmable pixel pipeline:
quote from original document:

The following steps are then carried out through shading instructions for the Pixel Processor:

1. textfetch_modulate a:Atexture, b:Btexture -> TMP1
Through this step, we will have bump mapped sky environment map color in TMP1. We also have the 6-bit index (from the bump map) in TMP1_alpha arranged in the bit order of 54321054. This bit layout makes it easier to use TMP1_alpha, for example, to carry out palette look-up or to use it as a blending factor.

2. textfetch a: TMP1 -> TMP1
This instruction fetches color information from texture memory using modulated texture component from TMP1 writing the result to TMP1 for further use.

3. palette c:TMP1_alpha (address 5) -> TMP2
At this point we have the diffuse color of the surface in TMP2 and specular color in TMP1. Next thing to do is to add these colors together (with saturation turned ON; register 13 bit 1).

4. logic_op 12 (a+b) a:TMP1, b:TMP2 -> screen
With the above three-instruction pixel code, the intended combined bump/environment mapping effect is realized.

Somehow, no one realized that pipeline would have been capable doing much more. And other makers that adopted it (mostly Matrox. you kristof can tell more how EMBM is implemented on Kyro cards...) did a dedicated HW for it. and the programmability was forgotten, until DX8 came and it was re-invented. (though R100 and NV1x, has some sort of programmability on pixel pipeline.)

it's kind of ironical that greatest thing that bitboys that have done was just an example of all that they were offering...

 

[no_way]

Kristof is right, ppl have been over this numerous times on this board, i think i remember at least two or three threads arguing over definition of "DX compliance".
Pixel Shader and Vertex Shader versions are the only reliable indicators of how "compliant" the hardware is. Either the card supports the full instruction set, or it does not. ( Pixel shader IS a bad termin, OGL fragment shader is much better )
Now, the problem is, we are talking about features/capabilities that are one step in front of Vertex processing in 3D pipeline, higher order primitives, Primitive Shading if you will, and we do not have any standards defined for that yet.
And it doesnt look like neither OGL2.0 or DX is going to do anything about it, so we'll be probably stuck with proprietary implementations for years to come and thats a very unfornunate situation IMHO. Obviously IHVs are willing to innovate in this area, like GF3/Radeon HOS support and Truform and Parhelias DM demonstrate.
Also, the other end of pipeline, namely the step of making framebuffer pixels out of fragments is poorly standardized, but from what i undersand OGL2 will address this somewhat. At the moment its demonstrated by IMHO lacking AA implementations, i.e. application has little to no control about AA filtering modes, sample positions.

 

[demalion]

I think PS/VS has best exemplified the functionality of a DirectX version ever since DX versions have included the functionality of PS and VS. I do agree that it qualifies a part for a valid "Direct X version" compliance monicker much more significantly than things such as (fixed) hardware T&L for example.

But we are taking about a qualifier in addition to that, "full". I do think this qualifier will be abused handily by IHVs and marketing, but I think for the purposes of anyone aware of other things besides the PS and VS functionality of a DX version it will include anything among those elements that can also be viewed as significant. Though, by the time of DX "10", all significant functionality may be in the PS/VS specification (?).

Was EMBM viewed as significant in DX 6? I'd think so, but was anyone discussing and claiming "DX version" compliance at the time? (I really don't know)

In any case, I think displacement mapping and other geometry enhancement functionality are important to help with the scalability of graphics engines with graphics cards scaling to such high geometry handling power (and the Least Common Denominator being so relatively low in the same area).
I'd hoped that with DX 9 all of this functionality would become standard, and am disappointed that neither lead player exposed quite as much functionality as I was expecting.

Maybe nv35 will have more of the rumored geometry handling functionality. Maybe R350 will fill in the gaps in the R300. Maybe both vendors have surprises in store via drivers. Maybe adaptive tesselation for procedural displacement mapping, as DC describes (which sounds awfully limiting...), will be enough to get started. We'll see, I guess.

 

[ERP]

Taking the risk of offending every Matrox fan on the board.

Matrox style displacement mapping is really nothing more than a stop gap solution, the right way to do it is texture reads in the vertex shader (as in VS3.0).

 

[arjan de lumens]

Taking the risk of offending every Matrox fan on the board.

Matrox style displacement mapping is really nothing more than a stop gap solution, the right way to do it is texture reads in the vertex shader (as in VS3.0).

It may be a stop-gap solution, but it still, unlike the other ones, adapts how finely surfaces are tessellated based on distance, and seems to mipmap the displacement map accordingly. This affects the process of generating the vertices in the first place - VS3.0 only adds new capabilites to the processing of an already-generated vertex. Those are separate features - which may well be combined at some point.

Hmmm ... doing texture reads in a vertex shader and still avoiding texture aliasing sounds ... challenging in the general case.

 

[ERP]

The texture read in the vertex shader can do mip mapping and texture filtering in exactly the same way as the Texture read in the pixel shader does.

Assuming that you maintain the stream processing nature of vertex shaders, the tessalation has to occur up front. Ideally in some sort of programmable unit that can be used to create NPatches, Subdivision surfaces or just flat tessalated tris whatever the application calls for. In this way the displacement mapping is independant of surface type, you can displace based on local normals or a global face normal, or some spherical projection from the object center.

More importantly though texture reads in the vertex shader increase flexibility above and beyond simple displacement mapping. Hard coded displacement maps do nothing other than displacement maps.

 

[no_way]

What would one achieve with displacement mapping without tessellation ? i.e. displacement mapping on vertices that already exist ?
I mean texture lookup in vertex shader can come handy, but why'd one do displacement mapping that way ?
Displacement mapping is nothing more than a form of geometry compression, but in solution where all geometry is generated beforehand, and then only perturbed in VS, no compression is achieved at all ?
IMHO, its only useful, when tessellation takes place as well, ideally along with mipmapping, so that lower LOD primitives dont get tessellated.
And vertex shaders will not be doing any tessellation, you need to go one step backwards in geometry pipeline, to primitive processing.

 

[DemoCoder]

But wouldn't you also want to adapt the tesselation based on the actual DM sample? For example, with a large perturbation, you might want finer tesselation.

I guess the programmer would know what level to set the detail at ahead of time based on his map, but it seems you could also adapt the tesselatoion using the map sample before it hits the VS.

Perhaps we need a texture unit in both the vertex shader and in a programmable tesselation unit as well (Per-Primitive Processor anyone?) Fixed function tesselation is kinda limiting.

 

[ERP]

What would one achieve with displacement mapping without tessellation ? i.e. displacement mapping on vertices that already exist ?

You misunderstand what I am proposing.
I am assuming that as is the case now adaptive tessalation takes place prior to the vertex shader. This happens in all of the existing HW curved surface implementations that I am aware of. Looking to the future a programmable unit here instead of a fixed function unit would be desirable.

The vertex displacement values rather than being applied during the tesalation are then applied in the vertex shader by the vertex program as required.

Matroxes existing adaptive tessalation most likely does not take into account the contents of the displacement map (this would be hideously expensive, even renderman doesn't do this), only the predicted projected size of the triangle (or poissibly it's edges), so there is no benefit to doing the sampling along with the tessalation. Moving the sampling hardware to the vertex shader increases it's usefulness dramatically.

It's just trading single function hardware for a more flexible solution, with the same basic logic requirements.

 

[gking]

arjan de lumens:
adapts how finely surfaces are tessellated based on distance

However, as the DX9 SDK docs describe, it's really only useful for rigid-bodies (i.e., terrain). Based on the DirectX docs, the tesselation level is determined for a triangle based on a single 4x4 matrix multiply, which makes it essentially useless for skinned (or skinned+blend shaped) character animation.

Also, as currently implemented, adaptive DM can't recompute normals or tangents -- an object-space normalmap must be supplied to encode the displaced normals, which also breaks down with character skinning.

Good, general-purpose, pipelined hardware displacement mapping is still quite a ways off. Matrox's solution is a step in the right direction; however, I wouldn't even call it a stop-gap solution, since it's largely incompatible with using vertex shaders for more advanced animation and transformation techniques.

ERP:
Assuming that you maintain the stream processing nature of vertex shaders, the tessalation has to occur up front

I don't think is the case at all. I think that the only way you'll be able to provide good control points into a programmable tesselation unit will require running at least part of the vertex shader on them, so that the exact clip-space positions are known in advance. I wouldn't be terribly surprised if future proposals for vertex shaders separate transform and lighting, creating a new vertex pipeline like this:

vertex shader transformation of control points
programmable tesselation and interpolation of vertex attributes
vertex shader displacement, computation of new surface parameters, and lighting

...

DX9 presampled displacement mapping has some utility as a form of geometry compression, but I'd be surprised if it's used for anything more than a handful of tech demos.

 

[Hyp-X]

Matroxes existing adaptive tessalation most likely does not take into account the contents of the displacement map (this would be hideously expensive, even renderman doesn't do this), only the predicted projected size of the triangle (or poissibly it's edges), so there is no benefit to doing the sampling along with the tessalation. Moving the sampling hardware to the vertex shader increases it's usefulness dramatically.

It can't use the size of the triangle as it couldn't guarantee continuity that way.

And you wouldn't want to calculate with triangle size anyway, as you don't want equally fine tesselation anyway. You wan't more details at some places and less at others. You can do this by putting smaller polygons where the more detail is required, as the relative detail level doesn't change with the tesselation level.

The only thing the tesselation level depends on is depth.

 

[Basic]

May I ask what you mean by "presampled DM"?

A) The DM must have been sampled before the mesh is sent to rasterization. For instance by doing a render to vertex buffer.

B) The vertex stream contains DM coordinates. The DM is sampled automatically for each vertex, before the vertex shader starts. The sampled value is available in a VS register.

All this as opposed to the real deal:
C) The vertex shader can calculate the coordinates for the DM sample, and then execute a TEXLDV to sample the DM.


(A) is pretty much equivalent to having no direct DM support. Since all that's needed is the possibility to send multiple vertex streams.

There's no problem combining (B) with adaptive tesselation, since the tesselation can interpolate the DM coordinates, and then you could get a DM sample for each tesselated vertex. At least in theory, don't know about the specific case R300.


So the important part here is what did ATI mean with "presampled".
Pre-"sending mesh to API" or pre-"runing the VS for this vertex"?

 

[Kristof]

Also, as currently implemented, adaptive DM can't recompute normals or tangents -- an object-space normalmap must be supplied to encode the displaced normals, which also breaks down with character skinning.

I agree, the biggest flaw in the current technique is the complete loss of the Normals and Tangents which severely limits the possibilities.

IIRC this is why Matrox is actually proposing to do the skinning on the CPU on the low tesselated model, then send that model to the hardware over AGP to be tesselated with displacements. Problem is lighting still has to be done per pixel using the pixel shader. If we are going through the effort of such high tesselation levels we really should not have to resort to per pixel lighting.

I guess we want connectivity information in the vertex shader next

K-

 

[arjan de lumens]

The texture read in the vertex shader can do mip mapping and texture filtering in exactly the same way as the Texture read in the pixel shader does.

Nope. Mipmapping is done in the pixel shader by estimating (or more commonly: measuring) the rate of difference in texture coordinate values between adjacent pixels and then selecting a mipmap based on this rate of difference. The only time you can estimate rate-of-difference in a remotely meaningful way for vertices would seem to be at the time of generating a vertex mesh ..?

Also, a question (to all): Barring the case of amplified/on-the-fly generated geometry, is there anything that can be done with VS3.0 that cannot be done with, say, PS3.0 and render-to-vertex-array?