Why 3Dc may not always be a better solution
- Thread starter Scali
- Start date
- Status
madshi said:
Not to me. What I meant to say was that the alternatives will always get either better performance, better size or better quality than 3Dc.
You choose to introduce an extra constant into the equation: the memory size. In that case it all becomes relative.
What is better IQ? DXT at twice the resolution, or 3Dc which has less artifacts? I'm sure you can come up with pathological cases for either.
But you are only looking at IQ for a fixed memory size then. Not at the performance, or what would happen of you decided to use more or less memory for one method. I never said that 3Dc couldn't give a method that is the best compromise in certain situations, I simply said that it would never be the fastest, give the highest quality or give the smallest memory footprint.
The rest depends on circumstance and opinion.
If you want my opinion: 3Dc's gains over DXT in quality are marginal in practice, at least for me, and it requires too much work, will reduce performance in most cases, and there's too little hardware that supports it, so it's not worthwhile to go through the trouble.
But isn't that what it is all about for game developers? To find the best compromise?Scali said:
Sure, a 10bit uncompressed 2048x2048 texture will look better than a 3Dc compressed 2048x2048 texture. But I think saying that alone doesn't help too much. There's a difference between "best achievable quality" (that would be very detailed >=10bit uncompressed textures) and "best usable quality". While using detailed 10bit uncompressed textures is possible, it might slow games down too much, while using detailed 10bit 3Dc textures might still be good enough for performance. I'm saying "might", because I agree with you that it depends very much on the circumstances. But if we add performance and data size into the overall picture, a *usable* 3Dc texture detail/size level might in some cases actually have better IQ than a *usable* uncompressed texture detail/size level. Well, at least that's my current opinion, which might change tomorrow...Scali said:
Ok, I'll add your opinion to my overall 3Dc evaluation brain. But I'll reserve judgement until I've seen what future games will do (or not do) with 3Dc.Scali said:
Do you mean DXT1 here? In which case it's only twice the resolution on one axis and the quality is terrrible. If you mean DXT5 using 3Dc-type encoding or channel separation encoding, then they are the same size data.Scali said:
3Dc will always look better than DXT5/3Dc encoding unless you have a broken compressor. No exceptions. The difference may, however, not be large as it is the one DXT5 format that provides consistently reasonable quality.
madshi said:
Yes, in which light I found it rather strange that ATi would just claim that 3Dc would be better for 3DMark05. Especially when they later admit they don't know enough about 3DMark05's use of normalmapping.
I think they want to exploit the fact that a lot of game developers aren't aware of the mipmapping problem (or a good solution for it). In which case 3Dc seems to be a better solution.
This seems rather sensationalist.Scali said:
If we were exploiting game developers in any way we would not get very far with our developer relations. If we went around giving out bad advice for the apparent purpose of obtaining some short-term gains over our competition then game developers would quickly cease to trust our advice, and we would end up doing ourselves more harm than good.
Our research into subjects such as normal mapping is designed to help game developers in tackling problems, not to exploit them. Our research identified a likely need for methods of normal map compression, so we developed those methods and passed on our results to developers to use as they saw fit. Additionally as a result of our research we developed 3DC to offer an additional high-quality option for normal compression - this certainly didn't stop us from being very clear with developers on how they could tackle things on hardware without 3DC support, or how to move forward if 3DC did not fit into their plans for whatever reason.
For many developers 3DC certainly is likely to be a better solution than DXT5 - not everyone wants to use denormalised maps, and if you want to do some more advanced effects such as parallax mapping then 3DC is likely to be significantly superior in all respects.
andypski said:
What has been the uptake of 3Dc in the developer community? Are they excited about it? Are we going to see 3Dc everywhere? Is it a candidate for inclusion in a future DirectX? Not trying to badger - really curious as to why Futuremark did not think that 3Dc would be a big player in the future.
trinibwoy - 3Dc is in current ATI hardware. ATI is making hardware for MS's next generation console so it would be hard to believe that 3Dc will not be included in the hardware for that console...
Where do you think the entire DST+PCF discussion has arisen from?
Depth/Stencil Texture.
It's a special textureformat, introduced by NVIDIA, which allows you to basically use a z/stencilbuffer as a texture/rendertarget.
It is an efficient way to implement shadowmaps, especially on NVIDIA hardware where you have the advantage of the double z-fillrate when using this textureformat.
It's a special textureformat, introduced by NVIDIA, which allows you to basically use a z/stencilbuffer as a texture/rendertarget.
It is an efficient way to implement shadowmaps, especially on NVIDIA hardware where you have the advantage of the double z-fillrate when using this textureformat.
Other than large scale cross-platform titles, cross pollonation between Nintendo and PC is likely to remain far less prolific than between Xenon and PC.
davepermen
Regular
scali just mixes up the fact that DXT for normal maps can get used in different ways..
in the 2 component way, DXT5 can give quite high quality results. but 3Dc beats it by far (as it's designed for it).
in the 3 component way (or even more), DXT5 leads to quite much lower quality normal maps. even while NOW, you could store the full normal in, even unnormalized.
but you should not forget that, for 2 component compression, 3Dc wins. for everything else, only DXT5 is a valid option.
but anyways, if you don't want additional information the way scali want it (for reasons that are at least questionable, as discussed yet), then you can use a 2 component representation. in THIS CASE 3Dc ALWAYS wins.
3Dc is _THE_ compression format for 2 component textures, with _INDEPENDENT_ texture components.
DXT5 is useable for the same purpose (with the green/alpha trick), but not as good. DXT5 is as well usable for up to 3 _RELATED_ components, and one independent one.
now to choose whats good for normal maps, thats a whole different question.
i'd stay with 3Dc and the green/alpha hack if not supported.
btw, scali, even nvidia suggests nearly everywhere the 2 component way. it's _the_ way introduced in gf3 days with the HILO formats. not compressed, but with auto extraction and renormalization of the 3rd component. and this was all just for bumpmapping! so the whole texture_shader unit can get dropped for bumpmapping, too..
in the 2 component way, DXT5 can give quite high quality results. but 3Dc beats it by far (as it's designed for it).
in the 3 component way (or even more), DXT5 leads to quite much lower quality normal maps. even while NOW, you could store the full normal in, even unnormalized.
but you should not forget that, for 2 component compression, 3Dc wins. for everything else, only DXT5 is a valid option.
but anyways, if you don't want additional information the way scali want it (for reasons that are at least questionable, as discussed yet), then you can use a 2 component representation. in THIS CASE 3Dc ALWAYS wins.
3Dc is _THE_ compression format for 2 component textures, with _INDEPENDENT_ texture components.
DXT5 is useable for the same purpose (with the green/alpha trick), but not as good. DXT5 is as well usable for up to 3 _RELATED_ components, and one independent one.
now to choose whats good for normal maps, thats a whole different question.
i'd stay with 3Dc and the green/alpha hack if not supported.
btw, scali, even nvidia suggests nearly everywhere the 2 component way. it's _the_ way introduced in gf3 days with the HILO formats. not compressed, but with auto extraction and renormalization of the 3rd component. and this was all just for bumpmapping!
so the whole texture_shader unit can get dropped for bumpmapping, too..- Status
