NV40 supports 3Dc

[wireframe]

Well, I can see artifacts on both 3Dc and DXT5, this is 3Dc:

http://bbs.gzeasy.com/index.php?act=Attach&type=post&id=223447

and this is DXT5:

http://bbs.gzeasy.com/index.php?act=Attach&type=post&id=223448

3Dc is doing better in places near the viewpoint, but the lighting is messed up at the far side.

If I recall correctly there was some discussion about the DXT5 normal maps not having been compressed "correctly" in this demo. I suppose this is not relevant in the sense that we are hoping to see "correctly compressed 3Dc" normal maps, but it is something to consider when comparing the two.

 

[wireframe]

I'm using a 6800 Ultra with ForceWare 67.02. The Project log is telling me 3Dc is not supported and Humus' 3Dc demo is not allowing me to toggle the 3Dc switch (set to False). Are you sure you are not doing something else or have used some other drivers that set this switch in the registry?

I have this in my Registry: D3D_54082152=hex:00,10,3c,3c

 

[991060]

I've done nothing unusual, just re-installed 67.02(from 70.41), I dont have that key in my registry.

BTW, I forgot to enable AF when testing, now 3Dc works fine, and it's slightly faster than DXT5.

 

[wireframe]

I've done nothing unusual, just re-installed 67.02(from 70.41), I dont have that key in my registry.

BTW, I forgot to enable AF when testing, now 3Dc works fine, and it's slightly faster than DXT5.

It's possible that 70.41 activated the 3Dc support then and when you reinstalled 67.02 it remained activated; 67.02 supporting 3Dc four-CC but not activating it.

 

[pino]

I've done nothing unusual, just re-installed 67.02(from 70.41), I dont have that key in my registry.

BTW, I forgot to enable AF when testing, now 3Dc works fine, and it's slightly faster than DXT5.

It's possible that 70.41 activated the 3Dc support then and when you reinstalled 67.02 it remained activated; 67.02 supporting 3Dc four-CC but not activating it.

yeah i think so, never used Rivatuner but tried 70.41 before and now i have 3dc with 67.02.

 

[Demirug]

I've done nothing unusual, just re-installed 67.02(from 70.41), I dont have that key in my registry.

BTW, I forgot to enable AF when testing, now 3Dc works fine, and it's slightly faster than DXT5.

It's possible that 70.41 activated the 3Dc support then and when you reinstalled 67.02 it remained activated; 67.02 supporting 3Dc four-CC but not activating it.

I never have 70.41 on my system.

Try to delete the "D3D_54082152" key and restart your system.

 

[wireframe]

I've done nothing unusual, just re-installed 67.02(from 70.41), I dont have that key in my registry.

BTW, I forgot to enable AF when testing, now 3Dc works fine, and it's slightly faster than DXT5.

It's possible that 70.41 activated the 3Dc support then and when you reinstalled 67.02 it remained activated; 67.02 supporting 3Dc four-CC but not activating it.

I never have 70.41 on my system.

Try to delete the "D3D_54082152" key and restart your system.

Ok, I have removed this key and now I have 3Dc support and judging from Humus' demo it is working (it looks more like uncompressed normal than compressed with 3Dc set to false (DXT5).

I am curious why removing a key would activate this. Isn't the logic to always look for a key and then activate the corresponding functions? It seems in this case the presence of the key masks it.

Edit: Just tested The Project and it reports 3Dc as supported, but activating it while the demo is running caused an exception. The demo also seemed to take much longer loading than previously.

 

[Reverend]

No, it will give you the same quality as 3Dc but it need more memory (2x) than 3Dc.

What's so exciting about this hack that defeats one of the main purposes of 3Dc?

 

[Xmas]

No, it will give you the same quality as 3Dc but it need more memory (2x) than 3Dc.

What's so exciting about this hack that defeats one of the main purposes of 3Dc?

It works just like 3Dc, so developers don't need to treat R420 and NV40 differently. And it still only takes half the space of uncompressed 3(4)-channel normal maps.

 

[Dave Baumann]

Well, with half the compression of 3Dc it can still provide some speed increases if a developer decides to provide no alternative compression for normal maps (and given the relative performance differences between the X800's and 6800's here I'm wondering if that hasn't already happened with Tribes Vengeance, which is a 3Dc title).

 

[Rys]

I spoke to someone at ATI yesterday and The Project reporting 3Dc compat on NVIDIA hardware is a UI bug, nothing else. The boards can't do it.

 

[ChrisRay]

I spoke to someone at ATI yesterday and The Project reporting 3Dc compat on NVIDIA hardware is a UI bug, nothing else. The boards can't do it.

Then why is it working with the Humus application? I would take ATIs explanation on Nvidia hardware support with a grain of salt. Anyway.. Wonder.. is Ruby running any differently? has anyone tried The Ruby demos?

Just tried it and it appears to be working fine for me as well.

 

[Hyp-X]

What's so exciting about this hack that defeats one of the main purposes of 3Dc?

It works just like 3Dc, so developers don't need to treat R420 and NV40 differently. And it still only takes half the space of uncompressed 3(4)-channel normal maps.

Any developer who doesn't know how to use U8V8 (16bit, supported on all DX9 hardware) for uncompressed format won't be qualified to use 3Dc anyway.
I believe this feature is done primary so nVidia cards run ATi techdemos (so their cards doesn't look bad for the users).

R420 and NV40 should still be treated differently if you want the texture to occupy the same amount of memory (video memory usage being the topmost concern).

This trick actually makes right feature detection harder - just like when we had to add special cases for GF4MX (it said it can do VS) - or GF2 cards (they said the can do non-pow2 textures)

 

[LeGreg]

that defeats one of the main purposes of 3Dc?

if the purpose of 3dc was to be only available on ATI then yes that defeats it

 

[Hyp-X]

I spoke to someone at ATI yesterday and The Project reporting 3Dc compat on NVIDIA hardware is a UI bug, nothing else. The boards can't do it.

Yeah I spoke to someone at NVIDIA who said ATI's instancing implementation is fake.

So, what's new?

 

[Mulciber]

that defeats one of the main purposes of 3Dc?

if the purpose of 3dc was to be only available on ATI then yes that defeats it

i thought its main purpose was to compress normal maps :?

 

[PP]

Far Cry 1.3 detects 3Dc the same way The Project demo does:

System: INFO: DirectX 9.0c installed
System: VideoCard Detected: nVidia (NV40)
Direct3D9 driver is creating...
Best-match display mode: 1024x768x32 (Error=8)
Creating D3D device (Adapter format: D3DFMT_X8R8G8B8, BackBuffer format: D3DFMT_A8R8G8B8, Depth format: D3DFMT_D24S8)
D3D Adapter: Driver name: nv4_disp.dll
D3D Adapter: Driver description: NVIDIA GeForce 6800 GT
D3D Adapter: Driver version: 6.14.10.6693
D3D Adapter: Driver GUID: D7B71E3E-4305-11CF-25690B2800C2CB35
D3D Adapter: VendorId = 4318
D3D Adapter: DeviceId = 69
D3D Adapter: SubSysId = 134287536
D3D Adapter: Revision = 161
D3D Detected: NVidia video card
D3D Driver: MaxTextureBlendStages = 8
D3D Driver: MaxSimultaneousTextures = 8
Using '8888' pixel texture format
Using 'Alpha8' pixel texture format
Using 'Alpha8Lum8' pixel texture format
Using 'V16U16' pixel texture format
Using 'Depth24' pixel texture format
Using 'BumpV8U8' pixel texture format
Using 'BumpQ8W8U8V8' pixel texture format
Using 'BumpX8L8U8V8' pixel texture format
Using 'BumpU5V5L6' pixel texture format
Using '3Dc' pixel texture format
Using 'DXT1' pixel texture format
Using 'DXT3' pixel texture format
Using 'DXT5' pixel texture format

But I did some testing and can't see any improvement using it.

X800 got some gains in levels like Research:

http://www.xbitlabs.com/articles/video/display/farcry13_9.html

 

[Dave Baumann]

if the purpose of 3dc was to be only available on ATI then yes that defeats it

Considering its been implemented as an open standard, that doesn't appear to be the case.

 

[ChrisRay]

if the purpose of 3dc was to be only available on ATI then yes that defeats it

Considering its been implemented as an open standard, that doesn't appear to be the case.

My guess is Nvidia is currently experimenting with it. I am wondering if((hoping as well)) they intend to implement it into future hardware. It wouldnt be a bad move on Nvidias part anyway.


Testing the Ruby demo right now. Seeing if I notice any improvement.

 

[Dave Baumann]

If its licensed as part of WGF2.0 then there is a very good chance it will have future hardware support.