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.
Separate names with a comma.
Discussion in '5.4 Beta' started by djarcas, Dec 29, 2015.
Yes exactly! This is the recommended way to do. Thank you @zkw
Hmm we are currently working on a Metal port of the instancing feature, so yeah 5.4 won't have instancing on mobile
Could you send us your project (a bugreport is preferred) so that we can take a look at your case?
And what about OpenGL renderers for mobile? Will these be supported? I'll try setting up an appropriate case and submit it later
EDIT: Just created a case for the emission property issue #803310
Hey @zkw ,
I believe this issue is caused by using scalar float as instanced property on OSX and it has already been fixed in b21. Please check it out when b21 airs
OK looking forward to it
Possible to answer my last question regarding OpenGL renderers for mobile and GPU instancing support?
Would love to see instancing for Metal on Apple tv
Is there any word on automatic instancing for SpeedTrees? Will this be available any time soon?
You might be better of asking the makers of speedtree about this -> http://www.speedtree.com/forum/forumdisplay.php?4-Feature-Requests-and-Bug-Reports
I don't think they do anything internally with Unity; every response I've seen from them is that Unity needs to fix the shaders to work with the trees, not the other way around.
Yes if Unity breaks the shaders, Unity is the one who can fix them,
If Unity implements instancing in the engine, Unity is the one who can support all the integrated plugins with the help of their partners.
Yes, this issue has nothing to do with speedtree - the shaders and the technology are required to get it working. Also, in some cases it cannot be fixed for example you cannot have properly rendered speedtree with instancing in forward. There is no way to make that happen without Forward+
Unless you only use one single light or do vertex lighting.
I'd be more than happy with Deferred Only, lit only by one directional light. In most outdoor scenes, the sun is the only noticeable source of light on trees, especially at a distance.
Deferred doesn't have an issue with instancing. The lighting does not require new draw calls.
I haven't tried 5.4 yet, but at least in 5.3, draw calls for speed trees are ridiculously high in Deferred, and batching doesn't work at all on them. I don't think it's combining draw calls currently.
Zeroyao said earlier in the thread: "As of SpeedTree instancing, we are fully aware it might be the most useful case for instancing. It works and performance get improved in demos, but that requires some changes to the instancing implementation. We are working on that right now. Stay tuned."
I'm just... staying tuned.
Yeah I'm just saying it's unity's problem, and instancing doesn't work on anything lit in forward. Instancing will work normally in deferred.
Not a speedtree specific comment as unity has to update shader for that etc.
One further question: Currently I have about 1000 objects with lets say 3 different colors, which change frequently. This sums up to - basically - three MateriaPropertyBlocks. Now when i want to change the color i update the property block (which is a class, not a struct! [isn't it?]) and then i have to assign this MPB-object again to all renderers (which is quite slow). Is there anything planned to reference MaterialPropertyBlocks, instead of "flushing" them into each renderer separately?
Well.. my question was whether or not instancing for SpeedTrees is going to be in 5.4 or if it's being pushed back. As I understand it, it does not currently work on SpeedTrees, regardless of forward/deferred or number of lights.
Some update on speedtree instancing:
There are two things in the SpeedTree shader that currently prevent it from instancing: LOD fade values (unity_LODFade) if you have "smooth LOD transition" option checked (I suppose you all do), and light probes (unity_SHAr, etc.). The first one, instanced LOD fading, is kind of easier to solve. We have made the changes and are going though the merge process (QA, reviews, etc.) to bring it to 5.5. The second one is a lot trickier, as our current lightprobe implementation requires 28 floats for each instance and that is too much for instancing to be performant.
That said, in 5.5 if you are not applying light probes on speedtrees you will find them instanced automatically. If your scene is bound by the draw call API overhead on CPU, you will see performance boost. Unfortunately, our speedtree shader currently is quite heavy at vertex and speedtree assets usually have a high poly count...most possibly in practice your speedtree forest scene will be heavily bound by GPU performance.
Our plan for SpeedTree instancing is: 1. work on a light probe instancing solution whatsoever, as it is generally useful (for rocks, grass, asteroids and the Unsullied army ) and 2. keep improving/optimising the speedtree shader and the wind animation, to make speedtree a good candidate for instancing.
As Yuanxing said in [Official] New Terrain System, we are a small team for a big and demanding feature...we will work on the new vegetation system and speedtree is a big part of it. Let us get back to you when we have more information and progress to share.
In this case maybe just use 3 distinct material objects of different colors, and swap materials on Renderers instead of swapping MaterialPropertyBlocks.
Still in this case it would be best if Unity can just stores the reference to the MaterialPropertyBlock object on the renderer instead of, in its current form, a copy of it. I don't know if it will be generally useful. Maybe @Aras have some thoughts? (hmm I heard the rumor that it is quite hard to summon Aras )
Basically you are right, however i simplified the example to much - there is also a float value which can be changed per object
Doh... no chance of the non-light-probe instancing showing up in 5.4? How far out is the expected 5.5 release? Will it be before the switch to subscription-only?
How about to make clusterrender? Share CBuffer data in clustered object. Is possible sh light data also shared?
Are there any plans to open DrawMeshInstanced function?
If added this function like your custom build version. we can make own LOD or Clustering solution.
Yes indeed the problem is reduced by itself if we consider only DrawMeshInstanced. I will poke people around in our graphics team to gather more ideas. Work work.
Looking at the SpeedTree assets on the AssetStore, there are packages that are optimized for performance. You need to find those with Mobile in the name, otherwise most possibly you are getting high-poly trees (of course they look really nice ). Also reducing the wind animation qualities will help vertex load.
Well some further annoyances.
First, so far it's non-functional on a rather significant platform. Why only the PS4 and desktop? - what about that other major console? This is a rather critical bit of missing functionality.
Also, I tried following some of the tips provided earlier in the thread to make the specatators animated by can't seem to get any of that to work. As soon as I attempt to apply the shader to a mesh with bones (so that I can apply the transforms from the 'root mesh') I get errors.
Two ways basically, either bake the animations to meshes beforehand and have a custom script updating them or have multiple Animator/SkinnedMeshRenderer objects with different animations/phases and bake the meshes each frame & set them to the objects. That way instancing works and you can start wondering what's going on with the culling taking milliseconds...
I just found out that in 5.4 we have instancing on Xbox One! Pretty good news I'll update the manual page.
If you are talking about instanced skinning, in Adam demo we packed skinning matrices of each instance into a ComputeBuffer object and setup a per-instance "_SkinningMatrixStart" property to index into the buffer. I believe soon you can have a peek at the implementation if it's not already available.
Thanks. Given we're talking about a console, it might be best to post this update in the specific console forum so that we can talk about it without breaking any NDA's. It's brilliant news and I have (a lot of) questions, but can't really ask them here. We're using B19 which doesn't seem to have that bit implemented yet.
As for the rest, I have no idea what the Adam demo is but I assume _SkinningMatrixStart is a shader property? Anyway, anything you can point me to would be very helpful.
is Adam project are published? i don't think it published already since it's also using some tech that hasn't released for public afaik.
As far as I know, only the full length of the video demo shown during Unite has been released, but should happen soon.
So just following up with this.
I have a prefab that is 90 polygons (so tiny) with one small 64*64 texture, I have just under 11,000 instances of that same prefab all using an instancing shader and my FPS drops about from rock steady 60 FPS down to about 30. Given the hardware I'm running on my frame rate should still be still up close to 60.
The meshes do not cast or receive shadows. They have no reflection prob or light prob attached to them.
Via the profilier my Camera.Render % goes up from behing 26% without these meshes up to over 58% with these meshes active.
The shader is just a copy/paste from the documents so I'm wondering if anyone has had any better results.
I'm seeing demos of Instancing with other engines pushing 100,000 objects and still getting very high frame rates. Clearly it's doable.
In b23 have you changed the instancing shaders as I've just tested it and seen a massive drop in instancing FPS?
B23 (only a subset of results but a massive drop in performance)
Using Instance Shaders zipped and linked to earlier in this thread.
What hardware do you have?
My graphics card is a GeForce GT730 and I'm only getting 30FPS with just 11,000 meshes (90 poly each). I should be getting results similar to yours. Unless I'm doing something horribly wrong.
I'm assuming those values are number of meshes? What is the polycount of your instanced meshes?
The numbers are number of cubes (24 vert, 12 tri) Unity can display on my hardware at the target FPS (AMD 7900 series GPU).
Wow.. okay, given how much better the GT730 is over the 7900 I should be getting much, much higher frame rates (even with higher polycount meshes). Assuming I'm looking at the right benchmarks...
Clearly I'm doing something wrong here.
I don't know maybe it's the other way around...
Could be, don't know how accurate those online-benchmarks are anyway.
Regardless, I should be getting better performance than I am.
I think the issue with the benchmarks is that your link shows a comparison of GeForce 730 vs GeForce 7900, but Arowx actually has an AMD card 7900. That's what he was pointing out. And there is quite a difference between the AMD 7900 and the GeForce 7900.
Is this a performance regression from b20? We didn't make much changes between b20 and b23 if there isn't any. What kind of the scene setup are you testing against? Is it GPU bound or CPU bound? And on what hardware?
With lots of renderers (say 10k) in the scene Unity usually has a bigger bottleneck on the main thread with the renderloop code sorting and iterating all of them. Turning on "Graphics Jobs" (in Player settings) to offload them to worker threads can boost performance in this case and it works best along with instancing. From 5.5 we will have DrawMeshInstanced API that eliminates the renderloop overhead at the cost of being not so flexible (you need to deal with sorting yourselves) and more code work.
@zeroyao Apologies anomalous result re-ran full test with no other apps on single display and got a much better result.
B23 Full test - rerun no other active apps!
Hey Anybody knows What are Unity Miester? I heard That Today. I lived in Korea. There are ten Unity Miesters.
It's not Joke. It's real.
We are developing Golf Game. Leader want to see whole golf club with all courses. That means It is same to open world game.
We decide to use texture streaming. And Select Sparse Texture not virtual vexture pooling. because We want to use old shader codes.
Also We wants HiZ and earlyZ with hole system. Unity Terrain is too heavy perf and too small size.
We are developing new tessellation Terrain System based Wither3 terrain system. We developed Texture2DArray splat painting using sparse texture. But We have no time then out Chief decide to buy unity source licensing and Premeum Support Service.
Maybe Ten Unity Miester support our project. But I know some of them. They didnot know what is Hi-Z , they didnot know what is Texture2DArray . Even They didnot know what is SH light. They think light probe is Unity's orginal somthing speical.
I am afraid.
Now I resigned. and I need not more DrawMeshInstanced.
Good luck Yoda. and Good luck Jedi.
Gotta create one first from Assets -> Create -> Shader -> Standard Surface Shader (Instanced). "NewInstancedSurfaceShader" as shown in your screenshot is the default name that gets picked for it.
Thank you - I literally just worked that out. Why on earth isn't this done in the usual fashion...
Aaand that's a flat shaded one? I'm supposed to write my own shaders? Seriously. There's a reason I stepped out of this thread 3 months ago, I come back in and this is *still* backwards.
So, using the standard shader created above, drawing cubes, and instancing isn't happening.
It's hard to believe it's been 7 months since I started this thread.
Update! I've gotten it to render. However, it's an orthographic camera, therefore deferred is not allowed, therefore forward rendering has been forced on, therefore it's a flickery, horrific mess.
This is beta isn't close to being released, is it?
I guess there's no chance of supporting multiple materials with propertyblocks, eh...
Also, question : why is it instancing what appears to be a completely random number of times? Here are 2 adjacent drawcalls, one instanced, one not because... reasons?
I'm still seeing issues with Instancing as well. On the PC it's working (although not very well) as I can note performance improvements. But it's not working at all on other platforms (even though the docs say it is).
I've sort of given up trying to get instancing on actual meshes (less than 90 tris) and probably need to fall back to spritemaps on bill boards (which is very early 2000s).
How do you change texture UV's on instanced meshes?
I've tried using mMaterial.SetTextureOffset("_MainTex", offset); (offset is a vector2) But it's extremely sloooooooowwwwwww. At this point I just need to animate the object by cycling through a sprite map. Really not what I was hoping for but getting any quanity of 3d meshes to render with instancing isn't working.
Have you tried to disable dynamic batching, just to see if it makes a difference? I could imagine these 90tris objects be picked up by dynamic batching instead.
Not sure how much sense the following points make, but I would try the following...
Use MaterialPropertyBlock to change shader properties from code, as it should not break batching as I understand the documentation. The texture offset should be stored in _MainTex_ST.zw (_MainTex_ST.xy=tiling).
Check if _MainTex_ST variable is implemented as instanced property. If you can't find it in the shader file, it is probably generated by Unity, but you can also look at the generated shader code. Implement your own _MainTex_ST (as instanced prop).
You could test to add an additional instanced property that only controls the offset, if it doesn't work with _MainTex_ST.
Thanks Yes, I've tried with both dynamic batch on and off. I see no difference.
One scene I have has just under 5000 of these 90 poly meshes (with one 128*64 texture) and even on the PC the performance isn't very good. On this hardware I shouldn't be dropping below 30FPS if instancing is working properly.
I'd like to be able to hit between 20 and 25k and as I'm seeing Unity made demo videos of 100,000 objects running at 60 FPS, I don't think I'm doing anything overly taxing.
Its worse on other platforms so something is clearly amiss.