Unity didn't have geometry instancing support?

Reading the patch notes, I read 'Geometry Instancing with low draw calls Support' as one of the big features. It is a big feature indeed, but are we back to 2004?

I'd try to sneak it in rather than show it as a big feature out of shame.

 

Huh. I wasn't aware this was supported as far back as the GeForce 6000 and Radeon 9500 cards. Today I'm learning a lot.

https://en.wikipedia.org/wiki/Geometry_instancing

 

https://forum.beyond3d.com/threads/how-to-enable-geometry-instancing-in-far-cry.15412/

Just google 'Far Cry geometry instancing.'

 

So you guys ignored most of our lobbying to have instancing in the last 6 years or so.

 

I only rarely go to the graphical sub-forums so if any of it took place there that's why.

 

Next big thing: material / shader editor. Moan moan, moan.

 

Now that complaint I'm quite aware of and agree with.

 

Better be nice to them, or we're getting Lithium back! "Complaining" about getting a new feature seems strange to me.


Instancing could be useful for my current project. I'm a bit scared of trying 5.4 again though. Last time enough things seemed broken, for me to go back to 5.3.5. Did anyone try the non-beta release yet?


Shader editor would be amazing! I'm sure it'll come, probably right after I've finished coding my first complex shader myself in painstaking trial and error for days on end ^^.

 

Fixed that for you. Because it's inevitable. We're doomed.

 

We shall defend our forum, whatever the cost may be, we shall fight on the threads, we shall fight on the landing pages, we shall fight in the fields and in the carets, we shall fight in the emails; we shall never surrender.

 

The question is what other GPU DirectX / OpenGL / Vulkan magic API calls and features are hidden by Unity?

 

Okay, so you got a point that Unity is late to the party.

But they shouldn't make a big announcement when they finally arrive? So that people still assume Unity is not at the party and will never be? Sorry, that is not a good way to handle public relations.
No matter how "shameful" something is, Unity devs need to know, and yes, also the guys that didn't used Unity till now because they weren't part of the Instancing party should be told.


Might not be enough to make them join the Unity party, seeing how Unity is always late to the party, and most probably always will be.

But are we now really complaining for getting something we wanted? Do it like @hippocoder implies, be thankful for what you got, and complain about the next thing on the priority list still missing.

 

Did anyone else notice they are giving us direct links to the downloads in the release notes? That's a nice addition.

 

Whoa, I completely missed that 5.4 actually released. Was that during the Lithium Incident, maybe? Odd that the Editor hasn't nagged me to download it.

Edit: Oh, yesterday.

 

A pipeline and built in support to do Skinned mesh instancing with animation on the GPU.

GPU GEMS 3 (cira 2007) http://http.developer.nvidia.com/GPUGems3/gpugems3_ch02.html

Wasn't this approach or something similar used in the Adam demo reel?

 

Editor version notification has been unreliable forever.

Speaking of which, I need to check out if their promised progressive lightmap baking actually works or not.
---edit---
Aaand judging by release notes it is scheduled for 5.5. Oh well.

 

Coming in Unity 6.0.
Unity 6.2: Working shader editor.

 

The moaning in this thread is mostly a contented moaning, there's no rage here as far as I can see... which means 5.4 must be less buggy!

 

Not that I'm doing anything particularly unusual, but my project loaded up and ran just fine (which wasn't true with the beta, I hit several showstoppers even fairly late in the beta).

As for future toys... I'm glad updating .NET at least made the "Research" list.

 

If you want to help them get to that promised land one day then consider joining in with testing something they need to do now as part of a multi-step upgrading process that eventually, hopefully, ends up with new .NET version. In this case the very early first step, the experimental unity version that has an upgraded compiler:

http://forum.unity3d.com/forums/experimental-scripting-previews.107/

 

I like 5.4 a lot. With the performance improvements and the new graphics stuff its starting to feel like an engine that can hold its own much better against some other engines that tout their visual quality. The TAA isn't perfect yet but its still very nice already in some ways, ditto motion blur.

I did moan about instancing in some of the 5.4 beta threads because they didn't quite go far enough with it to meet my earlier expectations. e.g. Speedtree support and some other details. So there is always more to do, but I shall give my thoughts on it a rest for a while. I would be happier if some further improvements to instancing were to appear on the 5.5 alpha roadmap.

 

I wonder why so many want the shader editor. I am struggling with shaderfx in Maya to replicate some simple shader, something that take 1' to write takes me half an hour to replicate graphically.
In case you are wondering why I use ShaderFx and not the other options, is because it's the least broken of all( still broken though).

 

Thanks, I'll keep an eye on that. Not really at a point where outside-the-editor compiles make much sense for my project unfortunately. I'd be all over it if they were supporting newer C# features though. Found it a little odd they chose to implement the recent change to closure variable-pickup.

 

Being able to create a shader without having to learn a shader language is the main reason. Being able to easily convert a shader developed in the other engines which use visual material editors themselves with only minimal hassle is just a perk.

 

From what I saw it's not like it's higher level, it's just visual. Not much difference in typing a keyword if or dot, or select a node with a label "if" or "dot" for example. If you start from an existing shader the level of knowledge required is the same, the big difference is made by the setup code which you can just copy paste.



Good luck copying something like this for example. Or even designing it if you don't have shader knowledge. And by the way my setup in maya is similar, and it's a shader that in cg is barely 10 lines of vertex shader and 15 of fragment.

 

Different visual editors won't be automatically compatible to each other. As @00christian00 the whole "visual" thing is just a different representation of a programming language, BUT the way nodes work with each other could differ significantly enough to make different editors completely incompatible.

 

GPU Instancing isn't quite finished yet, and it takes some tinkering but it does work on some platforms.

It's at least possible to produce large crowds of people now anyway...




It wasn't possible to render this many "people" in 5.3 (well, you could technically render them, if you didn't care about getting any sort of playable frame rates)

 

Well it was perfectly possible, you just needed to be creative... in fact the older technique might still be faster. A stadium crowd isn't really the best use of instancing. Instancing really is for dynamic things in my view. It's also kind of broken in forward as when another light hits it, it has to create a new batch. In deferred, this doesn't happen.

To fix I would imagine that Unity needs to implement some form of forward+ style renderer.

 

Stadium crowds are very dynamic. If they're not, you're not building a very good sports game.

And yes, it was possible. But only if you want to use billboards or some other 'creative solution' that hasn't been used in any modern sports title since about 2005.

There are 'billboard' spectators in that image, off in the distance, but the ones closer to the camera are proper meshes.

 

They're not as dynamic as you think. Animating does not mean dynamic. It means they animate on the spot. Instancing is key where you need to add, remove or actually move independently, otherwise there are approaches which can avoid even needing to instance, which are faster approximations.

In the case of stadium crowds, they aren't actually moving from their seating position to another location, and even if they did, they could be represented by individual normal rendered meshes.

My game has large crowds in a populated town so I've been doing a fair bit of R&D on various approaches, none of which involved billboards but animating in vertex shader for large prebatched meshes and so on..

 

Great, now I'm even more curious what you are working on!

 

It's actually kind of modest, I'm stripping a lot back to save on dev times, as it's gone on too long as it is, I can't fulfil the original aim but if I can make something fun this time round I'll be able to hire some more people to help out for next.

 

The built in shaders that ship with Unity 5.4 do not support instancing. This seems like a bit of a missed opportunity for Unity. At the very least, Unity could have included an instanced version of every included shader with Unity 5.4.

Additionally, the Unity 5.4 upgrade process does not automatically upgrade any shaders in the project to support instancing. Again, this is a missed opportunity. Unity should include instancing ready shaders and (ideally) a tool for converting existing shaders to instanced versions.

I found the following doc about modifying shaders to support instancing:
http://docs.unity3d.com/540/Documentation/Manual/GPUInstancing.html

While this document is fine for people who are already comfortable coding their own shaders, Unity missed a huge opportunity to make the transition easy for everybody else.

 

+1 , because this is not artist friendly.

 

The reason shaders aren't updated to automatically support instancing is because instancing comes with pretty severe limitations that would break your project's visuals, so nope not yet.

It's also a work in progress. Imagine the outrage people would get finding it doesn't work correctly in forward, or their skinned meshes aren't working out like they think, or things aren't being lit right...

Instancing isn't a slot in replacement at this point in time, and only suits some scenarios, not all.

As above, but by large Unity isn't actually artist friendly. You can't out of the box, click together a game or shader so dunno if this makes any difference really.

 

I know, no shader editor, no visual scripting editor , no visual behaviour tree designer etc ...there is areas to improve to become more artist friendly like UE4.
Anyway, there should be some visual settings to tell we want instancing usage instead of coding anything.

 

Will skinned meshes every be supported by unity's gpu instancing implementation?

 

I fully understand why Unity would not want to automatically rewrite 3rd party shaders during the upgrade, but Unity should have at least included an instanced version of each of their own shaders in addition to the existing non-instanced shaders.

 

On the other hand, if they supported instancing but held it back because they didn't have time to write and test out-of-the-box shaders, people would completely freak out. "I don't care! I'll write my own!"

(No idea if that's what happened but the beta cycle was actually pretty short and they got a lot done, seems like a plausible possibility.)

 

The beta cycle was not short at all. Especially for people who were pro subscribers who got their hands on earlier 5.4 betas long before Unity decided to make the beta completely public. It started last year!

What annoyed me most about the GPU instancing stuff was communication and failure to manage expectations properly. Someone from Unity actually shared an instanced version of the standard share on January 29th! But then later there were extended periods of silence and the idea that an instanced version of the standard shader being included in the box seems to fade away in dismal fashion.

 

Unity should have included an instanced version of each of their own shaders in addition to the existing non-instanced shaders. Not doing so has lead to a missed opportunity for Unity. Right now, only users comfortable editing their own shaders can use the GPU instancing feature, so the feature does not exist yet for most users.

If Unity had release a zip file or asset with instanced versions of every Unity shader, then everybody could be playing around with the GPU instancing feature right now.

The most ridiculous part about all of this is that Unity already does release a zip file copy of all of their shaders with each release, including with Unity 5.4. Unity already does that, but in this case Unity chose not to create instanced versions of their own shaders in addition to the non-instanced versions.

For example, on the following URL there is a link to download the "Builtin Shaders":
https://unity3d.com/unity/whats-new/unity-5.4.0

But that zip only included non-instanced shaders. Unity should have created an instanced version of each shader in that zip file. Is each Unity user supposed to manually download and modify Unity's shaders? Wouldn't it be vastly more effective for Unity to make instanced versions of their own shaders available to all users?

 

There is a zipped version they released in beta here http://forum.unity3d.com/threads/gpu-instancing.376635/#post-2486837

 

That is an instanced version of the Standard shader. What about an instanced version of all of the other Unity shaders?

 

Adding GPU instance support to your shaders is actually easy. Only few lines of code per shader.

 

Are you saying that it is so easy that each Unity user should manually update the Unity shaders, or are you saying that it is so easy that Unity should have updated their own shaders and made the instanced version of their own shaders publicly available with the launch of Unity 5.4?

 

Unity shouldn't have updated their own shaders, since people would haphazardly use them, things would go wrong, performance would suffer and people will complain.

Requiring minimal effort means people will look up how to implement them and also read on what to expect.

 

That last part would have happened regardless.

 

I guess that's why I used "would" for everything else and "will" for the complain part

 

Unity should have created an instanced version of each of their shaders in addition to their existing non-instanced shaders.

And yes, some people would have run into problems and submitted feedback, which would lead to additional improvements to the stock Unity shaders.

 

Well, struggling with learning shaderlab on and off, I see where you are coming from, but:

The big hassle with shader development in Unity is NOT the syntax. It is the needed shader knowledge involved (I finally started understanding what surface shaders are, what the vertex and pixel shader do, but WTF are fragment shaders again?). Its the hard to wrap your head around Math and Matrix manipulations involved that I, like so many others, just copy-pasta from the net and then wiggle around values and variables hoping that it will magically do the right thing, or at least something that does not look totally broken.

To me, THAT is the big showstopper for non-shader-magicians picking up shader development the first time. Happened to me in the UE4 Material editor too. Sure, I was clicking together a simple shader/material in no time. Yet writin a simple surface shader in shaderlab is also not much more involved once you know the syntax a little bit.

Achieving anything out of the norm (where you have no shadercode / node system you can flat out copy, or a simple and easy to understand algorithm to reproduce with clear instructions on how to implement it into a shader) is what is really hard, and again, the Syntax doesn't matter here.
You need to understand what the different stages in the pipeline do, what inputs get passed into the stage, and then some math to have a chance of producing anything worthwhile.