Scalable Vector Shapes 2D on discord - 2.34: New explainer video out today!

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

renevanderark · June 13, 2026, 10:04pm

RIgging SVG!

As of today you can rig your 2D Scalable Vector Shapes (and .svg as a node imports) to a Skeleton2D.

Early access

You can get early access to this feature via the 2.24.4 release on github. Do so at your own peril, the functionality was less stable than expected,

Released soon?

Well, I am a working dad too, so I hope I will get around to the bug fixes soon. I will revoke the releases for now.

Sneak preview

SVG import demo on youtube short

[edit]: after some extra extensive testing in the live you can see below, I still ran into some bugs having to to with transform mismatches (between skeleton and rigged parts). I will get back on it as soon as I am able,

renevanderark · June 15, 2026, 7:20pm

Release 2.24.4 is out now in the asset store and library; here’s to hoping for not too many bugs.

I will be going live for a while on youtube to try out a bit of rigging on my game character Jacques:

I’m always muted, but I’ll try and notice the youtube chat messages this time

[edit] I dropped the live recording for now; will make a new one once I’ve sorted out the bugs:

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

Fix multiple bugs with skeleton deformation

opened 02:23PM - 14 Jun 26 UTC

renevanderark

help wanted

- [ ] Fix the `deformation_map` bug by not setting an initial empty `Dictionary`… as default value and by testing for valid instances where it is used - [ ] Fix transformation bugs in deforms: use relative `position` and `rotation` delta's of the bones only and __do not cheat__ by using `global_position`. Most likely things went south because `global_position` is a derived value. This may be caused in edge case when Bone2D referred to in map value was freed by deleting it.. Also check for keys pointing to points that have been removed from the curve

Definitely not giving up.

renevanderark · June 15, 2026, 8:58pm

Well, it looks as though it all needs a little more work. Even though I thought I’d done quite a bit of testing there.

What’s life without a little risk, though?

I am taking down the releases from github and the new asset store for now… Thankfully that mysterious stable checkbox proves helpful already!

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

Fix multiple bugs with skeleton deformation

opened 02:23PM - 14 Jun 26 UTC

renevanderark

help wanted

- [ ] Fix the `deformation_map` bug by not setting an initial empty `Dictionary`… as default value and by testing for valid instances where it is used - [ ] Fix transformation bugs in deforms: use relative `position` and `rotation` delta's of the bones only and __do not cheat__ by using `global_position`. Most likely things went south because `global_position` is a derived value. This may be caused in edge case when Bone2D referred to in map value was freed by deleting it.. Also check for keys pointing to points that have been removed from the curve

renevanderark · June 16, 2026, 9:22pm

Scalable Vector Shapes 2D 2.24.5 is out!

After finishing up the last glitches and documenting the effect of RESET tracks on Rest poses, I’m finally ready to announce the release of:

Rig the System with a Skeleton2D!

Get 2.24.5 - The System is Rigged from the asset store.

From the asset library

From Github

Always back up your project when updating a plugin!

renevanderark · June 17, 2026, 3:11pm

Coming up - A Human Skeleton2D

Dear all, to help along the 2D SVG Rigging agenda I created a small Skeleton2D asset today to ship in the asset library and -store:

Skeleton 2D Asset Project on Codeberg

It will be shipped under the name “Human Skeleton 2D” and is currently under review.

dragonforge-dev · June 17, 2026, 4:08pm

Very cool.

normalized · June 18, 2026, 11:20pm

This looks great!

renevanderark · July 4, 2026, 7:35am

Hear ye, hear ye!
To anyone who wants to be in the Scalable Vector Shapes 2D Testimonial video this summer, you can still share how you used the plugin with a short story, screenshot and ideally a 1HD video (1920x1080)!

Just drop whatever you’d like me to promote in the discord showcase channel (with your explicit consent, so I know you want me to promote it).

These screenshots already made it into the asset store front:

Ballpark roadmap :

deliver SVSPolygonCacher for performance tweaking of animated curves and dynamic outlines
finish rigging + drawing video (“Rigoberto”), include the SVSPolygonCacher and publish
record testimonial video and YouTube short with all your contributions in it

Dizzy_Caterpillar · July 4, 2026, 8:18am

About the performance. In the scalable_vector_shape_2d.gd you have code like this:

polygon_points[0].distance_to(polygon_points[polygon_points.size()-1]) < 0.001):
...
if p.distance_to(from_local_pos) > farthest_point.distance_to(from_local_pos):
...

Why don’t you use distance_squared_to() function instead? It’s faster as the square root calculation is not needed. So for example:

polygon_points[0].distance_squared_to(polygon_points[polygon_points.size()-1]) < 0.000001):
...
if p.distance_squared_to(from_local_pos) > farthest_point.distance_squared_to(from_local_pos):
...

renevanderark · July 4, 2026, 9:35am

The answer is simple: I was not aware it was faster.

The biggest performance bottlenecks pop up in the profiler at runtime.

This specific example did not pop up. Probably because it is usually called during edit mode to test whether a line can be considered closed or not. But not sure right now, as I’m on a phone and not on a laptop. (Edit: from the top of my head, this is of course not true: testing whether a curve can be considered closed is of course used all over the place.)

I see the docs mention it being faster, but that to me raises the other question: why are there two separate methods that compute the same thing? One with an intuitive name and another with a mildly less self-documenting name that just happens to be faster. What problem does this solve and why not make distance_to an alias of distance_squared_to? There must be an important underlying reason I’m missing here. Do you know?

What I would welcome a lot is a very rigid code review, to see what all can be done to improve runtime performance (in pure gdscript) of the most Geometry heavy operations.

I am more a UX oriented programmer by trade, so a thorough review or contributions via pull request from a good - performance savvy - game developer would be super helpful.

But you see, we all do this in our spare time, so thus far I have not found anyone willing.

If you ever feel enthusiastic about going through all this code I would love it!

Then again. I understand perfectly if you too, like most of us, do not have time for all that either.