The Power of SVG / Vector (Updated)

  • The engine already sopports import of SVG files, but could really use a way to use it in the engine.

    Vectors has a lot of cool uses, and is commonly used around the web, for both animations, and lightweight UI.

    UPDATE/EDIT: (edited my original post to reflect the many uses of vector shapes, other than graphics, discussed later in the thread)

    I also posted idea here --> construct3.ideas.aha.io/ideas/C3-I-729 explaining how some of the first steps of supporting vector shapes could improve Construct 3.

    Reasons for supporting vector shapes in the editor.

    First step, Simple shapes and curves (not rendered)

    1. Animating objects along paths, curves and shapes. (would be very needed with a timeline feature)

    2. Defining areas and collisions. (Could be used as a null object instead of using dummy sprites.

    3. Working as null object, and making the use of Dummy sprites a thing of the past.

    4. Could be used to deformation purposes similar to how spine and spriter works (deforming shapes along a path, deforming the shape containing a sprite)

    Further uses, (rendered shapes)

    1. Basic shapes for buttons, UI, icons, etc. (A very lightweight option that would scale well)

    2. Import of SVG, for more detailed vector graphics.

    3. Support for vector animation and tweeining individual points (much like how Flash used to work)

    Some interesting online tools that use vector, to take inspiration from.

    Proto.io

    Very powerful prototyping tool i often use to make UI prototyping for apps and web.

    proto.io/en/demos (take a the whack a monster demo)

    Animatron

    A pretty nice timeline animation editor, which is pretty close to how I invisioned the upcoming timeline feature to be implemented. Open link and check some of the examples. Really cool and easy to play around with.

    editor.animatron.com

    Gravit.io

    Very cool and competent online design tool.

    designer.io

    Vectr

    Nice online editor that supports

    vectr.com

    svgator

    No need to explain, just look at these beauitiful animations, that would fit well in any game.

    svgator.com/svg-path-animation

    Tagged:

  • SVG would be absolutely amazing - the sheer reduction in file size for ultra minimalist mobile games would be fantastic, and the crispness of shapes are a huge bonus.

    Sadly I remember something about a canvas limitation the last time this was bought up, but I remain hopeful.

  • Yeah not much has been done to get svg to work with Webgl, and there's several reasons for that.

    Svg can be quite compact when drawing simple shapes programmatically, however it can also get very difficult when such things as complex splines, merged groups, and blends, etc are added. Those issues are then multiplied when you think of transformations. Top that off with the only way to introduce them is to turn them into either quads or triangles.

    So basically we should be able to get some support eventually, but like everything else it will have to be optimised out the wazoo.

    A simple svg to png is doable now, but don't count on transformations anytime soon.

  • There are a lot of very difficult technical challenges with this, especially if you think SVG animation should be included. SVG can't be directly rendered in WebGL, so the two options are to float an element like form controls, or rasterize them to a bitmap and render as a normal texture (which is what the current animation editor SVG import does - it's not real SVG support). Each alternative has severe trade-offs. For example off the top of my head: floating an SVG element cannot layer with anything else in the game (since it's all rendered in a WebGL canvas below it), nor can it use shader effects. Meanwhile rasterizing to a texture has significant impact to performance and memory, may alter the image quality, and seems so difficult to support animation I think we would simply have to rule it out. There would likely be lots of other difficult issues (including workflow issues in the editor).

    Meanwhile according to the suggestions platform it's not actually that popular! Add your votes if you think it's important - but votes won't solve any of those technical tradeoffs...

  • Ashley If SVG would be off-canvas, couldn't we get around layering with z-index? Divs could form a new layer system, which can float under the canvas. This would kind of blend into the requests to add more DOM functionality to C3 (admittedly I don't think many people request this).

    Unsure if this helps with the WebGL:

    github.com/canvg/canvg

  • The thing we need to look for is a 2d mesh editor/animator. Edgar was always hinting at it for Spriter.

    No idea how far it's gotten.

  • Ashley Hmmm... Supporting animations and more andvanced stuff might be second step, but should be fairly easy to at least draw vector images on canvas.

    ctx.drawImage should support drawing an SVG in the canvas.

    jsfiddle.net/Na6X5

    Would something like that at least be feasible? There's a lot of benefits of using SVG's in some cases. Small size, scalable, perfect for crisp UI elements, icons, etc.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Ashley If SVG would be off-canvas, couldn't we get around layering with z-index?

    No. It's a different element so can only appear above or below the WebGL canvas. Only things actually rendered in WebGL can appear layered between sprites.

    ctx.drawImage should support drawing an SVG in the canvas.

    That's the canvas 2D context, not the WebGL context. The workaround is to upload that canvas to a WebGL texture, which is the rasterize-to-texture approach I mentioned previously.

  • I did some further tests and was able to get an animation working as well using the same approach, but using setInterval to call the draw function. It stepped through the svg animation at the pace that I set, and could draw regular pixel images on top or below the drawn svg as well.

    Could be set to draw each frame, so I don't see why this would be very hard to implement at all.

    The best way would be to make it as a new object type plugin in C3.

    Of course you probably can't edit it directly in C3, but that doesn't matter, as long as you can preview it in the browser.

    There's a lot of differnet ways to animate svg's and most of them seemed supported, using ctx.drawImage

    en.wikipedia.org/wiki/SVG_animation

    There's even online vector editing tools like this one.

    editor.method.ac

    Using the inspector on this site, you can see how it would work to edit SVG's in construct even.

    drawing SVG's inside of a canvas doesn't seem very complex at all, and is probably supported by most browsers nowadays. ctx.drawImage drew most SVG's i threw at it, with transparency, gradients, etc.

    The same approach could be used to draw paths etc, for enemies to follow.

    I think it's about time Construct started supporting shapes, vectors, paths, splines, etc. ;)

  • > Ashley If SVG would be off-canvas, couldn't we get around layering with z-index?

    No. It's a different element so can only appear above or below the WebGL canvas. Only things actually rendered in WebGL can appear layered between sprites.

    > ctx.drawImage should support drawing an SVG in the canvas.

    That's the canvas 2D context, not the WebGL context. The workaround is to upload that canvas to a WebGL texture, which is the rasterize-to-texture approach I mentioned previously.

    So what's the overhead of doing that? Has it been tested?

    I found this quite interesting..

    two.js.org

  • I can't convey enough what a huge gulf there is between a simple experiment that looks like it works, and production-grade software that scales to real games in a range of real cases. Sure, you can upload a texture every frame, but this nukes performance on some devices (especially low-end Android). It's similar to the text-object-changing-every-frame performance hit that some people run in to, which uses a similar approach of texture uploads - however animated SVGs are likely to be significantly worse, since they would likely be used with many more instances and at larger sizes. Synchronous texture uploads can also jank the game; asynchronous ones have complex scheduling issues and can introduce a visible delay. Simply dumping everything in to a texture per-instance will end up using a colossal amount of memory if you have lots of instances showing differently - probably enough to crash the game on some devices.

    When I say it would be very difficult, it's not a question of "can it be done?" - as with most things it's easy to whip up a basic demo that shows something working. The real question is "will it work well once scaled up to the demanding requirements of real-world games?"

  • I don't understand the motivation behind this request. I can't think of a single game engine that renders svg in their runtime (the only exception is real-time text rendering, but that's not technically svg, just a similar process).

    The process in any major game engine is to build art in a vector graphics program like inkscape or illustrator, then export it as a png (rasterize it) to whatever resolution you want. The svg file is just saved off as a source document. You can still get very crisp looking art, especially if you export it at 2x the target resolution. That way when it's scaled down it still looks amazing.

    What's the issue with that?

  • I don't understand the motivation behind this request. I can't think of a single game engine that renders svg in their runtime

    Flash

    The main points are size, file inlining, scalability, and interpolation.

  • I don't understand the motivation behind this request. I can't think of a single game engine that renders svg in their runtime (the only exception is real-time text rendering, but that's not technically svg, just a similar process).

    You're forgetting a pretty huge one, although pretty dead now. Flash... There was a LOOOOT of games made with flash back in the day. Pretty much every game online was made with flash.

    Vectors was one of the few things I actually liked about it. Action script was pretty flexible as well, but now we're talking about vector itself.

    Vector paths support in general in any engine is still very useful. For many reasons.... apart from graphics.

    Here are some reasons

    * A simple path can be used for an enemy or Npc to travel along. Or just in general for animating movement, from A to B. (I don't know how they going to solve making a competent animation timeline feature, without any kind of paths to control movement.)

    * Paths and shapes can be used to define areas, a much better solution than placing a lot of useless dummy sprites with individual collision boxes all over your map just to block movement of where you can and can't go. Just draw or define an area with vector shapes directly on the layout, and use add it to the list of collisions boxes to interact with. Kill the old collission boxes and assign a simple shape instead.... and you can have perfectly round collision on balls for example.

    * Simple Shapes and paths can be used for deformation purposes as well, much how like Spriter and Spine works, but that's another topic.

    * Apart from these, there's the obvious advantage of using svg's for general graphics. Especially, UI, Icons, buttons, etc etc.

    Pretty much every game engine I know has some implementation of paths, and shapes in some form, for things mentioned above.

    My suggestion is to start from the ground up, starting to support basic shapes and paths for purposes other than graphics, later they can support loading more complex vectors.

  • Updated my original post, and also posted this on the ideas suggestion.

    construct3.ideas.aha.io/ideas/C3-I-729

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)