Relative Staticness?!

OK I think Unity uses the concept of static to reduce the workload of the physics, navigation and rendering sub-systems.

But what about relative staticness, for instance a moving camera could have static HUD components, a moving vehicle static components, a moving planet/asteroid/giant monster have relatively static components.

So my question is does Unity static work in a relative or absolute way?

And, I'm guessing it's absolute, could it still provide performance benefits if it worked relatively?

 

I'm pretty sure it is absolute. There aren't that many cases where a parent-relative Static option would be useful as in general you don't need physics or navigation in a HUD for example.

If you need it anyway you have to find a solution yourself.
E.g. if you have a spacecraft in which you can wander around you could make the spacecraft static and just move the world around it.
Or you could work with a secondary camera. So the spacecraft remains static in one place of your world and is rendered via camera 1. Camera 2 renders the outside world which is also static in a different place. You could even have different scales...

 

OK take the example of a ship, the majority of the furniture and fixtures and fittings will be static, and character will want to navigate within the ship. But the ship has to be seen as being on the sea (interaction with waves, spray, land) and can navigate between islands, also you would expect physics to work across the ship interior and world. So you can't do the render with camera trick as easily. You also want the physics of the boat moving on the ocean effecting the passengers and items on the boat.

 

Objects which are handled by physics wouldn't be static anyway.
Static objects like fixtures are part of the ship w/o a rigid body component.
For other things like lightmapping or pathfinding you would have to implement your own or a 3rd party solution.

 

If it's moving it isn't static. That is pretty much right there in the definition. There are lots of ways to optimize, but static isn't the answer. (unless of course you make the ocean move and the boat not).

 

Pretty much this.

Yes, one object can be static relative to some set of other objects (eg: the sub-colliders in a compound collider, and I suspect that in that case they're not being tested against one another), but generally if something moves at all then the possibility of it interacting with something else can't be ruled out by the code. If you can rule it out as a designer then you don't need to put a collider on it in the first place and the code doesn't even have to think about it... so the problem is already as optimised in this regard as it can reasonably be.

 

http://docs.unity3d.com/Manual/DrawCallBatching.html that might be the best your going to get.

 

@RockoDyne Thank You.

So with relative static objects Unity could optimise/combine objects, geometry and materials, reducing the overhead when moving and transforming their parent objects?!

 

No.
Static means static. The savings comes from recalculating values for those various features. It would be like saying that you want a white sphere that is black. It is static or not, "relative static" would mean not static.

What you are talking about is just basic optimization. And how you approach those optimizations can vary widely depending on need. As with static batching, there are trade offs based on technique and needs. Combining meshes/textures one very common way to do that. Again depending on requirements it can anywhere along the spectrum starting at the initial planning/creation of assets, all the way up to runtime. Selectively, manually, simple, or complex. Just like everything in building games, there is no one optimal method or solution, it is highly conditional.

For example, in SW:Commander, we optimize heavily when the assets are created, sharing textures and when possible meshes. Then during the pipeline we automatically optimize even further as many assets often always appear together, we analyze usage patterns and combine during build/buildling.

For example most FX occur only in battle and there are a wide variety. If you fire a rocket, it will have muzzle flash, a trail and impact and impact. All those images are combined. Since scaling breaks batching it is actually more performant to have small medium and large (or more) versions of those textures, that are exactly the same image at different sizes all lumped together. They are small in the first place, so having five different sizes of the same image is a minimal memory impact, but a huge performance boost because of the reduced draw calls.

Combining meshes conditionally is another great boost. When you are at your home base, buildings that aren't animated are all combined. The original meshes just turned off. When you go into edit mode the mongo mesh is destroyed, and the originals are turned on. In battle they aren't combined. Or other things like our ground is a multi-texture (really cool) shader that is affected by terrain and where you place your buildings. It's dynamic while editing, then stored and swapped out for performance.


Or even another approach... when I started working my lego x-wing game, I quickly hit a performance wall by having ships made up of individual bricks that have physics on each, I was never going to get huge multi ship battles with parts flying like I wanted. I ended up building a smart meshing/batching system that dynamically adjusts on the fly depending on conditions. It took about a year, and a ton of metrics/testing but is highly optimized. Being hard surface, faceted models the poly counts are very high at hero view (30-50k polys on average per ship), and the goal was to have a 100 ships in play with 4 being players networked (on mobile, not desktop). I was able to hit that. (on good devices, local network). Here is a bit of what a ship looks like post generation (for the hero).


Basically there are tons of approaches to optimization, but they are going to be largely done by the developer based on many factors. All the tools are available in Unity already. The discipline of performance optimization is a pretty wide area. And certainly engines do provide tools, and do quite a bit of optimization already, but there is no magic bullet technique, just lots of best practices based on the needs. And provided things like static gameobjects or static batching work well in the right scenarios, as pointed out in the docs.

 

What if Unity added a relative static option that did most of that for you and could be configured e.g limit texture size or mesh size. Then if you want to blow up you're lego spaceship you simply set the sub-components to none-static and the engine reverts the game object to a nested set of blocks.

I'm not sure how a relative static option would impact the particle system though?!

 

You seem to get hung up on the names of things without understanding how the underlying technology works. As zombiegorilla says, your concept of "relative static" is just a bunch of optimisations that already exist to a certain degree, but which have nothing to do with being "static".

"Static" means that something doesn't move. Not "only moves a little bit" or "moves under something else", "doesn't move, at all". Like I said in my other post, if it moves at all relative to anything then the optimisations that come from being "static" can't apply. Other optimisations, like those described by zombiegorilla, can apply but have nothing to do with being "static".

 

I believe the word you're looking for is "dynamic".

 

Yes Unity does have a very limited Dynamic Batching Facility.

Dynamic Batching
Unity can automatically batch moving objects into the same draw call if they share the same material and fulfill other criteria. Dynamic batching is done automatically and does not require any additional effort on your side.

Tips:

• Batching dynamic objects has certain overhead per vertex, so batching is applied only to meshes containing less than 900 vertex attributes in total.
  • If your shader is using Vertex Position, Normal and single UV, then you can batch up to 300 verts; whereas if your shader is using Vertex Position, Normal, UV0, UV1 and Tangent, then only 180 verts.
  • Please note: attribute count limit might be changed in future
• Generally, objects should be using the same transform scale.
  • The exception is non-uniform scaled objects; if several objects all have different non-uniform scale then they can still be batched.
• Using different material instances - even if they are essentially the same - will make objects not batched together.
• Objects with lightmaps have additional renderer parameter: lightmap index and offset/scale into the lightmap. So generally dynamic lightmapped objects should point to exactly the same lightmap location to be batched.
• Multi-pass shaders will break batching. Almost all unity shaders supports several lights in forward rendering, effectively doing additional pass for them. The draw calls for “additional per-pixel lights” will not be batched.
• Objects that receive real-time shadows will not be batched.

But as indicated Dynamic batching is done within the rendering pipeline at runtime.

Relative static batching could be processed as part of the build allowing for much higher vertex limit and hopefully a reduction on the other restrictions.

As Unity 5 is moving to a Standard PBR shader would that not allow for more "disparate" materials to be combined dynamically or statically?

 

No no, what @Ryiah means is that "relative static" can only mean "dynamic". He was not talking about "dynamic batching", wherein the word "dynamic" actually refers to something quite different.

 

Think of it this way, an gameObject has child objects, you move the object, Unity updates the object and all of it's children, updating their transforms.

Now if that gameObject has static child objects then Unity only needs to update the objects transform as the static child components are 'baked' into the parent.

 

And the difference between baked and unbaked is what as far as internal calcs go? It is still along for the ride so to speak.

 

Baking into parent would mean you would not be able to access that transform any more. In short, it's not possible to do without combining meshes, if I'm understanding you correctly. Doing it on the fly would be interesting but niche case.

 

Not really it just means that if you do the 'baked' meshes would need to be re-baked which would create a performance overhead. An action that Unity should then issue a performance warning on!

 

So http://docs.unity3d.com/ScriptReference/Mesh.CombineMeshes.html or command buffers, then?

 

Pretty much but built into the engine, so should be a bit faster and no code needed.

 

Why wouldn't you just merge them before the game started? what scenarios do you see this being useful for?

 

Deja-vu. I think it's not the first time I see you suggest something that already exists in some way or is fairly trivial to do

 

This is pretty much 3d 101. If you need to optimize multiple child objects like that you just combine the meshes. This is completely unrelated to static gameobjects. How and when you combine them is up to you, depends on many factors.

So very true.
@Arowx , what might be much more helpful for you would be to just ask questions about things you don't understand. You keep making these suggestions for improvements or changes that are completely pointless because they exist, are impractical or you simply don't understand how that underling tech works. Instead just ask how something works. This process of blue skying uninformed ideas and having everyone explain to you why all your suppositions are incorrect cannot be effective or efficient.

You make an assumption and propose it as an idea, but it stacked on other assumptions. These discussions usually follow that same path, slowly unraveling the stack of false assumptions. Start at the beginning, rather than the end. For example:

These aren’t “limitations” or “restrictions”, these are just safe conditions under which dynamic batching happens automatically. The developer does more robust optimizations based on needs. Nothing is free, optimizations are trade-offs, if the automatic optimization was too sweeping or aggressive it could be doing things that make performance worse. And some of the conditions are just simply how rendering works.

No. Every part of that comment is based on incorrect assumptions. I would suggest first reading up on what exactly what the new Standard shader is doing, and how batching/rendering works.

 

Single word answer LEGO or User configurable components.

Think of the FPS with 5 barrel types, 10 sights, 5 magazines, 8 stocks and each player in multiplayer mode or NPC type wants to make their own you would have to pre-make 2000 guns.

Or an extreme example what about chunks of landscape in a minecraft style game, 16x16x128 cubes. 32,768 cubes ( or pre-built 1.415461031044954789001553027745e+9864 permutations.

@Ostwind + @zombiegorilla - Ease of Use.

1. Click the static button on the static sub components of a non static object (Tip click static on the root object choose, all children and then unselect choosing only this object. 4 clicks, maybe Unity could provide a relative static option).
or
1. Create a combiner script (1 click + Rename)
2. Drag in the the Mesh Combiner script (is it in any of the built in assets???) from the help screen. (1 click + search + select + drag and drop + tidy up)
3. Drag the script onto your object. (drag and drop)
4. Test that it works. (1 click yay Unity's Play button)

Maybe I am stupid but us stupid types like things easy, and I think Unity should too?!

 

No you don't. You have 28 models that have 4 types of parts. After user choses the parts he then clicks the button to verify that is the config they want and it uses a combine mesh function to create their version as a single mesh.

 

My understand of the new standard shader is that it allows a range of features for different materials, and dynamically builds it's shader code based on the chosen feature set for a material.

My idea is that a compound object using different components of the standard shader, e.g. bumped normals, specular and diffuse could be baked into a single material (or fewer materials) combining the features into a single texture. Therefore reducing the calculations when the object is moved and the draw calls needed.

 

Or you could simply create those individual parts as game objects that are attached to a parent object representing the weapon at runtime. This very concept is used within Borderlands.

Creating one game object for each individual cube is a very naive approach. Assuming your suggestion brought anything to the table, you'd still see worse performance than someone who created the mesh at runtime everytime the chunk needed to be updated.

It isn't as if Minecraft-style games are difficult to make or not understood. We even have a 50+ page thread discussing implementation details along with sample projects. I recommend reading it.

I prefer the term "naive". We've all been there at some time or another, but most of us actively make the attempt to move forward rather than continue to sit in our naivety.

 

I don't get it I come up with an idea that could make Unity easier to use, faster and better and the 'UCP'* turn up to troll my idea.



UCP - Unity Change Police - Here to ensure Unity does not change for the better.

 

Is this really going to be your line of reasoning every single time one of your ideas fails to gain traction? I fail to see how those disagreeing with your naive idea, as pointed out by multiple users, is automatically classified as trolling.

 

OK If we could have an official Unity decision or comment on my idea, I will take that as a definitive UT view.

Otherwise it's just your opinion vs my opinion and I think it's clear that instead of considering and discussing my ideas you and a couple other community members tend to jump in and stomp on them.

This behaviour has occurred multiple times now. @Ryiah @zombiegorilla @Ostwind

The easiest way to allow a topic to vanish is to ignore it, by confronting it on the forum you are keeping it afloat. Wouldn't it be easier to ignore the topics you disagree with and let them sink into the depths of forum obscurity.

Actually the Unity Forum has a People You Ignore feature, lets use it on each other, then I can occupy a forum without the UCP and you can occupy a forum without Arowx's crazy ideas.

 

Wow just tried it it works, it Blanks your comments Sweet! UT thank you UCP Bye Bye!

 

My experience with the Unity community over the time I've been active on these forums has been that they are very tolerant of suggestions made by users. That they are willing to humor someone who apparently doesn't understand the concept he is suggesting is a very good example of this.

I do have to chuckle a bit though at you pointing out the behavior of said community members when your own is to pretty much make any attempt at disagreement into a personal attack as if we are deliberately seeking you out.

I'm more than willing to have anyone in this community prove me wrong with any statement I make. I've had it happen before and I've tried my best to learn from those corrections.

 

What, was that, I can't hear you, your on my Ignore List.

 

Your post smells like trolling. Guess you will put me on your vaunted ignore list next..LOL..sissy.

 

UV mapping creates the single texture setup for the various shader channels. You may not need normals on one part and on another you need normals and emissive. That is what selection sets are for. To manually combine the various appropriate shaders as each model has different needs. The shaders are different and applied to each submesh selection. This is a standard routine and good workflow regardless of the package..3D or game engine work.

 

No one is "trolling" your "ideas". Everyone is simply explaining why don't work. Your "ideas" all come from a lack understanding how things work. That is why I suggest that you approach from a learning standpoint first. As it is now, you don't understand something, and rather than learn how it works, you suggest an "idea" on how Unity redesign things to so you better understand them. Or, you offer suggestions that are tantamount to magic. The shader example, for the reasons that @ippdev pointed and others, it just doesn't work like that, and certainly not at the shader level. Unity can't simply reinvent how rendering/video cards work.

You cant just automatically combine meshes, there is a CPU cost. The developer makes the call if that is needed and how it done. The API has methods for this, they are literally a couple of lines, but there are many ways to handle it. There simply is no need for some magic "combiner" script, there are too many options that make impractical to be a general use tool. Besides, anyone with the skill/knowledge to be optimizing mesh in first place will find it trivial and want the control. Alternately, you can just write your own script based on your needs. Unity is a game engine, and a powerful one. Spend less time trying justify them writing tools for things you don't understand, and more time learning what you are doing. Its not that people don't desire improvement, is that these "ideas" you have presented just don't have merit. There are ton things that Unity can improve that would have real value (or are actually possible)

 

Just thought I'd butt in with a solution to the example of navmeshing/pathfinding on a moving surface (that pirate ship that was mentioned).

You could bake a static, invisible version of the ship mesh somewhere in your scene, and have your agents navigate on that static version. Then you record their positions, and move/animate the rendered versions relative to your moving ship, thus allowing them to navigate on a "relative static mesh". Ofc, the ship mesh would have to be dynamic so that it can be lit correctly.

They used this to simplify the simulations in the opening sequence of Portal 2, where Chell is in that moving motel room-pod thing. But I feel that it would be too niche a requirement to be a core component of Unity, especially when you consider that there are much more requested that are not included by default.

 

Nice. This is a perfect example of reality of game development, creative solutions. You have what you have. As someone posed in another thread, game dev is often smoke and mirrors. You can either wish it was different, complain about something isn't to your liking and worry about features of your tools, or... you can build games.

 

Cheers! I'm glad I stumbled upon this thread, because a I can imagine a similar solution could be applied to creating a navmesh that allows agents to navigate on walls+ceilings (with a separate navemesh for each side of a room with off mesh links connecting them), a problem I've been thinking about for a while now, and wouldn't have thought of without this prompt. So thanks Arowx!