Official Unity wants your feedback on usability and artist workflows!

While I see your points here, a proprietary format can actually hurt. If an artist has to build a format that only works on one engine, you risk turning away asset store potential. Using fbx means it works with almost anything, besides, try importing the same package in Unreal, the work is way more trouble. The textures don't automatically go on or anything..

 

If you don't have the asset, what package are you importing exactly?

You are right though. I had my though process purely on the new experience so didn't even consider this.

 

Standard asset are installed by default (unless you check them off I believe lol)

 

Ah, see I do almost all my selections with the hierarchy because my scenes have hundreds of objects.

 

For usability dark UI on personal edition or pro / plus having month to month plans where you can cancel and stop payment at any time. It doesn't doesn't make sense to not use various hacks to modify the UI, when a studio only uses Unity for game jams and projects with quick turn arounds. Being able to pay month to month just makes more sense when I only use Unity 2 months out of a year, with the rest of that time going towards Unreal development. (Prototype early game concepts in Unity, and optimize for release in Unreal)

There's also the fact the white Unity UI is unusable on an IPS panel. All that white causes eye strain from looking at the monitor for longer periods of time. I would gladly pay if I can do month to month just to get rid of the eye strain, and would be willing to sign up for a year long subscription when it makes financial sense just for the convenience of not needing to input credit details every couple months.

 

First here is you thinking unreal is better for production, that shows a lack of understanding of Unity's capabilities, enjoy your weird artifacts like hair that stretches across the screen while people run, even big AAA companies are struggling with stupid little things like that in Unreal....otherwise....

Black text on white background has been deeply studied and scientific results prove that light backgrounds with dark text is better for the eyes than dark backgrounds with white text. I almost bet I know where your eye strain is coming from, you sit in a dark room with nothing but the screen light lol... If you are concerened about eye strain, turn on a light, another proven fact. I do believe the dark theme should be free, its silly it isn't to me, but seriously its not worth 30 bucks to get a dark theme. I have a plus subscription for the few extra tools it provides.

 

Damn, that first paragraph was certainly unnecessary. They were just mentioning their use case with Unity3d. As for the dark background, I agree with @zerophase mostly. And you are totally right about the dark room thing, I know that's why I struggle with eye strain. Artificial light is mostly not good for the eyes no matter the context, I think. I'm a shift worker so that is all I'm used to.

 

I would not want them ditch Mecanim at all, but would like to see it improved. To be fair Mecanim is not that hard to work with; but it does have a steep learning curve in the beginning, but once you understand it it becomes very good in organizing and establishing animations for objects in game.

It is semi node based but still requires a strong scripting knowledge to link the controller component to the model and the values to trigger animations as needed.

Not sure how to make that part easier without basically re-writing the entire animation feature of the engine which would take literally years to complete and would probably still not satisfy everyone.

 

Even for those of us who can we have to a long winded workaround to get SpeedTree grass running at a reasonable framerate.. Which generally includes dynamic LOD generation / instancing / grid components etc.

I don't understand why you'd enable SpeedTree integration if you wasn't going to finish the job? It is about time that terrain system went bye bye.! The official request for feedback was like 4 years ago now?

Anyway, there's a lot missing in 2017 than you either have to do yourself or buy (that's in every other engine), deferred decals, mesh painter, vertex / painter (for water / puddles / walls etc.)

You'd be suprised at the amount of asset store tools or self made tools I have, IK systems, water systems, occlusion culling (as Umbra is static), shader editors, TOD w/ atmospheric scattering (which UE has an AS actor) just to name a few..

Now it is a grey area where Unity begins and the asset store ends, but I'd probably say where Epic was a couple of years ago..

Just to mention this isn't an outright complaint, because fact of the matter is no matter how many staff Unity has some asset store stuff is always going to be better.. I'd much prefer them to focus on the core and stability..

Although terrain system aside, there are some little touches that would make life easier (and cheaper) for everyone.

 

Hello, Unity 2017.3 is out and we're still having these annoying picking issues !!!
When is this going to be fixed ???
It is that hard ???
This is still eating a lot of time when you need to select a couple of object !
This is since v 5.x !!!

Thank You !

 

As an Asset Store developer myself, it's probably weird of me to say this, but I think THIS should be the one area in Unity that should actually be defined.

There are wildly different expectations from person to person here as to whether the Asset Store is a savior or a boon to the Unity pipeline as well as whether or not Unity should handle some of these developer issues themselves. I personally feel like Unity does a LOT more than what people give it credit for, BUT most things Unity does it tends to do 'half-assed' (in a perpetual bid to keep up with the technology without hemorrhaging money) -- or with an entirely poor design (which spawns from trying to keep the idea of selling Unity's source a viable option for revenue). Unity is in a tough place, but its ability to overcome both of these problems is trivial -- draw a dividing line between the Engine/Editor and the Asset Store.

Who fixes what?

The former issue ('half-assed' / 'incomplete' features) is Unity's problem because only they pick and choose what features they're willing to tackle. The latter ('poor' design of features) can be fixed by the Asset Store since 'poor design' can be relative to personal opinions or project-specific needs --

-- BUT there's one exception to the "poor design" issue:

The core features of the game-engine must always be fixed by the game-engine. Whether these features are poorly-designed or simply half-assed doesn't matter -- If users of the game-engine can offer (or implement!) a better design or implementation (of a core feature) themselves, either allow them the tools to do it, or do it for them. But it'd be a lot cheaper to just provide users the tools -- I am willing to bet that would save more money in both support and engineering costs (for errant or half-assed features users didn't /really/ want or need anyway) than selling the source code alone would make.

So

Since Unity, took on the task of implementing a terrain engine themselves, here's a great real-world example scenario to fix the "poor design" issues plaguing Unity's toolchain.

Here's a (very relevant) -- USABILITY AND ARTIST WORKFLOW -- example:

Listen up, Unity:

Here is "TERRAIN" - FEATURE-DESIGN 101:

As we probably ALL know, there are clearly MANY waaay better options out there for terrain in Unity than Unity's standard implementation, and since "terrain" has such a general meaning to each user anyway (i.e. some users would be satisfied with a stretched-cube), the best and most efficient implementation would allow for ALL permutations the engine can ever be asked to handle: -- (i.e. I need terrain, but I need a (perhaps 2D?) mesh- or voxel- based 'terrain' that would let me scatter (perhaps sprite-based?) trees/grass/rocks/boxes/houses across its surfaces via brush, and I'd like to provide LOD and distance-based fade options to the 'terrain' too -- but, no matter what -- I would never need a heightmap for my 'terrain').

Since terrain is mostly just patches of (sometimes never-ending) meshes, whether you generate a large voxel mesh, a large mesh of animated sprites, a mesh of tiles in a tilemap, or just a regular mesh -- ALL possible permutations revolve around a single concept -- That concept being a series of (sometimes neverending) "meshes" (whether heightmap, sprite, or voxel-based) and their connections to one another involving distance (and culling routines), each mesh having blobs of smaller meshes that have LOD and distance-based routines themselves, with a heavy focus on instancing and less on LOD display), that are usually defined by some sort of paint- or brush- based placement across various "layers" and a detailing interface that infuses data into each terrain detail, letting the engine automatically handle instancing at runtime. If it dealt with its own floating point issues as well (perhaps through a simple "tile" drawing routine for each large terrain mesh, possibly tied into the camera rendering system), this would never be an issue again. (Future-proofing is a great thing in technology! -- Can't even fathom the concept can you?)

Besides, if more features (like the new "terrain engine") were designed THIS way, Unity would not only have avoided releasing a "poorly-designed" or outdated tools (such as the Terrain Editor), but by releasing tools that are only an example (i.e. example terrain editor) that anyone could tweak or rewrite, it would also have succeeded in creating a proper "terrain ENGINE" as well, due to its ability to future-proof its entire toolchain!

Is this good for everyone? Let's just say that even if I was happy with stretched cubes, I would never have to worry about instancing, culling, placement, drawing, tiling, LODs, working around floating-point BS, or infinite terrain ever again! -- My stretched-cubes terrain would "just work" no matter what the hell I threw at it.

That concludes FEATURE DESIGN 101.


These are very relevant issues to even the most simple feature concepts -- but without it, each and every one will have to be solved over and over -- and over -- again, for every permutation imaginable. Unity itself probably won't live THAT long. -- Designing *one* large modular/pluggable feature-set this way is the way it HAS to go to be efficient over the long-run. Think about the "Scriptable Rendering Pipleline" concept -- this terrain design isn't too terribly far off from that is it? -- but I think every 3D artist agrees that this is a great direction for game graphics in Unity! -- To be able to define your stuff down to the granular level is what makes it possible to add the "style" that games will need to stand out these days. And if Unity really is serious about that pipeline -- take that same "pluggable/scriptable-pipeline" concept to all the other areas of Unity such as Terrain and Animation -- both things every game developer HAS to struggle with in Unity. After all -- no matter what we're creating -- we need a world (terrain), and we need to populate that world with life (animation). Aside from physics and low-level graphics (Unity's bread-and-butter until now), these aspects are just as important -- and probably easier to provide a final solution to as well!!

Just my two-cents -- Take of it what you may.

 

Are you aware of the Playables API? It is amazing

I completely agree with this, but I gotta say I am under the impression that Unity has been putting a lot of effort into solving these sorts of problems for many parts of the engine lately. For instance:

• Playables API solved pretty much any animation problem/limitation imaginable. I'll probably never use Mecanim again
• Unet LLAPI is excellent and allows us to do any type of networked game very well
• Scriptable Render Pipelines.... I probably don't have to explain this one
  
• Navmesh LLAPI
• Exposed PlayerLoop (in 2018.1)... allows us to rearrange and modify the entire updates lifecycle of Unity
• Physics.ComputePenetration, Physics.Simulate() and Kinematic collision pairs gives us some much-needed control on physics, and there are plans to create a "Physics LLAPI" that gives us even more low-level control after Phyx3.4 has been implemented

etc..... "Low-level APIs for everything" really seems to be the key to Unity's future, in my opinion (which is sort-of what you were saying). I know this is an "artist workflows" thread, but LLAPI's are still very relevant to the discussion, because they're what will allow the community to build proper tools

I actually think they're doing a really great job ever since Unity 5.6 or 2017.1. The terrain system is something that hasn't been solved yet, but I'm pretty optimistic about the situation. It's on their roadmap, so they are aware of it

 

I actually totally agree with you there!

My entire point of making that post is to ensure that the Unity Team fully understands that they are definitely aiming in the right direction and that their efforts could (and should!) still be applied to other areas of Unity's toolchain as well (such as the "terrain engine" becoming more of a "world-populating-and-distance-based-culling/LOD-system-with-paint-tools" -- leading to a lot more usability than its current "heightmap" implementation suggests it could ever have). They could still replicate this awesome progress in other areas too! -- assuming they go forward into the future using the correct design approach!

It makes me cautiously-optimistic that they seem to be on track with this -- but I still feel the need to point it out to anyone on the Unity Team who reads this because I feel that there's still a culture inside Unity's software-planning team that lends itself to the idea that: "They want a "terrain" editor... but there's lots of different kinds of "terrain"... so what specifically do we give them?? -- Whatever we do give them they won't ever be happy with! -- Why even bother??"

And this is understandable -- but the correct design approach (the "how-to" is explained in its entirety in my previous post) will solve that problem entirely.

Indeed, you're right -- but it's been on the roadmap (and in the long/uncertain category) for a very long time. Unity has a pretty bad track-record with design issues. Projects like the 2D sprite animation system, plus the new Input system we were promised (that stated it would make input less tied to framerate and more universal) have failed -- (and in sadly fundamental ways). I have reason to believe these failures are likely due to the fact that they really don't know how to design an artist-focused tool that will be satisfying to said artists -- and although I feel they really do want to deliver the best possible features/tools to artists, they might not feel like they have the budget they think they might need to do that, and I'd be willing to bet most of their art-tool programmers are NOT game artists because, if they were, they'd know just how far a tiny tweak or two would go to provide leaps-and-bounds more usability than they currently offer without deep or sweeping changes to the source-code.


As mentioned before though -- it is indeed possible to satisfy everyone (including the newbies just picking Unity up!) by providing an example use of the API features that double as legitimate (fully-featured) editor tools. This not only solves the expectation by users that all great tools on the Asset Store "should be built-in to Unity" -- but also justifies the Asset Store a lot more to them because Unity has both developed a competent tool while also drawing the line -- "I do the tool back-end API -- and you design the tool interface using that API -- and here's how we do it."


As an Asset Store dev myself, this has always been sort of an understood thing, but many things in the engine I want to add require /them/ to edit the interface or add some sort of API to make the tool I want to create possible (Timeline, Animation Window, Shortcuts, etc.) -- MOST of these things, people want to edit themselves to make the tools they need, but they just need a viable API written to interact with them -- and that "sufficient API" in their "design" process is a bit of what I'm pushing for in my post above -- your API must support all possible incarnations of whatever it can be applied to (i.e. meshes, lods, sprites, etc. supporting distance-based or rule-based occulsion/Lods/culling/etc determined by the paintbrush that painted them onto the "terrain", as exemplified in my previous post).



Let's face it -- we've got some badass tools on the Asset Store -- but a LOT of them owe themselves to the fact that Unity has a great API for them to prop themselves up with on the backend. Thus all kinds of heightmap-based 'terrain' tools exist that actually only include fancy shader voodoo and/or a few extra painting tools (for those shaders) on top of Unity's otherwise robust heightmapping engine. If the API for the heightmapping system wasn't as robust or didn't exist, those tools would likely not exist either. Granted, there are a few tools out there the author had to design and implement almost entirely from scratch (i.e. Voxeland) -- but even these tools are limited (and cost a lot more or can be less feature-complete than they /could/ otherwise be due to Unity's internals not being exposed enough where they could be useful for a custom solution) because the author can't piggy-back off many existing API systems to do the work their systems in general require (such as the stuff that comes outside the scope of traditional "terrain" systems) -- and due to this, these features (though basic and already exist in the Unity engine) end up costing the author a lot more time or energy than it really should have cost them in the first place (such as having to implement our own CURVE EDITOR each time we need a curve to control data), and naturally, the authors want to be compensated for this (and thus the asset costs more.)

With more modular, robust, and flexible (less-specific) APIs intended to solve more general problems, Unity can free itself almost entirely from the toolchain design process -- and users get more (and better!) toolsets and features a LOT faster with each release.

Very valid points! -- Unity is indeed becoming a lot more flexible thanks to their efforts. I'm not bashing anyone -- I just hope they do this with more deeply-integrated toolchain stuff too (i.e. the "design" stuff that's been on the roadmap for a long time that seems to be holding them up, where a general-pupose API would just make common tasks for a particular purpose [i.e. Environments / Animation] more simple wherever possible [and flexible, wherever required!]). Just focusing on subsystem backends and LLAPIs is okay some of the time -- but I personally want backend API to do some of the more intensive interim workarounds for us that Unity's internal architecture requires (i.e. floating point precision-loss in large or endless worlds). Other stuff in regards to terrain, Mesh LODs, vertex limits, culling, distance-based fading, etc. etc., we can do ourselves, but because games usually entail SOME form of these systems, and because they are usually -- visually -- very specific, having generic systems to handle all the other parts of this kind of stuff would be entirely worth Unity's time (and ours!) to make using Unity, overall, an entirely enjoyable experience.

That said, I feel they really are doing a great job! -- I really hope to see this "correct design approach" using better and more general-functioning APIs applied everywhere in the coming days! -- especially when it comes to the usability of artist toolchains and workflow issues! -- For now, I will remain cautiously-optimistic that they are hearing my pleas, but it'd be nice to have some solid confirmation every once and a while that they are listening to the little guys like me too.

 

Please make all common properties of materials editable when multiple materials using different shaders are selected...
At least - GPU Instancing would be great to be accessible !

 

Another one...

Can you please add a simple "Unparent" command to the context menu ( right mouse click ) in order to be able to quickly get an object out of a hierarchy - In the "Hierarchy" window. Current way of having to drag an object up or down to move to another parent or un parent it is really tedious ! May be adding some options of moving selections to another root will be good as well - like move selection to the last selected object .

Thank You !

 

The command GameObject > Clear Parent in the main menu isn't doing the trick for you?

 

Sure. You have Copy and Paste in the Edit menu as well as in the contex menu as well.
It is just some commands are used more often and it's good to be able to access them as quick as possible !

 

Hi another one !

I am always having trouble with the vertex snapping precision - see the video !
Is this actually normal !?

 

When using the EnumMaskPopup to select multiple options, each time you click an option, the popup closes and you have to reopen it if you want to select another option. It would be convenient if it stayed opened until you click somewhere else.

 

The ragdoll wizard should automatically make the joints created have projection enabled, or the ragdolls are very unstable when colliding with even medium forces.