Feature Request Should it be possible to use UIElements for everything?

What I meant is UXML and USS should be possible to declare everything in game, 2D and 3D, not just UI

Actually, we could see every visual, audio, bounding or any object that could interact with user as the "UI of the game". The 3D building on the ground that user could touch to invoke popup. A ball that player could drag around. Weapon that user could pick if the character's hand can reach so it would be highlighted. Everything could be considered as UI. Especially in a non realtime game that almost all objects is bound to game state, not physics

So it should be possible to serialized every kind of GameObject in addition to

VisualElement

, into UXML and USS property. And so we could bind a game state that need to sync with UI to visual object in game too. Such as, when we select a character, we want to have some effect on target character along with character UI showing character's information. We could be doing this with UXML and USS, selected character could be defined with USS selector

Character:active > selectedEffect

and we might set the

color

display:none

or

--animator-set-shown:true

(custom property that will trigger the animation boolean value)

What do you think?

 

digging

 

What I wondered is why they chose a completely different format instead of just authoring with GameObjects and converting to an optimized format for runtime. They seem to have no problem throwing the pure entity editor out the window and pushing their conversion workflow. Or, you know, just improving uGUI. I do understand a different format for the editor, though. I think it's quite hard to like writing UI in code.
And since they did choose a different format, I wonder why custom XML and CSS instead of just XAML. In fact, I was just about to open a thread on this.

 

@Ramobo One thing I know is, GameObjects and legacy scene serialization format is the optimized yaml

Which means, it not really easy for written and edited by hand

UIElements on the other hand, using uxml and uss, trying to make a format that could be both editable in editor, can written by hand, and could be loaded from raw string at runtime. It also harness cascading style system which is more compatible with xml and less compatible with yaml. The current UGUI is not possible to did that

UXML actually still deserialized into GameObject system (also there was a plan to changed into ECS but not now). That was the reason why it is not XAML. It current functionality actually mapped with current UGUI which is very difference from XAML

I kind of understand why this solution is half way on everything. I think it try to be XAML but imitating xaml means writing too many new codes. With this UIElements they could clone many old codes under xml format they just want

But that's not the point of this issue. I just think they should not limit this system to support only UI. It should have more capability. It should be able to define 2D / 3D object. Maybe even sound and physics material, if the parser just allowed

 

@uDamian Thank you very much for your clearer information

> However, fully replacing GameObject with UXML would lead us to the opposite problem - UI being optimized but GameObject not being optimized.

What I expect is, I just want a dynamic scene serialization that could be loaded and edited by hand with text format on the fly. And uxml with uss has that potential. Aside from serializing it could also define property of 3D objects in batch with uss selector. Such as, set an attribute of object to playerID, then define USS to paint a tint color of each object oned by each player

My point is, it don't really need to be the same file with same capability. We could have written uxml3D or even uxml2D separated from normal uxml for UI. Or we could have separate root node like this

Code (CSharp):

1.  
2. <uxml>
3.     <canvas>
4. // current uxml optimized for UI
5.     </canvas>
6.     <scene3D>
7. // new xml optimized for 3D objects
8.     </scene3D>
9. </uxml>
10.  

And it could share the same uss style of some property, such as color, but not layout

Also, it don't need to be GameObject at all. we could just have this new uxml3D use an ECS system from the get go. And optimize it eventually. I just wish that there is official dynamic scene serialization in unity

 

@uDamian Hello, are there any progress relate to this?

For instance, can we currently use USS on 3D object and material ?