This looks juicy! :)
@mindbrix does it blend colors in linear space/are colors linearized internally?
Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
21–30 of 58 posts
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#22This looks juicy! :) @mindbrix does it blend colors in linear space/are colors linearized internally?
Linear at present.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#23Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#24Nice work,
without having looked at your particular shader code, I can only imagine the horrors and countless of hours that went into writing and debugging the shader code...
Which OpenGL and GLSL versions are you targeting?
I've been thinking about possibly prototyping integrating an SVG renderer into my game engine that would rasterize the textures from .svg files on content load. Would offer some benefits of improved packing and better scaling and resolution independence. Using an GPU based solution would offer the benefit of being able to skip the whole "rasterize on CPU then upload" dance but just rasterize directly into a texture render target in some FBO and then use the texture later on. That being said CPU based solution is definitely easier and more bullet proof ;-)
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#25Interesting, how does this comparento the Rive renderer?
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#26Interesting, how does this comparento the Rive renderer?
I can't really answer that in detail yet. I suspect Rasterizer will be faster for complex scenes.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#27I am still endlessly fascinated by how modern GPUs can handle stuff like UE5, raytraced lumin (whatever) but still struggle to do 2D rendering. I mean I get it logically, but it just feels so disconnected. Always neat to see this kind of stuff however. Very cool.
The core problem is path winding: https://en.wikipedia.org/wiki/Winding_number Paths can be any size, and the problem is hard to parallelize. GPUs like stuff broken into small regular chunks. TestFiles/Manchester_Union_Democrat_office_1877.svg is composed of a single huge path, which was a great torture test.
[deleted]
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#28I've been working on this problem on and off for over 10 years. AMA ;-)
You mentioned winding numbers in a couple of places
Wouldn't it make sense to do a "first pass" and eliminate paths that intersect themselves? (by splitting them into 2+ paths)
I never understood why these are supported in the SVG spec.
It seems like a pathological case. Once self-intersecting paths are eliminated the problem gets simpler.. no?
Or would a CPU pass be cheating?
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#29This looks juicy! :) @mindbrix does it blend colors in linear space/are colors linearized internally?
Once you do color space correct color mixing you realize that people actually expect the wrong result, i.e. the result you get from mixing in sRGB and then you have to make the rendering output visually more "correct" by making it incorrect. One of the cases where the correct computation is the wrong answer.
Heck, that's what people expect with CSS for example.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#30I've been working on this problem on and off for over 10 years. AMA ;-)
You mentioned winding numbers in a couple of places Wouldn't it make sense to do a "first pass" and eliminate paths that intersect themselves? (by splitting them into 2+ paths) I never understood why these are supported in the SVG spec. It seems like a pathological case. Once self-intersecting paths are eliminated the problem gets simpler.. no? Or would a CPU pass be cheating?
The Rasterizer algorithm handles self-intersecting paths without issue. Removing them requires expensive and complex computation geometry.