Hi, Update on what I did. So after I made the IK script I realized there is no reason not to test both methods and see what does best. My 7 year old laptop was used as I am traveling at the moment.
Method: Made a small IK script and a Large IK script, then used the scripts to make a 2000 IK chain.
Large IK script: This uses a single script that uses an array to hold each object. The code then uses Index-1 to find the head and Index+1 to find the tail. It loops every Item in the list every Update() to solve the IK math.
Render Time: Averaging 54 FPS. || Memory: 211 MB
Small IK script: Using a very small script I allow each object to solve it's own math in it's own update(). It's script has a Public Gameobject for the head and tail that is hooked either manually or with a spawn script.
Render Time: Averaging 72 FPS || Memory: 416 MB
Amazing right? The small script actually rendered faster, the exact opposite of what I feared would happen. The down side is more memory.
The memory is mostly from Vectors and Quaternions, the small script causes every object to make there own variables where the large script re-uses it's variables.
What does 2000 IK chain look like?:
Is it really IK? Yes but only the very basics, I need it only for small animation purpose.
WAIT! Isn't the color adding to the memory? No, I added it after the test to make these images you see more interesting.
In the end I decided to go with small scripts, the extra memory is very small for a desktop PC and it's only 102 kb per object I add. Since my worst case is 12*24 it's only going to be 28.8 mb.
On 2/28/2018 at 1:01 AM, swiftcoder said:
I'm a fan of the small scripts approach from a cleanliness perspective.
This is one more bonus to doing it this way. Not only is it easy but it keeps everything in there own neat little class that is easy to use and read.
On 3/1/2018 at 12:00 AM, frob said:
In large projects there are often reasons to consolidate functionality. There are costs to iterate
This is correct. The costs of small scripts is accumulative.
Although 205 MB isn't a lot for a desktop PC, in a large game it can be what makes or breaks the game and this memory is often better used elsewhere. Also this was only the most basic of IK calculations if I added Polar and tension the memory costs would more than triple.
It looks like for complex and large games, using a large script would be better.
On 3/1/2018 at 6:34 AM, ddengster said:
I remember the developer for Yandere simulator had like 200 c# scripts in unity and was complaining that it took 2 hours to compile everything.
Ah, this was something my test could not reveal, thanks for pointing this out.
In my test I was just using the same script 2000 times, so no compile errors. It looks like a lot of different small scripts will lead to long compile times. Something to keep in mind as the game progresses.
16 hours ago, flodihn said:
For most games, this will not be an issue, imagine a game where you never have more than 20 or 50 enemies at a given time, the performance of those enemies will most likely not cause any trouble
And this is why I feel that small scripts is a fantastic way of doing things. In most games you won't have thousands of a script, only a few copies at a time.
16 hours ago, flodihn said:
but I think that if you do not define an Update or LateUpdate function in the script, Unity will not call (even a virtual) update function.
I did try this and it only worked with a inheritance. So each script must call it's Update() to update.
Although my test shows the large script was rendering slower, I think the For Each Loop is to blame, because I run it once every frame.
The time the loop takes to solve is added to the calculation and even if it's small it will be added each frame, resulting in a accumulative.
What I believe is: that if there was no loop and 2000 math problems where solved in 1 Update() call, it would have the same cost as running 1 math problem in 2000 updates.
In other words there is no extra cost to having more Update() calls.
