Josh on NV40 & R420

[frost_add]

N-patches aren't going to come back. They're an inflexible HOS technique and are prone to significant graphical artifacts. Hopefully we'll see a programmable primitive processor soon that will allow tessellation in or before the vertex processor, or at least a more interesting HOS technique than N-patches.

I agree about quadratic tesselation mode - it is a problem to make it work right and cannot be just enabled/disabled (artist/tools work needed). However, I think that linear tesselation mode is extremely useful (and probably much cheaper to do in hw). Two examples:
a) dual paraboloid shadow maps depend on tesselation level of scene geometry - useful for these (not that I am fan of this technique)
b) on vs3.0 hw this could allow for displacement mapping the way it was done in Parhelia - I was actually quite hoping for that but NVIDIA GDC slides explicitly mention no tesselation

PS. First post! Had to happen one day

 

[KimB]

Well despite your lack of awareness of them, there have been many. The most appropriate would be DirectX which didn't have a stellar start now did it? Now it dominates. Actually that would describe alot of MS' endevours as would the opposite.

DirectX may have sucked at the beginning, but it was adopted fairly widely very early on. Once developers started moving away from proprietary 3D API's, most went straight for Direct3D.

Regardless, Microsoft is somewhat an exception here. They have had, for a long time now, more than enough money to continue to throw cash into failed software in order to make it successful. Most companies don't.

Surround gaming on the Parhelia may not have legs for Matrox's line, but if SurroundView survives with ATI perhaps it will get a rebirth., especially with the drop in LCD prices

I doubt it will ever catch on significantly. I just don't think most people will ever see the need for multiple monitors.

 

[Lezmaka]

I doubt it will ever catch on significantly. I just don't think most people will ever see the need for multiple monitors.

Even if people want it, most won't be able to afford multiple monitors. Sure, you could buy 3 15" screens, but I would question the person who wants a 15" screen.

 

[jvd]

Err a 5-10 fps framerate drop on my sisters 9600pro is not the end of the world. Not when it makes the game look a whole lot better .

What game? What resolution/FSAA/AF settings? From what framerate to what framerate?

Regardless, the R3xx's truform implementation is much more CPU-hungry than it was with the R2xx.

Also, another big strike against truform is parallax mapping (or holographic texture mapping, or whatever you want to call it). Basically, since N-patches are transparent to the developer, they would break parallax mapping. Since this technique is sure to be used in most games coming out in the near future, I don't see any reason for N-patches support.

Don't know the framerate she just told me the drop.

Res is 1027x 768 and 2x fsaa and 8x aniso.

The only reason you see any mark against it is because its from ati and not from nvidia.


if nvidia supported it and not ati you would be running around telling everyone how bad ati is for not supporting it.

You prob praised the geforce and its tnl even though by the time a game used tnl its tnl engine performed worse than the cpus of the tiem

 

[T2k]

Surround gaming on the Parhelia may not have legs for Matrox's line, but if SurroundView survives with ATI perhaps it will get a rebirth., especially with the drop in LCD prices

I doubt it will ever catch on significantly. I just don't think most people will ever see the need for multiple monitors.

I bet you never tried.

I remember playing UT2k3 w/ Parhelia and my ex 3x 21" CRT - I had a lot of FUN at the time.

I foung something for the Truform subject:

OFF:

ON:

Last post here: http://ubbxforums.ubi.com/6/ubb.x?a=tpc&s=400102&f=452106891&m=337108923

Dunno it's real or not, I haven't had a chance to check yet in UT2k4 but I'll do it.

 

[Lezmaka]

For games that are designed with Truform in mind, there isn't much of a performance drop. For games not designed for it, the drop can be quite large.

 

[anaqer]

Just checked Soldier of Fortune II ( v1.3 ) and fiddling with r_ext_ati_pntriangles / r_ext_ati_tesslevel gives no noticable difference on character models, same with Return to Castle Wolfenstein ( v1.4 )...

 

[demalion]

Check your control panel and see if Truform is always off or application preference.

 

[micron]

I foung something for the Truform subject:

Wow!...thanx for posting that T2K

 

[T2k]

Just checked Soldier of Fortune II ( v1.3 ) and fiddling with r_ext_ati_pntriangles / r_ext_ati_tesslevel gives no noticable difference on character models, same with Return to Castle Wolfenstein ( v1.4 )...

You mean

seta r_ati_truform_pointmode "GL_PN_TRIANGLES_POINT_MODE_LINEAR"
seta r_ati_truform_normalmode "GL_PN_TRIANGLES_NORMAL_MODE_LINEAR"
seta r_ati_truform_tess "1"
seta r_ext_ATI_pntriangles "0"

IIRC tess value sets the strength, from 1 to 7, min to max.

BTW, is this installed? http://hrc.webzeppelin.hu/Patches-By_T2k!/TRUFORM%99_patches-By_T2k!/wolf_update_132.exe

If so, you messed up something there: IIRC RTCW had some nice, noticeable effect.

 

[T2k]

I foung something for the Truform subject:

Wow!...thanx for posting that T2K

NP. I'll give it a try in UT2k4 now, hold on...

 

[T2k]

Here are my shots: http://hrc.webzeppelin.hu/-=Utils=-/ut2k4/truform_enabled/

Working, nice.

Edit 'NPatches' to 'True' under your corresponding D3D section in UT2004.ini - for me it's D3D9... then set your desired tesselation value in the next line.
These shots taken with '5.0'

FYI: enabling like this takes a HUGE hit on your frame rate!

Edit: typos

 

[Mintmaster]

Also, another big strike against truform is parallax mapping (or holographic texture mapping, or whatever you want to call it). Basically, since N-patches are transparent to the developer, they would break parallax mapping. Since this technique is sure to be used in most games coming out in the near future, I don't see any reason for N-patches support.

Are you talking about this? Why would it break it? It's just an approximation done by using the height of a bumpmap (scaled by some angle dependent function) to perturb texture coordinates. Nothing is affected by N-patches that wouldn't be just linearly interpolated anyway.

However, I do agree with your view that N-patches doesn't have much of a future, especially since R300 dropped hardware support. I think HOS in general won't be very useful for games at runtime, but you never know.

 

[KimB]

Surround gaming on the Parhelia may not have legs for Matrox's line, but if SurroundView survives with ATI perhaps it will get a rebirth., especially with the drop in LCD prices

I doubt it will ever catch on significantly. I just don't think most people will ever see the need for multiple monitors.

I bet you never tried.

I'm not saying it's not great. Multiple monitors are definitely one thing I plan to buy, but I just don't have the cash just yet (besides my desk is currently too small, so it'd be a big change), and have other things I want to buy.

But I just don't think most people will bother. I suspect multiple monitors will always be a niche thing.

 

[KimB]

Why would it break it? It's just an approximation done by using the height of a bumpmap (scaled by some angle dependent function) to perturb texture coordinates. Nothing is affected by N-patches that wouldn't be just linearly interpolated anyway.

The position of the pixel being rendered is affected. I believe this will make the model less resemble the higher-resolution map that a "poly-bump" style model is meant to imitate, and should lead to artifacts which will be particularly noticeable on regular surfaces.

 

[Mintmaster]

Why would it break it? It's just an approximation done by using the height of a bumpmap (scaled by some angle dependent function) to perturb texture coordinates. Nothing is affected by N-patches that wouldn't be just linearly interpolated anyway.

The position of the pixel being rendered is affected. I believe this will make the model less resemble the higher-resolution map that a "poly-bump" style model is meant to imitate, and should lead to artifacts which will be particularly noticeable on regular surfaces.

I still don't see the problem. If anything, it will more resemble the original high-poly model. The normals, tangent vectors, and texture coordinates will be interpolated pretty much identically, unless you do the fancier quadratic interpolation, but even then you can just recalculate the tangent vectors. The position moves, but all the relevant rendering parameters of that "pixel" will remain the same. The effect will be just how you expect.

A model with messed up normals will always screw up TruForm, but I don't see how "poly-bump" style models or any other bump-mapped model should have incorrect normals anyway. This usually only arises from modelling tools that don't bother to duplicate vertices at sharp edges or corners.

If bumpmapping looks right with TruForm (which it does), then there won't be any problem with holographic texture mapping. The offset will basically be s * (E dot U, E dot V) multiplied by per pixel height, or something similar, and these quantities will be interpolated just how they should be.

Can you describe me a situation which will make noticeable artifacts?

 

[Hyp-X]

A model with messed up normals will always screw up TruForm, but I don't see how "poly-bump" style models or any other bump-mapped model should have incorrect normals anyway. This usually only arises from modelling tools that don't bother to duplicate vertices at sharp edges or corners.

If you duplicate the vertices for sharp edges, the N-patch tesselated model will have cracks...

 

[KimB]

Can you describe me a situation which will make noticeable artifacts?

First a simple texture-mapping example:
Applying N-patches changes the area of the surface, and therefore the texture is stretched, and it will be stretched non-uniformly for more complex surfaces. Obviously this will affect bump maps in the exact same way.

Additionally, parallax/holographic mapping displaces the apparent position of a pixel from the surface of the triangle. So, since a "polybump" object will assume that the bumps are being displaced some specific distance from the triangle surfaces, changing the triangle into some sort of curve will displace that surface.

Here's an example that should easily be visible:
Imagine a polybump cylinder. The polybump makes the cylinder appear perfectly round, despite having fairly large facets (plus some surface grain, of course). Now we'll use N-patches, and assume that N-patches makes the cylinder perfectly round. The polybump-generated normal map will still assume that the cylinder still has large facets, and so you will end up with periodic bulges on the cylinder.

Of course, you could possibly get around this, but that would require having stored separate normal maps for each possible amount of tesellation.

 

[Mintmaster]

A model with messed up normals will always screw up TruForm, but I don't see how "poly-bump" style models or any other bump-mapped model should have incorrect normals anyway. This usually only arises from modelling tools that don't bother to duplicate vertices at sharp edges or corners.

If you duplicate the vertices for sharp edges, the N-patch tesselated model will have cracks...

Wouldn't that only happen if your normals aren't perpendicular to the faces? I guess you could have some precision problems, and some sharp intersections are rounded in the other direction.

Anyway, I didn't necessarily mean separating the edges. You could put a degenerate quad in these edges so that you could have multiple normals at one location. The main problem is that if you have a sharp edged object, like a cube for example, you shouldn't have normals averaging neighboring faces, even for non-truform models. There should be multiple normals at each vertex. Disabling gourad shading works, but only if the entire object is supposed to look faceted.

 

[Mintmaster]

Can you describe me a situation which will make noticeable artifacts?

Here's an example that should easily be visible:
Imagine a polybump cylinder. The polybump makes the cylinder appear perfectly round, despite having fairly large facets (plus some surface grain, of course). Now we'll use N-patches, and assume that N-patches makes the cylinder perfectly round. The polybump-generated normal map will still assume that the cylinder still has large facets, and so you will end up with periodic bulges on the cylinder.

I don't think that's right. First of all, the polybump wouldn't look perfectly round because the bump mapping only affects the normals. If the cylinder was rotating, you'd definately see the specular highlights moving back and forth.

Secondly, the normals and tangent vectors are linearly interpolated across the N-patch surface the same way they're interpolated across a regular triangle. The normals will be the same for corresponding pixels.

However, I was thinking more about ordinary bumpmapping where you use the same bumpmap on a variety of surfaces and maybe even tile as well. In the polybump technique augmented with the parallax mapping, each texel has a unique location on a model, and in this case, you can tailor the height of each parallax value not only to the corresponding bump map, but also to it's specific point on the mesh.

Good point. Do you know if any of the current polybump generators are implementing parallax mapping yet?