Engine Caching of base64 CubeTextures

In the past, I made a JS file which created PBRMaterials that I wished to assign an environment variable, in a self-contained way. I obtained a base64 representation of the .env, and loaded the env from a small class, using the string for the data as the url arg for CreateFromPreFilteredData.

Tracking thru CreateFromPreFilteredData(), it calls the CubeTexture constructor, and there the data is also used for the name. That is why I later assigned null over the name field. It almost seemed like a data leak.

Now, I have adapted this JS file to run in a mult-scene architecture (mostly, except for this). The materials using the env are re-created in each scene. If textures are cached in engine by name that would be a 600k name search, right? For many Env’s, the damage could be far worse.

It seems like 3D textures are treated differently than 2D. 2D textures even have a method CreateFromBase64String(), which takes both a data & name as arguments

     * Creates a texture from its base 64 representation.
     * @param data Define the base64 payload without the data: prefix
     * @param name Define the name of the texture in the scene useful fo caching purpose for instance
     * @param scene Define the scene the texture should belong to
     * @param noMipmapOrOptions defines if the texture will require mip maps or not or set of all options to create the texture
     * @param invertY define if the texture needs to be inverted on the y axis during loading
     * @param samplingMode define the sampling mode we want for the texture while fetching from it (Texture.NEAREST_SAMPLINGMODE...)
     * @param onLoad define a callback triggered when the texture has been loaded
     * @param onError define a callback triggered when an error occurred during the loading session
     * @param format define the format of the texture we are trying to load (Engine.TEXTUREFORMAT_RGBA...)
     * @param creationFlags specific flags to use when creating the texture (Constants.TEXTURE_CREATIONFLAG_STORAGE for storage textures, for eg)
     * @returns the created texture
    public static CreateFromBase64String(
        data: string,
        name: string,
        scene: Scene,
        noMipmapOrOptions?: boolean | ITextureCreationOptions,
        invertY?: boolean,
        samplingMode: number = Texture.TRILINEAR_SAMPLINGMODE,
        onLoad: Nullable<() => void> = null,
        onError: Nullable<() => void> = null,
        format: number = Constants.TEXTUREFORMAT_RGBA,
        creationFlags?: number
    ): Texture {
        return new Texture("data:" + name, scene, noMipmapOrOptions, invertY, samplingMode, onLoad, onError, data, false, format, undefined, undefined, creationFlags);

Notice that this just wrappers a constructor, and the Texture class has separate arguments for both, while Texture3D’s constructor does not.

Is there any way out of this, using caching, in a multi-scene way, without using Huge names?

Well, I found some more stuff, which seems like it might be possible. If I look at the constructor of CubeTexture, it does not strictly take a scene as an arg. It is a Scene or Engine. This gets passed to super, a BaseTexture.

Not really sure what that is, but if I pass an engine, might I be able to assign the CubeTexture instance from the first time to a static in my little class above, and subsequent “Gets” all return the same CubeTexture instance? That way I would have exactly one texture, which could be use across all engine’s scenes.

If the answer to that is yes, then I would like an enhancement (I could PR it) to CreateFromPreFilteredData to also allow an engine for that arg.

Yup please try to create a PR for it :slight_smile:

1 Like

Just pecking on a tablet, waiting for the Bills game (there’s a 1hour delay today :unamused:). Going to look at the feasibility of giving 2d the same treatment while I am at it.

I have a texture for a scene to scene wormhole as well. That mesh & material combo need to be created twice for each long distance teleport. Probably going to want to store that inside a JS as well.

1 Like