UNDER CONSTRUCTION
These are the open-source libraries our Editor will use:
Paper.js
Using HitTest as like in Visual Basic, we can create a more curved physics engine as described in the white landscape and since it is vector based instead of pixel based, we can create water waves that can influence how the character moves in water, that is, the environment can influence the movement of the character just by a simple hittest of a wave as shown below. Depending on the boyency, the wave can simulate water or Jello! Jelly!
Instead of using Alembic as with Unreal Engine for high-end devices, we can create splashes and other interesteing environment and therefore physics that the character can interact with, like slime. These are just some of the FUN gaming possibilities of using SVG instead of WebGL, that is, these are the benefits of SVG that WebGL would not be capable of doing for low-end devices.
TwoJS
SVGator
Here is an example of an 2K rasterized png animation that is not supported on iPhone3G because the image file sizes are too large in size, and the RAM of the iPhone3G divice cannot support it, so you wont see the animation displayed if you view this website on the iPhone3G
New Window
Here is an SAME example of the 2K animation but converted to SVG using InkSpace and then using SVGator CSS export. We went into the exported SVGator file and using our algorithm, converted it to be able to play on even iPhone3G at a good FPS, let alone an iPhone4
SVG gives better performance with smaller number of objects or larger surface.
Canvas gives better performance with smaller surface or larger number of objects.
"Technically, they aren’t entirely mutually exclusive. A SVG tag can be painted to a Canvas tag.
As Blake Bowen proves, you can even keep the SVG on the canvas very crisp!" (Citation)
USE BOTH? SVGator + Pixie.js
WickEditorLegacy
is a great tool that exports to low-end devices, and for this reason, was chosen to be one of the developer tools used by the TMC_API to render for low-end devices like the iPhone3G. If we look at the WickEditor legacy source-code, we notice it uses Pixi.js. For this reason, we choose to use Pixi.js in TMC_API as well independant of the Art authoring tool that is the LegacyWickEditor.
Using wickEditor Legacy, on each frame Update() WickEditorCanvas' SVGator svg-tag to correct resolution, using Blake Bowen proven example.
Then only, using the created Path2D object that the svg-tag was passed as a parameter, check the hitTest of wickEditor's characters' Bounding Box points using CanvasRenderingContext2D.isPointInPath(x,y) function
CONCLUSION:
One extremely basic way to answer it is "use canvas when you cannot use svg" (where "cannot" might mean animating thousands of objects, manipulating each pixel individually, etc.). To put it another way, SVG should be your default choice, canvas your backup plan.
TMC_API goal: Intermediate between both SVG and Canvas based on their benefits
An example of a game that can benefit from both SVG and Canvas(Raster graphics) is a game like Streets of Rage.
The Canvas will be benefitial to render the character animations as sprite sheets so that it is able to be quick in rendering the characters animation, as opposed to computing thousands of svg paths to draw the character at runtime without cacheing to bitmap.
The SVG is benefitial to draw LARGE areas, so SVG is benefitial to draw entire game level-designs compared to 2K+ Rasterized (Canvas) elements as background.
TMC_API must be able to control the layer system of both Canvas elements and SVG elements, for example, notice in the below example that the rasterized character is behind the SVG element to show that it is behind the building that is transparent. If the character is to come front, then the TMC_API should be able to bring it to the front. Therefore we cannot use Canavas alone as the primary tool because Canvas alone cannot draw the level in detail as like how Google Maps does when you zoom in.
Having the option to render in SVG compared to Rasterized allows a SVG to allow rendereing huge characters in high-end devices (Desktop, iPad, Laptop, etc) that benefits the Artist ability to show curves and lines as in Classical Animated Film.
At the same time, for low-end, low pixel screens, to help performance of the game, instead of rendering thousands of SVG path lines, we just make a Rasterized image the size of the screen, that is, a 720p image or even a 320p display image for iPhone4/iTouch4 or iPhone3G (1-core processor/GPU) respectively.
The iPhone3G is not duel-core but has a GPU, so rendering thousands of svg paths for a single characters' frame in an animation will take too much of the (CPU) processor. That is, the 1-core processor is not enough to render it quickly to keep the fps at a believable rate. Only the GPU can keep the framerate at a good rate, so we rasterize using Pixi.js and the performance of the character animation is believable because the fps is good enough to render at a higher fps, so no lag.
But the character sprite sheet that is created can still have each frame of it's animation as big as the display screen, as long as the image data is removed after it has displayed its FILM-like Classical Animation. So Characters can still be rendered BIG as in Animated Film, even on low-end devices because we have the Artists create them using SVG technology of bazier curves that the device will later transform if necessary (1-core processor) to a rasterized version.
Although SVG Character animations can benefit from Rasterization, there are some things that should not be Rasterized, that is, LARGE landscapes that can be zoomed into such that when zoomed into, the detail of the sceen does not reduce but is still high (as opposed to zooming into pixels of a sceene).
SVG can also be used for physics, not only in 2D but also in 3D. Example is to use SVG to control and calculate a car on a smooth 2D curved surface that can then be translated to positions in a 3D world. An example is going up or down a hill in a low-polygon 3D environment. In a low-poly sphearical world (like-in Dragon Ball Z) we do not want our car or character physics to be constrained to the the large triangles surfaces of the terain that will cause rigidity of movement. Although we need a low-polygon count for the landscape becuase we are creating an entire world to be played on a low-end device, it shouldn't make the gameplay frustrating, so SVG can help with this.
VINE GROWING IN BLENDER (WITHOUT USING BONES), MAY BE ABLE TO BE EXPORTED TO PLAYCANVAS USING MDD WORKFLOW & SHAPEKEYS. RESEARCH IF POSSIBLE?