Hi all,
I am new to game development, but I like it very much as a hobby. I like learning by doing and solving hurdles on the way.
I am prototyping a VR game for the Oculus Go, so high requirements for min 60fps in stereo, on a very modest hardware. Here is a very early version of my prototype from August last year
I stopped developing for 4-5 months, but since 2-3 weeks I am back on the project. My main goal now is to optimise the game to run on very large grids.
As you can see, the game consists of a large amount of “nodes” and “links” between them that are procedurally generated each time you start a new game. You will find a summary of the game logic at the end of this post.
I have taken down the drawcalls to a very low number, because I use Graphics.DrawMeshInstanced for the “links” and Renderer.SetPropertyBlock for changing the color of the “nodes”. The Text Mesh Pro elements also batch well, apparently.
For a grid of 1093 “nodes” and 3-4 times more “links”, the Stats window shows 22 batches and 4782 saved by batching: https://i.imgur.com/NRROtd2.jpg
The Stats window shows 229 fps, but that is on my PC.
In the Oculus Go initially, when the Text Mesh Pro components are not enabled, things look OK at 60 fps
However, once the Text Mesh Pro elements show up too, the framerate drops to around 50 fps (on a monitor that’s not bad, but in VR it creates stuttering):
It is even worse when I rotate the camera around the grid, at 40 fps it is simply unacceptable as a VR experience:
I guess that the framerate drop is due to many GameObjects being drawn at the same time (that is 1093 icospheres and 1093 GameObjects with a Text Mesh Pro component). I think it gets even worse when I rotate the camera around the grid, because I have a method that goes through the array of transforms for each GameObject that has a Text Mesh Pro component and orients it towards the camera. It looks like that:
void OrientNodes(){
Vector3 camPos=camContainer.position;
Vector3 camUp=camContainer.up;
for (int i = 0; i < allLvlArrayNum; i++) {
AllLvlArrayCenter [i].LookAt (camPos, camUp);
}
}
So I think I am out of ideas as to how to increase the performance with the classic Unity framework. Am I right in my assumption?
I read a little about ECS/DOTS and watched this introduction by Mike Geig
, but did not understand all of it. So, having looked at this scenario and the summary of the game logic below, do you think ECS/DOTS could be a solution for my performance problems? If so, where can I start from? How do I even plan what part will be in ECS/DOTS and how to combine the two parts? Does ECS/DOTS even support sphere colliders and does it interact with the Unity physics raycasting (I use raycasts for selecting and operating on the “nodes”)? I guess there is no “one-click” conversion to DOTS (I wish there was), but I would prefer to get the full (potential?) benefits without too much change.
Thanks in advance to all. I realise it is a long post, but I needed to explain how things work in order to give you a better idea what issues I am facing.
Summary of the game logic:
I wrote my own very simple instanced shaders that support an instanced color, simple diffuse effect, vertice collapse (for disabling the rendering when I change the alpha of the material to 0) and recently (as an option in some of the shaders) dimming based on the distance from the camera.
The “links” between the nodes are not GameObjects and I render them in batches of 1024 with instanced rendering Graphics.DrawMeshInstanced from the script.
The nodes are simple icospheres that I created in Blender. The nodes also use an instanced material with instanced color, simple diffuse effect, etc. The “nodes”, however, are GameObjects that I instantiate at the start of each game, because they have a sphere collider that enables me to interact with them (select, open, mark as mine, etc.). Each “node” also has an empty child object (“center”) at the center of each node and a Text Mesh Pro element as a child object of the “center” that is offset towards the front of the icosphere. That enables me to rotate the Text Mesh Pro element to always face the camera when you are moving around the grid, while the parent icosphere does not rotate.
I am running all the game logic on a main GameManager.cs script and apart from the procedural generation of the grid, which happens only at the start of the game, the code is not that heavy, I think. The only heavy part might be the constant reorientation of all “nodes” towards the camera when you rotate the camera around the grid.
While creating the grid, I keep a number of 1 or 2-dimensional arrays. Most of the arrays consist of integers that describe the structure of the grid, i.e. how many “links” each “node” has, to which other “nodes” does each “node” link, how many adjacent “mine-nodes” each “node” has and then from the perspective of each “link”, which 2 “nodes” that “link” connects to. I keep an array with the the Vector3 position of each “node”. For the instanced rendering of the “links”, I keep 2 arrays of Vector3 (for the position and localscale) and 1 array of Quaternions (for the rotation). I also have some bool arrays that contain the state of each node (is it selected or not, is it a mine or not, is it already revealed or not, does it show text or not etc.). I also have arrays of the transforms of the “nodes”, of the “centers” and an array of the Text Mesh Pro elements.
