Implement real-time vector graphics rendering (e.g. SVG, Rive)

projectitis commented 3 years ago

Describe the project you are working on

Game development using vector art work. I'm a long-time (former) Flash/AIR/ActionScript3 developer, almost exclusively using vector art assets.

Describe the problem or limitation you are having in your project

Although vector art can be imported into Godot, it is rasterized on import and is a bitmap from that point and is not rendered in real time. Real-time vector art rendering has several benefits over bitmap art, which include:

Scalable (and rotatable, transformable etc) without quality loss
Much smaller file size
Transformable in real time, and transformations are not destructive (e.g. can be reversed)
Many vector asset types can be managed in source control as they are essentially text based

Yes, there are negatives too - the main one being much slower to render than bitmaps, and lack of GPU acceleration. However, many game developers are willing to make this trade-off for the benefits that vector art can provide,

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose a new Node2D descendent which supports real-time vector rendering using a TBD vector renderer.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The mechanism, if this is the way recommended by the core devs, would be basically to use the custom drawing feature of CanvasItem to update the node (draw a new texture) if the vector updates. Ideally a vector graphic asset would be assigned to the node.

If this enhancement will not be used often, can it be worked around with a few lines of script?

The work-around is not to use vector art, which is really not a workaround :)

Is there a reason why this should be core and not an add-on in the asset library?

If available, it should be a core feature and maintained as part of the product.

octanejohn commented 3 months ago

thorvg is all ready in use plus is easier with lottie

projectitis commented 3 months ago

ThorVG is a rendering engine. Rive is an animation format (like Lottie but more powerful). They both work together - ThorVG can be used to render Lottie animations AND it can be used to render Rive animations.

I contributed to the port of the latest Rive renderer to ThorVG some time ago. It worked perfectly - however, Rive evolved and gained many features that ThorVG didn't have yet, and my interest waned :) I may look again at some stage because ThorVG has been evolving steadily.

However, ThorVG renders to a bitmap canvas, and what we really need is an OpenGL rendering engine that generates meshes etc to take advantage of hardware. ThorVG did have the start of an OpenGL renderer, but not sure how far it got. There is a Rive implementation for Unity that works in this way.

SlugFiller commented 3 months ago

The people from Rive have actually shown interest in making a Godot port/integration/plugin. But it is not currently possible with the things Godot exposes, or rather, doesn't. Rive operates by using the stencil method for winding counting. However, while Godot does request the stencil buffer, it does not expose it to canvas items, and certainly not to plugins.

The other known methods for hardware rendering vectors is pathfinder, which operates as a compute shader, and would therefore require an ability to produce a texture from a compute shader; and mesh generation, which is still mostly CPU-bound, due to the need to compute path self-intersections.

By contrast, ThorVG, being a software renderer, has very high compatibility. Rendering doesn't need anything exposed other than the CPU, and transforming the output buffer to a texture doesn't require any odd GPU-GPU copies, or GPU-CPU-GPU round-trip transfers. The cost is, of course, performance. It's useful for static graphics, but is not good enough for creating a couple of hundreds of animated enemies on the screen at once. Even meshing, which performs the fill on the GPU, proved not performant enough for gaming.

fire01z commented 3 months ago

The people from Rive have actually shown interest in making a Godot port/integration/plugin. But it is not currently possible with the things Godot exposes, or rather, doesn't. Rive operates by using the stencil method for winding counting. However, while Godot does request the stencil buffer, it does not expose it to canvas items, and certainly not to plugins.

The other known methods for hardware rendering vectors is pathfinder, which operates as a compute shader, and would therefore require an ability to produce a texture from a compute shader; and mesh generation, which is still mostly CPU-bound, due to the need to compute path self-intersections.

By contrast, ThorVG, being a software renderer, has very high compatibility. Rendering doesn't need anything exposed other than the CPU, and transforming the output buffer to a texture doesn't require any odd GPU-GPU copies, or GPU-CPU-GPU round-trip transfers. The cost is, of course, performance. It's useful for static graphics, but is not good enough for creating a couple of hundreds of animated enemies on the screen at once. Even meshing, which performs the fill on the GPU, proved not performant enough for gaming.

Interesting.. I thought it would be easier to integrate Rive with Godot. In a discussion, one of the Rive developers mentioned that they needed a few things to integrate the renderer with Godot and that everything seemed to be well underway and available for this... Rive mention

SlugFiller commented 3 months ago

If you look closely at what the Rive developer is saying, it's basically that they're missing any way to interface with Godot's graphics engine in a meaningful way. They are asking for direct access to the GL/Vulkan context, which is pretty low level, and not particularly likely to happen (It would be too backend specific, and not work very well for DX12 or Metal backends). It is a very far cry from "Well underway and available"

godotengine / godot-proposals