[Reverend]

Wouldn't work coz if there's no booze I'll look for girls.

Is this thread dead?

[jimmyjames123]

Originally Posted by Demirug

I do not believe it I allready know it.

You know that it can easily be done on R3xx hardware, even with the relatively small maximum instruction limits? I'm trying to get a better understanding here of exactly why that is.

No, because this is a different situation. In the case of the new lightmodel the make it only available to SM3 hardware even if it can done with SM2 hardware. 3dc is something you can only do with 3dc hardware.

Naturally 3dc can only be done on 3dc hardware, just as SM 3.0 can only be done on SM 3.0 hardware. Now, we already know that there are some workarounds that can be used to create certain effects on SM 2.0 hardware that were originally designed to work on SM 3.0 hardware. Isn't there a compression scheme that can be utilized on non-3dc hardware that will approach (albeit, perhaps not equal) the effectiveness of 3dc? If I recall correctly in the Humus demo thread on 3dc, some people were claiming that, when used effectively, DXT could approach the effectiveness of 3dc.

[Dave Baumann]

I don't think there is anyone in this thread that would disagree to DXT5 fallback normal map compression should the developer wish to include it, as that will provide some benefit to the majority of users. However, the situation may not be entirely analoguous.

In the case of 3Dc vs DXT5 compression there will be a slight quality drawback for the DXT5 method, hence the only way of getting 3Dc quality is by using 3Dc hardware. However, it appears that in the case of the shaders in Far Cry it may well be the case they can be coded in such a fashion that they are qualitatively equivelent on SM2.0(+) hardware as they are under the current SM3.0 path.

[Demirug]

Originally Posted by jimmyjames123

You know that it can easily be done on R3xx hardware, even with the relatively small maximum instruction limits? I'm trying to get a better understanding here of exactly why that is.

Maybe you have missed one of my posts. It is not possible to get each combination of 4 lights in the 2.0 limits. But you still can pack as many lights as possible in one pass and use more than one pass for all lights. This will reduce the number of passes even on a SM2.0 chip. Less passes = more performance. SM2.X is better because each combination will work.

Originally Posted by jimmyjames123

Naturally 3dc can only be done on 3dc hardware, just as SM 3.0 can only be done on SM 3.0 hardware. Now, we already know that there are some workarounds that can be used to create certain effects on SM 2.0 hardware that were originally designed to work on SM 3.0 hardware. Isn't there a compression scheme that can be utilized on non-3dc hardware that will approach (albeit, perhaps not equal) the effectiveness of 3dc? If I recall correctly in the Humus demo thread on 3dc, some people were claiming that, when used effectively, DXT could approach the effectiveness of 3dc.

Sure, DXT give you the same effectiveness as 3dc but not nessary the same optical result. Write shadercode that can use each possible solution (uncompressed, DXT, 3DC) is easy. It will more work to check each texture if it can compressed well with 3dc and or DXT.

[digitalwanderer]

Originally Posted by Reverend

Is this thread dead?

Nope, it's just getting interesting.

What's your poison Rev, I'm buying...

[digitalwanderer]

Originally Posted by Reverend

That would depend on whether you're a Doomtrooper/Hellbinder or a Chalnoth/radar1200gs.

Hey! :?

That is a pretty low-blow on Chalnoth, he's better than that...

[jimmyjames123]

Personally, I would be very interested in seeing what Crytek could do with modifications for SM 2.0/2.0+, DXT, etc. Maybe in a future patch? Perhaps wishful thinking, but would be nice nevertheless.

[jvd]

Originally Posted by Reverend

That would depend on whether you're a Doomtrooper/Hellbinder or a Chalnoth/radar1200gs.

well i own a x800xt pe. Soooooo

[Pete]

Originally Posted by Reverend

There are things happening at Crytek that you guys don't know (but of which you would jump up and down screaming if you do know).

Originally Posted by Pete

I'm taking the very cynical route and assuming Crytek's SM3.0 banner-waving is induced by a financial arrangement with nVidia, which may have been further induced by their recent software-related legal troubles. I'm probably giving them way too little credit, but I'm casting a very suspicious eye on shader-heavy games from relatively new/smaller devs with strong IHV affiliations ATM.

[Quitch]

Originally Posted by Pete

Wouldn't surprise me if they've taken a donation from nVidia for SM3 support and from ATI for 3dc support. I have a bit more sympathy for ATI since, as Dave said, you have to have 3dc hardware for 3dc, but with the "SM3" shaders they've done...

[Chalnoth]

Wouldn't surprise me if they've taken a donation from nVidia for SM3 support and from ATI for 3dc support. I have a bit more sympathy for ATI since, as Dave said, you have to have 3dc hardware for 3dc, but with the "SM3" shaders they've done...

1. Since we don't yet have the final patch, we don't yet know if those SM3 shaders that have been written will be ported back to SM2.
2. Not all of the shaders are possible with SM2 (any version).

[Evildeus]

Well the patch is now available:
http://www.fileshack.com/file.x?fid=4787
http://www.3dgamers.com/dl/games/far...tch12.exe.html

[kipper67]

There's a few interesting bits in the log files after upgrading to 1.2

Using '3Dc' pixel texture format

HDR Rendering: MRT
MRT Rendering: Disabled

Use Hardware Shaders for ATI R420 GPU
Pixel shaders usage: PS.2.B, PS.2.0 and PS.1.1

Well they're interesting to me - the mention of 3Dc and PS.2.B would seem to suggest Crytek aren't solely concerntrating on the 68XX line of cards .

Mark

[Ruined]

Originally Posted by hovz

apparently vertex instancing is completely useless.

now every time i read some uninformed jackass rant on about shader model 3 in the current gen i will just post this

From 1.2 patch:

v1.2 SM2.0 - 51,213 polygons, 69fps

v1.2 SM3.0 - 46,139 polygons, 73fps

Well, that argument was just proven wrong

Note the # of polygons from the exact same position.

[hovz]

try disabling the pixel shader optimizations and see how the fps compares.

[Bouncing Zabaglione Bros.]

Originally Posted by Ruined

Note the # of polygons from the exact same position.

Errr, but if the scene has less polygons, wouldn't that account for the (massive) five frame difference?

Or are you saying that the two scenes have the same number of polygons, but that instancing means that the game pushes less polygons to the card, and the card makes up the difference via instancing, thus giving you a peformance advantage for the same number of polygons?

I have to say, that five frames are not exactly the stellar improvement Nvidia was pimping.

[Ylandro]

Originally Posted by Ruined

From 1.2 patch:

v1.2 SM2.0 - 51,213 polygons, 69fps

v1.2 SM3.0 - 46,139 polygons, 73fps

Well, that argument was just proven wrong

Note the # of polygons from the exact same position.

Please (re)read the review quoted at the start of this thread. While it was confirmed that instancing works and is used, it seemed to give no significant performance gain. Turning it off didn't change performance. Those 4 fps came from the other changes in the SM3.0 codepath.

So it's not so strange that 'hovz' considers vertex instancing useless, when it apparantly doesn't give any gains in performance or image quality.

What makes it worse, is that I would consider Farcry a game that would benefit most from instancing. All those trees, grass, foilage and stuff should make a best-case scenario. Quite unlike other games. Can't image games like Doom3 or HL2 having much use for instancing. Unless HL2 includes a scene like in Starship troopers, where you see millions of these creepers invading a base.

Otoh... that games, that were developed before instancing is available, don't have much use for it, doesn't necessarily mean future games can't use it in a meaningfull way. Maybe it's just difficuly to patch in afterwards...

[Hanners]

I'm running some SM 2.0 vs 3.0 path testing right now - I have to say, there is a performance improvment in the 3.0 path, but its magnitude isn't matching up to the numbers seen prior to the patches release thus far...

[Kombatant]

Anyone that wants to speculate? From R3D's front page:

Well, looks like FarCry's 1.2 patch is finally out. The v1.2 patch contains a number fixes in which alot of ATi users have been extremely pleased so far. I asked Terry Makedon at ATI if there is anything specific to ATI in the patch. His response was:

With that being mentioned above, i can assure you that most of your jaws will be dropping to the ground when this news is finally upon us.

[Demirug]

The poly count is different because FC counts every poly that is renderd. If it need 3 passes for one object all polys of this objects count 3 times. SM3/SM2B need less paases per object. This will reduce the polycount.

object instancing will not reduce the polycount it will only reduce the number of drawcalls. Drawcalls are not counted from Far Cry.

[Demirug]

Originally Posted by Kombatant

Anyone that wants to speculate? From R3D's front page:

No reason to speculate. There is a SM2B Path in the Patch. I am allready have a look at the shadercode. It is the same method that is used for the SM3 Path.

[Kombatant]

Originally Posted by Demirug

No reason to speculate. There is a SM2B Path in the Patch. I am allready have a look at the shadercode. It is the same method that is used for the SM3 Path.

If you see no reason, fine by me.

[Bouncing Zabaglione Bros.]

Originally Posted by Kombatant

Anyone that wants to speculate? From R3D's front page:

Next official ATI Catalyst release is what, two or three weeks away?

[JBark]

Originally Posted by Hanners

I'm running some SM 2.0 vs 3.0 path testing right now - I have to say, there is a performance improvment in the 3.0 path, but its magnitude isn't matching up to the numbers seen prior to the patches release thus far...

Are you seeing SM2.0 improvements from 1.1 -> 1.2? Maybe the SM2.0 path was improved upon as well?

Demirug, is the SM2B path used by default if your card supports it, or do you have to specify something like \r_SM2BPATH 1 to enable it? If it's enabled by default, then could that explain why there is little perf diff between the SM2 and SM3 paths?

Could I ask any more questions?

[Kombatant]

Originally Posted by Bouncing Zabaglione Bros.

Next official ATI Catalyst release is what, two or three weeks away?

Yes, I believe so; but judging from the nature of Terry's post, I would assume that it will be a bit sooner (speculating here)