3Dc

[Sabastian]

I think I ought to thank some for their patience regarding my stumbling through the issues.(I suppose reading the thread might be good advice for future reference. )On the features end of things I think that 3Dc has a greater likelihood of success simply because there is so little in the way of other new features on the R420 series. Consider that ATi dev rel will be able to focus more of their efforts towards 3Dc without having to worry about other more complex issues. 3Dc has a greater likelihood of success I believe because of that. This is a good thing overall because it will be the harbinger of normal mapping into the mainstream software development.(hope so anyway.) Undoubtedly ATIs dev rel team will be more able to give assistance more readily concerning the 3Dc feature.

 

[Basic]

I think you can patent an improvement on a technique and reference the old patent as "prior art" without having to get a license on the prior patent. In any case, MS could "license" 3Dc from S3 and include it in DXTC in the next DX revision free of charge to developers.

IANAL, but that sounds rather strange to me.

I've always thought that you can get a patent on an extension to somebody elses patent without paying any royalties. But if you want to use it, and your product includes parts that is covered by the original patent, then you need to license it.

However. One trick you can do (and I've heard that some east asian companies do it a lot), is to flood any interesting patents with extending patents. So that the original patent holder have problems to use their own patents without stepping into the extensions.
And now you bring out the lawyers and propose a patent portfolio cross license.

 

[nelg]

I've always thought that you can get a patent on an extension to somebody elses patent without paying any royalties. But if you want to use it, and your product includes parts that is covered by the original patent, then you need to license it.

That is my understanding also.

 

[Simon F]

I think you can patent an improvement on a technique and reference the old patent as "prior art" without having to get a license on the prior patent. In any case, MS could "license" 3Dc from S3 and include it in DXTC in the next DX revision free of charge to developers.

Yep. That's my understanding. The easiest way to come up with a patent is to start with an existing patent and make some tweaks.

NO! I've written/cowritten quite a few patents so I know a little on the subject...

You can patent an improvement on existing patented techniques but, if someone wanted to use that technology, they have to get a licence from all the parties involved.

Since it's only a minor tweak to DXT5, it would be easy for all IHVs to support it in their next designs. And until then, game developers could either implement a DXT5 fallback with a very small amount of work, or IHVs implement 3Dc emulation (via converting to DXT5/changing a swizzle) in their drivers.

Just playing the usual Devil's Advocate: You could just as easily argue that if compressed normal maps via DXT5 are supported on all modern cards and that spending time to also code a 3DC path will only give a small improvement, why should the ISV bother?

I only ask because there have been features in earlier chips that have either improved performance and/or quality and have not been supported. <shrug>
(For example, HW translucency sorting only required the ISV to not do some CPU processing and yet it was never used EDIT: ..on the PC. It was, of course, used a lot on Dreamcast.)

However. One trick you can do (and I've heard that some east asian companies do it a lot), is to flood any interesting patents with extending patents. So that the original patent holder have problems to use their own patents without stepping into the extensions.
And now you bring out the lawyers and propose a patent portfolio cross license.

And that is partly why, when you write a patent, you add a section at the end (prior to claims) describing some broad alternative applications so that anyone trying to extend the patent in 'trivial' ways will often be stopped by obviousness given these descriptions in the original patent.

 

[Basic]

Ah, so that's the reason for those broad parts.
Maybe I should have guessed that. I've always thought that the broad part were rather strange. "Are they going to chase someone for this!" But if it's to avoid to get chased themself, it makes more sense.


More about the S3TC patent vs 3Dc.

I don't know how it's written (and I suppose nobody else here does either), but MS' licence could be written in two basic ways:
"You may use the S3TC patent" or "You may implement DXT1-5".

With the first, there would be no problems for 3Dc in DX. With the second, there could be some more money to pay.


Either way, I assume that any such patent issues will be solved, and that 3Dc will get implemented by other IHVs too. It's a usefull format, IHVs that have DXT5 already have the hardware block implemented, and since it's easy to do a DXT5 fallback, it's rather likely to get used.


I agree that HW translucency sorting was a cool feature, and it's a shame it wasn't used considering ho easy it sholud be. But it had one big difference to 3Dc, it was very unlikely that the feature would be available in more than one rather small IHV's hardware.

 

[Xmas]

Just playing the usual Devil's Advocate: You could just as easily argue that if compressed normal maps via DXT5 are supported on all modern cards and that spending time to also code a 3DC path will only give a small improvement, why should the ISV bother?

Because the improvement/work ratio is quite good.

I only ask because there have been features in earlier chips that have either improved performance and/or quality and have not been supported. <shrug>
(For example, HW translucency sorting only required the ISV to not do some CPU processing and yet it was never used EDIT: ..on the PC. It was, of course, used a lot on Dreamcast.)

Never used for the same reason quadric patches were never used: API support. I don't think any developer would not use it if the API of choice supports it and you push it enough. It would be an incredibly simple one line of code to add.

Oh, and in case you're just sitting over a new design... PLEASE, PLEASE PUT IT IN AGAIN!

 

[Simon F]

API support. I don't think any developer would not use it if the API of choice supports it and you push it enough.

The API (DX) did support it. There was a flag that said "you do not have to sort transparent polys".

 

[Xmas]

Hm, really? I don't have the old DX docs any more. But then there's the other point "and you push it enough"...

 

[mczak]

Does the s3 patent even apply to the alpha component compression of DXT5? If not, 3Dc should be patent-free.

<OT rant>The patent office will grant you a patent on anything - be it trivial business methods (like amazon one-click patent) or things with lots of prior art (someone got a patent on "the wheel", just to prove the point). DXTC itself doesn't actually look like it should be patentable (too trivial - why do you think 3dfx invented a compression scheme which is 99.9% identical at about the same time?).
</OT rant>
But even if DXTC is covered by a valid patent (remember - courts define validity, not the patent office), I doubt the alpha component compression scheme could be patented (at that point in time). This one really is obvious and trivial, with lots of prior art (google for some papers about (monochrome) texture/image compression). And since 3Dc just uses 2 times this alpha compression scheme, it also should not be patentable (VERY trivial extension - if you say this really is patented, I'm just going to file a patent for the same copmression scheme with 4 components now, who knows for what this could be used in the future!).

 

[andypski]

DXTC itself doesn't actually look like it should be patentable (too trivial - why do you think 3dfx invented a compression scheme which is 99.9% identical at about the same time?).

They didn't. They 'invented' a very similar scheme a long time afterwards - DXT compression debuted with Savage3D in 1998, FXT1 compression debuted considerably later.

That is not "about the same time" as far as I'm concerned.

And the research that went into S3TC is certainly not trivial - it might look that way with the benefit of hindsight, but so do many things which aren't immediately ovious until someone does them for the first time.

 

[mczak]

DXTC itself doesn't actually look like it should be patentable (too trivial - why do you think 3dfx invented a compression scheme which is 99.9% identical at about the same time?).

They didn't. They 'invented' a very similar scheme a long time afterwards - DXT compression debuted with Savage3D in 1998, FXT1 compression debuted considerably later.

That is not "about the same time" as far as I'm concerned.

You're right, from my memories the cards were released much closer together. But Savage3D - around June 1998, Voodoo4/5 - June 2000 (and even considering the target date was fall 1999, that's still a considerable gap). So, it's possible 3dfx did not develop fxtc independantly of s3tc.

And the research that went into S3TC is certainly not trivial - it might look that way with the benefit of hindsight, but so do many things which aren't immediately obvious until someone does them for the first time.

Maybe not trivial, but compared to the (really old) btc/ccc it doesn't look like it's that much of huge leap. It is certainly better, and I'm sure it required some research. I'll agree that there are certainly patents out there which are way more trivial.
It's unfortunate that the OGL ARB has adopted the s3tc extension (but didn't license it as MS did), since it prevents the open-source xfree86 DRI drivers from implementing it. The Mesa3D people tried to ask, but the attempts were fruitless, there never even was an answer if they were allowed to implement it...

 

[OpenGL guy]

It's unfortunate that the OGL ARB has adopted the s3tc extension (but didn't license it as MS did), since it prevents the open-source xfree86 DRI drivers from implementing it. The Mesa3D people tried to ask, but the attempts were fruitless, there never even was an answer if they were allowed to implement it...

I wasn't aware the ARB had accepted the extension. The only extension I am aware of being accepted was GL_ARB_texture_compression as GL_EXT_texture_compression_s3tc is a non-ARB extension. GL_ARB_texture_compression doesn't specify the internal compressed format, it only asks that the driver compress when possible.

I got my information from SGI extension registry.

 

[mczak]

It's unfortunate that the OGL ARB has adopted the s3tc extension (but didn't license it as MS did), since it prevents the open-source xfree86 DRI drivers from implementing it. The Mesa3D people tried to ask, but the attempts were fruitless, there never even was an answer if they were allowed to implement it...

I wasn't aware the ARB had accepted the extension. The only extension I am aware of being accepted was GL_ARB_texture_compression as GL_EXT_texture_compression_s3tc is a non-ARB extension. GL_ARB_texture_compression doesn't specify the internal compressed format, it only asks that the driver compress when possible.

I got my information from SGI extension registry.

Bad wording on my part. It's not adopted as an ARB extension nor into the GL core, but being a GL_EXT extension makes it somewhat of a "standard" extension which will be used a lot. Proprietary extensions typically use GL_<VENDORNAME> prefix. In fact, AFAIK this is the only GL_EXT extension which might require licensing for implementing it. AFAIK it could not be adopted as an ARB extension (or be incorporated into GL core) exactly because of the licensing issues (not sure though).

 

[3dcgi]

I think you can patent an improvement on a technique and reference the old patent as "prior art" without having to get a license on the prior patent. In any case, MS could "license" 3Dc from S3 and include it in DXTC in the next DX revision free of charge to developers.

Yep. That's my understanding. The easiest way to come up with a patent is to start with an existing patent and make some tweaks.

NO! I've written/cowritten quite a few patents so I know a little on the subject...

You can patent an improvement on existing patented techniques but, if someone wanted to use that technology, they have to get a licence from all the parties involved.

Right. DemoCoder mentioned that. I was just trying to say I've read that improvement patents can sometimes be easier to get than an entirely new patent. I'm no patent expert so I won't try to argue any more details.

 

[Simon F]

Does the s3 patent even apply to the alpha component compression of DXT5? If not, 3Dc should be patent-free.

The claims refer to a colour which, IMHO, which could include alpha, however, that is irrelevant. The patented idea is that of breaking the data into N*M blocks, storing 2 representative items per block and deriving at least one other representative directly from the stored two. Other data is then used to index into this expanded 'palette'.

3DC still falls into that.

<OT rant>The patent office will grant you a patent on anything - be it trivial business methods (like amazon one-click patent) or things with lots of prior art (someone got a patent on "the wheel", just to prove the point). </OT rant>

Some rubbish does slip through (in the USPTO), but have you ever tried getting a patent? It's not that easy to convince the examiners that your invention is patentable (more so in the UKPO and EPO)

But even if DXTC is covered by a valid patent (remember - courts define validity, not the patent office)....

However, the assumption is that a granted patent is valid

...I doubt the alpha component compression scheme could be patented (at that point in time). This one really is obvious and trivial, with lots of prior art (google for some papers about (monochrome) texture/image compression).

Well, IMHO, you are wrong, but please, give me the references you found that you think are prior art.

And since 3Dc just uses 2 times this alpha compression scheme, it also should not be patentable (VERY trivial extension - if you say this really is patented, I'm just going to file a patent for the same copmression scheme with 4 components now, who knows for what this could be used in the future!).

A trivial extension will not be granted.

 

[DeanoC]

API support. I don't think any developer would not use it if the API of choice supports it and you push it enough.

The API (DX) did support it. There was a flag that said "you do not have to sort transparent polys".

I used it on PC. I guess that means that those games I worked on back then weren't big enough to 'count'.
Was a simple matter of

if( Material->Flags & BackToFrontSort && Caps->RequireSorting )
    SortAndRender()
else
    Render()

BackToFrontSort was per material and Caps->RequreSorting was pulled from DX. Worked a treat on PowerVR cards.

 

[Simon F]

/me does a double take.

Wow! You must be one of the few then. The devrel group used to say that many developers simply couldn't be bothered or simply thought that it was impossible in HW!

 

[mczak]

The claims refer to a colour which, IMHO, which could include alpha, however, that is irrelevant. The patented idea is that of breaking the data into N*M blocks, storing 2 representative items per block and deriving at least one other representative directly from the stored two. Other data is then used to index into this expanded 'palette'.

But the only new thing here is the "derive at least one other representative directly from the stored two". The rest (break data into N*N blocks, store 2 representative items, index) is straight BTC (published 1979) (or CCC, 1986).

3DC still falls into that.

Ok, so there goes that theory...

Some rubbish does slip through (in the USPTO), but have you ever tried getting a patent? It's not that easy to convince the examiners that your invention is patentable (more so in the UKPO and EPO)

I've never had the need to try. I get the impression though the difficulty is mostly that the patent is written in proper legalese, not so much that it's really something new and innovative...

But even if DXTC is covered by a valid patent (remember - courts define validity, not the patent office)....

However, the assumption is that a granted patent is valid

Unfortunately...

...I doubt the alpha component compression scheme could be patented (at that point in time). This one really is obvious and trivial, with lots of prior art (google for some papers about (monochrome) texture/image compression).

Well, IMHO, you are wrong, but please, give me the references you found that you think are prior art.

You might be correct. There were quite some improvements attempts to BTC, but they don't seem to derive other values. In fact, it looks like noone even tried any ideas to make improved BTC suitable for graphic accelerators (the improved BTC versions typically have not completely fixed compression ratios).

And since 3Dc just uses 2 times this alpha compression scheme, it also should not be patentable (VERY trivial extension - if you say this really is patented, I'm just going to file a patent for the same copmression scheme with 4 components now, who knows for what this could be used in the future!).

A trivial extension will not be granted.

At least I'll assume that this means there is no new patent for 3Dc...

The problem I have isn't so much that the compression implementation details are patented. But it means that the format itself (which, AFAIK, as such could not be patented) is patented, since it's impossible to write an encoder/decoder without violating the patent. Though it makes me wonder, maybe it would be possible to write an encoder which encodes according to BTC, but stores the compressed data in the dxtn texture format. That should not violate any patent (it certainly would make the quality worse, the 2bit index just would use only 1 bit, in the alpha case the 4bit index would only use 1bit), and the data would still be decodable by standard S3TC deocders (which is important for the graphic cards). Though the software S3TC decoder still would have the problem of either non-compliance (if it would decode according to BTC), or potentially violating the patent.

 

[Simon F]

The claims refer to a colour which, IMHO, which could include alpha, however, that is irrelevant. The patented idea is that of breaking the data into N*M blocks, storing 2 representative items per block and deriving at least one other representative directly from the stored two. Other data is then used to index into this expanded 'palette'.

But the only new thing here is the "derive at least one other representative directly from the stored two". The rest (break data into N*N blocks, store 2 representative items, index) is straight BTC (published 1979) (or CCC, 1986).

Yes, and both BTC and CCC are acknowleded in the prior art section of the S3 patent. As stated, patents can be an improvement over prior art and that is exactly what S3TC is.

Some rubbish does slip through (in the USPTO), but have you ever tried getting a patent? It's not that easy to convince the examiners that your invention is patentable (more so in the UKPO and EPO)

I've never had the need to try. I get the impression though the difficulty is mostly that the patent is written in proper legalese, not so much that it's really something new and innovative...

Not at all. Apart from the claims, writing a patent is not very different to a scientific paper except that you must go into a lot more detail when describing an implementation (a.k.a. preferred embodiment) in the patent.

And since 3Dc just uses 2 times this alpha compression scheme, it also should not be patentable (VERY trivial extension - if you say this really is patented, I'm just going to file a patent for the same copmression scheme with 4 components now, who knows for what this could be used in the future!).

A trivial extension will not be granted.

At least I'll assume that this means there is no new patent for 3Dc...

What I meant was you couldn't just patent a simple "double 3Dc" since 3Dc is now prior art

Though it makes me wonder, maybe it would be possible to write an encoder which encodes according to BTC, but stores the compressed data in the dxtn texture format. That should not violate any patent (it certainly would make the quality worse, the 2bit index just would use only 1 bit, in the alpha case the 4bit index would only use 1bit), and the data would still be decodable by standard S3TC deocders (which is important for the graphic cards). Though the software S3TC decoder still would have the problem of either non-compliance (if it would decode according to BTC), or potentially violating the patent.

Errr I'm not a patent lawyer but I suppose if you don't use the derived colours then, technically, I guess you would not be infringing since it would then just be BTC with colour - in fact, IIRC, it'd be one of the early schemes described in CCC.

 

[mczak]

And since 3Dc just uses 2 times this alpha compression scheme, it also should not be patentable (VERY trivial extension - if you say this really is patented, I'm just going to file a patent for the same copmression scheme with 4 components now, who knows for what this could be used in the future!).

A trivial extension will not be granted.

At least I'll assume that this means there is no new patent for 3Dc...

What I meant was you couldn't just patent a simple "double 3Dc" since 3Dc is now prior art

Yes, but 3Dc is just a "double DXT5 alpha" too. Unless you consider the normalization step as patentable...

Errr I'm not a patent lawyer but I suppose if you don't use the derived colours then, technically, I guess you would not be infringing since it would then just be BTC with colour - in fact, IIRC, it'd be one of the early schemes described in CCC.

Thinking some more about it, it would be hard to do this in a way so the results are at least somewhat correct. Compression would be not much of a problem (except that quality would suck, and the 1bit alpha format might pose a problem for reduction to ccc), but software decompression would not give very meaningful results if s3tc precompressed textures would be decompressed with btc/ccc-restricted algorithm (problem with the 1bit alpha format again, and dxt5 alpha decoding can use fixed 0/255 values depending on alpha values, which is not done with btc - that could lead to not only somewhat incorrect results, but completely wrong results). Unless decompression isn't covered by the patent?