I’ve written a reply: Hey i don’t understand this managed update concept. If i have 50 gameobjects with a script component that has update() function and inside the update it accesses gameobject position for example. In this case the gameobject position is unique to each gameobject. I need to have 50 update() calls, 1 for each gameobject. How do I implement an approach where i have only 1 update() in some manager and can access gameobject position of all objects??? i don’t understand how i would do this properly? Would i have to keep all 50 gameobjects in an array and access their positions in a loop and then pass data back into the gameobject? Is this better than having 50 update() funtions? seems like im just moving calculations from 50 script instances into 1 script instance but also increasing calls between scripts.
Can someone make a tutorial or something showing how this works in practice?
And if your script doesn’t have an ‘Update’, don’t put an ‘Update’ function in it.
That blog post is getting into some design ideas that your higher level programmers would find more comfortable because the ‘magic’ aspect of unity reflecting out your update method to determine if it needs to be updated just feels dirty to some programmers. And yeah, technically you can eek out a little extra oomph from the system if you went with there single update manager.
The thing is you lose a lot as well… they leave out, or only tangentially touch on, the fact that the update method in each script takes ever so slightly longer to be called because unity has a lot of protective code around that update call allowing for easier debugging, profiling, and the sort.
If you don’t understand what they’re doing in that blog, you’re just going to shoot yourself in the foot. Go with what is supported and documented by unity. Premature optimization like this is just a bad idea. There are much better places to optimize your game then this if you’re truly having framerate issues.
Sorry, my mistake, totally didn’t see your link somehow. But yea if you already read that one, there’s nothing more but saying most of it would be premature optimization.
Yes. And that’s whooping 200 bytes!!! (+array overhead like 8 bytes maybe? Most likely more)
No. It’s same (± several nanosec you won’t notice). On object count larger than 10000 I’d think. But Unity won’t handle that much anyway in other places like rendering or physics.
It won’t help you at all.
Last time I tried rendering 10000 objects that don’t do anything(no Update() calls or whatever), I got horrible 20 FPS… So you would need to rearchitecture solution anyway.
P.S. I forgot to mention profiling features: each method call comes with profiling overhead(especially in deep profile like on screenshots in article) so you’re seeing overheads in profiler that aren’t happening in real life with non-debug version.
You want 10000 audio sources? Or 10000 of what exactly that requires them to be Unity based then? It’s either physics or rendering or bones(+IK targets for bones or any other Transform uses like guiding something) - there’s no other reason for them to be GameObjects which clutter Editor object list. Not only editor’s object list will stutter, but also you will have a lot of unnecessary Transform allocations where they’re not used.
If every one of them is rendering in camera view at same time (none are culled) it will drop FPS considerably. Especially on mobile systems/intel GPUs or old PCs. Even camera culling requires operations and on mobile systems you want to reduce that as much as possible. Also don’t forget it tries to dynamically batch, which requires quite a bit of resources. But having 10k active objects at same time means you have game architecture problems already.
I’m a bit confused by your replies. Your response kind of implies that you need a gameobject per script.
A complex player, NPC or other kind of complex system designed with Unity’s usual component based approach in mind may have lots of scripts, if you properly or even extremely take care of single responsibility principles, then it’s not unlikely that you’ll be having even more.
That alone may lead to thousands of script instances with only a tenth or less GOs, many of them don’t even need to be visible because they’re position references, manager, and all that stuff that you usually don’t see. So you can’t just put this discussion aside like “it may have influence, but you won’t be able to have that amount of GOs anyway so just don’t care about it”. That’s at least what it sounded like.
You can have 10 scripts per GameObject, it’s still thousands of times less than what’ll be noticable. Only difference between calling methods yourself and calling Update() from Unity’s code is some checks as stated in blog link, so change won’t be noticable before millions of calls per frame anyway - and that much calls require different solution anyway. OP is talking 50. What is 50 against millions?
Because there’s not 10.000 objects in list so Editor won’t be slow. Besides, they don’t have anything but Transform and don’t have any scripts that receive Update() calls. So why would anything be different? Also, I’ve mentioned half of that use-case:
So what are you showing? Behaviours packed into GameObject tree? I’ve seen better solutions and that’s still not 10.000 GameObjects.
There’s all sorts of things from Rigidbodies, to Colliders, to custom scripts of mine…
Which honestly was my point. That Renderers aren’t the only thing that might be on GameObjects.
And the thing is we could have MANY of these in our scene. This is a single brain. I’ve put 20 of them in the scene, wandering around, reacting to their stats. Hardly any slow down.
And yes, many of the scripts do have Update calls, because they need them to track stats.
I can’t show ALL the scripts because that’d require too many screencaps (or a video), so here’s just one of them. Note the scroll bar… my 2560x1600 screen isn’t even tall enough to show all the scripts on them.
Update() call itself takes almost nothing. What are you trying to say?
Because I’m saying you will run into other issues first (like rendering or physics, in this context), and Update() performance only with really, really bad architecture.
P.S. Duplicating behaviour tree for each NPC is inefficient in itself, so it kinda proves my point further?
Lol, I love that you cut off the 3rd part of those comma separated things… custom scripts.
As well as the picture I posted containing no physics things.
What I’m trying to say is that you claimed 10,000 GameObjects in a scene would slow the game to 20fps or less, because of all those renderers. And I refute this by saying you might have many gameobjects with out renderers.
I agree, that’s why my original post said to ignore the blog in general, as if optimization issues become an issue. There’s better places to look than if you uses ‘Update’ vs and ‘single Update Manager’.
This proves your point that renderers are slow? I don’t see how that proves your point.
And it isn’t inefficient… they work just fine, no slow down.
Not sure how duplicating the behavoiur tree is that inefficient if each behaviour tree is stateful and has its own uniqueness.
Or are you going to figure out from just a few screen shots how inefficient my game is… despite the framerate constantly being shown in the several hundreds. ???
Here’s the nice thing about my BT design… I can have unique BT’s per entity. Or share BT’s amongst entities.
You seem to be thinking my argument is about ‘Update’. My argument is about your claim that 10K objects equates to 10k renderers. Which it does not. But alas you like to keep moving the goal post around and ramble on about other things… back on subject here. 10k go’s does not mean 10k renderers.
Custom scripts can only be slow if they do something in loop or regularily (Update() and such or Coroutine). And that’s exactly what we’re talking in topic about, no? That’s why I left them out from that quote.
And will it be slow? If those objects do nothing on per-frame basis, only editor’s list of objects will be slow when it needs to show all of them. And we’re in Topic about Update() calls so I assume they do something on per-frame basis, so they have at least one Component with Update() or renderer or physics or such.
No slow down yet doesn’t mean it’s efficient… At least you’re doing about 50 extra small allocations(each transform is extra allocation you don’t really need) on instantiate so instantiating 100 of them in one frame won’t work nice. Also moving object behaviour tree is parented to will move all Transforms inside which does nothing visually in your case, but requires extra operations.
Test performance on thousands on NPCs first. Most I’ve pushed out was about 2500 of my NPC’s AIs on core i7 CPU(=~1200 on AMD A8-5600K). And I consider it badly-written. Can you make more without slowdown? Then I’ll admit you’ve made an efficient monster. I can make extremely inefficient 100 NPCs that won’t drop down FPS, but at least I won’t claim they’re efficient. And yes, I understand that you might never need this much and thus it’s not efficient. Just don’t claim it is when it’s not.
So wait, you’re arguing that 10k objects would be slow, because of 10k renderers.
BUT, they would also be slow if 10k udpates in the 10k objects as well?
I’m totally lost as to what you’re even saying here. So… whatever… sure.
OK… so more memory is taking up. Memory increase doesn’t mean it’ll slow down the game.
Sure the initial load might be slower.
And, if I’m SHARING the BT, I don’t have to reparent it. If it’s unique to an entity, it’s parented once… at load. If it’s shared, it remains separate from each entity that shares it. Not understanding your point about this…
Depends on how I structure it. When sharing BT’s, it’s plenty fast. If I made thousands of unique BT’s it’d probably be a little slower.
In the same respect, I don’t NEED thousands. Just because something could be more efficient, doesn’t mean mine is inefficient. There’s trade offs to design… this one being simple for my designers to work with, so I don’t have to muck about with them.
I mean really dude… are you so annoyed that I refuted that 10k gameobejcts doesn’t mean 10k renderers, that you just decide to smear my programming skills with little to no knowledge of how they work beyond a simple screen shot of the editor?
Pfff… that’s pathetic of you. You’re arguing has devolved to what essentially is name calling. No longer entertained by your ramblings that result in goal post moving and name calling. You have a wonderful night.
Yes, that’s what I’m saying. So why care about Update calls?
Then there won’t be ever even 10.000 GameObjects with Update, not to mention we need at least 100 times more for Update() calls to become a real problem so what are you showing then using those pictures?
I really don’t understand why you posted those huge pictures showing nothing.
