Radeon 9700 not all that? - Page 15

Mono · 09-28-02, 11:38 PM

Quote:

Originally posted by Chalnoth

It's more for developers. What I was speaking about specifically was OpenGL extensions.

As for Truform, I don't really care.

of course you don't, you don't have it

ha, first post here and already making friends.

Chalnoth · 10-03-02, 01:50 AM

Actually, I've explained a number of times why I don't like Truform. There are a number of reasons.

First of all, from a programming perspective (I'm sort of an off-and-on hobbyist programmer), there is no possible way that I could, for example, write code that would automatically make any model look good with truform enabled. It's just not possible. For this, you truly need a fully-generalized HOS technique available (It doesn't look like we'll see one for about 6-8 months in a consumer card, at the very least...though the rumored Primitive Processor that nVidia may be developing would be just what the doctor ordered). I had thought for a while that the RT-patches support in the GeForce3/4 cards would be general enough, but it seems that developers weren't so enthusiastic, and support has been dropped entirely (It was dropped in D3D a long time ago, and just recently dropped in OpenGL).

The second reason that I don't like Truform is that it always seems to produce undesirable effects on certain models. I'm of the opinion that even if it makes 99% of the game look better, but 1% of the game look worse, then it is not worth turning on. That is, a game only looks as good as its worst-looking part. I have yet to see sufficient evidence that any game has been able to satisfactorily enable Truform in every situation.

The third reason relates to the lifetime of Truform. Due to the hours required of the artists to modify their models for Truform, and also due to the increasing performance hits from increasing polycounts (See the UT2k3 Demo), it just seems obvious that Truform simply is not going to be viable going into the future.

As an aside, subdivision surfaces are not a totally useless concept, it's just that Truform uses the most basic and ugliest version of them. If we see more subdivision surfaces in the future, as opposed to other HOS techniques, hopefully they'll use much better techniques in generating the new surfaces. Actually, what I hope is that we both see a superior subdivision surface technique (that doesn't show the balooning effects of Truform...something that is most certainly possible), as well as a fully-generalized primitive processor. One thing to note, however, is that it is far from trivial to have backwards-compatibility with any sort of generalized HOS implementation for older hardware that does not support that particular HOS technique. Hopefully we'll see a standard technique arising soon...and, perhaps even more importantly, that that hardware implementation quickly filters down to the low-end.

jbirney · 10-03-02, 07:57 AM

Quote:

Due to the hours required of the artists to modify their models for Truform, and also due to the increasing performance hits from increasing polycounts (See the UT2k3 Demo), it just seems obvious that Truform simply is not going to be viable going into the future.

You do realize that there is a plug in for Max made by ATI that turns this "hours required" into a 3 clicks and you done thing, right? Also I find it funny that even with the massive increase in polys that UT2k3 has, epic still thought to put truform in the game and have it work more or less with out side effects?

**saturnotaku** · 10-03-02, 09:15 AM

Quote:

Originally posted by jbirney
epic still thought to put truform in the game and have it work more or less with out side effects?

Describe "more or less." Is it buggy? Are there points in the game where it doesn't work?

Chalnoth · 10-03-02, 09:43 AM

Quote:

Originally posted by jbirney
You do realize that there is a plug in for Max made by ATI that turns this "hours required" into a 3 clicks and you done thing, right? Also I find it funny that even with the massive increase in polys that UT2k3 has, epic still thought to put truform in the game and have it work more or less with out side effects?

"Hours required" refers to the amount of time needed to adjust all game geometry for which Truform is enabled. All that I had heard was that ATI made a "Truform viewer" for 3DSMax.

jbirney · 10-03-02, 12:01 PM

If you want I think I still have the link for the pluging that converts the models to be "truform" ready as its on ATI's devloper site. Also dont forget you can turn on truform only for models that support it (like the option in SS:SE) thus not effecting any other model then they ones you wanted.

Chalnoth · 10-03-02, 04:49 PM

Oh, that reminds me. There's another problem with Truform.

In order to "fix" the problems of Truform, it is certainly required to make the normals of at least some of the vertices of adjacent triangles different. Since doing this adjusts lighting calculations, this will lead to discontinuities in lighting. For this reason, I have a hard time believing that "auto-Truform" would always produce a good image, even if it might resemble the low-detail geometry accurately.

This also begs the question of vertex caching. Unless ATI also has a plugin for automatically optimizing Truform-optimized meshes, then those meshes optimized for Truform could be quite a bit less efficient. As a point of interest, has anybody checked to see whether running this "auto-Truform" plugin increased file size for the mesh?

jbirney · 10-03-02, 09:40 PM

Good point but I dont have Max anymore so I can not try it out.

Chalnoth · 10-04-02, 02:01 AM

Quote:

Originally posted by jbirney
What worries me is the drivers for the nv30.

Last time nV majorly changed designs was from the GF2 to a GF3. Out of the gate GF3 had driver issues.

Out of the gate, the GF3 had performance issues related to immature drivers. The drivers were quite stable at launch.

Then again, the GeForce3 had lower hardware specs than the GeForce2 Ultra, so there's no reason why it certainly had to outperform it in all situations at all.

jbirney · 10-04-02, 07:32 AM

Quote:

Originally posted by Chalnoth

Out of the gate, the GF3 had performance issues related to immature drivers. The drivers were quite stable at launch.

Then again, the GeForce3 had lower hardware specs than the GeForce2 Ultra, so there's no reason why it certainly had to outperform it in all situations at all.

I would call holding back reviews unitl nV felt the drivers were ready as driver issues. Also with all of the new technology in the GF3 it should have never lossed to the GF2 Ultra (crossbar mem being just one of the new tech it had over the older).

Chalnoth · 10-04-02, 08:56 AM

Obviously the new memory bandwidth saving techniques weren't being used to their fullest at launch, were they? The card was still very stable, and still performed very well in situations where it counted: 32-bit, FSAA.

And not allowing reviewers to publish benchmarks doesn't constitute "driver issues." That's more "PR issues."

Kruno · 10-04-02, 09:04 AM

Are you sure Nvidia were not just saving the performance for later competition by Ati?

10-04-02, 09:04 AM	#180
Kruno TypeDef's assistant Join Date: Jul 2002 Location: Australia Posts: 1,641	Are you sure Nvidia were not just saving the performance for later competition by Ati? __________________ "Never before has any voice dared to utter the words of that tongue in Imladris, Mr. Anderson" - Elrond LOTR

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
R9700 Oficially Announced	druga runda	Other Desktop Graphics Cards	20	04-25-08 10:28 PM
Get a Radeon 9700 now or wait for the NV30?	sancheuz	Other Desktop Graphics Cards	88	02-19-03 04:40 PM
FalconNW and Voodoo under ATI 9700 spell!!!	mizzer	Other Desktop Graphics Cards	12	09-20-02 07:53 PM
Radeon 9700 pics	-=DVS=-	Other Desktop Graphics Cards	12	08-01-02 09:35 AM
Are there any comparisons of the GeForce4 Ti 4600 to the Radeon 9700 yet?	john19055	NVIDIA GeForce 7, 8, And 9 Series	8	07-28-02 02:07 PM

10-03-02, 01:50 AM	#170
Chalnoth Registered User Join Date: Jul 2002 Posts: 1,293	Actually, I've explained a number of times why I don't like Truform. There are a number of reasons. First of all, from a programming perspective (I'm sort of an off-and-on hobbyist programmer), there is no possible way that I could, for example, write code that would automatically make any model look good with truform enabled. It's just not possible. For this, you truly need a fully-generalized HOS technique available (It doesn't look like we'll see one for about 6-8 months in a consumer card, at the very least...though the rumored Primitive Processor that nVidia may be developing would be just what the doctor ordered). I had thought for a while that the RT-patches support in the GeForce3/4 cards would be general enough, but it seems that developers weren't so enthusiastic, and support has been dropped entirely (It was dropped in D3D a long time ago, and just recently dropped in OpenGL). The second reason that I don't like Truform is that it always seems to produce undesirable effects on certain models. I'm of the opinion that even if it makes 99% of the game look better, but 1% of the game look worse, then it is not worth turning on. That is, a game only looks as good as its worst-looking part. I have yet to see sufficient evidence that any game has been able to satisfactorily enable Truform in every situation. The third reason relates to the lifetime of Truform. Due to the hours required of the artists to modify their models for Truform, and also due to the increasing performance hits from increasing polycounts (See the UT2k3 Demo), it just seems obvious that Truform simply is not going to be viable going into the future. As an aside, subdivision surfaces are not a totally useless concept, it's just that Truform uses the most basic and ugliest version of them. If we see more subdivision surfaces in the future, as opposed to other HOS techniques, hopefully they'll use much better techniques in generating the new surfaces. Actually, what I hope is that we both see a superior subdivision surface technique (that doesn't show the balooning effects of Truform...something that is most certainly possible), as well as a fully-generalized primitive processor. One thing to note, however, is that it is far from trivial to have backwards-compatibility with any sort of generalized HOS implementation for older hardware that does not support that particular HOS technique. Hopefully we'll see a standard technique arising soon...and, perhaps even more importantly, that that hardware implementation quickly filters down to the low-end.

10-03-02, 12:01 PM	#174
jbirney Registered User Join Date: Jul 2002 Posts: 1,430	If you want I think I still have the link for the pluging that converts the models to be "truform" ready as its on ATI's devloper site. Also dont forget you can turn on truform only for models that support it (like the option in SS:SE) thus not effecting any other model then they ones you wanted.

10-03-02, 04:49 PM	#175
Chalnoth Registered User Join Date: Jul 2002 Posts: 1,293	Oh, that reminds me. There's another problem with Truform. In order to "fix" the problems of Truform, it is certainly required to make the normals of at least some of the vertices of adjacent triangles different. Since doing this adjusts lighting calculations, this will lead to discontinuities in lighting. For this reason, I have a hard time believing that "auto-Truform" would always produce a good image, even if it might resemble the low-detail geometry accurately. This also begs the question of vertex caching. Unless ATI also has a plugin for automatically optimizing Truform-optimized meshes, then those meshes optimized for Truform could be quite a bit less efficient. As a point of interest, has anybody checked to see whether running this "auto-Truform" plugin increased file size for the mesh?

10-03-02, 09:40 PM	#176
jbirney Registered User Join Date: Jul 2002 Posts: 1,430	Good point but I dont have Max anymore so I can not try it out.

10-04-02, 08:56 AM	#179
Chalnoth Registered User Join Date: Jul 2002 Posts: 1,293	Obviously the new memory bandwidth saving techniques weren't being used to their fullest at launch, were they? The card was still very stable, and still performed very well in situations where it counted: 32-bit, FSAA. And not allowing reviewers to publish benchmarks doesn't constitute "driver issues." That's more "PR issues."