Scalable Vector Shapes 2D on discord

renevanderark · April 30, 2026, 9:11am

Dear all,

I decided to start a discord server for the Scalable Vector Shapes 2D plugin:

It’s hard to find the 5-50 (?) adopters out there across space and timezones, let alone encourage them to get in touch via Github issues or YouTube comments. I try to be just easy enough to find, which seems to fit discord best.

Reddit and bluesky gave me too much stress altogether so I’m off of those.

So just in edge case you were looking for me, I’ll be checking the discord daily and I have a chance of being active between 21:30 and 00:00 CEST

Best,
René

dragonforge-dev · April 30, 2026, 3:20pm

Very cool plugin BTW.

renevanderark · April 30, 2026, 4:28pm

Thanks!

normalized · May 1, 2026, 1:07am

This plugin looks quite impressive. You’ve packed in many neat features

renevanderark · May 1, 2026, 5:37am

Thanks!

I’ve had a lot of questions about performance.

Updating curves at runtime does seem to cause some cpu spikes.

Of course I try to put in some stuff to help mitigate it, but it’s pretty hard to get across all the potential of 2D vector graphics.

Most notably:

you could pack and ship a pretty tiny web game, with all the disk space you save using 2D vector graphics.
you could generate rasterized images at runtime via script using code I already built in (if you follow the button trail that is)… Even spritesheets
auto scaling images for GUI (is also in there)… Currently I’m working on auto-scaling touch button textures in my game
But also drawing collision shapes in engine way more quickly .. I dunno, seemed quite useful to me.

For 2D rendering OpenGL does seem to perform best by far on the devices I’ve tested with, but of course to make stuff look good some type of GPU based antialiasing is helpful

Which is why I’ve been lobbying a bit for likes on this pull request:

github.com/godotengine/godot

Add 2D MSAA to GLES3 backend

master ← Joonnas:msaa_2d_opengl

opened 10:33PM - 11 Oct 25 UTC

Joonnas

+169 -10

This PR implements the 2D MSAA in the OpenGL3 backend. It is based on the discus…sions in #83976 and the already existing code from #84688 Current base commit: 6d6e822 (4.7 Beta 1) # New version (v2) I overhauled the previous implementation to address the amount of blitting used in my first approach. You can find the implementation details of the older version below. Images are provided after. I will squash the commits if this approach is approved. For now I'd keep both to have the comparison to the first version available. ### Technical details We create a multisampled framebuffer when turning 2D MSAA on and delete it again when turned off again. I introduced two new functions in the TextureStorage class: - `render_target_prepare_canvas_msaa` in which we copy the scene that is rendered up to this point onto the MSAA framebuffer using the CopyEffects class. - `render_target_finalize_canvas_msaa` in which we simply call `render_target_do_msaa_resolve` which in itself blits the final 2D render onto the normal framebuffer. These functions are only implemented in the OpenGL backend since these operations are already implied in the other backends. `render_target_prepare_canvas_msaa` is called after a potential 3D scene is rendered, before we render the 2D scene. `render_target_finalize_canvas_msaa` is called after the 2D scene is done rendering. Since Godot supports the rendering of the 3D scene in between the 2D scene which in turn relies on the non-multisampled framebuffer, we need to resolve our MSAA framebuffer before rendering the 3D scene. This means that in this case we need two full resolves in one render cycle. Furthermore, if the backbuffer is used we might need to copy parts of the frontbuffer onto the backbuffer. For this I introduced a partial resolve in `TextureStorage::render_target_copy_to_back_buffer`. For Mobile devices we can still use the `GL_EXT_multisampled_render_to_texture` extension so we don't need the resolve steps. ### Discussion For this approach I decided to not support MSAA on the backbuffer, apart from the mentioned partial resolve when copying from the frontbuffer to the backbuffer. 1. Because the other backends don't support it as well 2. Because otherwise we would have way too many blitting and copying operations which is counterproductive, especially for the compatibility backend. I also decided that the partial resolve is a tradeoff worth making, since otherwise we would need to turn off MSAA completely when encountering a copy from the frontbuffer to the backbuffer. # Old version (v1) ### Technical details ~~We create a multisampled framebuffer when turning 2D MSAA on, as well as a multisampled backbuffer if it is needed.~~ ~~When rendering without the backbuffer we simply have to blit the already rendered 3D scene (if available) to the multisampled framebuffer, render the complete scene and finally resolve the MSAA buffer into the normal framebuffer. I put the final resolve now into the end of `RasterizerCanvasGLES3::canvas_render_items`, since everything should be already rendererd at this point (but please correct if I am wrong).~~ ~~When using the backbuffer we have to consider the following things:~~ - ~~We need to resolve the backbuffer everytime we render onto it, since we sample from it later on~~ - ~~When copying parts of or the complete render_target we first need to resolve the frontbuffer, so we can sample from it, and after copying we need to blit the backbuffer back to the multisampled backbuffer~~ - ~~When clearing the backbuffer we need to clear the normal backbuffer as well as the multisampled backbuffer~~ ~~For Mobile devices we want to use the `GL_EXT_multisampled_render_to_texture` extension so we don't need the resolve step.~~ ### Discussion ~~While this approach works, we introduce quite a lot of blitting operations when using the backbuffer. If this is not wanted, another approach could be to copy or adjust the relevant shaders (like the copy shader or the default_clip_children_shader) to support multisampled textures.~~ ~~While making the images below, I noticed that the vulkan backend does not include MSAA on the backbuffer. That would of course also be an option for the OpenGL backend.~~ ### Images <figure> <img width="1150" height="646" alt="OpenGL_2D_NoMSAA" src="https://github.com/user-attachments/assets/9b7b916a-9edd-4a28-bf7b-cefbf238891a" /> <figcaption>No Antialiasing; Scene with lines, meshes, Sprites, screenreading shader, canvasgroup and groups with a clipped child</figcaption> </figure> <figure> <img width="1149" height="647" alt="OpenGL_2D_8xMSAA" src="https://github.com/user-attachments/assets/c210b3c3-9ceb-43e8-b7c7-62909cf20cd5" /> <figcaption>MSAA 8x in OpenGL</figcaption> </figure> <figure> <img width="1152" height="647" alt="VK_2D_8xMSAA" src="https://github.com/user-attachments/assets/9e11cda6-fc51-4765-9761-a041fe5bbe9f" /> <figcaption>MSAA 8x in Vulkan</figcaption> </figure> <figure> <img width="1152" height="648" alt="OpenGL_2D_NoMSAA_over_3D_8xMSAA" src="https://github.com/user-attachments/assets/64b88a53-4d58-4d7e-95fa-c5e5cd0f0108" /> <figcaption>MSAA 8x 3D scene with not antialised 2D scene on top in OpenGL</figcaption> </figure> <figure> <img width="1150" height="647" alt="OpenGL_2D_8xMSAA_over_3D_8xMSAA" src="https://github.com/user-attachments/assets/aa007dd0-cb09-464f-9000-faeafd43d8da" /> <figcaption>MSAA 8x 3D scene with MSAA 8x 2D scene on top in OpenGL</figcaption> </figure> <figure> <img width="1151" height="646" alt="OpenGL_3D_8xMSAA_inBetween_2D_8xMSAA" src="https://github.com/user-attachments/assets/c4b3a0f2-21fe-415d-9d84-34abb9e31350" /> <figcaption>MSAA 8x 3D scene in between MSAA 8x 2D scene in OpenGL</figcaption> </figure> closes #69462 and #84688

For instance by making this video about it:

I don’t know about you, but I think Godot for lightweight web games has huge potential.

dragonforge-dev · May 1, 2026, 1:26pm

I think this has a lot of uses beyond that. A LOT of published game resources come in SVG formats. Being able to manipulate them for animation could be really useful. All of Kenney’s 2D assets have alternate SVG versions - usually in sprite sheet form. Craftpix releases a lot of their art with alternate SVG versions.

normalized · May 1, 2026, 1:59pm

How do you do it? From what I saw in your videos, you tesselate beziers and update native line and polygon nodes with tesselated points. Point count change will always trigger the whole gpu buffer update. Since in most typical bezier editing situations only a single/few segments are affected, you could do partial buffer updates for those segments only, going directly to the rendering server. The constraint would be fixing the number of sample points but that may be acceptable.

If you constantly tesselate, the obvious thing for improving performance would be to delegate that part to native code via gdextension. It’d be harder to maintain and install but you could have this version for anyone who needs performance boost.

renevanderark · May 1, 2026, 3:47pm

From what I saw in your videos, you tesselate beziers and update native line and polygon nodes with tesselated points

Yes, each time ScalableVectorShape2D.curve emits changed a flag is set to invoke tessellate on it in the next _process invocation. For bézier curves I can simply invoke the native code from godot’s core.

When there are arcs registered in the ScalableVectorShape2D.arc_list those segments are tessellated by gdscript code I adapted from godsvg’s bounding-box calculation:

github.com/Teaching-myself-Godot/ez-curved-lines-2d

addons/curved_lines_2d/scalable_vector_shape_2d.gd

2.19.3


      
          	for i in range(curve.point_count):
          		var c_p := _get_closest_point_on_curve_segment(p, i)
          		if p.distance_to(c_p) < p.distance_to(closest_result):
          			closest_result = c_p
          			before_segment = i + 1
          	return ClosestPointOnCurveMeta.new(before_segment, to_global(closest_result), closest_result)
          
          
          # Adapted from the GodSVG repository to draw arc in stead of determine bounding box.
          # https://github.com/MewPurPur/GodSVG/blob/53168a8cf74739fe828f488901eada02d5d97b69/src/data_classes/ElementPath.gd#L118
          func tessellate_arc_segment(start : Vector2, arc_radius : Vector2, arc_rotation_deg : float,
          						large_arc_flag : bool, sweep_flag : bool, end : Vector2) -> PackedVector2Array:
          
          	if start == end or arc_radius.x == 0 or arc_radius.y == 0:
          		return [start, end]
          
          	var r := arc_radius.abs()
          	# Obtain center parametrization.
          	var rot := deg_to_rad(arc_rotation_deg)
          	var cosine := cos(rot)
          	var sine := sin(rot)

If you constantly tesselate, the obvious thing for improving performance would be to delegate that part to native code via gdextension

As you can see, performance optimization is not my forté, but for a lot of use-cases there are no serious bottlenecks.

That being said, if I were a good c-programmer I would probably want to have a dedicated compute thread to batch all these tessellates to… I’m not a good c-programmer though

And with only 2 focus hours per day to spend I need to pick something I can handle without too much effort: learning better c/c++ would take too long.

Also: I love the ease of shipping for web (also android based web browsers and pwa for touch interaction) and with that ease comes the nothreads compile flag

renevanderark · May 9, 2026, 5:49am

Hi all!

I’m looking for a few more beta testers / code reviewers for the new freehand pencil tool I built into my plugin (Scalable Vector Shapes 2D):

I would love feedback on this pull request:

renevanderark · May 9, 2026, 2:37pm

I merged the pull request, but feedback is always welcome! Release in the asset library is pending now: link to the latest edit