Page 2 of 2

Re: S3TC software decoding in OpenMW

Posted: 03 Oct 2017, 12:45
by scrawl
It's worth noting that there are no such things are "software patent" in Europe, this is why the party for the expiration mostly happens on the other side of the ocean.
Europeans can still party, after all they don't want their software to only be used in Europe.

Created a bugtracker request (for the feature, not for a party :lol: ).

Re: S3TC software decoding in OpenMW

Posted: 03 Oct 2017, 22:48
by raevol
scrawl wrote: 03 Oct 2017, 12:45 not for a party :lol:.
... *discards ticket draft*

Re: S3TC software decoding in OpenMW

Posted: 04 Oct 2017, 19:16
by jvoisin
It's all right, we'll have a party for OpenMW 1.0 anyway.

Re: S3TC software decoding in OpenMW

Posted: 05 Oct 2017, 06:50
by psi29a
I confirmed with Erik about VC4 (Raspberry Pi) support for S3TC:

bret curtis <[email protected]> writes:

> Hello Eric,
>
> just wondering if this will be supported now that the patent has
> expired? It seems that Mesa put their bits in place yesterday and
> Intel has enabled it on their side. Will this go into effect for the
> VC4/VC5 as well?

The changes to Mesa yesterday don't affect the drivers at all, just
bakes the compression code in so that end-users don't need to install a
separate library. VC4 HW doesn't support S3TC. VC5 does.
VC4 doesn't support this in hardware, so we'll need to do the decompression ourselves in OpenMW. VC5 on the other hand does support S3TC. 8-)

Re: S3TC software decoding in OpenMW

Posted: 13 Oct 2017, 21:11
by scrawl
That was fast! :o

https://github.com/openscenegraph/OpenS ... h/pull/363
-added dxtc support in Image::getColor

Re: S3TC software decoding in OpenMW

Posted: 13 Oct 2017, 21:54
by psi29a
Kan we backport that to your OSG fork? Does this do what we need it to?

Re: S3TC software decoding in OpenMW

Posted: 14 Oct 2017, 19:42
by scrawl
It does... I just tested and was able to run OpenMW without S3TC and all the textures looking fine. Committed here and here:

https://github.com/OpenMW/openmw/commit ... 89b227df74
https://github.com/OpenMW/osg/commit/b6 ... b7d5ca0abf

Gotchas:
- Because OpenMW has no idea if the OSG fork is being used, the new functionality needs to be enabled by running OpenMW like this:

Code: Select all

OPENMW_DECOMPRESS_TEXTURES=yesplz ./openmw
- I haven't loaded the precomputed mipmaps because the getColor() API doesn't work for that. Not a big deal, OpenGL will autogenerate new mipmaps for us.
- I got ahead of myself when I said that we would no longer need to prerender cursors on the GPU. We still need to rotate them (by 45 degrees in one particular case) so the graphics card is still a good choice for that I guess.

Re: S3TC software decoding in OpenMW

Posted: 15 Oct 2017, 01:04
by Chris
scrawl wrote: 14 Oct 2017, 19:42 - I haven't loaded the precomputed mipmaps because the getColor() API doesn't work for that. Not a big deal, OpenGL will autogenerate new mipmaps for us.
I actually had a suggestion relating to that. Given that decompressing S3TC to RGB(A)8 will increase VRAM usage, it might be a good idea to have a texture quality level option for lower-end systems (and given the recent patent expiration, low-end systems are likely where this option will be most needed). Oblivion has this option where it'll use the first or second mipmap as the texture base so it doesn't have to keep the biggest texture level in memory, at the expense of blurrier textures.