radeon 9000 and truform
- Thread starter muppy
- Start date
Doomtrooper
Veteran
nAo said:
Says who ??
Tesselation can be handled similarly as Truform, in fact N-patches are part of Displacement mapping.
I've seen the Matrox displacement mapping demos, and yes Displacement Mapping can be used the same as truform, only in a more advanced state.
ftp://ftp.matrox.com/pub/mga/parhelia512/demos/hdmc_process_avi.zip
I doubt Carmack would have overlooked Truform, if it wouldn't have been causing him problems with stenciling. It was rather an either/or choice and albeit I'm not really personally fond of tons of stencil ops, I still think that in terms of creating a specific atmosphere in a game you're better off with dynamic shadows, than more details on models and/or objects etc.
As for the fundamentals of hardware based displacement mapping, read Matrox's white paper for it.
Truform is a type of subdivision surfaces. It takes existing information and creates new triangles.Doomtrooper said:Says who ??nAo said:
Displacement mapping creates new triangles them and perturbs them based upon additional information.
Those are two fundamentally different techniques. The only reason they could be lumped together in the future would be because of marketting. It's not accurate at all to think of Displacement Mapping as an extension of Truform.
O.K. Deep breath, start explaining NPatches and displacement mapping.
This is might get a bit long....
There are 2 distinct stages to surface evaluators (of which NPatch and displacment maps are both a form of).
1) Tesselation
2) Perturbation
The second stage is doable on ALL vertex shader hardware, you want NPatches, want displacement maps, want subdivision surfaces just run it though a vertex shader. You take some input, run it through a basis function (which defines how you perturb the vertex) and voila any surface you like.
But to do this you have to tesselate the base triangle, this isn't programmable (yet) so you either do it on the CPU (could be expensive) or the hardware has a fixed function tesselator.
The fuxed function tesselator on the ATI 9700 was meant to be better than the fixed function tesselator on the ATI 8500, the ATI 8500 can only do integer steps (i.e. level 1 might give you 5 triangles, level 2 might give you 15 triangles) whereas the ATI 9700 was meant to have floating point levels (i.e. level 1 might be 5 triangles and level 2 might still be 15 but level 1.5 would give 10).
That appears to be the only difference between Truform v1 and Truform v2, the fact that lots of people think its much slower on 9700 might indiacate a hardware bug and they've fallen back to software I honestly don't know. The other possiblity why the 9700 seems slower is that AFAIK ATI had dedicated NPatch perturbation hardware in the ATI 8500, it seem likely that they may have removed this and moved its function into the vertex shader (in the same way they moved the entire fixed function vertex pipe into vertex shaders).
Now a clever tesselator would alter the tesselation based on the data (i.e. if your surface is flat, don't add more triangles), this of course makes the 2 stages dependent. This is what the Matrox card does, its fixed function only but tesselates the mesh based on the basis function and the displacement map.
Now whats likely to happen one day, is that we will have a tesselation shader that generates vertices (and triangles) that are passed to a vertex shader that perturbs them. This combined with vertex texturing would give generalised programmable surface evaluators. We can currently do a crude form of vertex texturing (the badly titled pre-sampled displacement maps), have fairly capable vertex perturbation shaders (/plug check out my ShaderX2 article, I'm hoping to put it up here on Beyond3D soon /end plug) but only fixed function or CPU tesselation shaders. Vertex shader V3 gives us proper vertex texturing and I predict DX10 will give us tesselation shaders.
BTW Some people seem to think that we are moving to a Renderman type system with vertex and pixel shaders becoming one, I happen to disagree. While some hardware may be shared, the problem with a single shader approach is the removal of the concept of frequency. For real-time shaders will need to evaluate different things at different rates, I'm personally hoping that DX10 shaders will have advanced frequency concepts (i.e. run this shader every base triangle, this every vertex, this every pixel, this every sub pixel and this every write to the framebuffer). A system like that would give us (with shared memory) tesselation shaders, alpha blender shaders, anti-aliasing shaders etc.
This is might get a bit long....
There are 2 distinct stages to surface evaluators (of which NPatch and displacment maps are both a form of).
1) Tesselation
2) Perturbation
The second stage is doable on ALL vertex shader hardware, you want NPatches, want displacement maps, want subdivision surfaces just run it though a vertex shader. You take some input, run it through a basis function (which defines how you perturb the vertex) and voila any surface you like.
But to do this you have to tesselate the base triangle, this isn't programmable (yet) so you either do it on the CPU (could be expensive) or the hardware has a fixed function tesselator.
The fuxed function tesselator on the ATI 9700 was meant to be better than the fixed function tesselator on the ATI 8500, the ATI 8500 can only do integer steps (i.e. level 1 might give you 5 triangles, level 2 might give you 15 triangles) whereas the ATI 9700 was meant to have floating point levels (i.e. level 1 might be 5 triangles and level 2 might still be 15 but level 1.5 would give 10).
That appears to be the only difference between Truform v1 and Truform v2, the fact that lots of people think its much slower on 9700 might indiacate a hardware bug and they've fallen back to software I honestly don't know. The other possiblity why the 9700 seems slower is that AFAIK ATI had dedicated NPatch perturbation hardware in the ATI 8500, it seem likely that they may have removed this and moved its function into the vertex shader (in the same way they moved the entire fixed function vertex pipe into vertex shaders).
Now a clever tesselator would alter the tesselation based on the data (i.e. if your surface is flat, don't add more triangles), this of course makes the 2 stages dependent. This is what the Matrox card does, its fixed function only but tesselates the mesh based on the basis function and the displacement map.
Now whats likely to happen one day, is that we will have a tesselation shader that generates vertices (and triangles) that are passed to a vertex shader that perturbs them. This combined with vertex texturing would give generalised programmable surface evaluators. We can currently do a crude form of vertex texturing (the badly titled pre-sampled displacement maps), have fairly capable vertex perturbation shaders (/plug check out my ShaderX2 article, I'm hoping to put it up here on Beyond3D soon /end plug) but only fixed function or CPU tesselation shaders. Vertex shader V3 gives us proper vertex texturing and I predict DX10 will give us tesselation shaders.
BTW Some people seem to think that we are moving to a Renderman type system with vertex and pixel shaders becoming one, I happen to disagree. While some hardware may be shared, the problem with a single shader approach is the removal of the concept of frequency. For real-time shaders will need to evaluate different things at different rates, I'm personally hoping that DX10 shaders will have advanced frequency concepts (i.e. run this shader every base triangle, this every vertex, this every pixel, this every sub pixel and this every write to the framebuffer). A system like that would give us (with shared memory) tesselation shaders, alpha blender shaders, anti-aliasing shaders etc.
DegustatoR
Legend
TruForm is emulated on CPU on R9600, 9700 and 9800. And AFAIR 9000 too, not sure about it.
Why did ATI choose to do so? I don't know. They could _possibly_ decided to kill TruForm in favor of some more advanced and programmable technics which will come w/ shaders 3.0 or DX10.
Why did ATI choose to do so? I don't know. They could _possibly_ decided to kill TruForm in favor of some more advanced and programmable technics which will come w/ shaders 3.0 or DX10.
Are you sure? Nothing I've seen on HW (or the Refrast) indicates that you get a useful, inbetween number of polygons. AFAICS, the fractional level only allows you to smoothly change from one level to the next without the model popping but the number of polys is increased the instant you go over the threshold.DeanoC said:
I'd be impressed if there was some research that was better but it seems like a really tricky problem!
Simon F said:
I thought Juan Guardado come up with a method while at Matrox for the N-Patch displacement map, IIRC its described in Real time Rendering 2nd edition (Haven't got my copy here to check).
Of course I could have put 2 and 2 together and made 5. I haven't looked that deeply at it and may have just got the wrong end of the stick.
Simon F said:
Hmm. It's not symmetrical. That must make it tricky to join patches together cleanly.
It doesn't appear to gradually add triangles. AFAICS it instantly adds a bunch of degenerate tri's which are gradually slid into place, which is pretty much what I thought was typical.
It looks quite interesting all the same.
Doomtrooper
Veteran
nAo said:
Bahhh, I never said it was the same (your attitude gets old fast)...I said it was a logical extension to a similar technique.
The idea was use low poly models for bandwidth savings, spare me from your 'godly' superior inteligence
I think we've moved way past the point where TrueForm is a useful approach. It was a great idea when heads, arms, hands & fingers, circles, and many other shapes in 3d games were squared because of the lack of polygons supported by the game engines. But it was always a transient technology in my view. Displacement mapping using on-the-fly mapping (instead of pre-computed) I would think would be the next logical step beyond TrueForm. Really, talking about Trueform in present 3d software strikes me a bit like complaining about banding in 16-bit integer display modes...
What do you mean on-the-fly displacement mapping? Do you mean where the displacement map itself is computed on the fly? Or just real displacement mapping, such as the Parhelia does?
The first wouldn't make much sense. The second isn't much like Truform at all.
The natural extension to truform is programmable subdivision surfaces, where the positions of the new triangles are still computed using existing triangle information, but the way they are computed is programmable.
Displacement mapping is a way of passing extra information to the video card for perturbing the extra triangles, which makes it quite a bit different in principle from Truform. Personally, I think I'd rather see a patch-based higher-order surface technique than displacement mapping. At the same time, however, displacement mapping would be good for a few limited situations, such as terrain (if you could make collisions work properly...).
The first wouldn't make much sense. The second isn't much like Truform at all.
The natural extension to truform is programmable subdivision surfaces, where the positions of the new triangles are still computed using existing triangle information, but the way they are computed is programmable.
Displacement mapping is a way of passing extra information to the video card for perturbing the extra triangles, which makes it quite a bit different in principle from Truform. Personally, I think I'd rather see a patch-based higher-order surface technique than displacement mapping. At the same time, however, displacement mapping would be good for a few limited situations, such as terrain (if you could make collisions work properly...).
Myrmecophagavir
Newcomer
Not yet we haven't, even UT2003 benefits from it. I see so many games coming out with blocky-looking characters that would benefit from n-patch support, it makes me cry.WaltC said:I think we've moved way past the point where TrueForm is a useful approach. It was a great idea when heads, arms, hands & fingers, circles, and many other shapes in 3d games were squared because of the lack of polygons supported by the game engines. But it was always a transient technology in my view. Displacement mapping using on-the-fly mapping (instead of pre-computed) I would think would be the next logical step beyond TrueForm. Really, talking about Trueform in present 3d software strikes me a bit like complaining about banding in 16-bit integer display modes...
The trouble with it is it tends to make objects look slightly bigger than they were designed to be, because the surface runs through each original vertex and "outwards" a little as well. But it's pretty minor.
noko said:
An ATi employee 'recently' stated that truform was not dead (scroll down to comment by ATI-ISV):
http://www.rage3d.com/board/showthread.php?s=2ebd3ce543c30537fa4f5f82854dfca3&threadid=33692655
And a list of truform supporting games can be found here:
http://www.ati.com/products/gamesupport/index.html
HTH
P69
Similar threads
