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

DataTextureLoader: provide alternative function for parsing explicit databuffer. #20225

Open
sciecode opened this issue Aug 30, 2020 · 0 comments

Comments

@sciecode
Copy link
Contributor

sciecode commented Aug 30, 2020

Parsing a simple buffer with a similar API as the common DataTexureLoader.load is not standardly supported, however it would seem logical for allowing features like drag and drop and easy server-side loading of DataTextures.

An example of the current workflow for doing such can be observed in webgl_materials_matcap.
jade.exr - open example file for testing - credits to Michael Harmon.

var contents = event.target.result;
var loader = new EXRLoader();
var texData = loader.parse( contents );
var texture = new THREE.DataTexture();
texture.image.width = texData.width;
texture.image.height = texData.height;
texture.image.data = texData.data;
texture.format = texData.format;
texture.type = texData.type;
texture.generateMipmaps = false;
texture.magFilter = THREE.LinearFilter;
texture.minFilter = THREE.LinearFilter;

In order to allow drag-and-drop ( or similar instant parsing ) we are required to manually invoke the specific loader.parser and replicate the onLoad events of both DataTextureLoader and the loader itself.

Wouldn't it make sense to supply a simpler built-in function for such workflow? Or, perhaps, it is expected of the loader to always provide a structured object that can be immediately used, bypassing this:

if ( texData.image !== undefined ) {
texture.image = texData.image;
} else if ( texData.data !== undefined ) {
texture.image.width = texData.width;
texture.image.height = texData.height;
texture.image.data = texData.data;
}
texture.wrapS = texData.wrapS !== undefined ? texData.wrapS : ClampToEdgeWrapping;
texture.wrapT = texData.wrapT !== undefined ? texData.wrapT : ClampToEdgeWrapping;
texture.magFilter = texData.magFilter !== undefined ? texData.magFilter : LinearFilter;
texture.minFilter = texData.minFilter !== undefined ? texData.minFilter : LinearFilter;
texture.anisotropy = texData.anisotropy !== undefined ? texData.anisotropy : 1;
if ( texData.format !== undefined ) {
texture.format = texData.format;
}
if ( texData.type !== undefined ) {
texture.type = texData.type;
}
if ( texData.mipmaps !== undefined ) {
texture.mipmaps = texData.mipmaps;
texture.minFilter = LinearMipmapLinearFilter; // presumably...
}
if ( texData.mipmapCount === 1 ) {
texture.minFilter = LinearFilter;
}
texture.needsUpdate = true;
if ( onLoad ) onLoad( texture, texData );

If so, how would you suggest structuring such API? Would it make sense to supply a similar interface to other loaders?

Credits to @WestLangley for the idea, I'm replicating and discussing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
1 participant