[Feature request] Allow "svg" as image resource

[Wend1go]

Description

Allow to choose "svg" as image resources.
Pixi allows to choose scalable vector graphics (svg) as image resources and automatically converts them into raster images.
(The raster image size depends on the size settings inside the svg file)

I did a quick test and added svg to the filter of the choose image resource dialog in:

GDevelop/newIDE/app/src/ResourcesList/LocalResourceSources.js

Line 67 in 6a9f109

extensions: ['png', 'jpg'],

And it worked (almost) out of the box. The svg sprite shows up in the sprite editor dialog with a thumbnail, it can be dragged into the scene and it gets rendered as a usual raster graphics sprite.

What needs to be done?

• As it is a scalable vector graphic it obviously can't be edited inside Piskel editor, so the button must be disabled / hidden when an svg image was loaded
• Further testing should be done although it seems to work out of the box

[4ian]

Interesting, I did not know about this capability.
Is it something that is:

• Supported by other game engines?
• How do we specify the size of the renderer bitmap in memory?
• When does the conversion happen?

I want to be sure not to unlock a feature that would get used but then would be hard to maintain if Pixi drop the support for this or if we switch to something else/another platform in the future. In short, is this a useful addition that other game engine/games are supporting or a risk of feature creeping/bloating?

[4ian]

Note that as GD is growing, I think more and more features like this could be labelled as "experimental" - i.e: can be working but not production ready and use at your own risks.

[blurymind]

this is quite interesting. Potentially piskel shouldnt be able to edit it, but in theory we could send it rasterized?

[Wend1go]

I don't think this feature will be removed. It has been a Pixi feature for quite some time, up to Pixi v4, they had a dedicated load function for it (now deprecated):
https://pixijs.download/dev/docs/PIXI.Sprite.html#.fromSVG
Later, they integrated it into the regular load from function (recommended way to load them in Pixi v5):
https://pixijs.download/dev/docs/PIXI.Sprite.html#.from

Pixi converts the SVG into a raster image by first rendering it to a temporary canvas and using this as a source for the image:
http://pixijs.download/dev/docs/core_textures_BaseTexture.js.html#line554
So loading of SVG images might take a bit longer but since they use a DOM element to convert the SVG to a raster image I think it should be Future Proof™️.

The dimensions of the image are read directly from the SVG itself.
Theoretically we could even add a scale property to the IDE and parse the SVG file, since it is plain text and change the dimensions via a temporary copy of the file. After a reimport we'd have a higher or lower resolution version.
And this would also be the main benefit of supporting SVG images. The game developer doesn't need to worry about the size of the graphics while drawing them, since it can easily be adjusted later on without any loss of detail.
The Godot engine also supports SVG images with an automatic conversion into raster images.

[Wend1go]

Created a Trello card here:
https://trello.com/c/X1C6C3d9/333-add-support-for-svg-scalable-vector-graphics-in-the-game-engine

[4ian]

Nice the trello card is a good idea :)

And this would also be the main benefit of supporting SVG images. The game developer doesn't need to worry about the size of the graphics while drawing them, since it can easily be adjusted later on without any loss of detail.

Right, but as the game engine we still need to render to a temporary canvas, meaning that the size is still being important - how to know if you must render this rasterized SVG as 100x100 or 1000x1000? Should we add a limit in terms of size to avoid rendering things that are huge?

The Godot engine also supports SVG images with an automatic conversion into raster images.

Do we know how they do? On the fly, during the game? During the loading? What happen if I take an object using a SVG and multiply its scale by 1000? Is the whole thing re-rendered?

[blurymind]

I believe godot converts them on import and keeps the result in a subdir. They implemented an import system that is similar to unity's way of handling resources. When you copy new files to the game project folder, godot detects the new file and applies an auto import conversion on it that creates the optimized file that the runtime will use. It does this with 3d files, svg, images, fonts and possibly other types. Once you edit/change the files, godot detects the changes and re-runs the appropriate importers to recreate the runtime file. The game only uses the optimized results from the importers. What is nice with having this system is the ability to automatically pack all image resources in atlases the engine reads- reducing draw calls.

In essence, godot has an abstraction between what the dev is editing and what the game engine uses in the end. The editor automatically optimizes the resources in the background and is tracking for changes

[Wend1go]

Right, but as the game engine we still need to render to a temporary canvas, meaning that the size is still being important - how to know if you must render this rasterized SVG as 100x100 or 1000x1000? Should we add a limit in terms of size to avoid rendering things that are huge?

Well, what I meant was that it doesn't matter if I draw an image at 64x64 or 128x128 since it can be scaled freely. Importing extremely huge images is also possible with raster graphics, so I don't really see why SVG should be a bigger problem than conventional raster graphic images.
Since SVG is plain XML, we could parse the file before the import and check if the scale is reasonable. By adding a new property to the image resource, we could even overwrite that value.
By loading the SVG file from memory things like the scale could be overwritten:
var texture = PIXI.Texture.fromImage('data:image/svg+xml;charset=utf8,' + mySVGContentAsString);

[4ian]

Sure it's not worse than raster, it's just that people can't expect objects rendered with an SVG image to be scalable like in a SVG editor - apart with some logic re-rendering the SVG in memory or with an integration of a SVG engine drawing the shape directly without rasterization (but SVG engine are complex so I doubt there is one for Pixi?) @blurymind yeah there is nothing like this in GD but the resources manager/resources system is a layer of abstraction made for this :) Right now all resources are used as is, directly from their files, but we can image some being processed into texture atlas, or SVG processed into images.

…

On Fri, 12 Jul 2019, 07:55 Wend1go, ***@***.***> wrote: Right, but as the game engine we still need to render to a temporary canvas, meaning that the size is still being important - how to know if you must render this rasterized SVG as 100x100 or 1000x1000? Should we add a limit in terms of size to avoid rendering things that are huge? Well, what I meant was that it doesn't matter if I draw an image at 64x64 or 128x128 since it can be scaled freely. Importing extremely huge images is also possible with raster graphics, so I don't really see why SVG should be a bigger problem than conventional raster graphic images. Since SVG is plain XML, we could parse the file before the import and check if the scale is reasonable. By adding a new property to the image resource, we could even overwrite that value. By loading the SVG file from memory things like the scale could be overwritten: var texture = PIXI.Texture.fromImage('data:image/svg+xml;charset=utf8,' + mySVGContentAsString); — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1137?email_source=notifications&email_token=AAJYRAX3AUJQ2RWBSCYW5XLP7AME5A5CNFSM4H44AUGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZYYMUY#issuecomment-510756435>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJYRAUW3OJQFTN7SVX25K3P7AME5ANCNFSM4H44AUGA> .

[arthuro555]

According to https://pixijs.download/dev/docs/PIXI.Texture.html we would also need to wait for SVGs to fully load, so modifications in game.loadAllAssets would probably be required.

[CCIGAMES]

maybe try using photopea?
https://github.com/photopea/photopea