PathRenderingLab
PathRenderingLab copied to clipboard
JoaoBaptMG
Would a Xenko integration be easier?
From what I've heard, the Xenko graphics API is pretty much the same as MonoGame , but it has a full-featured editor, an absolute great shader language and you could make SVG a new asset type that can be imported, managed and previewed by game developers in Game Studio.
I've made an example of a xenko root render feature that integrates properly into a scene and could be used.
That’s interesting, I’ve never heard of Xenko. I was going for MonoGame because it exposed very easily the raw drawing primitives so I could prototype easily my functions.
However, the idea currently is to move most of the performance-critical code to C++ and properly transform it into a library, so it can be called not only from MonoGame, but from any C# codebase, like Unity.
the performance-critical code to C++
which stage of the SVG process do you have in mind there? isn't loading/parsing an SVG a one-time thing and the rest is done on the GPU?
No. Passing the SVG is actually the easiest part. The lab processes the SVG data into triangles that do not overlap, are simple and only cover the actually filled region of the fill. For that, it employs heavy algorithms that can be as worse as O(n^2), the reason which I want to squeeze every ounce of performance (e.g. a somewhat complicated path that “wraps itself around” is taking 16 seconds to process).
oh right... you need to construct triangles! thanks for the explanation. yes, could be a little native lib with defined in/out data that can be called from everywhere...