I tried changing changing tessellation to advance and different combinations of step distance and sampling with virtually no enhancement. According to the advertisement I shouldn’t be getting that much pixelation. I am using the same drag-and-drop import demonstrated on the following link:
I appreciate the recommendation. This is the result after building for PC with 2X MSAA and ultra quality. Any other suggestion or this is the best result I should expect? By the way in terms of game performance should I use raster images or the vector graphics importer provide similar speed?
You will get better results with more samples per pixels (4x or 8x), but this requires more GPU memory. So you will have to evaluate if this is acceptable for your project.
In terms of performance, simple colored SVG sprites should perform very similarly to normal sprites. SVG sprites that contain textures and/or gradients are a bit more expensive to render. If you don’t really need the “infinite” resolution of the SVG sprites, you may use normal sprites instead. Some users made simple tools to render SVG sprites into texture, and rely on normal sprites afterward. We have a method to help for that matter: VectorUtils.
RenderSpriteToTexture2D(). That said, it’s always a good idea to use the profiler to see if SVG sprites are causing performance issues.
From the looks of the image, there is no MSAA active at all (not even 2x). Double-check the quality settings as well as the camera settings to allow MSAA on the scene. It should look better than this.
While I can see how this would work well, I really think Unity is missing a dynamic antialiasing method for vector graphics right now. Especially when you consider the previous state of the art was the likes of RageSpline etc, where you can set the thickness of an outline “edge” which uses a thin texture to produce an antialiasing effect. I recognize though that this means when the graphic or camera are scaled, the thickness of that outline is compromized and it would either have to be regenerated dynamically all the time or the shader would have to do some trickery based on a scale factor/camera distance etc to generate it dynamically. Unless the game doesn’t do any scaling of course.
It’s also possible to compute and render curved antialiased edges in a shader, on a per-triangle basis, if enough info is passed to the shader. So maybe you need a dedicated curve-rendering shader?
Switching on the full-screen antialiasing and having tons of extra samples is probably a big drag on performance without giving really ideal 256-levels of antialiasing smoothness.
Valid points indeed. AA without MSAA is something we’d like to tackle too. Of course, without the additional samples you can never get back pixels that fell out the rasterization. Personally I wouldn’t bet that a cheap software AA can beat HW 4xMSAA quality. Probably it will be a tradeoff of some sort where (as you mentioned) you need to pack more data in your vertices to fuel the SW AA shader, which also takes memory and performance. As more vertices are included in the scene the cost will increase and probably hit a breaking point where HW MSAA would become the faster and tighter-in-memory path.
Just wanted to shed a light that a potential SW AA solution might not be the magic bullet people hope for
Yes it would likely double the number of triangles, and there is the problem of scaling. But it does look good. Another approach is to actually compute curves in the shader across a triangle, with perfect antialiasing. That said, microsoft files a patent on that method so I’m not sure you could use it. Doesn’t MSAA quadrouple the number of pixels of memory when you go to 2x, and then basically 16x more when you go to 4x? It’s not really as perfect as it could be though particularly on edges close to vertical/horizontal.
What do you think to possible using some kind of blur operation across the whole screen?
2xMSAA = 2 samples per pixel instead of 1 sample, 4xMSAA = 4 samples instead of 1 sample, so the multiplier is also the memory size multiplier. A 2xMSAA surface takes double the memory amount of a non-MSAA surface… etc.
This can work for certain cases where the art is mainly flat (no texture details), otherwise a naïve blur will smudge the details along. Also, it can never restore pixels that escaped rasterization, so it might look ok on a static image, but if the camera starts panning for example, shimmering artifacts due to undersampling will still occur.
Fighting undersampling in computer graphics is never an easy task. MSAA happens to be an ok approach for now because of the HW support, but other techniques might work well for certain cases too. It’s a matter of choosing your battle: memory vs perf vs quality vs detail. The more high-level knowledge you have about the final scene, the better-educated will be your decision. Personally, I’d love to play a bit with some SW AA for vector graphics, but I know already I won’t be able to achieve something that pleases all needs. It will be just “one more option” that people can choose when trying to address undersampling in SVG.
It sure helps. This balances quality & detail over memory and performance, which certain targets can take (e.g. PC and PS4) but doesn’t sound like a good option for limited phone devices.
When the geometry is being rendered as triangles, is there some way in a shader perhaps to calculate the ‘angle’ of the slope of the side of the triangle, and then render that edge antialiased at a 1 pixel width no matter the scale? I guess you’d have to pass in all 3 sets of vertices to every vertex.
Another thought based on that… would be to store the normals of the angle of the “edges” in some output buffer then run that through a shader that antialised based on the edge angles.
That’s interesting. In a future where every device has a high-DPI display, maybe sub-pixel antialiasing will be a thing of the past!
This is something @wbahnassi_unity and I were thinking about. This has a few downsides as each vertex become heavier with the extra data, as you mentioned. Also, we may need extra space to compute the antialiased edges. We could add extra geometry around the triangles or enable conservative rasterization, both of which have downsides as well. But this is one of the approaches we are exploring.
At least you’re not using an “accumulation buffer” to jitter the position of the output over several frames to try to make it look antialiazed
I wouldn’t mind seeing the extra geometry outlines around the edges of shapes, maybe as an option that can be switched on/off for those who want the quality. It doesn’t add a lot of extra fill rate, mostly more mesh data. Maybe a vertex shader could adjust the thickness of the extra quads to match the zoom factor.
Or… you could convert all straight edged triangles into spline data and render the whole thing antialiazed inside each triangle so that even when you zoom in there are no straight edges seen. Somewhat more overdraw though I guess.
Re High DPI yes I think that apple’s intent to try to get rid of “the pixel” by having them be so small you can’t see them, so that you don’t even need to antialiase anything… though it’s much the same as a full-screen multi-sample, just showing the hidden buffer to the display rather than blending groups of pixels together.
OR hey… an option to convert the geometry to a textures made from a signed distance field, so that it always looks crisp and antialised at almost any size
