Official Unity wants your feedback on usability and artist workflows!

Couple of things...

1. Save scene to remember the folder and name of current open scene
2. Colour coded ui elements. I.e. Profile could be coloured to reflect different types of function. Inspector, hierarchy and project windows could be coloured by item type.
3. Multi dimensional array or database in inspector that auto updates in relation to other objects or variables (without custom editor)

 

I had a good laugh too until I tried animating a door...
For characters Mecanim is the way to go, it'd be super extra lovely to have a wrapper that looks like the old ANimation component.

Question: 5.6 animator icon no longer look like a thing that's related to animation but instead it looks like a graph... is this a mistake?

 

There IS an answer to that problem built into Unity, though. It's called the Playables API. It basically lets you handle all animation through code. Ever since I've started using it in 5.6 and 2017.1, I've abandoned Mecamin completely. It amazing! But it's not an artist's tool. Then again.... working with the Playables API made me realize that maybe animation logic should've never been an artist's responsibility in the first place

I think the fundamental problem with visual animation state machines is the fact that you need to explicitly define every possible transition, which can quickly become a huge chore. When you handle animation with code, you don't need pre-defined conditions. You just decide to which state you want to transition with custom logic depending on the state.

I think it would be pretty simple to create a "SimpleAnimation" component that replicates the old Animation component with the Playables API

 

Also I want to share an opinion that may be a bit (very) controversial:
I don't think visual scripting should be an option at all in Unity

For these three reasons:

1. It gives too much power to people who don't necessarily know what they are doing.
   We've tried visual scripting in a 8-12 people project in the past (it was our own in-house visual scripting system. Something to create questlines, dialogues, level scripting and such...). And after a few months we ended up removing it from the project completely and re-writing everything in code. The issue was that artists and designers were doing crazy stuff with this. Either it was incredibly prone to bugging, or super not performant, or both! Designers and artists should just not try to do these things. In the end, we would've lost way less time if we just let the programmers do everything correctly in code from the start.
2. It'll divide the knowledge and the community
   I have messed around in UE4 for a few years, and there's something pretty frustrating about its community; knowledge is divided between the blueprint camp and the C++ camp. And since the introduction of a visual scripting language tends to make 90% of the tutorials and learning resources focused just on visual scripting, the extremely large majority of the how-to's you find on the internet are in VS. And then you end up in situations where you're looking for a solution to a trivial problem that should normally take 3-4 lines of code to fix, and the only thing you find is some guy saying "Oh, that's easy..." and proceeds to give you a screencap of his unfathomably messy spaghetti-like blueprints code that has at least 80 nodes.
3. It'll incite beginners to make a bad decision.
   Code will always be easier, faster to work with, better structured, more performant, more versatile, more scalable, more workable for teams, and more debuggable than visual scripting. Code's only downside is that it's scarier. So a person starting out and given the option to choose between code and visual scripting will almost always unfortunately choose the latter.

Besides... I think I've already mentioned it in this thread, but it's worth saying again: The UE4 forums are filled with people who are sick of blueprints and UE4's weird C++, and just want something like C# or lua instead. Unity already has the ideal scripting solution

 

For the love of god, PLEASE don't start another one of these endless, pointless, Visual Scripting debates. We've had enough of them in the last two threads.

 

It's pertinent to the discussion, though. Either no one talks about visual scripting, or some talk in favor and some talk against.

You can't set an arbitrary rule that only those in favor are allowed to talk, because it would have repercussions on everyone. Even on those who wouldn't use it

 

This has been driving me insane for weeks now. I've been looking at thousands of tutorials for FP character movement and I can't get my model to move for the life of me it just stays in idle not matter how many times I press the keys. The scripts kill my soul and no matter how many times I go back over them the model still doesn't move. Ice done the animator correctly as well. I know this is stupid but I am still kind if a newborn please make a tutorial on fp character movement with the basic keys (wasd space for jumb ect) :c

 

To create an 100% already Asset Store / Asset package Unity Library with visual TOC & then have that extracted and compiled (for WebGL) Library, sort of like it was a massive project and then have the Unity Editor allow you to create projects in/using that Library and create many different projects with sub-projects (actually multiple project targets is better description) that are actually the same projects but different platform targets. Each gets it own set of target project files and scenes and only the needed resources from the master Library (ie this huge WebGL master project) are used to compile that sub-project's targeting platform.

That way I could have this huge generic library of assets already sanity tested for compilation problems via WebGL to draw on to create many projects in that master Library targeting many platforms and for example if I had a 12 projects using the same subset of assets I wouldn't need to create 12 projects and eg import that same subset of assets into all twelve, I would just create a new project, choose the build target, create the scene(s) and Unity would save the new project and the new project files & scenes and build files in the new project.

It wouldn't rebuild the massive WebGL Library but just rebuild the needed assets accounting to the project settings, assets, used and target for the sub-project of the project.

Of course special handling would have to handle platform specific assets that would fail in a WebGL compilation. EG, I have one asset that fails on import because it needs DirectX11 and I have only DirectX 10.2 but Unity Editor & build system already does a bad job of preventing namespace clashes and platform dependency problems in a project so that needs improvement anyway.

Whoa! Would I save soooooooo much time over how the Unity editor now works....

 

Hi guys, one last (may be ) request i am having:

WheelCollider 3D collision detection - instead of using RayCast... (may be given as an additional option to choose).

Current implementation of the wheel collider is good enough except the fact that in many cases the wheel intersects the ground quite a lot. If you have car with bigger wheels this is even more visible let's say in case the car landed after jump and bounce around, or hits some road object and bumps... Thanks !

 

From a programmers perspective I do agree that the Playable API is much more flexible. But I also believe that there's a place for a visual graph as well, for the non programmers. Both for the Animator and any future Visual scripting graph.

The inherent problem with all visual graphs is how to organize them. Simple graphs don't suffer this problem, but as soon as you start wanting to animate a fully playable character / AI, you're gonna need to be very diligent with your graphs structure.

So I think Unity needs to give some options to users in regards to organization in these graphs. Things like:

• Grouping states into a single view, allow renaming groups, expand/collapse. Show all outgoing/incoming transitions to the group node. Once expanded, show transitions going to correct states.
• Grouping parameters in a tree-like structure
• Better visuals on tags - show the tag on the state, tag selector, color coding?
• Contextual views - Only show whats relevant on the graph to your current selection (fade out the rest)
• Graph search - much like project search, fade out items not contained in the results
• Re-sizable states / machines - drag the edges to change size
• Zooming -
• Better visuals on transitions, maybe curves? Maybe detect similar destinations/origins on transitions (visually) and group them into a single line. If I have 20 idle animations all pointing to the exit node, why have 20 lines? Show 20 lines joining closely then 1 line moving to exit.

For me, it's all about reducing the clutter and making it comprehensible. It may look great to me, but to someone else, it's hell spawn. When I look at that Recore graph, I think, when would I ever need to see all this information at once? How could anyone look at 100 white lines and understand all the complex relationships there? It looks like it would take about as much time to decipher that graph than to make it.

A Visual code editor would be welcome, and although I personally would never use it for the "big stuff". I certainly would consider it as a replacement for simple animated things. Hook that sucker up to DOTween and you're good to go.

 

1.Nested prefabs

2. Small change to script forces Unity to reload every script file, it gets cumbersome for big project , lot of time gets wasted.

 

God damn it, my newest post got deleted! Guess there was a rollback because of the hack... I'll try to rewrite my post because it was an important opinion of mine, which I've had bottled up for a long time. sigh...

Anyway, I also agree doing complex behaviours in mecanim isn't approachable without programming skills. But, we have to accept practically all these cases involve people trying to build a complex character controller for either the Player or AI Agents, which is an extremely hard/annoying task to do, and even with coding it can quickly get out of hand if you are not careful.

The real issue here is not the lack of visual scripting, is that the current CharacterController and NavhmeshAgent don't handle character states and its animations, they are useless, unless you have programming skills. Wouldn't it be easier to just create a customizable Character controller like Invector's or Opsive's?

Imagine a character controller in which you can define Character States. Each state with a group of selectable conditions to be triggered (Player input, Grounded state, Ground Angle, is Obstacle Ahead/behind?, obstacles angle, obstacles height, Is obstacle x distance away?, has obstacle X Tag/component?, etc). Then, you could define which Animation state/parameter to play when the state is active, you could set it to play once or loop, and also define if to crossfade from the previous animation or not (a thing which can be done programatically much less messy), and define crossfade time if any. You could easily define if other states should not play while the active state is playing too. And also define if the player position should change during the state (ie: during vaulting, move x distance ahead,etc).

This would allow users, specially designers and artists to create decently complex character controllers without much of a fuss. Programmers could still just make their own if they feel like it (though I'm sure some would most likely use the built-in character controller just to save time).

The lack of a good character controller with animation support is an issue I encountered even after I learned to code (as an Artist/writer I had no other choice but to learn). Let's just admit it, the example Player controller in the Standard assets is subpar. It has very few states and everything is hard coded. People even have to use the same animator setup. Once I got better at programming, and thanks to a lot of tutorials, I just ended up making my own custom character controller with more states (with vaulting and climbing,etc) and rigidbody movement, but honestly, I was left wishing there was an easier way to do all this already built-in (specially because every time you want to add a new state it becomes a huge chore).

If at least the examples in the standard assets had more common states, like swimming, vaulting, climbing, punching, etc. then they'd be more useful. But, even then, I don't think that's what people need. They need a standardized character controller they can configure to be whatever they need it to be. Freedom to choose animations included.

 

Consistent UI behaviour across all of the Editor. It used to be this way, but the new GUI, Mechanim, and Shuriken each have their own interface and working practices. This makes Unity harder to learn.

I have avoided using those systems as much as possible, because I have to relearn them on the rare cases I need to, and things have sometimes changed from the manual, making it even harder. I am not looking forward to using Shuriken, but will have to because the much more useable legacy particle system is being depreciated (there are other reasons for staying with the old system, such as missing features in the new one, but not liking the interface is one of them).

 

Imagine... and build it! You can already create things like that with GameFlow!

Check this link for an example. That is just a basic state machine, but you can extend it with multiple conditions, set animator states (with crossfading), change properties of any component and even invoke methods in your own scripts (that is, no need to go exclusively "visual", code is and always will be good and it's possible to have the best of the two worlds).

So, yes, there exist tools makers like me with a clear purpose: making visual scripting a REAL option for everyone. You'd better not take those "code purists" too seriously; this is a war they are gonna lose (and they know it).

 

@Nevin

Would be an idea to sum the suggestions from this thread into a sticky / or have a list of already made suggestions (like we do for Game Design tools)? I notice a lot of duplicates. Might be easier to give feedback about them later - but surely it would make it easier to know what has been added to the wishlist.

<3

 

Just remembered: Undo is hideously broken for nGUI (4.6 GUI?). Adding a component and then hitting undo does not bring the layout back to where it was.

It's going to be really hard to fix (the way you've implemented driving implies to me that you have to put the entire canvas state on the undo stack for every operation to make this actually work), but the UX for the UI now is that I'm terrified of adding a layout group because it might destroy my layout with no way of getting back to how it was.

So we end up in situations where things doesn't look good, but everyone dreads touching the UI to a point where it never gets worked on.


@Nevin, is this thread Unity admitting that Suggestions doesn't work? It's always been broken (by design, not bugs), and with the different asking for input threads (for the profiler, for this, etc.), you seem to be wanting to bypass it and go directly to the community.

That's great! Having a conversation is much better than a hidden-off, unwieldy piece of the site where people can put ideas to be ignored.

 

Umm, Gameflow looks very nice, and it would be cool to have something like that as part of Unity too, but for a character controller I'd rather have something built-in and with clean UI, maybe even with an editor window to see the state trees (similar to the animator window).

I don't want to be rebuilding the core functionality of the controller every time I start a new character controller, I just want to define states and let the controller do its thing under the hood.

Besides, I'm still poor and live in a country with a different economical situation than the U.S or countries in Europe. I can rarely allow myself to even spend $20 in the asset store. Maybe when things pick up, but right now it's a no go for me. Else, I wouldn't have gone through the trouble of making my own character controller, I would've just bought Invector's or Opsive's or the Motion controller, etc...

And still, third party solutions tend to be messier, built-in will always be better.

 

Are we going to get a big list with the features requested here, what is going to be implemented, what is not, when, etc... ?

give us at least the small stuff.

 

yeah I think it'd be great to see a dev make a post about the "official" notes they've taken from this thread, and what the process will look like for the validation/implementation of these things.

Also I'm sure a lot of these things are already in the works, if the roadmap page is accurate. A status update on the progress of these things would be nice

For example, I remember hearing at some Unite conference that they were waiting for the new SceneManagement/Additive scenes feature to be complete before they could tackle the Nested Prefabs problem. Now that this is done, does that mean work has officially started on Nested Prefabs?

 

Animation chooser where we can see thumbnail of the animation. I made one before as proof-of-concept (turn on captions on the video):

 

Open-source your fbx importer (xxx\Unity\Editor\Data\Tools\ImportFBX.dll), please. Let's see how it works.

 

Having folders to organize instead of GameObjects.
This could be implemented by tagging the gameobject and then showing inside a gameobject the list of tags that its childs contains. Then, clicking on a tag (that may appear as folders) will show inside the gameobjects that use that tag. A folder should only group things without modifying properties of them, and could be an option to render the hierarchy window with "folders" or not

The point is to avoid using logic (gameobjects) to solve a "rendering" problem

Also, is it possible to separate physics layers from rendering layers? it is not logic to have a layermask in the ui with physics collision layers. It is a big problem because you have to divide the limited ammount of layers between physic objects (layermasks for physics are logically useful) and graphics (ui, camera rendering). This two things are separate and still share the same space here when it does not make sense. A gameobject should have multiple dropdows to select its rendering and physic layer independently.

And maybe, multiple layers/tags per gameobject? If you consider as tags "Floor", "Grass" and "Concrete" it makes sense instead of two tags, "Floor Grass" and "Floor Concrete" as "Grass" and "Floor" being different things are easier to manage

(Of course, a lot of this things can be hacked by us, but not all of them)

Thank you!

 

Hello @Nevin

Here is my opinion on what Unity should put in its roadmap.

1 - Node Based Shader Editor
With this, people would be able to make better looking games, and also get used to see how shader works( I'm really bad at writing shaders, so this would be really helpful for me).

2 - Better Navigators
Unity naviation on the scene view isn't bad, but it would make the workflow really faster with some hotkeys( you should check the 3 pictures that demonstrates this asset: http://u3d.as/tzG )

3 - Better Hierarchy
Again, Unity's hierarchy isn't bad, but it would help a lot having something like this asset does directly on Unity: http://u3d.as/bf9

Thank you very much for making this thread and checking our messages. I hope my opinion can be useful.
Cheers

 

That's what I was talking about, although in a round-a-bout way. All assets need to be imported once and sanity checked for compilation and data structure integrity for the art and so the Unity Editor needs a dual mode purpose - one is to access the huge library of assets already imported and the second is to create and manage all the projects using bits and bobs from that library for the relevant platform so that when you change something for a project on that platform only the needed copy of assets is compiled and not the entire library which remains as an unchanged master copy.

 

One more one that I think everyone needs.

The ability to specify which coordinate system is in use on the model importer. Lots of stuff comes in with Z/Y swapped, etc. It'd be great to have a option near the model scale to swap axes around. Even better if you put the program names in the dropdown.

 

Yes,this always makes me crush...

 

Hey Nevin, thanks for your reply!
Right now we use masks to combine different animations. Yet doing so gives unpredictable offsets in the final motion. Getting rid of these offsets is a bunch of work right now, which is why I asked about this feature.

Also, could you guys build something like this?:

I have no idea how hard that is to do, but it looks like it would save tons of work on any production.

 

We're hoping to improve the feedback portal over the next while so it's seen as an active area users can go to give us input on really annoying things, problems we're not solving, or areas we need to improve. Going forward the intent is to have threads like this to cast a wide net and have collaborative discussions with users but also paying attention to the feedback portal to identify the impact, severity, and more focused discussions on specific features/problems.

This thread is an example of the dual nature where we're combing the feedback portal in combination with this thread to really identify where we're lacking in artist workflows.

 

We are actively looking into Nested Prefabs internally though I'll preface this by saying we're still in the early phases of prototyping and exploration. Keep your eyes peeled for a post like this focused on Nested Prefabs to help us gain better insights into the problems, workflows, and structure needed for Nested Prefabs to succeed. It should be coming Soon™*

 

I could be wrong, but it seems to me like both of these things aren't "genericifiable". Which means there can't be an easy to user interface to make any character walk the way you want using those techniques. There's too much custom logic that goes into it. In the end, it seems like it's very specific to your particular situation and you'd have to build these systems for you own needs.

But you can build such systems for your game using the Playables API. For instance, if you wanted to add motion matching to your game, you could create a "3DBlendSpace" playable that is basically like a mecanim blendspace, but inside of a cube instead of a square. And then, for that playable, write the custom logic that chooses the animations in that blendspace depending on the normalized 3D blend value (based on which animation most closely matches what you want to reach).

.... I know it's vague but it would be something like that

This is why I love the Playables API and the UNET LLAPI and the new Navmesh API so much. Proper low-level APIs are the solution to every single problem!

 

I know nothing about programming so you could be right. It does seem like a genericifiable system to me. You tell the system what kind of movements the character will have and maybe the control inputs, load in some animations and let the system generate the rest. Check to see if everything looks alright, if not do some custom animation tweaks.
I'm sure it's more complex, but I do imagine something like that would be possible.

 

Why not make Feedback a Unity Forum? It will be more visible, and almost certainly used more.

 

I think the problem with making any "official feedback place" is that it's gonna get instantly swarmed by people who want a "Generate MMO" button and the elusive "Machine Learning thingy that does everything! " and other such things

 

It's all being discussed but I don't want to derail this thread into Forum vs Feedback. If you have thoughts/opinions on how we can improve Feedback shoot me a PM and I'll be happy to discuss.

 

I though for sure that last sentence was going to end like this:

"If you have thoughts/opinions on how we can improve Feedback, please make a post in the Feedback section and vote on it."

 

I would never do such a thing. Though there is the Bug Reporter....

 

There was a "Wish List" forum, that's not a good idea, it's hard to keep track of duplicated feedback entries, separate entries by category, implementation status, etc... I think improving the feedback (making it more "social") would be better.

 

I'll help you cut a year of dev : hire this guy and integrate his asset https://www.assetstore.unity3d.com/en/#!/content/84495
It's got overrides, it's fast with a minimalist, non intrusive UX and it doesn't break.
Then you can iterate on the nested editing that Nich showed about 200 years ago

 

Navigate in the selection history : Left arrow goes to the previous selection, right arrow goes to the next selection(s) if you've pressed on the left arrow. Like jumping back and forth in your web history. That's what monodevelop has and it's so useful that I'm always reaching out for it when I switch back to unity.

 

Right off the bat, there's something that scares me about this package: It uses UnityEvents for referencing things between prefabs. UnityEvents take about 20x more CPU time than a direct call, but that's not even its biggest crime. They generate GC allocs on every single call. Meaning a game with many references between prefabs would have huge GC collect lag spikes.

And it also seems to use "SendMessage" in some way. Don't even get me started on that atrocity. Though it's not clear if it's the system that uses it, or if it's just a usage example

This is why I really hope Unity is careful about integrating asset store packages. It's always better to make things properly from scratch. I don't want to have to worry about things being poorly optimized because it was initially designed without source code access and without proper internal engine knowledge.

I'm already a bit skeptical about CineMachine and TextMesh Pro. I hope this doesn't become a trend

 

it follows a different color scheme and shape to the rest of the animation related stuff so it's harder to make the visual connection between them and since so much effort has been made to create that visual connection, like say yellow for sound, green for physics, I was wondering if that's a hint at a larger change of direction for unity like "everything is now a graph" maya style or just a mistake.

 

Well, after seeing this post I immediately thought of this:

It's the locomotion system developed by @runevision for the old animation system before mecanim.
And the guy who made it is the one responsible for developing the new input system for unity. He even said that if the comunity showed interest, it could be developed directly into mecanim.

 

I don't have that in 5.6, at least not in 5.6.0f3... I like the look of it.

 

Hah! Thanks for the input and reference. I've added it to the list of existing asset store solutions.

 

Was almost forgetting this, but, what about vector/flow fields for particle systems? that'd help achieve some really nice effects (it could be used in path finding too or other stuff I guess).