A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'General Discussion' started by Nevin, Apr 25, 2017.
I have made my 18 points here.
Great contributions to a thread about feedback on usability and artist workflows
No, it is not always better. Go read Things you should never do by Joel Spolsky, maybe you change your mind and stop making such bold statements.
Speaking of which, please don't forget that behind CineMachine and TextMesh Pro there are great developers who have invested an incredible amount of hard work to create solutions for problems Unity never managed to solve. That said, there are obviously good reasons for Unity to integrate those products. It is an intelligent move from Unity and I really hope this becomes a trend because it would be GREAT for most Unity users, specially artists and designers.
An off the wall suggestion: A tracker window.
Sometimes you want to follow a few vars on various game objects, or maybe a certain area in the scene view. Some of it can be done in code, but it might be easier with this method if it can be made to work.
The tracker view can watch multiple elements, even if they are not currently visible, or even if the window they were in is hidden.
Click-drag to select a rectangle in any window. This rectangle is then replicated in the tracker window until removed. The rectangle remembers what was being viewed at the time. Multiple such rectangles can be selected for viewing at the same time.
Perhaps this window should have an option to remain visible even if the Game view maximises (docked alongside each other if selected).
An example: Select object A, click-drag a viewing rectangle in the Inspector to show a var that should trigger something spawning. The viewing rectangle now appears on the tracker window. That view continues to show that var, even if the Inspector looks at something different. Now drag a viewing rectangle across the spawning area in the Scene window. That view continues to show that area, even if the scene view is changed. Press play and see what is happening, and why the supposedly spawned item is not showing.
Cool, now I spoke too fast on saying it's "fast"... I ran some benchmark after post by @PhilSA... so emphasis on the word "integration" ;-) I'm sure in native code the performances would be close to what we currently have.
The workflow though is what I'd expect from Unity, it's good (although apply should apply changes at the gameobject level, not push apply to all sub prefabs I think you'd figure that out pretty quickly).
Spline tool: Create a "Spline" GameObject in the scene, which is a GameObject with a "Spline" component on it. Users can then add points and edit the spline in scene view. Useful for making any kind of Camera/AI/VFX paths. Would come with an API with methods such as:
Better "Curve" object: Rename "AnimationCurve" to just "Curve" (this is very important stuff), and make it saveable to assets. Saving to assets is useful because it applies the change everywhere the curve is used. This is not currently possible (unless you make a ScriptableObject that contains only an AnimationCurve, but it's kind of an unsatisfactory solution)
DataTable asset: A scriptableObject-esque asset type that lets you define columns (each with their own specific type) and add lines to it. Great for game designers, localization, and plenty of other stuff. Currently, the existing workflows for google sheets or csv integration leave much to be desired. It's better to have something in-engine where you can directly drop assets without having to get them via some ID or string
"Focus Modes" (?): Instead of relying on the inspector and the little preview window to fill every role, make dedicated windows for all editable asset types.
Clicking a texture opens the Texture window, with a nice big preview of the texture and all the texture import options
(...) material opens the Material window, with a nice big preview of the material, the tweakable shader parameters, and the shader node graph if applicable (the material node editor is probably the most important addition you could make at this point, but it must still be possible to write code shaders when needed. The graph would just display "no graph available" in that case)
(...) fbx, AnimationClips, and Prefabs open their respective windows, as I described earlier in the thread
same for VideoClips, AudioClips, etc, etc.....
Not sure where you got this information but that is definitely not the case! The plugin runs as an Asset Postprocessor and all connections are stored as a direct reference to the object or asset GUID (Stored as GUID initially and immediately cached as direct object reference once accessed).
Not using SendMessage in any way, I am guessing you got this from the screenshot on the store page. It is simply an example to show that a complex custom serialized class is fully supported. UnityEvents, SendMessage, etc. is often used in UI and therefore seemed like a good example.
That's good to know. I made those assumptions based on the screenshots. Though now I'm curious about what @laurentlavigne benchmarked (maybe he benchmarked UnityEvents and not the package itself?)
Spline tool would also help create curve driven particles!
I tried implementing a spline class following the catlike coding, it was all fun and games until I tried to get the length of the spline and couldn't...
A native spline class would be extremely welcome!
edit: came here to post another feedback and forgot:
I was thinking about a world origin gizmo, we can do that extending the editor, I know, but...
"Native is always better" Barney Stinson
Feedback from me -
Make grid snapping and angle snapping great again. Currently grid snapping in unity is iffy at best. Grid Snapping is non existent.
This drives me insane every time I use it. Unreal Engine does this very well I would advise you to look at that for further inspiration as well as the trenchbroom level editor and old school level editors from the Quake era. These did their jobs really well which were making levels.
Improve angle snapping as well.
Give us "presets" when it comes to the Grid snapping and angle snapping. As well as the ability to set our own presets for angle and grid snap.
I would also advise getting some form of toolset such as SabreCSG or RealTimeCSG into Unity. This will greatly reduce the amount of time to make prototype levels and the like. It drives me insane that Unity does not have this yet.
When it comes to adjusting presets for angle snap and grid snapping. Give us artists the ability to adjust the snapping via a menu in the editor that is not burried in a nest of other menus.
Anyway - My 2 cents on what could be improved.
If you need an asset to get an idea of what I am requesting too look at progrids 2.
Thanks for the feedback!
Are there other snap settings we should be looking at integrating or do you feel that grid and angle are the most problematic from a workflow perspective? Any problems or input about the grid itself?
Are there any other workflows related to transforms, snapping, placement that are really problematic for you in Unity?
Are there any plans to have editor-only components/objects? This can be useful for creating custom gizmos and notes in the scene for artists and designers without having the overhead of storing and loading all those objects and serialized data in a build.
We've had a few discussions about this internally but nothing specific at the feature level. What sort of functionality would you need here? Would you want us to define it as editor only concepts or something you have control over?
@Nevin: Like laurentlavigne said, it's essentially a selection history, not undo/redo. It doesn't modify any component properties. It only changes what is selected in the Unity Editor.
Oh, and if this is ever implemented, I'd like it if the back and forward buttons in the mouse (4th and 5th mouse buttons) to work for this.
I just saw there is an 'EditorOnly' tag for game objects, which is already great! (didn't notice it before)
However something for components would be useful, for example an EditorOnly attribute. Being able to apply an EditorOnly attribute to components you don't want in the build in combination with the EditorOnly tag that already exists for game objects should give enough control to make anything you want.
Interesting suggestion @moonjump ! Would it be possible for you to make a quick mockup showing how it would look in the editor?
I wonder if this can be solved by encasing the entire class with "#if Unity_Editor". Have you ran benchmarks of empty components?
It's not very hard to make a class be editor only (PostProcessScene + FindObjectsOfType), but that's often not fine-grained enough. I agree - having this on a per-component level would be nice!
- ability to do make stuff editor only on a per-object and per-component level (maybe hide it behind the cog?).
- don't do it through the tag system!
- clearly mark in the editor which GO's and Components are marked as Editor Only, probably with a background color in the inspector.
I have seen this causing runtime errors when Unity tries to deserialize data and suddenly finds that the serialized data doesn't fit into the size of the declared fields.
You can do this with HideFlags. Just tested this code and it works:
public class TestHideInBuildScript : MonoBehaviour
public bool HideGameObject = false;
private void Reset()
private void OnValidate()
private void HandleHiding()
this.gameObject.hideFlags = HideFlags.DontSaveInBuild;
this.hideFlags = HideFlags.DontSaveInBuild;
private void Update ()
transform.localScale = Vector3.one * Mathf.Sin(Time.time);
Here we use Reset() and OnValidate() to get editor-only callbacks without going through the trouble of making a CustomEditor or doing something with [ExecuteInEditMode] and an Update loop to check if our bool has changed. When "HideGameObject" is false, only the component is excluded in builds. When it's true, the whole gameOject doesn't appear in builds.
Maybe all Unity could add is a way to select HideFlags in the inspector.... although it may result in tons of people changing this without knowing what it does and then wondering why their things don't work. The various HideFlags options aren't super clear at first. And things like this probably won't mean much to non-programmers:
Interesting approach but unfortunately it doesn't seem to work with assets. If you save an object with the DontSaveInBuild flag as a prefab you will get the following error when building:
An asset is marked with HideFlags.DontSave but is included in the build:
(You are probably referencing internal Unity data in your build.)
True, it would need to be reworded/renamed. But some people might never really need a lot of the hideflag options.
Anyway, some of the posts I've seen in this topic, from several different people, reminded me of something.
I used to work for call centers. Did so for a few years. And one of the first lessons you learn about dealing with customers/users is:
Never expect the user to know what you know.
To elaborate, let me talk about this post which appeared in the forums of a well known asset store plugin: basically, a user complained that certain action in the plugin (an action to produce random numbers from a min and max ints) wasn't including the last number. The author then answered that that's how the function worked in unity and that he didn't change it because he didn't want people to get confused about it. But, really, from the user's point of view (which is, even now, largely none coders) that didn't make any sense at all. It made sense to him, because he already knew this from his own long programming experience. But a regular person just starting out on unity and his plugin wouldn't really have had a clue about this. And this is specially true about artists and game designers. Plugins or no plugins.
In short, I think too many experienced programmers fall into this error. They tend to expect everyone to know what they know. When most often than not, it's not really the case at all... I hope unity doesn't fall into that mistake too.
PS: Just to be clear, I didn't mention this because of the post I was replying to, lol, I really just thought about this while I was answering.
The new splash screen automatically resizes the selected graphics to be as large as possible. If you try to make them smaller by adding transparent pixels around it this is ignored (I suspect that the automatic sprite trimming ignores it). So you have to add colored pixels to prevent this (which is kind of weird as they might show up unintentionally when changing the background of the splash screen). Also this behaviour isn't documented, which adds to the confusion. I would appreciate a little less automation in favor of flexibility.
Suggestion: highlight hot zone when the mouse cursor is above it. (hot zone is any area that triggers an interaction when it's clicked on, like a field or a button or a panel, interactive icon, transform gizmo)
I see... I managed to get the error too when placing an editor-only object in my Resources folder.
I found 2 solutions for this:
Keep using the HideFlags method and just place those editor-only prefabs under a "Editor" folder... which kinda makes sense when you think about it. (it can be a Resources folder under a Editor folder)
Use the "EditorOnly" tag for hiding GameObjects, and the HideFlags for hiding components. Something like this:
private void HandleHiding()
this.gameObject.tag = "EditorOnly";
this.hideFlags = HideFlags.None;
this.gameObject.tag = "Untagged";
this.hideFlags = HideFlags.DontSaveInBuild;
And maybe not handle this through OnValidate(), because it gives annoying warnings (which probably means something wouldn't work at some point)
Basically it seems to be possible to achieve this right now, but I think it'd be better if Unity handled all this properly through the DontSaveInBuild HideFlag or something of the sort
I just thought of something, what if we could have different layer visualization for each scene view tab, this would solve the problem with UIs being on top of everything else in the 3D world, we would just need to add another scene view tab and set their layers to be only UI and set it to 2D, and the other one we would just need to remove the UI layer, and done, also, make sure to put on the tab title "Scene (2D)" when the scene view is in 2D mode.... The layers dropdown could sit in the scene view itself like this:
hi Nevin ,ı think use totally same interface with Cinema 4D, overmore may be uniting Cinema 4D and Unity 3D,overmore you can add a script editor so be integrated system and please add fullscreen and make button some bigger
sorry for bad english
I think that there should be a built in geometry editor and also there should be a built in model editor
There should also be a built in day and night system like a light that keeps on rotating it can be called Sun Light (pun intended)
You are right but then unity will gain best game engine title
Also add more shader and camera effects like rain and snow falling on the camera
Oh, one more.
Please, allow us to move scripts to/from a DLL, or rename them, without all the associations breaking - right now Unity searches by GUID alone, if it could search by GUID, and if failing to find, search by class/namespace name, that would be a huge life saver on so many occasions. (or even a [PreviouslyKnownAs(...)] attribute!)
Unity must already do something like that for DLLs already, so it hopefully isn't impossible to add?
I'd like a better project view.
Right now, you can only see 1 level of nested GameObjects and they can't even be re-ordered. It doesn't make it easy for designers to edit a prefab without first dragging it into the scene, wasting time and potentially messing up stuff if the Prefab has [ExecuteInEditMode] or OnValidate.
I'd like to see the Project View as a node tree similar to the image on the left:
And you'd be able to keep drilling into prefabs until they have no more children.
That's my first wish.
Quite irritating things when trying to make modular environments or in general are (using 5.6.0f3);
1- Reflection probe boxes do not rotate, and should.
2- Light shadows near plane can not go to 0.0f
3- Animator window doesnt have a zoom feature.
4- Ability to chose a certain reflection probe per mesh, or ability to choose layer(s) that probes effect would be great.
5- Nested prefabs!!
6- Better documentation!!
Oh, and another small but desired feature:
It will save me a lot of time if there will be a HUGE button that will collapse all groups to the top level like on screenshot.
I think you can collapse all by holding alt and clicking on the Scene name on the top of the Hierarchy pane...
edit: oops, forgot, not the name, the arrow!
Better than nothing but every time scrolling to the top to reach that Scene name... Thanks anyway, it will help me a lot ).
Just select any item in the hierarchy and press home... But I think that the scenes should stay visible like fixed rows/columns from an excel sheet... (that's another feedback right here)
As I'm primarily an artist who designs characters and levels, I would love to see some improvements that would make setup easy.
Object Suffixes: What would be nice to do when using a 3d app like Modo, is to set a suffix for each object so that I don't have to keep setting flags manually on import. Example: I have a large level and I don't want to keep changing the flags.
A suffix like Statue_STATIC will set the object as static for lightmaps. Or Statue_RefProbeStatic for the model to be seen in reflection probes. Currently, I have it set up so I can type in the suffix in the scene hierarchy and I can set it that way. Same with locators and what kind of light it is. Example: Lamp_point. _Point allows me to put a point light on the locator in unity
And Amplify Shader Editor is EXACTLY what we need... getting tired of having to keep reimporting shaders every time a new update releases, and something breaks. With Amplify, I can make my shader and see it. Keeping it artist friendly
Working with Mecanim can get pretty messy and painful. The animation workflow could be re-thought. One example of a missing feature:
I remember there was a free tool on the asset store that does just this. I wrote my own, it's not too complicated for basic functionality.
I'll try if I get time, but I am busy at the moment. I'm a part-time lecturer in Games Computing, and it is the middle of marking season.
Also make a magic button to make high poly models to low poly and vice versa
A realistic physics engine
"And vice versa"
...now that's a bit of an unreasonable request, don't you think? This very much falls in the realm of the mythical "make MMO" button
How would the program even know what the high-poly version is supposed to look like?
@Nevin can we get a proper light function in unity, or an extended light cookies with shader support?
And update for the projector component with option to cut the affected mesh to only draw the mesh in projector coverage, currently projector render the whole mesh and this is bad for performance
I think kevmiz is trolling, most of his requests is not about artistic workflows.
I don't know if he's actually trolling. This type of "I want Unity to make the game for me" request is unfortunately very common in this community.
Things like a built-in snow/rain effect, or a built-in day/night cycle, or a "Machine learning thing that makes my character walk automagically" should never be part of an engine by default imo. It's way too dependant on your game's style. And it has the annoying side effect of making all games built with that engine look/feel the same (UE4 kinda has that problem, although it's a huge improvement over UE3)
This stuff belongs on the asset store. I opened up Lumberyard/CryEngine the other day, and right off the bat, there's something that turned me off completely; new scenes have a terrain, an ocean system and a weather/clouds system built into them. There's also a built-in "Weapon" class and a "Vehicle" class. It feels like I'm modding Crysis instead of creating my own original game. I don't want Unity to turn out like that.
"In general" i personally agree with this. There is "but wait" however...
Well 5 years ago this was like valid ... !
as those requests you mention and most of the others from the thread are available in the other available engines and with that at really high quality, probably this is what Unity have to do -> provide users with as many big/small features as possible just because as they say, they try to democratize the game development. Most of the users that are using Unity imo have not the skills needed to produce high quality project without auxiliary tools and to be honest buying a ton of packages for a given project should not be the solution...
Currently ( ignoring the fact you have to fight with the engine while you try to produce something ) the reason i am using Unity is that it is intuitive and because of the programming language and i am like learning a lot which is great, plus supporting the devs will make the engine much greater.
So i guess we still have to try not passing the border of madness wishes which actually no one can tell where it is, but all features that have been requested should be analized, prioritezed and considered be added one by one...
Otherwise Unity will keep being the base platform and not the tool... for making games, videos etc...
P.S. i agree the with the "kevmiz" post about physics. I feel kie:
1. Interpolated Rigid Bodies are producing constant stutters (are not smooth enough)
2. Whenever a group of dynamic colliders collide with each other, some of them are jumping and flying around - probably because of some improper forces applied to them when they overlap
3, There is no any way i think ( i played with every setting i know ) to stop a collider from penetration even at low velocities ( i played with Unreal engine and colliders seems to be really solid there and it is NVidia physics as well )
Will be great if this could be taken into account as well. Thanks !
Maybe I'm in the minority, but I have a different opinion regarding this. For me, Unity's "abstractness" and "genericness" is a huge part of it appeal, and it's one of the main reasons why I'm using it instead of UE4 or CryEngine.
Like I said earlier, I hate it when working in a game engine feels like I'm modding someone else's game, instead of making my own original game with a "basic tool".
Besides... - and now this is extremely subjective - I think it's always a better idea to create a fully original and hand-crafted small-scale game than creating a large-scale game that's full of third-party assets and results in a completely incoherent artistic direction. Think of "Inside" versus those poorly-made DayZ knockoffs that keep polluting the steam store. For anything that's "artistic", I feel like there's no other good option but to make it yourself. It's more realistic to compromise on "tech" things.
More of a "usability" thing than an "artist" thing, but:
Right now I'm investigating a performance problem with a colleague, and we'd love to have a "Shader Complexity view" to see if that's the problem. Something like this:
Just a scene view mode that gives you the "weight" of a shader with a color code