3Dc

[Joe DeFuria]

Why would they? PS2.0 is a subset of PS3.0. People will use PS3.0 features where they count, and not some silly red herring like using dynamic branching on everything where a conditional or predicate would suffice.

Right...so where it counts, use it. And don't "automatically" have a fall-back to 2.0 if it doesn't make sense to.

Number one, there is no proof that it is inferior in a way that even matters in the majority of cases.

Except as Dave stated...if it is up to snuff, why is no-one apparentlu using DXT5, despite ATI's white-paper on it?

I'm thinking your trying to deflect the argument because you have no technical base to stand on.

I don't just ignore OpenGL guy's comments...you might.

(BTW, Temporal FSAA is not "ATI" only either, it can be done on any card)

Obviously, but it's not at this time, is it?

Fact is, I'm calling for developers to support both methods. You're the only one who's "pooh-pooh"ing anything Pooh-Boy.

Fact is, I'm calling on developers to implement 3Dc, and then DXT5 only if it makes sense..

 

[DemoCoder]

Except as Dave stated...if it is up to snuff, why is no-one apparentlu using DXT5, despite ATI's white-paper on it?

Because a) it's only been available to the public for a few months and b) it requires new compression tools to use, just like 3Dc.

I don't just ignore OpenGL guy's comments...you might.

I didn't ignore him, I responded to his comments. The original issue was over automatic support for 3Dc on non-R420 cards. I said it's not needed as long as developers support the DXT5 fallback. If we get into the situation which you appear to be advocating, NVidia and other vendors will have to add software emulation for 3Dc in their drivers to avoid their users of being unfairly saddled with crappy low-res normal maps which *could* be automatically enhanced to better quality if the driver reported 3Dc support.


Fact is, I'm calling on developers to implement 3Dc, and then DXT5 only if it makes sense..[/quote]

This whole thread is over whether it makes sense or not, if you haven't figured that out yet. Your position is a nice semantic weasel, equivocation that totally ignores the main discussion, which is whether

a) DXT5 makes sense from extra developer labor
b) DXT5 makes sense from an IQ stand point (vs using LOW RES normal maps as in Dave's comparison)

Both answers appear to be "yes". You appear to have no input on this. Dave appears to be saying "Must be false since no developers are using it", but the technique is new and no developer tools exist yet (nor do they exist for 3Dc either), so that's quite irrelevent to the issue of how much quality difference there will be and how much work it is to support DXT5.

What's your response to ATI's own test results which draw the conclusion that DXT5 delivers compression with very little noise, artifacts, or blocking, and "essentially identical to the original"?

 

[Joe DeFuria]

This whole thread is over whether it makes sense or not, if you haven't figured that out yet.

I thought I had figured out that you called on developers to just support both?

Your position is a nice semantic weasel...

You said it, not me.

aBoth answers appear to be "yes". You appear to have no input on this.

Because I haven't seen any results to support it?

Dave appears to be saying "Must be false since no developers are using it", but the technique is new and no developer tools exist yet (nor do they exist for 3Dc either),

I thought Valve and and Crytek were using 3Dc? And someone must have done something to get 3Dc into the Ruby demo....or do you mean no publically available devleoper tools?

 

[AlphaWolf]

I thought Valve and and Crytek were using 3Dc? And someone must have done something to get 3Dc into the Ruby demo....or do you mean no publically available devleoper tools?

You forgot Croteam, who managed to throw together something with it in a couple days.

 

[Sxotty]

But valve and crytec are doing ps3.0 as well right? They just want to have all the feature check boxes

 

[dksuiko]

I believe his main point was how much better is 3Dc than DXT5?

Isn't the answer to that kinda implicit in that no-one is using DXT5 for normal mapping?

It would, if not for the fact that nobody is yet using 3Dc, either. (Though I think Fry Cry will be supporting it soon?). Because if 3Dc is a not-so-significant improvement over DXT5, why would they use 3Dc if they wouldn't even use DXT5? One answer to that question would be ATI would assist them in implementing it. In which case, 3Dc, to developers, would be a better choice by virtue of having help doing it - wherein DXT5, there wouldn't be any.

And in so doing, 3Dc gains more support over DXT5. So yeah, the fact that nobody is yet using DXT5, in comparison to 3Dc, would be an implicit answer the question (because, of course, an unused feature is a useless feature ) But as it stands now, nobody is using either correct?

 

[Scarlet]

i'm pretty sure its dx specific but remember we are most likely a year off or more from dx10/ next .

Would you believe two years?

 

[DemoCoder]

I thought I had figured out that you called on developers to just support both?

Yes, but not because of equivocational reasons like you, but because I view them as requiring nearly identical amounts of shader labor to use, in fact, common labor that could be handled with a single #DEFINE/#IFDEF in the shaders. Thus, if I was developing a game, I'd be inclined to go with both.
If there was a huge amount of coding work that had to be done to support one or the other, I'd have to choose.

I thought Valve and and Crytek were using 3Dc? And someone must have done something to get 3Dc into the Ruby demo....or do you mean no publically available devleoper tools?

Publically available. Yes, well, Valve and Crytek are also claiming to support some SM3.0 features as well But these are PR launch partners urged to hack in stuff quick for a demo. General widespread usage isn't going to happen until ATI and others release tools for development environments.

It's just like PolyBump. It's all well and good to show off some demos, but it takes a plugin for Maya or 3DSMax to make it easy enough for most developers to use. Not many developers are John Carmacks and will write their own IDE tool.s

Part of Microsoft's XNA approach is to make it easier for all of these techniques to be used off the shelf by developers much easier than happens now.

 

[jvd]

i'm pretty sure its dx specific but remember we are most likely a year off or more from dx10/ next .

Would you believe two years?

yea thats what i figure . I said 1 just in case .

But if therei s no new dx coming out soon its hard to get gdc to be standard . perhaps they could have gotten in dx 9.c or whatever

 

[DemoCoder]

If ATI released their internal Compressonator modifications/plugins that support both the DXT5 alpha trick and 3Dc, we could better guage developer interest. As it is now, I expect them to drop the DXT5 technique and ship tools with only the 3Dc technique. Since the DXT5 was mostly an experiment than led them to 3Dc, they probably won't spend time "productizing" the DXT5 testing/experimental stuff, since it's against their purposes of promoting 3Dc anyway.

 

[Joe DeFuria]

If ATI released their internal Compressonator modifications/plugins that support both the DXT5 alpha trick and 3Dc, we could better guage developer interest. As it is now, I expect them to drop the DXT5 technique and ship tools with only the 3Dc technique. Since the DXT5 was mostly an experiment than led them to 3Dc, they probably won't spend time "productizing" the DXT5 testing/experimental stuff, since it's against their purposes of promoting 3Dc anyway.

Right.

So get of your ass and write some dev tools (or write to nVidia) to "productize" DXT5 stuff if that's what you want.

Though since DXTC is actually needs to be licensed, I'm not sure if you can do it for free, particularly for use with GL support. (I think using it with DX is covered by an MS license.)

 

[dksuiko]

Yes, but not because of equivocational reasons like you, but because I view them as requiring nearly identical amounts of shader labor to use, in fact, common labor that could be handled with a single #DEFINE/#IFDEF in the shaders. Thus, if I was developing a game, I'd be inclined to go with both.
If there was a huge amount of coding work that had to be done to support one or the other, I'd have to choose.

How labor intensive is implementing support for either? Because if ATI pushes support for 3Dc by offering assistance in implementation, 3Dc would have an extra benefit due to the assistance. But if both are relatively 'easy' to implement, I'd agree - why not support both?

But to be honest, I'm not too optimistic about support for either 3Dc or DXT5. Compression techniques have not be utilized too often in the past, as far as I can see. I mean, how many games have there been that made good use of compression? As much as I'd like to see either one supported, the track record of compression itself doesn't promise much.

 

[Scarlet]

i'm pretty sure its dx specific but remember we are most likely a year off or more from dx10/ next .

Would you believe two years?

yea thats what i figure . I said 1 just in case .

But if therei s no new dx coming out soon its hard to get gdc to be standard . perhaps they could have gotten in dx 9.c or whatever

I dunno. I think 3Dc is somewhat orthogonal to DX9.anything.

P.S. Usually I perceive DC as being pretty pro-nV, but on this issue I think he has it pretty much right. I think his observation on ATI productizing 3Dc and not spending any effort on DXT5 is a good one, although I suspect we difffer on ATI's motives if this is the case. If one does the job and does it to better benefit for the customer base, why do two? Seems like a waste of resources to me.

 

[bloodbob]

Something else about 3dc which SimonF pointed out in another thread is it appears to be covered by the s3tc patent. Which means unless you ( the IHV) have a licence for s3tc you can't use 3dc in OpenGl.

 

[DemoCoder]

Though since DXTC is actually needs to be licensed, I'm not sure if you can do it for free, particularly for use with GL support. (I think using it with DX is covered by an MS license.)

This indicates to me you still don't understand how the technique works. The DXT5 technique is a developer technique. It requires no new driver changes, no API additions. You are using the same DXT5 support in DX that is already free. You're just compressing data with one of the tangential components in the alpha channel instead. I don't see why using DXT5 would require a license, nor does writing DXTC compressors (there are oodles of open-source ones)

 

[Joe DeFuria]

How does my not understanding of the technicalities of the DXTC licensing structure indicate that I don't know how the technique works?

As I said, I'm not sure you could do it for free. You can't, AFAIK, support DXTC formats in graphics drivers for openGL, without a licence from S3.

 

[DemoCoder]

Because technically, if you wanted to, you can reuse existing DXTC tools, and just massage your input data, with the caveat that it will increase blocking artifacts slightly.

Realistically, there are lots of free DXTC compressors floating around with source, NVidia even has one on its site, so there's nothing stopping someone from adapting an existing compressor in-house.

Unless S3/VIA plans to start dictating what kinds of inputs can be fed to their algorithm (non-color data), I don't see any licensing relevance. They haven't gone after the people selling DXTC photoshop plugins either.

Technically, you can always be sued, so you can always argue there is some question was to whether something is legal. For years, people wrote free LZW GIF libraries, and then, out of the blue, Unisys decided to start suing people. That's why PNG was invested (among other reasons) Realistically, there is probably a higher chance that 3Dc will get cited for patent violations than some guy writing his own DXTC compressor in-house.

 

[Bjorn]

Because I haven't seen any results to support it?

Neither have i but Ati seems to think that (which you seem to ignore):

5.4 DXT5 with renormalisation
- Very slight noise remains, but almost invisible.
- All other areas look essentially identical to the original.
- Specular blocking has almost completely disappeared. Specular highlights are the correct brightness.

It's nothing wrong with Ati evangelizing 3DC though but it would be ridicilous of the developers to not support DXT5 also if it also gives much better quality (though lower then 3Dc) and it's just a matter of adding a #IFDEF.

 

[Evildeus]

I believe his main point was how much better is 3Dc than DXT5?

Isn't the answer to that kinda implicit in that no-one is using DXT5 for normal mapping?

Isn't that your role to show us a comparison?

 

[DemoCoder]

Well, to be fair to Dave, he seems to have alot on his plate recently (two 25+ page reviews in less than a month) and, there is a lack of tools right now for him to do the comparison.