“com.unity.ui”: “1.0.0-preview.13”,
“com.unity.ui.builder”: “1.0.0-preview.11”,
“com.unity.vectorgraphics”: “2.0.0-preview.13”,
I have imported an svg but when I go to UI Builder into a VisualElement and in the Inspector go to Background > Image > Vector the svg does not appear.
Is this not a supported functionality, is there another way to use svg’s in UI Builder?
Hi,
Did you import your SVG asset as a “UIElements Vector Image”? Unity imports as “Vector Sprite” by default.
Try to reimport and let me know if you are able to see it 
Sebastien
Sorry I followed the process of
“Assets” > “Import New Asset…” > Then I clicked on my svg
Is there another workflow to import an Asset? I also tried dragging it into my project folder. Sorry if I am missing something obvious.
Image is broken when I put it in ui builder as a vector sprite. Is there a way to put the SVG into a vector image?
Select the asset in the Project window, and in the inspector select the importer type as “UIElements Vector Image”
This worked thank you!
hi, I am new to Unity UI’s new toolkit and unable to do the above-mentioned step to import the SVG file. please help me with screenshots
Hi there, I am trying to use an svg vector image, and even though I am using the “UIElements Vector Image” setting, the image loads but its not scalling smoothly as I would expect, not sure what setting I should be trying.
Thanks!
The UIElements Vector Image type does not currently import as an actual vector data.
You can try to increase the resolution in the import settings, at the expense of large file size.
Just curious if there is a timeline for it to import as vector data? I didn’t realize this until I came here. It was the whole reason I was using svg vs png.
Thanks!
The storage is still different than PNGs though. Basically SVG is interpreted into a Mesh, which can then benefit from anti aliasing.
I don’t have a timeline for actual vector data storage.
Why was a CSS based approach chosen, without considering the rendering benefits of CSS (antialiasing of shadows, bevels, SVG, and shape rendering), whilst also seemingly handicapping TextMeshPro’s spatialisation opportunities, and without consideration of the problems of doing diegetic interfaces with CSS (not sure it’s even possible), nor concern for near field perspective oriented UIs as seen in The Division?
Is there any chance these can come to be within the next 2 years?
Vector Graphics wasn’t started with UI Toolkit in mind, but rather to be used with the Sprite system, which is Mesh and Texture based. UI Toolkit support was added as a workflow improvement
In 2021.2 UI Toolkit is internally moving away from tessellation to implement USS styles (rounded corners, borders) so we are definitely going in that direction.
Obviously we are considering upgrading the SVG support with a similar approach but this is a complex endeavour.
As usual we have finite resources and we have to chose where to focus first.
Edit: Note Vector Graphics is still in preview, the lack of runtime vector data support plays a large role in keeping it in this state for now.
There is a chance, probably not 2022 release, maybe 2023 release.
Using a CSS like approach to UI in games is, I don’t have a nice way of saying this… ludicrous.
It will not and cannot end well.
UGUI was a repurposing of NGUI and that was better than nothing…
But Unity had the chance to go to the next level for Game UI, to design a dynamic system based on physical constraints… because it’s a game engine with a plethora of physics engines to choose from.
Using a CSS-type approach is the worst possible choice.
Akin to forcing users into The Hub instead of starting their engine and project as fast as physically possible.
I think we’re getting a bit off topic. I am not sure what you mean by “dynamic system based on physical constraints”, maybe you could start a new thread to discuss it ?
I don’t know what you believe won’t work in taking inspiration in CSS. A lot of users seem to appreciate this decision and borrowing on familiar technologies was on purpose. Again, if you have some questions or concerns, please start a thread.
As per the first comment, you’ve taken the worst ideas of CSS (verbosity and nesting and code) and ignored the best aspects… that’s why it’s on thread. One of the best aspects of CSS… the rendering of shapes, svgs and effects.
None of these three things have you taken on board. And they’re some time away.
This tends to suggest the reasons you chose CSS-like goings on were for reasons other than the actual benefits of the tech, meaning we have to begin guessing why it was chosen over improving the existing constraints system of UGUI, or making a more dynamic constraint system with physics… both of which would have forced a focus on SDF for smooth drawing…
but we’d probably still be stuck without scaling of vectors, svgs and shapes.
Why, in the age of massively increasing resolutions and frame rates, did you think a CSS-like coding layout system was more important than the rendering qualities of CSS and the dynamics of a constraints based system?
I will not address the topic of a new system vs. improving UGUI.
Regarding the rendering strategy, as I said in my previous message we have made already some progress towards a real infinite resolution rendering, with 2021.2, in UI Toolkit. This is already available in beta. And we thought it would be critical to go along with Runtime UI support.
Regarding layout (e.g CSS/Flex vs. Anchors/Constraints), I don’t think there is single approach that satisfies everyone. However I believe this is very much orthogonal to the general scaling of UI - both systems have a way to control how the UI is scaled to the screen size, independently of the layout, or to scale elements responsive to the screen size. Both systems would benefit from vector-based assets.
Agreed. I’m saying this!
That’s what makes the decision to spend years on getting to UGUI parity with a CSS-like approach such an odd waste of time… especially when only constraints have any benefits in 3D space, have ever shown any ability to be visually represented and controlled by visual representations fo and of themselves, and deal well with rotation in 3 dimensions and existing in discordant 3D planes as is so very popular in modern game interfaces.
The best options were:
Fix the redrawing/dirtying problems in UGUI and/or train users in ways to avoid the performance problems they create
and
Find a way to use constraints in 3D for a new, DOTS based (and highly performant) modern physical constraints UI positioning system able to scale OUT in all dimensions, because unlike what CSS was designed for, games are often best with diegetic UIs…
etc.
Which brings us back to the drawing of vectors, shapes and SVGs… because they’re all needed to make a good looking UI in a scaling, 3D world, on truly high definition and rapidly refreshing, HDR+ screens.
So whilst you’re hammering away at getting to parity with UGUI and TMP… I dunno… maybe have someone at least investigate what you’re going to do about diegetic UIs in a future with ever increasing UI complexity in ever increasing resolution displays, with ever faster refresh rates in ever wider gamuts.
and ask yourself:
Is your CSS-like approach multithreaded? Has it overcome the performance issues of complex UI’s that were present in UGUI setups?
Can it be placed on planes not flat to the screen? Multiple planes? Performantly?
Or did you just choose to make UIBuilder from the same stuff you used for CSS-like creation of the Editor UI because someone thought it should work for in-game UI’s too?
The rendering is multithreaded by virtue of using some low-level Unity rendering primitives. We have some plans to multi-thread some of the heavier CPU operations in the future, though it is tricky with UI due to its hierarchical nature.
We believe it has, as it takes a completely different architecture to batching.
This Unite talk goes into great detail about it:
https://www.youtube.com/watch?v=zeCdVmfGUN0
This is not supported yet, but I don’t see why it couldn’t be achieved. I am not the rendering expert though.
I understand why the HTML-CSS model might seem at odds with diegetic / world space UI, but we have complete freedom in terms of implementation to make the system excellent for these use cases.
Unifying the UI development stack is an explicit choice. However I recognize there is a lot of work remaining to get there and convince the majority of users that the migration is worth it and that our strategy is viable.
If you have questions about the roadmap, you can also post to this thread. https://discussions.unity.com/t/847813
If you want to discuss improvements to UGUI, you can use the dedicated subforum.
