Search Unity

Discussion Do you want to move to UI Toolkit for runtime UI?

Discussion in 'General Discussion' started by andyz, Jan 15, 2024.

Thread Status:
Not open for further replies.
  1. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,853
    Nihilism is one helluva drug.
     
  2. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,853
    I am thinking of using the GPU via Shader Graph and SDF functions derived from the spline paths. It would read the spline path for the edge and draw a line using color or not, have internal and external glow gradients, a fill that is either color, gradient or bitmap with movable anchor to mask out the bitmap or gradient unused portion. Really don't see any barriers except time sink. I was watching a video where a guy had one million bitmaps running from a Shader Graph GPU implementation at 60fps. Blitting the graphic is a simple is this pixel inside or outside the spline. If outside and no glow make transparent. If inside and color just color the pixel. If gradient or bitmap then sample the pixel needed.
     
  3. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,065
    If nihilism is 6+ years of broken promises, half-baked MVP tier packages developed at a snail's pace, 1.5 years of layoffs with more on the horizon, billions wasted on nonsense acquisitions, and Unity still being unprofitable, then sure.
     
    Last edited: Jan 22, 2024
  4. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,822
    Jetbrains Rider just added support for UI Toolkit, which definately makes it just a little more tempting to check out...
    :rolleyes:
     
  5. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,566
    EVERY feature can work poorly, negatively affect performance and so on. But if all features are rejected on that basis, there will never be a single improvement to anything.

    The issue you list is solvable. 2d shapes can be relatively easily clipped. in 2d space. So, once again, there's no "arbitrarily large assets", and if the feature ends up too hungry for your specific usecase, you are not forced to use it.

    For the record UGUI implements clipping for child objects. I vaguely recall seeing it during one of the rare code dives.
     
    Last edited: Jan 23, 2024
    ippdev likes this.
  6. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,853
    I am doing fine with it over here. The performance for the VFX graph materials and particles systems is great. URP is pretty powerful. I did not used to like it but it can look pretty raytraced with the right shader and textures. Substances really shine with the Arnold material. I can do alot of things effiiciently that were not possible before without killing framrate. The Articulated Joints work sweet for robot sims and the Rigging package allows me to make cinematic level multi constraint rigs that use DOTS tech so there can be dozens(hundreds?thousands) on stage with no observable fps performance hit. I wager that alot of the core algos in Shader and VFX graph were crafted by the brain trust from their "worthless investment" in WETA. I can produce cinema level VFX in realtime with millions of particles.

    The half baked packages loaded with obtuse interfaces API sucked. I agree. Many couldn't be finished because the frameworks were devised by enterprise coders and not game engine component coders. They painted themselves into the interface corner. The tools I have chosen work just dandy with my bells and whistle extensions. You seem to be battling the "War of Art". If you walk to the easel and your gouache paints don't please you you complain that the paint sux and you need oils. Something just as dynamically creative can be created with either medium. But hey..the gouache sux and I don't think my final work will be worth the effort. The question arises with the creator. Am I killing my muse by toying with technical demands as a form of active procrastintion.
     
  7. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    517
    I think UIToolkit is decent for static editor UIs. There are still heavily-branching UIs where IMGUI can shine.

    Gameplay UIs I'm much less convinced. In addition to the aforementioned missing worldspace UI and lack of shader support, the killer feature UGUI has is debugging and editor integration. After spending some time in Unreal's UMG and seeing UI Toolkit take the same path, I want to emphasize the lack of runtime debug is the biggest downside. Having all of your UI in the scene layout that lives in the same environment as all of your runtime game objects is incredibly valuable. You can visually inspect UI Monobehaviours and rect transforms as the game is running, see which objects are enabled/disabled and instantiated the standard Unity workflows/APIs for GameObject/Prefabs.

    I do agree that UGUI has a lot of problems (confusing layout, weak styling, poor perf). However, with all of the resources they invested in UIToolkit they could have easily reworked these UGUI weaknesses.
     
    Last edited: Jan 23, 2024
    Noisecrime and ippdev like this.
  8. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    You know there is a debugger window for UI Toolkit?

    https://docs.unity3d.com/Manual/UIE-ui-debugger.html

    I've found it pretty useful to debug my runtime UI's, as you'd expect.
     
  9. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    517
    Thanks, I have used it a little to troubleshoot some basic layout stuff. I personally don't find it as helpful/useful as the standard game object inspector driven UGUI. Fundamentally, I'm not sure why users prefer to have their UI be completely separate from the other game object management in their game. The UI elements are a part of your game, why would you want the text/buttons/fields exist in a different space that requires additional UIs/workflows to inspect the behaviors/values and bind? That's not to say that UI Toolkit is all bad. The layout system is easier to work with and the styling system more powerful and web dev friendly. However, making the UI hierarchy hidden with a duplicated but less powerful animation/rendering system divorced from the standard game object workflow seems like a poor tradeoff.
     
    Last edited: Jan 23, 2024
  10. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    So... we went from UI toolkit has no runtime debugging to saying you've used said runtime debugging?

    It having a dedicated debugger is arguably better than being able to see some (but not all) things in the inspector.
     
  11. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,853
    If I can't see it in the Inspector then it is considered to be a third leg IMHO. My debugging consists of writing values to the console when the code is not working as I thought and watching the Inspector values as mechanics unfold. Unit testing is done when I hit Play to see if the code addition worked. It is a frame dependent, not state dependent application. You are mostly observing gradients of value along time. The devs who are writing UIToolkit threw the baby out with the bathwater by not adhering to components, the Inspector and GameObjects paradigm. You ain't ever getting me to write CSS crap. The day I was able to drop web dev was a joyful day in my professional career. And Javascript..AAAARRGGHH!
     
    bluescrn likes this.
  12. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,977
    From talking to developers in another thread, it looks like UITK wont get worldspace until 2025 at the earliest.... so do with that what you will but its really offputting when working on XR to be locked out by what I would describe as classic unity decisions to replace an existing system with something that is not a real replacement. This really should have been a basic necessity of V1, I am not sure how they can claim its runtime ready when it doesnt really support even the basics of the old system

    It was said that "it wont be part of Unity 6" :confused:

    "The main focus for the past 2 years has been UI Toolkit for Editor UI, which World Space doesn't support directly. We are now moving our feature development focus towards Runtime Game UI, so yeah, a release 2025 is likely a realistic time-frame for it."
     
  13. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,065
    It was originally intended only for the editor. The runtime was later tacked on because of user demand. And here we are years later with UGUI deprioritized while UI Toolkit hasn't really had runtime focus until now. Also, Unity haven't hit a single development timeline they've set. So 2025 seems optimistic, maybe it'll be in preview with another year or two on top to get it in LTS.
     
    MadeFromPolygons likes this.
  14. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,139
    I'm pretty sure this isn't true at all. It was always planned for use in game UI and this is confirmed by every search I've done.
     
  15. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,065
    I'm fairly sure I saw a Unity person saying that somewhere here in the forums, but search is kinda crap, so it's hard to find past statements.
     
    angrypenguin likes this.
  16. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    275
    Then explain the UI builder and the fact it doesn't support linear rendering.
     
  17. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,145
    It's simply incomplete. Before it was merged out of its package into the main engine it was marked as experimental and I've seen nothing to suggest that it's stopped being considered that way.
     
  18. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,139
    You mean Unity Technologies has put out something that is dramatically incomplete? But that never happens!
     
  19. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,518
    We have no plans to migrate to UITK for runtime, even on the long term roadmap. I've also never had a client suggest it. Regular UI (UGUI) is simply more useful and will continue to be for a long time. Web guys seem to be excited about it for obvious reasons, but I only know of a handful of moderately successful implementations I happened across publicly and none personally.

    That being said, I do like it for editor stuff and I expect that once they have more dogfooding, time to iterate, add more docs/examples, etc... that it will probably become pretty useful for runtime! I'd be pretty happy if there were some official tutorials and/or practical examples of it in practice. Problem is the same as it was with the editor code though - they were very impractical and generally a struggle to understand.
     
  20. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    467
    Lovely. Again: everything can be "production ready" or "not production ready".
    It depends on the requirement of your fricking production.

    UITK is fine if you don't need flashy, epilepsy-inducing menu animations what nowadays so popular on crappy mobile games. It has enough animation to satisfy basic desktop-menu and UI-needs in the majority of the times. So if you make mobile games, you probably choose UGUI, if you make desktop games, you have a choice.
    Same with XR, if you make VR/AR/XR game, you use UGUI at the moment, because we don't have real world space support in UITK just yet, but for a desktop game, you can get away with world-space to screen space coordinate conversion and planning properly.
    Do you need custom shaders for some reason? Also fine, what's stopping you to use UGUI and TMPro?

    The point? Use whatever does the job properly for you. If you don't like UITK or it doesn't fulfill your requirement, fine, use UGUI. If it does, use UITK. If you want the best of both worlds? Use both of them in tandem for things they work the best.

    It's not rocket science.
     
    ippdev likes this.
  21. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,145
    Funny because I've been thinking UITK for mobile. UGUI is great right up until you have to deal with more than a couple aspect ratios. :p
     
  22. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,139
    I wouldn't use UITK on mobile given how much it still suffers from loads of performance issues even on desktop. This whole "it's the right tool for some jobs" (as well as the idea that only flashy games need custom material support???) attitude is really ignoring a lot of the fundamental shortcomings of what has been in development for over four years now.
     
    Ryiah likes this.
  23. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    467
    I think your reading comprehension had a momentary slip-up. Because my post did not state what you are attributing to it. So what the hell?
    I don't care how long they are developing what anymore. (Not just Unity, anyone) The only question I'm willing to entertain if the stuff we're talking about is useful to me or not. Nothing else matters.
    So, again, I understand if it doesn't fulfill your requirements, but your requirements aren't universal.
     
  24. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,139
     
  25. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    467
    That's yepp, but you were saying this:
    And besides, being so popular on mobiles aren't exclusive. They can be used on desktop games too. So that's more like double-slip up.
     
  26. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,139
    The reason you can't do things beyond basic transitions is because of the situation with material support.
     
  27. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,145
    Which considering the company in question is much more likely to be 2026 or 2027 since world space support is likely dependent on other features like shader support and we saw how long it took them to add support for UGUI to Shader Graph.
     
  28. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    467
    I guess we have differing understanding about potential animation-support and what does it mean for UITK.
     
  29. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,735
    Why would you choose UGUI? Maybe it is easier to make flashy crap, but also performance completely falls apart if you animate a lot of stuff with it (unless you break your GUI into multiple canvases, at which point you've almost eliminated what little ease of use UGUI has given you).

    UITK not supporting world space is a pretty big limitation. And also, if it's not convenient to do complicated and flashy stuff... why do I need a toolkit? A button is a polygon, a box collider and a textmeshpro, a menu is a series of text, relative and absolute positioning via "normal" Unity code is not harder than using UIToolkit's API for positioning... Why do we need a toolkit again?
     
  30. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    Yes thank you, we get it, you like components and only components. You don't need to tell us in literally every post.

    Some of like components, as well as other patterns.
     
  31. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,566
    I'd expect the to move that to target to 2028. Then, around 2025 they'd begin to argue that worldspace is not necessary and does not match their vision. At the end of the year 2026 they'll roll out 5 more unfinished UI frameworks that are incompatible with each other and deprecate UIToolkit. None of the toolkits would have worldspace support. Around 2028 they'd start recommending UGUI for production again.

    That would be more in line with typical unity approach.
     
    AcidArrow and Ryiah like this.
  32. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,065
    They do tend to make long-term plans, none of which pan out for some reason. They stopped developing the Graph Tools Foundations package because it'll become an engine module. Now a few years later, the engine module is cancelled in favor of some new package named Graph Tools Authoring Framework per recent beta 3 change log. Same with Visual Scripting. Any multi-year plans should not be taken into an account. Use what is available now, otherwise you'll wait indefinitely.
     
    NotaNaN, AcidArrow, Ferazel and 3 others like this.
  33. ElevenArt

    ElevenArt

    Joined:
    Dec 12, 2012
    Posts:
    17
    Hi, I recently watched this video and it looks like the new system of data binding and UI builder inspector extensibility could be useful. In versions 2023.2 it is already there and it is much simpler than before.



    I agree that it takes a long time for the developers at Unity. World-space is necessary. And of course also 9-slice images, which would work properly, I don't understand why such a simple thing takes so long. It would also be good if there were more pseudo-classes from css such as :first-child, :last-child, :nth-child(), other styles such as grid system, gap property and even flex does not have full functionality, box-shadow , z-index, gradients. There is enough that they should add there. CSS possibilities in web is much bigger than are in UI Toolkit.

    https://forum.unity.com/threads/background-clip-property.1439407/
    https://forum.unity.com/threads/please-implement-grid-layout-and-the-gap-property.1405477/
    https://forum.unity.com/threads/add-new-pseudo-classes-after-nth-child-etc.1440376/

    Linking with the animation system should be a priority, but until that is there, this plugin could be useful. It's free on github and through it is possible to animate UI toolkit elements via the timeline.

    https://github.com/mihakrajnc/UITTimeline

    I haven't had a chance to try it all yet, but I like it, I guess I'll get around to it :)
     
    Last edited: Jan 24, 2024
    Voronoi and DragonCoder like this.
  34. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,853
    I am telling Unity tech. I use these posts as a bullhorn. I am 100% correct on their package completion bottleneck. I have had to fix those other patterns in many a freelance job I was hired to complete or back them out of a painted into code corner.. 90% of the time it is simply over-engineered extra layer to talk thru cruft. I can tell you why I dislike them and where they interfere with workflow. The boosters like them because..muh compsci patterns.
     
    neginfinity likes this.
  35. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    Components on GameObjects are literally what 'unified' Unity.

    Every move away from them turns what was an incredibly beginner-friendly engine into something else entirely.

    (I thought moving away from GameObjects/Components was perhaps a necessary evil to win some performance gains, but I see UI Toolkit performance being listed as a significant complaint in this thread?)
     
    ippdev likes this.
  36. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,065
    Beginner friendliness can't financially sustain Unity at this scale, which is why all new workflows are geared towards studios with sometimes hostile learning curve since studios can dedicate a person or a team on one single thing no matter how complex it is to get started with.
     
    spiney199 likes this.
  37. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    Yes you have anecdotes of over-engineering. Doesn't inherently mean anything that's not component-based is bad.

    There are plenty of games that used components for everything as a detriment to the game. Subnautica (despite being quite successful) has always had performance issues because everything was done with components. It's also the source of numerous bugs.

    On the other hand, games like Dyson Sphere Project, which has a minority of scripts that inherit directly or indirectly from monobehaviour (about less than 40%) has amazing performance. And you 100% cannot make a game like DSP by relying entirely on components.

    Components are just tool for use in certain situations. Need something to happen in a scene on a game object? Use a component. But they can't be used for everything.
     
  38. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,566
    Such statements require proof. Because as far as I could tell performance issues had nothing to do with components, and everything to do with it poorly optimizing rendering. For example, underwater sea base components have ton of polys, reflection enabled and no occlusion culling in any form. More shiner surfaces - lower fps.

    Of course you can. The point is not to be an idiot. Meaning you won't be using component per object, and at some points components will represent systems.

    Also ippdev's criticism is sound. Unity does have a problem with "corporate code", prime example of which are EventSystem and actually UGUI itself. There's ton of bloat because someone really loved generics and interfaces too much. Stuff like ExecuteEvents.Execute is fun. Then t here are examples in the docs like the one here:
    https://docs.unity3d.com/Manual/editor-CustomEditors.html where you look for proprerties using strings.

    Everything needs fewer lines, simpler apis, and so on. THe reason why unity became popular is because it was accessible to large audience. Meaning almost anyone could make a game. "Corporate code" is inaccessible, and needs skilled programmer. But if a user needs a skilled programmer, why would he/she pick unity?
     
    ippdev, Ryiah and Gekigengar like this.
  39. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    One of the issues with the game is all items in the game are game objects. No item has a pure data representation. A storage locker container is a bunch of hidden game objects as children to represent their contents, as opposed to just plain data. So the game world has tons of these game objects (and by extension, components) that it's constantly streaming in and out as you zip through the game world, causing tons of stuttering in the process, even on top-end hardware.

    It would've been less of an issue, or a non-issue, had they done the sensible thing to separate item data from game objects/components.

    Note I said "entirely on components". At some point in a data-oriented game like DSP, you have to start encapsulating your data. That means plain C# objects, container objects, scriptable objects, etc etc. I don't really see how you could do a game like DSP with only components.

    And DSP operates at some absurd scales. Bigger than Factorio even on a normal, non-modded run. And yet, as they have the simulation running in pure C#, the memory footprint of the game is tiny and it runs smoothly even on dated hardware.

    Besides I'm not really commenting on their opposition to 'corporate programming'. It's more their stance that anything that isn't a monobehaviour is bad. Which is absurd.

    Also this is entirely off-topic admittedly.
     
    Last edited: Jan 25, 2024
  40. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,566
    Again, those things require proof. Where is this information from? Are you SURE it is a problem and causes performance problems?

    Because I played subnautica and the only issues with performance I had happened when I was building bases. And your claim for me rings false.

    "How you could" is explained by "not being an idiot" part. Meaning not doing stupid things. The component design is very, very, very efficient, and easily approachable, that's why people use it. That does not mean you need to make every grain of sand a separate gameobject. That's not what it is about.

    In the same fashion you should not apply "everything is a nail" logic to any other method, including "data separation".

    No, DSP is significantly smaller than factorio. Now, granted, I played it back in 2022, but I finished the sphere. DSP has smaller number of objects, smaller number of animated objects, and so on. The number of planets is kept low on purpose, and each one of them is a tiny construction grid compared to madness you can do in factorio.

     
    Gekigengar likes this.
  41. Gekigengar

    Gekigengar

    Joined:
    Jan 20, 2013
    Posts:
    738
    I was using pure DOTS for a project, and bumped into a lot of limitations. The amount of missing features I have to write from the ground up is impossible to do as a solo dev.

    But I've learned a lot from it, I found that processing game object components as a data container into a system is very very efficient. Especially when the system can utilize Unity's Job System to process whatever the component needs to do. Currently this is the only thing keeping me with Unity, Job System is very versatile, powerful, and easy to write safely. This also helps me write clean, better, and reusable code.

    Component is not inefficient, they simplify and accelerate game development if you design them correctly.
     
    Last edited: Jan 25, 2024
  42. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    Proof is that I spent some time modding Subnautica after getting into game-dev and getting confident in my coding skills. I've mentioned this on the forums before.

    First thing I investigated by delving the game's code was the inventory system, an endeavour that left me sorely disappointed. I attempted to rewrite it to improve it for other modders, so new items could be implemented a whole easier, but ended up giving up due to what an overall dumpster fire the game's code base is.

    The Subnautica modding discord even has a rule against requesting mods for new base structures because the code base for that is an incomprehensible mess. Most of which is in the 10K+ line script, Base.cs.

    A lot of the stuttering problems were improved in the Living Large Update, where they started using Addressables to asynchronously instantiate everything, though causing a lot more pop-in if you scoot around quickly in a Seamoth. The issues still exist when playing the Legacy branch.

    And if you think I'm making that all up... not sure what to tell you.

    I'm not disagreeing with you here? Components are great! I love them. We all do. I use them tons. I use them alongside UI Toolkit, ironically enough. My whole rebuff against ippdev was he seems to be against anything that is not a component. A strength in a developer lies in using a variety of tools in all manner of ways to accomplish the task at hand.

    I think solar systems were made larger at some point, but I will concede, in retrospect, DSP feels bigger due to the interplanetary nature of the game. Even then, there are mods to make systems balloon to huge sizes, and yet the game still runs incredibly smoothly.

    Anyway, enough offtopic-ness.
     
    neginfinity likes this.
  43. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,566
    Fair enough.

    In my experience, this is not the case. Which is why I interrupted. He seems to be following KISS, like I do, and is against, "corporate bullshit".

    An example of corporate bullshit, in my opinion is ExecuteEvents.

    ExecuteEvents.Execute<IInventoryMessage>(target, null, (x,y)=>x.NewItemInInventory());

    Related: https://stackoverflow.com/questions/54999697/how-is-unitys-executeevents-execute-supposed-to-be-used
    Or:
    public static bool Execute<T>(GameObject target, BaseEventData data, EventFunction<T> functor) where T : IEventSystemHandler;


    Basically, this is overengineering. This is not designed to be useful or convenient. This is someone's attempt to create supreme typing exercise. In my opinion, this is bad code, and there's a ton of bad code like that in unity codebase. Complete disregard of experience of using the API while stubbornly folloiwng some paradigm.
     
    spiney199 likes this.
  44. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,849
    Iunno, only a few days ago they berated a newbie for using a plain C# object in their script.

    In any case, I don't like over-engineered code either. But I usually do want my code flexible enough that I can keep extending things, or to keep things performant as the project grows.

    I don't disagree with your points. My point is that components are just one tool among many we have access to in Unity.
     
  45. andyz

    andyz

    Joined:
    Jan 5, 2010
    Posts:
    2,269
    You can talk about UGUI vs UI Toolkit, you can not de-rail the thread into systems architecture discussions - make a new one please!
     
  46. Voronoi

    Voronoi

    Joined:
    Jul 2, 2012
    Posts:
    587
    I like all the changes mentioned in this video. Once world-space is implemented, I might dive in again. TBH, this version of UI is how it should have been implemented as the replacement to IMGUI and I don't think anyone would be complaining. It would just be 'how it's done' and you need to learn it.

    I always felt like uGUI was a sort of a tacked on solution based on NGUI. They bought it, tinkered with it and did the best they could. But it still had NGUI's ridiculous nested prefabs which just aren't fun to work with on a complex interface. My main dive into UI Toolkit was a step sequencer that was quite layered and complex, I don't think it would have been possible to make it at all with uGUI, or it would have been painful to try to do.

    I agree with the comments that components are what makes Unity easy to pick up. It's great for prototyping and testing out ideas. Where it starts to fail is in complex projects, as mentioned in the video, and with teams of people working on a thing. I also greatly dislike corporate code and generally feel it slows down development and makes things overly complex and hard to grasp. However, UI itself is complex and I think in that case the corporate code starts to make more sense.
     
  47. TreyK-47

    TreyK-47

    Unity Technologies

    Joined:
    Oct 22, 2019
    Posts:
    1,820
    Locking this thread as it has strayed from the thread topic. Please create a new thread if you'd like to continue the new conversation.
     
Thread Status:
Not open for further replies.