Search Unity

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

Discussion in 'UIElements' started by Thaina, Aug 6, 2019.

  1. Thaina


    Jul 13, 2012
    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
    , 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
    (custom property that will trigger the animation boolean value)

    What do you think?
    uDamian likes this.
  2. Thaina


    Jul 13, 2012
  3. Ramobo


    Dec 26, 2018
    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.
  4. Thaina


    Jul 13, 2012
    @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
    Ramobo likes this.
  5. uDamian


    Unity Technologies

    Dec 11, 2017
    This is actually not the case. :) UIElements uses entirely internal objects. For runtime, the entire UI can be under a single child-less GameObject. It's not just an edit-time representation. You are always working on the fully optimized data structure.

    UI and GameObjects don't have the same runtime requirements. The way transforms are updated, for example, is very different between the two. You can of course use the same data structures to represent both but you will always have a sub-optimal solution for one them. This is the case with uGUI, and implementing UI on top of GameObjects while still trying to have a UI layouting engine on top.

    We chose to implement a different data structure for just UI so we can significantly improve usability and performance.

    As to your point on using UXML for 3D objects as well. It's definitely an interesting thought and there might be some limited authoring of 3D content via UXML (for our integration with 3D objects in the UI). However, fully replacing GameObject with UXML would lead us to the opposite problem - UI being optimized but GameObject not being optimized.

    There's always the balance between consistency and specialization (optimization). We tried the consistency route for UI (using GameObjects) for a long time. It did the job for a lot of use cases very well. But we hit more and more barriers over the years, especially around performance. We now believe the specialization route will allow us to push UI much further.
    mandisaw, TextusGames and Thaina like this.
  6. Thaina


    Jul 13, 2012
    @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):
    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>
    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