S3TC software decoding in OpenMW

Feedback on past, current, and future development.
User avatar
scrawl
Posts: 2049
Joined: 18 Feb 2012, 11:51
Contact:

Re: S3TC software decoding in OpenMW

Post by scrawl » 03 Oct 2017, 12:45

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: ).

User avatar
raevol
Posts: 2397
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: S3TC software decoding in OpenMW

Post by raevol » 03 Oct 2017, 22:48

scrawl wrote:
03 Oct 2017, 12:45
not for a party :lol:.
... *discards ticket draft*

User avatar
ap0
Posts: 244
Joined: 11 Aug 2011, 18:47
Location: France
Contact:

Re: S3TC software decoding in OpenMW

Post by ap0 » 04 Oct 2017, 19:16

It's all right, we'll have a party for OpenMW 1.0 anyway.

User avatar
psi29a
Posts: 3394
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: S3TC software decoding in OpenMW

Post by psi29a » 05 Oct 2017, 06:50

I confirmed with Erik about VC4 (Raspberry Pi) support for S3TC:

bret curtis <psi29a@gmail.com> 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-)

User avatar
scrawl
Posts: 2049
Joined: 18 Feb 2012, 11:51
Contact:

Re: S3TC software decoding in OpenMW

Post by scrawl » 13 Oct 2017, 21:11

That was fast! :o

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

User avatar
psi29a
Posts: 3394
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: S3TC software decoding in OpenMW

Post by psi29a » 13 Oct 2017, 21:54

Kan we backport that to your OSG fork? Does this do what we need it to?

User avatar
scrawl
Posts: 2049
Joined: 18 Feb 2012, 11:51
Contact:

Re: S3TC software decoding in OpenMW

Post by scrawl » 14 Oct 2017, 19:42

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.

Chris
Posts: 1274
Joined: 04 Sep 2011, 08:33

Re: S3TC software decoding in OpenMW

Post by Chris » 15 Oct 2017, 01:04

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest