Is it possible to add plain SVG support for textures in the GLTF specification ?

[anuprao]

Hi,

Current specification quotes

"Texture files use the official image/* type based on the specific image format. For compatibility with modern web browsers, the following image formats are supported: .jpg, .png, .bmp, and .gif"

With regard to this, I would like to propose support for Plain SVG for textures (as opposed to SVG generated from an editor directly). This would greatly benefit platforms which can natively support SVG. For example: Browsers are very capable of rendering SVG these days and can utilise this facility to generate the texture before uploading to the GPU. This would reduce the overall size of the GLTF asset.

This would also permit viewers to opt for higher quality representation based on available resources. For example: A device which can spare more RAM for the GPU, can use a 2048x2048 version of the texture instead of 512x512.

Regards,
Anup Jayapal Rao

[emackey]

Last year the Cesium team ran into problems using SVG textures in Chrome WebGL, but the bug tracker claims that's fixed now. Perhaps this should be considered valid for glTF.

[pjcozzi]

Concretely, are we just talking about being able to reference an .svg file in glTF?

Sounds OK for browser clients, but would increase the implementation barrier for others.

Could be a 1.0.1+ spec update.

[anuprao]

Being able to refer is exactly what I am referring to.

Thank you for considering this.

[pjcozzi]

If recent browsers have reliable svg support than I am in favor of this. I labeled this 1.1 so we can consider it for the next round of glTF spec updates.

[lexaknyazev]

@pjcozzi
What do you think of addressing this in 1.0.1?

[pjcozzi]

OK, same comment as before:

If recent browsers have reliable svg support than I am in favor of this. I labeled this 1.1 so we can consider it for the next round of glTF spec updates.

Longer-term, if this is an implementation burden for non-web clients (think C++/OpenGL), this could be moved to a "WebGL profile."

[lexaknyazev]

I would vote for an extension to glTF for SVG support. So it will be something like SVG with PNG fallback as with proposed compression formats.

[lexaknyazev]

After playing with SVG textures, I admit that they can be useful not only for asset's size reducing but also for integrating 2D animations into 3D models (think of a street with animated billboards).

Browser support is not rock solid at the moment: Firefox' support for SVG CSS animations from ImageElement is broken.

Considering possible implementation issues, SVG support could be something like:

{
  "images": {
    "ad": {
      "uri": "fallback.png", // or use "data:," for no fallback
      "extensions": {
        "EXT_svg_image": {
          "uri": "fancy.svg",
          "updateOnRedraw": true // for animations support
        }
      }
    }
  }
}

[anuprao]

@lexaknyazev
Yes, harnessing animated SVGs would definitely help a lot. Many thanks for giving the concept a spin.

I anticipate that using GLTF with SVG Textures as well as SVG Fonts (via SVG Textures) will become a popular choice.

Also, SVG filters could provide an added bonus. Though some of the SVG filters could be considered computationally intensive (depending on client), the rest (such as GaussianBlur and Blend) might become necessary for client-side generation of detailed textures. This could find good use in bump mapping techniques, terrain maps and even vectorised lightmaps.

Sometimes, I wonder if SVG had been JSON based rather than XML, GLTF could have seamlessly accessed SVG constructs. :-)

[lexaknyazev]

Massive usage of high-res SVG animations can be a bottleneck since runtime needs to copy full size uncompressed data each frame. Situation should improve after WEBGL_dynamic_texture adoption.

[pjcozzi]

@lexaknyazev thanks for the example JSON. I don't know this area well, but it looks like a good start.

@anuprao thanks for your support.

Labeling this extension.

[donmccurdy]

I'd encourage interested developers to experiment with an SVG extension and share their results, but because this probably cannot be widely implemented, I don't think there are near-term plans here. Per the extension readme:

For features that are not listed here but may be important for different uses, we encourage the community to begin with vendor extensions (which do not require review), reach out for feedback and collaborators, and as consensus forms we may consider the best way to bring a vendor extension into the broader ecosystem

[aaronfranke]

(I hope it's OK to discuss here, I know the issue is closed but I have just found it and I am somewhat interested)

"updateOnRedraw": true // for animations support

@lexaknyazev To me this would make more sense as "animation": true. I think it's better to specify what the image is rather than how an implementation is supposed to redraw it. However, wouldn't you also just be able examine the SVG contents and check for the <animate> tag, so this is not necessary?

[emackey]

@aaronfranke Thanks for the interest, but I think the group has moved away from considering SVG support. Since version 2.0, glTF has a large desktop presence, so browser support for SVG is no longer enough to qualify. The focus these days is on educating the glTF community about GPU-friendly and GPU-compressed texture formats like KTX2, for better runtime performance, and unfortunately SVG is a step in the wrong direction there. SVG asks the client to follow a complex set of rules to generate a set of pixels, only to then upload those pixels to the GPU for rendering, but the design goals of glTF 2.0 prefer that those pixels are delivered and/or stored in the GPU much more efficiently.

[lexaknyazev]

SVG asks the client to follow a complex set of rules to generate a set of pixels

This is generally true for all compressed texture and image formats. In some cases, vector-based image representations may yield smaller files on disk and on top of that their rasterization (2D path rendering) may happen directly on GPU without taking too much of the texture memory.

The issue with SVG is its enormous scope, which also includes custom CSS and DOM, and the fact that implementations (even web browsers) are neither complete nor consistent. There could be a well-defined and well-tested subset of SVG that is portable across different platforms (web, desktop, mobile, etc.) but there has been no community interest in pursuing this direction so far.

[aaronfranke]

@emackey This would be an extension, not part of the base spec, so the extension can simply not be implemented in places where it's not supported. SVG is supported in the web and in Godot Engine, so it does have some uses. Also we would recommend including a low resolution raster image as fallback, and the SVG can be used for higher quality in places it's supported. Would anyone mind if I use the name EXT_texture_svg?

[donmccurdy]

Typically the bar for an "EXT_" prefix is that at least two registered vendors have implemented the extension. If there is only one implementor, another prefix should be used.

I would just note that even on the web, support for rendering an animated SVG within a WebGL or WebGPU context is not common. In three.js we have an SVGLoader implemented, but it has no support for animation. We do support similar animation types in Lottie files (example: https://threejs.org/examples/?q=lottie#webgl_loader_texture_lottie) which seem to be better suited for our goals, but Lottie isn't standardized like SVG.