search

JoaoBaptMG / PathRenderingLab

Repository for research on complete SVG rendering
Other
99 stars 4 forks source link

Would a Xenko integration be easier? #2

Open tebjan opened 4 years ago

tebjan commented 4 years ago

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.

JoaoBaptMG commented 4 years ago

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.

tebjan commented 4 years ago

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?

JoaoBaptMG commented 4 years ago

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).

tebjan commented 4 years ago

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...