Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Basis support #710

Closed
wants to merge 13 commits into from
Closed

Conversation

lbergman
Copy link
Contributor

@lbergman lbergman commented Oct 31, 2019

Support for loading basis files (https://github.com/BinomialLLC/basis_universal).

It is working as is, but still a WIP for a few reasons:

  1. Support is tested for DXT, ATSC and PVRTC, but having issues with ETC.
  2. Integrate with asset system.
  3. Include basis transcoder and wasm binary.

...

Not sure when ETC is needed, but will see if I can find why it is not working. DXT, ATSC and PVRTC seems to cover desktop and mobile browsers well though.

Since we handle loading without depending on assets system in heaps, this is not really a priority for us and seems a bit tricky to do. One reason being that basis adds another async stage to the process (first the usual loading, and then running wasm), so rather than adding another supported format all asset handling needs to be modified to be async both when loading and parsing. Any help on this would be much appreciated.
At the moment is has to be used through BasisTextureLoader.getTexture. Current solution we use in our games looks like this:

function getImageTexture(path:String, ext:String, name:String):js.lib.Promise<h3d.mat.Texture> {
	return switch ext {
		case 'basis':
			final bytes = _fileSystem.get(path).getBytes().getData();
			hxd.res.BasisTextureLoader.getTexture(bytes);
		default:
			final bytes = _fileSystem.get(path).getBytes();
			js.lib.Promise.resolve(hxd.res.Any.fromBytes(name, bytes).toTexture());
	}
}

Unsure if .js and .wasm needed should be checked in to heaps and added to build folder as needed.

@lbergman
Copy link
Contributor Author

ETC is working now and added parsing of bytes to get image width/height from basis bytes.

However that presented another obstacle with regards to integrating with heaps asset system. You can encode several images with different size into one basis file. However hxd.res.Image is built for resources with a single image.

So considering both that and the async parsing of images, hxd.res support seems like a big invasive task, so I probably skip that. Since it is so different than other formats and only applicable to js target, at least for our needs it is fine to access it via BasisTextureLoader.

That leaves one point, and it is eventual inclusion of js and wasm for transpiling.

Let me know if you have any ideas about that or the MR i general. If it is of interest merge in I will add relevant documentation and example.

@lbergman
Copy link
Contributor Author

We are using this in our latest games, and despite being a very limited implementation it is at least working well to minimize filesize on the web, getting similar size to jpg but with alpha support.

However there is one problem that is really limiting the usefulness. With PVRTC it seems like source png's need to have pre multiplied alpha. However it seems like heaps is not automatically correcting the blending in case of PMA, see #726

What we currently do is correcting by redrawing texture with a shader applied when loading, but this means that the texture is no longer compressed in memory, defeating some of the purpose with using basis in the first place.

A couple of other minor issues:

  • ETC1 doesn't support alpha channel, and to have proper support for it one should blend an rgb and alpha texture. Considering it only seems to be needed on some very old Android devices it doesn't seem worth the hassle.
  • capturePixels in GlDriver fails. Does this work with S3TC in HL? I get mismatch with data length and size.
  • Have not tested with mipmaps, probably will not work.

@lbergman
Copy link
Contributor Author

lbergman commented Jan 7, 2025

Closing, new implementation for ktx2 support #1254

@lbergman lbergman closed this Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant