Unity API issues and Editor design thoughts..

Unity API issues and design thoughts.txt

List of design/api/usability thoughs generated while working with Unity- will be extended over time. Unity peeps
asked for some priorities, which are labeled (#1-5, 1 being highest) but are somewhat arbitrary (since these range
from massive refactors to simple fixes). Now adding with dates, so it's easy to see what's new..

3/28/2017
Asset publisher gripes:
- No way to enforce "one seat per user" license - companies with multiple employee's using my software only ever pay
once, when it's supposed to be one copy per user. 
- Piracy of assets is rampant
- No subscription business model. You're moving to subscription, why can't we? 
- Review system doesn't notify you on new reviews or responses. User isn't notified when you respond. No way to
contact the reviewer. 
- Not allowed to do your own system to fix any of the above.
- Not allowed to use analytics to improve your asset
- Favoritism in the asset store- some developers can bypass reviews, secret forums, etc..

3/6/2017
   - A global shader include directory (or Editor folder like system) would be really useful. I rarely use .cginc
   files anymore, because it either requires that all my shaders be carefully pathed to them or exist in the same
   directory. Problem is, when they're all in the same directory, all the shaders in that directory will recompil
   when something changes with any one of them. I'd love to have something like a GCINC path or Editor/Resource like
   folder sytsem where includes can be easily stored and all shaders can easily have access to them in a path invariant
   way. 
   
   

2/28/2017
   Haven't updated this in a while, but here goes:
   - Asset Store reviews are annoying for developers. Some user who doesn't understand the basics of Unity buys your
   asset, then gives you a 1 star review because they can't figure out how to assign a shader to a material. They
   don't post on the forums or send an email, just 1 star review you. You get no notification that this has happened,
   and they get no notification if you respond and try to help them. Thus, they leave pissed off, and you're stuck with
   an unfair rating which you have no way to contact the customer about or resolve. 
   - You have no way of seeing the ratings which don't contain written reviews
   - Reviews should explicitly be about reviews, not customer support, especially with the current structure which
   makes it nearly impossible to help users through the review system. Allow us to put a customer support thread at
   the top of the review area for an asset, and make email an optional field (spam filters often hide messages sent
   by users because they are of unknown origin). 
   - Not sure if the time->value ratio of Asset Store reviewing assets is worth it. I've pushed 10 patches since
   releasing MegaSplat, and had 0 issues found. I get the need for the review process, but having a way to rush a
   badly needed patch on occation, perhaps based on your record or something, would be really useful. Sometimes issues
   sneak through and need faster attention than 5-10 business days.
   - MegaSplat got caught in some "upload glitch" and sat in the line an extra few days, only to get released after I
   put a support ticket in asking why it was taking so long.
   - A list of what the asset people test for would be really useful - it's a big black box right now.
   - Asset Store uploader fails on large package uploads sometimes
   - The unity API updater is kind of awesome when it works; in many cases, I can code for 5.4 and have it auto-update
   for 5.5/5.6, which keeps my code cleaner. However, I've noticed that warnings due to minor API changes are often
   not auto-updated, which means I end up with a bunch of #if directives around things anyway. Would be nice if it
   could just update those as well.
   - Unity terrains don't give you access to the data created for the distance material, or a way to customize that data.
   It seems to auto-create some kind of distance texture from the splatData on the terrain, but MegaSplat cannot use that
   data, so the terrain just appears black in the distance. Additionally, the slider which controls when it switches to
   the alternate material is capped at a value. After contacting support, we found a hacky way to get at the material
   which is used in the distance by iterating over all materials and seeing which one had the right shader- but this only
   works when there is a single terrain object in the scene.
   
   

12/14/2016
   - PreviewRenderUtility apparently has GL/DX specific coordinate requirements. If you try to put a camera at
0,0,-1 and point it at 0,0,0, it won't render the thing at 0,0,0 correctly, and what it renders will depend on
which API your using. The right values for both still have to be fudged into possition as well.
   - The skin for GUI.skin.box has a different alpha in the light skin than the dark skin. This was causing some
of my users to not be able to see something because I drew a box after it and was on the dark skin (where alpha is 0).
   - Mouse coordinates are dependent on a special "multiply by 2" flag on retna monitors. Why not just return
these premultiplied so they just work? Seems like if the display size is secretly multiplied by some factor, I
should generally have to know about this for things to just work. (This broke my Vertex Painting system for lots of
users)
   - Making custom editors is expensive on memory allocations. EditorGUI, in general, is a GC nightmare. I was getting
2mb of allocations from a single gui (mostly strings allocated for enums, etc). Seems like some of this stuff could be
automatically cached in some kind of FIFO dictionary of enum->string, under the hood. I know IMGUI is basically dead, 
but it's the only way to make stuff in the editor, so could use some help. If a GC.Collect goes off every time you scroll
the editor, the tool doesn't feel very good.
   - Profiling the IMGUI in the editor is a nightmare. I have to use deep, and by the time I get down to my actual
functions, it takes 4 seconds to open a foldout and see whats in it. I'm under the impression that this is the editor
for the profiler being slow; if that's correct, then maybe change the paradigm to not draw so many foldouts, or better,
just it all faster and allocate less.
   - Seriously, could rendering previews of things be any harder? I've tried several alternatives to
PreviewRenderUtility, and they all have huge issues. I tried using an actual camera and game object, and it doesn't
draw the game object correctly- but if I don't clean them up, they draw fine in the editor. I really, really, want a
way to explicitly draw things to a camera, ie: myCam.Render(Mesh[], Matrix[], mat[]), so I don't have to worry about
all the things that can go wrong when things are in the actual scene (fog, objects in view, culling costs, etc). Ideally,
editor or runtime.

11/21/2016
   - The "Fix this normal map for you" needs a [surpress] attribute. I often pack things into normal maps, then have
to change shader defaults and names around to avoid it. Also, the ability to have my own = "mybump" would be really
useful.
   - I really wish there were good ways to use Unity's render engine internally; without the hassle of dealing with
creating cameras, lights, and making sure layers and such are all set to filter things.
   - Really, I just want a command buffer type thing where I can .AddMesh, .AddLight, SetCamera, etc, then call
Render(myTargetTexture) on it to render the result into a texture I can use. The ObjectPreview stuff is kind of
like that, but doesn't work in game. 

11/11/2016
- Why is generating a normal map from a greyscale image default when you select normal map for compression type? What
year is this? Have you ever seen how bad the normal map generated in Unity is using this option? Is there any reason
for this to even exist as an option except to be an extra click I have to make constantly? (Yes, I set up import
scripts on my work projects to avoid this, but really, this option serves no one).


11/9/2016
- Today I spent 5 hours chasing down a very strange bug. Turns out a pointer on a prefab pointed to the internal object 
on another prefab rather than it's own copy of that object. When the object got instatiated, it updated the pointer and
now the prototype prefab has a pointer to a live game object. It seems to me that the ability for one prefab to point 
to another prefab's game object root is needed, but the ability for it to point to the internals of that prefabs 
objects seems wrong, as it can cause no end of issues and is extremely hard to track down.


10/28/2016
- Really need a "Redownload from cache server" option. Reimport actually recompresses the textures, so they only way
  to accomplish this is to delete your library folder. Several of our devs are seeing a corrupt texture, so we think
  it has spread to the cache server and it's hard to verify. The other issue is that if they reimport the texture, we
  don't know if the cache server actually takes the new one or not without doing a library clear on another machine.

10/27/2016
- Surface shaders have a lot of undocumented edge cases. For instance, today I had an input structure which was 
  running out of interpolators; so I switched one of the interplators to use COLOR0 since the precision wasn't 
  an issue. However, no matter what I do, the value in the pixel shader is the vertex color value- all assigned
  data is lost and is not even in the compiled code.
  I often get bitten by "magic names". For instance, having something with "uv" in it in your input structure 
  magically maps it to one of the texcoords. Or using the word color. For some reason I recently had a variable 
  in my structure (or maybe my code?) called line, and the shader wouldn't compile until I renamed it to something 
  else. I would love a list of what things happen 'automagically' in a surface shader via naming structure.   
- I would like a simple way to call into Unity's lighting system in standard vert/frag shaders. You have considerably 
  more control in a vert/frag shader, but having to reconstruct all the boiler plate and lighting functions is undesirable, 
  and there's no simple way to, say, new up a surface structure and pass it to a function to do the lighting. 
- Asset Bundles were a hot issue on the forums/blog this week and invoked my PTSD from STT. My two cents is that the 
  design of a new Asset Bundle system should follow these design tenants:
  
  No possibility of duplicating assets in memory or on download
  No or minimal marking of data for the user (just bundle everything? Or only mark top level assets..)
  Creating bundles handled automatically from dependency graph (not just duplicated into every top level bundle)
  Variant processing for common assets handled via OnPutIntoBundle style callback (change texture compression, 
  swap files, localize, etc)
  No requirement to write tons of dependency based loading code - set server address and call load on your top level 
  asset, it handles the rest
  No GC allocations for loading process, decompression, etc.


10/21/2016
- In 5.4, the new API on materials lets you SetVectorArray, but there is no GetVectorArray or way to create a property
  for the array, which means you cannot store that state on the material. So, lets say I have a texture array and want
  to have some user editable data associated with it (per texture material parameters, scale, etc); the workaround
  would be to have a GameObject in the scene with a component on it which stores this data and sets it on my material,
  but this is brittle because there's no way for me to perminantly associate that data with the material - someone could
  use the material without that object, etc. It would be much nicer to store that data in the material and be able to
  read it back from a custom material editor/ShaderGUI, allowing me to expose the array settings along with the texture
  array in a nice editor.
- For some reason, in 5.4, all of my mouse positions were off yesterday by a multiple of 2- suddenly they're working
  again, without any code changes. (Maybe this issue is to do with internal retna scaling in the editor or some such?)

10/20/2016
- When entering the cache server address, you have to press return for it to take. If you just type the address and
  press "Test Connection" it will clear the address. (10 minutes lost to this every few months by several people)
- Audio Curves suck. Logarithmic doesn't clamp to maxDistance, so you can't actually filter out sounds with distance
  at all with it. Workaround is to create a custom curve somewhere and set it on every source in the game. (This 
  might be duping memory all over the place though). Additionally, since custom curves only respect maxDistance, 
  and not minDistance, you can't share those curves if you care about minDistance. This is all pretty impractical for
  actual game audio, which need to not follow the laws of physics correctly and fudge things, much like lighting 
  and everything else in a game. 
- Audio is in DB and in scalars. Would be nice if either you chose one, or provided conversion, else you get crap
  like this: https://twitter.com/eastshade/status/785762243900080128
- When I Event.current.mousePosition in concert with sceneView.camera.ScreenToWorld() in Unity 5.4.1p3, I have to
  multiply the mousePosition by 2 for it to match the behaviour in 5.3.. wtf?
- ScriptableObjects will sometimes load as null when building from the command line. Work around is to instantiate
  them, then all the data magically shows up.
- TextureArrays are massively unfinished. You have to construct them via code, but there's no way to setup the import
  format for them (ie: AutomaticCompression). The UI just shows the enum value for the format too.
  

ProgressBar
- (1) If your script has a progress bar and you have a NRE or it doesn't complete, that progress bar is stuck open and
  can never be removed; further, all menu options are disabled, etc- the only remedy is to force quit Unity. As
  a solution, I suggest that a recompile of scripts should always clear the progress bar state, since your going
  to attempt to fix the error and return to Unity to find it broken.
- (4)Calling AssetDatabase.StartAssetEditing brings up a "Importing small assets" dialog, which blocks the dialog that
  shows useful information I'm providing while processing- basically, it makes it so you can't use a progress bar,
  and the app looks like it's locked up- but if you move this dialog out of the way you can see the one you created
  underneith it. 

LoadLevelAsync, not so Async. 
- (2) So, I'm working on my own system to stream chunks of the world into Unity. Each block
  in my test scene has about 2k prefab'd instances in it, with 4-9 blocks being requested in a single frame (I'll 
  amortize it later, once it's as fast as I can get it). I recently did a test with replacing it with Unity scenes. 
  Loading one block with static batch enabled takes 1200ms, without takes about 600ms. That's really, really not async. 
  (I didn't test prefabs, because without prefab nesting the files would be way too large). 
  My system can currently load and instanciate this stuff in about 8ms on the same machine,
  but unfortunately I'll need it much faster for mobile. Not really a fair comparison, it's extremely limited to my
  case vs. scene loading. 
- (2) Loading aync in general tends to hitch, a lot. 

Mono Develop
  - (3) The new version of MD constantly loses intelesense, requiring a restart of the app before it will work again. 
    Happens about 3x a day for me, and I'm such an intelesense junky that it's like someone blindfolded me as I 
    was getting on the highway.

Prefabs
- (1) Nested Prefabs w/ support for encapsulation. Basically, I want to make a prefab and expose the data which is allowed 
  to be edited from the user of this prefab. This gives you a real API for your object, instead of letting everyone mess
  with anything. Then allow you to nest them inside each other, and as long as you don't change that API, everything can 
  be safely refactored below. Had this in a previous custom engine and it really helped reduce breakage and simplify things.

Streaming Asset Path
- (4) On most platforms, "file://" + Application.streamingAssetsPath, but on android, just Application.streamingAssetsPath
  is required, and putting "file://" at the begining breaks it. 

Texture2D
- (1) Need a GetPixels variants which take a pre-allocated array instead of allocating a new one each time. Basically
  the GetPixels variants are useless at runtime because I'm never going to take the GC hit. 

Transform
- (4) During OnEnabled/OnDisabled, you cannot change the heriarhcy of child objects. This may be there for a very good 
  reason, but it isn't explained, and it's easily hacked around because the check in transform.SetParent only checks
  the parent directly above. So if you put an extra object between the object getting the OnEnabled call and the object
  you want to parent, it will bypass this check and allow it. Thought I don't know why, this seems like either a very
  odd restriction, or a check that is insufficient. 

HideFlags
- (4) Would like finer grained controls. Basically, I have a case where I have a game object with a bunch of meshes below
  it set to HideInHeriarchy | DontSave. This allows those objects to be drawn and selected, but what I really want in 
  this case is to have it select the visible owner object instead of the meshes below it (which you shouldn't be able
  to edit). 

Gradient
- (3) Max 8 keyframes, why? 

Handles
- (2) Need a DrawMesh on Handles. Right now, there are certain places to use handles, and certain places where you can 
  draw meshes, so you end up having to create state to do the work in the right places. A Handles.DrawMesh call would
  make life much easier in these cases.

Color Picker
- (5) On my multimonitor display, the color picker often opens on a different screen than the editor used to trigger it's 
  opening, requiring me to look around for a few seconds to find it. Rather, the position of the color picker window
  should always be over the position of the control used to open it (or at the mouse position).

Asset Import Pipeline
- (1) Need a way to control data going into texture compressor- for instance, being able to load the raw 16bpp image and 
  map the normals from it into 8bpp texture data with better controls than simply throwing out the bits. 
- (1) I would like a runtime equivelent of userData where you can stuff data needed in runtime calculated at import time
  to associate with an asset. For instance, normalization parameters for textures, etc. Can be done in a separate file,
  but quickly becomes clunky.
- (1) Need AssetPostProcessor function for everything else; like prefabs, scriptable objects, etc. It's nice to set asset 
  bundle information in them, but you can only do it for certain file types.
- (1) Texture compression for ETC2, PVR, ATSC is brutally slow; move to the GPU. Binomial's new system, eventually?
- (3) Would like a way to prevent texture compression from being used until build time that is actually useable. The
  current option for this skips texture compression when working in the editor, but when you build does a full
  reimport of every asset each time- so it's basically like suffering a library refres on every build, even though
  you just compressed those textures a few minutes ago on the previous build.
- (1) Async Import, everywhere, on everything, ala UE4. Don't break use workflow, especially when imports can take 18+
  hours.
- (1) Store library once per platform instead of clearing each time. 
- (1)Library folder corruptions are rampant on large projects. 
- (2) Sound importer occationally fails on our build machines in a similar manner to how the texture importer fails. 
  With the texture importer, we are able to hack into the unity call which the editor uses to show you bad imports,
  reimporting them when it happens (as a pre-build step) - but we don't have the equivelent for sound. If an asset
  fails to import, a single retry would likely fix it the flakeyness with these exernal processes. 
- (2) Meta files mismanagement commonly creates issues for people (forgetting to check them in, etc). Currently looking 
  into p4 triggers to prevent this. GUID collisions also create invisible havok; would like a message box when they 
  happen that allows you to decide which one gets the new ID. 
- (3) Unity goes to the cache server for types that do not get cached. For instance, change the asset bundle name on a bunch
  of prefabs and it will go to the cache server and see if it has one. But prefabs are not platform specific, so they 
  aren't cached in the cache server, so this is just unnecissary delay. (Changing the bundle name also doesn't affect 
  the cached data, but it's just easier and less error prone to hash the whole importer, so I get that)..

EditorWindows
- (3) Custom editors constantly lose context when working on them and get stuck as blank windows in the layout, forcing 
  you to reset the layout to remove them.
- (4) When editing prefab assets (not instanced), calling EditorUtility.SetDirty on the game object does not dirty the
  prefab for saving, but calling it on a component you edit does.

EditorApplication
- (4) projectWindowItemOnGUI should happen before the item is drawn and allow you to modify the icon/text being drawn. 
  Right now, I have to make icons that are large enough to fully cover the base data
- (4) HeirarchyWindowItemCallback should happen before the item is drawn, allowing you to modify the text display as well
  as add icons, etc..
   - One use case I have is making items which are “HideFlags.CanNotEdit” darker by changing the GUI.color. Luckily 
     my items are in a list, so I can hack it by changing the color back to white before the last item is drawn.
     If I just looked at the hide flags, the next item in the hierarchy would be incorrectly grey. 

ISerializableCallbackReciever
- Current implementation is very limiting due to threading concerns, not knowing what type of save we’re doing, 
  and not happening when prefabs are applied. Would prefer an overloadable serialize method, optional so 
  everything just works when you don't care
- (2) Explicit control over what gets serialized and how
   - Pack and unpack data into smaller types at serialize time
   - Would prefer a before/after method which allows for object modification
     - Note, this could be an EditorApplication callback, which is called whenever anything is about to be saved
       to disk
- Prefab Apply not calling these functions make them pretty useless for a lot of stuff. Though this may be my error
  since prefabs don’t save the way everything else does.
- (3) Could also live with just knowing whenever the buttons to save/load/whatever get pressed in Unity.

Animation Window
- (2) Any change to the heriarchy/names of objects breaks your animation data- the only restore is through hacking 
  text files. The editor should at least listen for object name changes and transform changes and remap 
  automatically. Additionally, if a remap cannot be done, you should be able to retarget that timeline to any 
  object/property of the same type.
  (You should likely be able to do that anyway). 
- (4) Fixed parameter counts is a bummer.  Limited types is fine but it'd be great to have 2 ints, for example.  We ended 
  up doing a lot of casting shenanigans in STT to pull objects from 2 arrays in one event or divide an int by some 
  magic number to get 2 floats.


MecAnim
- Makes simple animation tasks very complex
  - Sequencing animations from code
- Banned use of it in STT, because it always sucks frame time even when not doing anything
- (3) Clip data is hard to access.  Animator can't read clip duration except from an already active state or clip, or by 
  looping through the runtime or override controllers clips to find the clip.  Since this returns you clip pairs 
  everything has to be managed based on clip names and every instance of the base controller must have an identical 
  base set of initial animations which ensures the worst case scenario is always present.  And at the end of the 
  process the Animator itself only cares about states which know nothing about their clips.

Lighting Window
- (3) Cannot access many functions via regular scripting; you have to use reflection to get at secret functions.

[FormallySerializedAsAttribute]
- (3) Needs a way to call a function with the data to revision it. If you changing a Vector3 to 3 shorts for tighter
  packing, it’s very painful to revision the data right now. 

Serialization
- (2) Serialize null properly please; easy to accidently cause serialization size explosion
- (2) Would love a way to read the raw serialization stream. For instance, being able to pack/unpack data as it's serialized
rather than having to store it that way in memory and pack/unpack as needed (or dupe copies). Or revion types, etc.


Shader Editor
- (5) Would like a way to expose "Property enum options", specifically for mapping texture channels. In an old engine, 
  I could make an enum for Channel (red, blue, green, alpha) which mapped to 0-3 as a property, then in the shader 
  use that property to access the texture channel, ie: float height = tex2D(mytex, i.uv)[heightChannel]; This allowed
  us to not require explicit packings of textures in our shaders, allowing users to pack the channels how they
  want to and choose which element is packed into each channel.

Particles
- (3) Need a way to specify a per-particle float4 curve to be sent to the shader. UE3/4 supports this, and it makes it
easy to synconize shader effects across the particle lifetime, etc. At minimum, being able to get the particles
lifetime as a 0-1 value in the shader would do a ton.
- (4) The value/range/curve/curve range controls are really nice in Unity- we stole that idea for a previous engine I
worked on. However, we provided an additional option for how values are chosen in range/curve range values. You
could chose a constant proportion betwene the values/curves, a random value between them, or a 2 point interpolation
between them (it would chose a start proportional value and an end proportional value). This increased the range of
effects creatable. (seems something like this is in 5.5?)
- GPU particle system, but in standard shader type format. Basically, get passed a StandardParticle struct to fill
out each interpolation frame and update position/rotation/velocity etc. 

Camera
- (1) Need a way for explicitly rendered cameras to not perform all of their setup. For instance, if I just want to render
  a game object into a render texture, it will cull the world, etc, even though I explicitly know exactly what I want
  to draw.
- The camera's draw distance seems to clamp the shadow map distance. I would have expected the shadow distance parameter
  to adjust the camera when rendering the shadow buffer, especially since the needed distance can be different on both. 
  For instance, our camera only needs to draw to 130, but the shadow map distance needs to be 200 to cover the area
  the camera see's from the light angle. Having these bound together kind of makes sense, but produces an unintuative
  binding for the user.

Graphics.DrawMesh
- (1) Want Graphics.DrawMesh like system that persists between frames. Submitting 10k DrawMesh calls a frame can take 38ms 
  on a low to mid range android phone. Modifing source to persist this between frames removes this overhead completely.
  (Implimented a version in source, significantly faster than dealing with game objects- likely real implimentation 
  is to use something like a command buffer)
- (1) After this stuff gets submitted, it gets dynamically batched, which combines all of these into about 12 objects
  looking at the profiler. This takes about 6ms if I'm reading it correctly. (Combining this ourselves in C# is not viable,
  as it takes forever using Unity's code, and I suspect rolling our own, even threaded, wouldn't be much better and would
  have serious GC issues). Ideally, we'd like to submit these as persistent DrawMesh calls, and use the ID we have for
  collections of them to be used by the dynamic batching so that we don't have to rebatch them each frame either. 
  
Command Buffers
- (2) Allow adding command buffers to normal rendering queue moments, such as during the shadow or depth pass. This would
  allow you to use Command Buffers as re-usable rendering lists that work like Graphics.DrawMesh. Have 50k objects
  you need to render every frame and don't want to pay the instanciation and transform cost? Just build a command buffer
  for them and add it to the right passes.
- (2) Allow Graphics.DrawMesh style rendering, which basically says "insert this into the standard 
  rendering pipeline". Allows you to do a DrawMesh style draw but for lots of meshes with a cached list and no C# CPU
  overhead. 
- (2) Command buffers do not dynamic batch, would be better if they could. 

Paths
- (2) Paths returned by Unity and many c# functions return in platform specific formats (\ instead of /). Would be nice
  if these were always platform neutral “/” as you have to do a replace after every path function to fix this, or break
  on some platforms.

Project Window
- (1) I have a case where I want the user to select a folder (they open a tool that adds data to the folder's meta file),
  but they have to select the parent folder in the left hand column, then select the folder in the right hand one, which
  which is not intuative. It would be nice if I could querry the selection on both columns of the project window.
  
Script:
- (1) There are many cases where structs/classes are never initialized by the constructor. For instance, if I have a
  List<MyClass> and I assign default values in the class, those values do not get set. My hacky workaround is to have
  the default value of some property be invalid (like 0 in an enum) and write an editor script which crawls the list
  and initializes the value when it finds one with an invalid value. Note that giving the class a constructor also
  doesn't work.

Documentation:
- (2) Documentation often doesn’t say what root paths are expected/returned from various functions
  - Some want “Assets/”
  - Some return “c:/”, some “Assets/”
- (2) Documentation is missing/incomplete on many systems
- Tends to be lesser used systems, but these are the ones I need documentation on the most
- (2) Every page should have a clear explanation of what the thing is for, and a code example of it being used. 
- Examples of bad documentation
   - UnityEditor.VersionControl*
   - SceneView
     - Not documented at all, but easily accessible
   - AssetDatabase.StopAssetEditing, etc..
- (2) Shader documentation is incomplete and mostly missing
   - Document all the .cginc functions
   - Document using the Unity lighting pipeline from vertex/pixel shaders
- (1) Users should be able to comment on documentation, which is either filtered by Unity or the community. NOT A WIKI,
 please, but a way to append the current documentation with useful information which should be included. Gotchas, etc.
 
Editor Refreshing
- (3) When a file is written to disk, Unity picks it up as a change and calls the import process. However, if you are, 
  for instance, generating a bunch of scenes or prefabs, this makes the process very slow. It would be nice if 
  there was a decent way to work around this. (Save scene outside of asset folder, shell out to copy into unity,
  then call AssetDatabase.Refresh? Couldn't get the AssetDatabase.StopEditing() to work for this)

Sprites
- (2) Sprite information doesn’t serialize in AssetBundles; you only get the texture, no sprites
   - Had to write wrapper system to restore this functionality
- (1) Sprite cannot be created with a RenderTexture; why? For that, you have to use a RawImage with UV offsets, which in
  my case means keeping two workflows around (one for sprite sheets that are generated at edit time, one for runtime).

Frame Debugger
- (2) Sometimes it will get into a mode where every selection of a draw call causes the frame to advance or the view to
  jump, making it nearly useless. I haven't found a particular reason why this happens sometimes and not others..
- (3) Sometimes the first frame will not analyse correctly, and most of the information is missing. A simple re-grab will
  fix it..
- (4) Would be nice if you could see the index count on the MeshRenderer preview as well as here. Very useful information 
  when working with dynamic batching, but artists tend not to look in the frame debugger and want to use vertex count,
  which doesn't mean they are under the real limit. 

Window Design
- (2) Unity has a GameView and a SceneView. In the engine we wrote at a previous job, we only had views, and the only
  difference between a scene view and a game view was what camera it used. If the camera renderered was the main
  camera, that view got input control. This made the code much simpler and removed all the restrictions we currently
  have between game and scene views. 
   - Users can look through any camera in the scene, as well as top/front/side/perspective/game/user camera
   - Users can script the behaviour of any camera in the scene, including the cameras which we currently do not have
     access too
   - Very useful for tools work; syncronize a game view with your editing or move the editing view to the area where
   the game view is. 
   - Users can open up multiple of any view
   - Would love a way to use editor selection/movement/etc in the game view

"New Scene"
- (4) The default new scene (not the empty one) should have a minimum lighting setup so your models look good when you 
  drag them in (light probe, etc). This matters less for my needs, but is one reason UE4 looks so good when you first
  start using it.
   
Saving playmode changes
- (4) Serialize out the undo history when play mode ends and if the user wants reapply it to the scene. Allows you to
  make play mode edits, test, and save back the changes easily. 

(3) Scene or Level, make up your mind. SceneManager, LoadLevelAsync, choose one and stick with it.

Engine Stripping
- (3) Useless with Asset Bundles (being addressed in 5.5!) Defaults to on, no way that can cause any issue for people

AssetBundle
- (partially fixed in 5.3.5p3) - LoadAllAssets no longer needs to be called, but paths still need to be stripped.

  When loading scenes from an asset bundle, the required code depends on if you have 1 or many scenes in a bundle.
  With a single bundle, you download the bundle and call SceneManager.LoadScene to load your scene- simple. However,
  if you have multiple scenes in a single bundle, you must call LoadAll on the bundle before you try to load the 
  scenes. Additionally, the names returned by GetAllScenePaths() must be stripped blah/foo.unity -> foo. This is 
  not only confusing as hell, but requires unnecissary string ops which create extra garbage. Not to mention, what
  happens if I only want to load ONE of the scenes in this bundle instead of all of them? Do I still need to 
  call LoadAll?

- Replace entire asset bundle system with a torrent like glob. Make two folders at the top of the project, one for
  stuff in the app, one for stuff in asset bundles, and stuff everything from the asset bundle folder into a 
  filestream with offsets and let the client request files just like they do stuff included in the build. This 
  whole "Lets have two build systems, one extremely automatic, and the other extremely manual with harsh issues 
  if you make any errors" is silly.

Asset Bundle Variants
- (1) Need a better solution for managing variants which are only importer differences; such as texture compression 
  options; across variant levels. Current solution requires multiple copies of the asset or a very complex and 
  brittle preprocessor pipeline to modify the data before it gets into bundles. Would prefer a 
  "OnAssetBundleInclude(AssetImporter ai)" option that lets you modify the settings/reimport as it's being 
  fed into the bundle variant.

WebRequest
- Doesn't support streaming sounds on android
- Still seems to have a lot of bugs preventing us from replacing WWW, which has issues bloating memory, etc..
- (1) Should be a complete replacement for WWW for use with AssetBundles, as memory use is much better, but isn't.

GetComponent()
- (2) Allocates GC in editor; really annoying, because any frequent GetComponent call ends up being wrapped in an 
  #if UNITY_EDITOR which creates a static list and calls GetComponents<SomeScript>(myList>) so that the runtime
  is somewhat closer to the runtime in game. 

Project Preferances
- (2) Some project preferences are stored in the wrong places. For instance, P4 information should be stored in it's 
  own file, one which isn't part of settings which may need to be shared.
- Some preferences are not exposed at all. I wasted 4 hours today trying to figure out why _ShadowMapTexture stopped
  working, as it was suddenly in light space instead of screen space. Turns out there's a hidden setting in
  GraphicsSettings.asset which toggles this (useScreenSpaceShadows), but it completely undocumented and unexposed 
  to the editor. (apparently a 5.4 feature partially in 5.3, and now correctly exposed in 5.5)
- useScreenSpaceShadows constantly flips itself back to 0 as I work. Code in Unity checks the platforms and slams
  this to true or false depending on platform. Had to write pre-build step to slam it back. (apparently a 5.4 feature partially in 5.3, and now correctly exposed in 5.5)

Project browser
- (4) Could use an update for different modes. Current version is like filesystem browser, but consider modes more
like Lightroom for content creation.
- (3) Placement of objects is horrid (drag and drop). Objects are places at an arbitrary distance from the camera, 
which is almost never useful. Favor collision based placement, including non-physics objects and project to 0z if not.

Grid
- (3) Can't seem to adjust the size of the grid to be in our game's tile scale

"Recent Scene"
- (2) Native recent scene menu, for quickly recalling scenes

Scriptable Play Mode
- (3) Add a callback when the various playmode buttons are pressed, allowing you to intercept and script their meaning. For instance, perhaps I want to always instantiate a player character whenever you press play on a scene, or route every play to load the start scene for the game. This saves a ton of time, preventing me from having to constantly set up a bunch of data to test a scene.

Scene visualization
- (3) Overdraw, mip modes, etc, are great- but why aren't they available in the game view?

On Device Testing
- (2) Would like a tool-sync type mode where the editor is available for a live running device. Many engines support 
  different degree's of this, but when optimizing and debugging just being able to see the heriarchy and state of 
  objects is extremely useful. I've written an ingame heriarhcy browser which lets me see/enable/disable components
  or objects in the tree, but it would be useful if something like this was built in while attached in the profiler/
  debugger/etc.

Text Rendering (1) 
- Takes up too much ram due to generating new bitmap for each font size. 
- Should be three channel SDF, which can preserve corners and still scale very large
- We weren't totally happy with TextMeshPro, so I spent a bit of time seeing what it would take to replace the
  system with our own- but many of the methods it uses to generate geometry, etc, are in c++ and not customizable. 
  Additionally, I tried to hijack the font system with our own data (allowing us to use Unity's c++ font system, but
  our sdf texture and shader), but the Font's can't really be generated from code. Ideally, I'd be able to use 
  Unity's standard text rendering but with my own sprite sheet and shader, so I could do 3channel SDF myself and 
  not have to write all of TextMeshPro.
- Suggest allowing users to edit the texture of a font manually. This would allow us to easily generate a font using
  SDF, or paint on a font for special effects (we did this a lot at Harmonix). 

Console
- (3) Need better filtering/channels/ability to compile out/etc. 

Field values on Scripts
- (4) If you create a field like "public Shader shader" in your script, then assign it in the inspector on the script,
  any new component created will have this shader set automatically. This is very useful, but unfortunately if you
  create the component via code it will be set to null. It would be nice if there was a way to automatically include
  that shader in the build (via dependency) and have it auto assigned when the component was created via script.