Truform in RTCW

pcchen said:
AFAIK it is not a purely software scheme. The problem is GF3 has only iterators (for HOS) in hardware, and set-up works have to be done by softwares (not possible by vertex shader since vertex shader applies after vertex iteration). Therefore, unless very high level tessellation is used, the overhead with HOS can be very high.

Oh, sorry my bad, I guess. I learned that from what seemed to be a conclusion in an older thread on the older form.(Of course I can't find it.) But their conclusion was that there was no hardware support on the GF chips at all and that it was done only in software. I am not sure who exactly it was that made the comment but their conclusion seemed to rather absolute. Anyhow pcchen, thanks for the enlightenment. :oops: I will ask around to see if I can find out if this is the case because it seems contradictory to what I read somewhere once.

Sabastian
 
pcchen said:
There is a GF3 FAQ talking about this issue:

http://developer.nvidia.com/view.asp?IO=geforce3_faq

The questions #19 ~ #21 talked about HOS support issues, and #37 talked about HOS performance issues. I don't know if GF4 has any changes to this.

Thanks for the link. Hmm they say that RT-patches are superior but if the hardware doesn't work well enough then bother touting it at all. I would like to see a good working HOS on an nvidia card but really haven't heard anything about it, even on the GF4. Thanks again.

Sabastian
 
hmm, what I read about the GF3/4 and HOS is that it was disabled, at least in DX, b/c if a truform enabled game sees the GF3 supports HOS, it'll try to run on the GF3/4, b/c the device caps says HOS are supported. However, since truform is a different technique, the GF3/4 will fall back to software, making the game run very, very slow. So it's not an issue of the HOS on the GF3/4 not working, or running in software, it's an issue of games trying to get the card to run HOS that it doesn't support. I guess since there aren't any games out there that support NVIDIA's method of HOS, they figured the easiest way to solve the problem was just disable HOS.
 
Tagrineth said:
Actually TRUFORM is faster than high-poly T&L because of one easy to understand factor... memory bandwidth. TRUFORM takes up no extra bandwidth, just extra cycles.

And you know for a fact that your always have [free] cycles to burn as opposed to always being limited by memory bandwidth?

I know that it makes [easy] sense - and I would like to believe, but:

1) I was looking for performance numbers to settle this once and for all.
2) I guess there was a reason why John Carmack talked against nVidia including HOS in GF3 and thus prefering polygons. (Note: I know that Truform is different and may have some great avantages over GF3's HOS, but still...)

Just wondering out loud!

REgards, LeStoffer
 
Hi rhink,
hmm, what I read about the GF3/4 and HOS is that it was disabled, at least in DX, b/c if a truform enabled game sees the GF3 supports HOS, it'll try to run on the GF3/4, b/c the device caps says HOS are supported. However, since truform is a different technique, the GF3/4 will fall back to software, making the game run very, very slow.
This is a fairly insubstancial rumour that has been spread by the allmighty Inquirer. D3D applications don't just check for general HOS support, but for specific HOS support (N_PATCH, RT_PATCH). No NV driver supports NPatches, and certainly can't emulate them in software, transparently to the application in question.

ta,
.rb
________
glass pipes
 
Last edited by a moderator:
yeah, I was curious about that. I thought it sounded pretty stupid to expose both HOS mechanisms through the same D3D cap. Thanks for clearing that up.
 
http://www.theinquirer.net/05120104.htm

GEFORCE 3 and its derivatives included a nice feature called HOS (Higher Order Surface) implemented by a polynomial surfaces technique, and a few days back we asked Nvidia if this HOS had gone to the knacker's yard.
It has been disabled, Nvidia confirmed.

Nvidia's HOS technology is a similar approach to ATi's Truform, but rather more advanced, although games developers need to be more involved in its interaction than with the latter technique.

It's a two edged sword. Developers need to remodel the character – which means hard work, time and money. Characters would be easier to render and would have less polygons since the Nvidia implementation uses a feature called adaptive tessellation.

Truform, which are really N patches, just need a few lines of code and a few hours of work, to make a game look better, so my friends from Croteam, the developers of Serious Sam, tell me.

Why did Nvidia disable HOS? The answer the techies gave us was because the "few games: that use Truform technology, by default turn on the software implementation of N Patches on Nvidia cards and that results in unacceptably slow frames per second (FPS).

The real answer is that Nvidia does not have any hardware implementation of Truform. That's because it's ATi's technology.

As I personally know of three major games that use this ATI feature, it appears that Nvidia didn't want to take any chances and to give their users a hard time and slow FPS on Geforce 3 TI 500 cards. So it was simply disabled.

Software emulation of Truform technology on Geforce 3 cards slows down the game.

So with the new drivers the HOS has gone to the knacker's yard, and no problems will occur, but this still begs the question why Nvidia developed it in the first place.

One developer who knows a thing or two about the HOS implementation told the INQ that he does not expect to see games using polynomial surfaces within the next six to 18 months.

Truform already has a few supporters and a potential for growth, but we wonder if there is a future for polynomial surfaces

This is from Digit-Life:


The drivers of the NV20 and NV25 do not support hardware tessellation of smooth surfaces (HOS based on RT-Patches). When a card doesn't support N-Patches on a hardware level the API tries to emulate them using RT-Patches. It makes operation of N-Patches very slow. NVIDIA thus had to disable the RT-Patches so that games supporting N-Patches won't be too slow.

http://www.digit-life.com/articles/gf4/index1.html

So if these two articles are not true then why disable HOS ?
 
Hi DT,

check pcchen's posting on page one, and the information found therein.

My personal guess would be a combination of what he (and the site) mentions, and marketing tactics / politics . . . Richard Huddy was nice enough to ask on the DXDEV mailing list whether removing HOS support would bother anybody, and there were no reactions. He didn't supply any reasons for that step, though.

Regarding the DigitLife quote, thanks! On the other hand side, I would be very interested to learn how the API is supposed to automatically emulate N-Patches using polynomial surfaces . . . ;)

ta,
.rb
________
Honda CM200T
 
Last edited by a moderator:
Isn't it possible ATi could force a game to use TruForm through drivers regardless or not if the game actually enables it? Much like FSAA...
 
It is possible, but it is not a good solution. First of all, N-patch creates a lot of new triangles. Therefore, a good application should use N-patch on those models which matter most, and perhaps with an adaptive scheme (farther objects have fewer tessellation). Second, force enabling N-patch can make games show strange models since many games don't have models tuned for N-patch.

So it may be a nice experiment to force N-patch on some games, but it is not a generally good solution.
 
Mystiq said:
Isn't it possible ATi could force a game to use TruForm through drivers regardless or not if the game actually enables it? Much like FSAA...

That was an idea ATi thought about in the early days, but it turned out to be impossible to make a solid implementation. The problem is first of all that the app must send normals, and even if it does it's still impossible for the driver to know whether it's something that can be truformed or if it's intended to be just flat.
 
Back
Top