Optimize FPS in mmorpg OpenGL
Budget: $250 – $750 USD
Project Description:
I am looking for a skilled developer to optimize the FPS in our mmorpg game. There are specific areas in the game where the FPS drops significantly, and we need to address this issue. The target specifications for the game are low-end devices.
Ideal Skills and Experience:
- Strong experience in optimizing FPS in mmorpg games
- Proficiency in OpenGL and game development
- Knowledge of low-end device optimization techniques
- Ability to identify and fix performance bottlenecks
- Familiarity with profiling and debugging tools
- Excellent problem-solving and communication skills
The task to follow is the following:
My suggested solution is to use glDrawElements with client side buffers, and avoid glBegin/glEnd in RenderMesh().
As it is now, the unchanging vertices in Mesh get transformed by the Bones, and end up in VertexTransform.
Already there, you can remove glBegin/glEnd, and set glVertexAttribPointer to the right place in VertexTransform.
You also need the elements array for glDrawElements, but you can populate it by looping through Triangles and getting the vertex indices from there. I think that the elements should be unchanging so that could maybe be precomputed in Open2() already.
Drawing with glVertexAttribPointer at VertexTransform and the precomputed elements with glDrawElements, is how I got the performance increase, but with texture and ligting glithces.
For the color you can point glColorAttribPointer to LightingTransform.
The issue is that the texCoords, normals and vertices use different indexes.
So precompute a list of unique vertices. I did it by creating a typedef struct { short v, t, n; } and putting them all in a std::set. Then iterating over the set gives you just the unique combinations.
You can also make a map, that maps old indices to new ones. So when VertexTransform is getting calculated, at the last step, you can efficiently just copy that value to all the new places it also needs to be in.
When you have new lists of texture coordinates, adjusted VertexTrtansform and adjusted LightingTransform, so they all use the same indices, you can then draw them with glDrawElements.
Right at the end in RenderMesh there are a few special cases hardcoded that manually change the data. For them it might be ok to just fallback to the old glBegin/glEnd.
And there are a few things to keep in mind. Liek check if the color is constant, or if it should be fetched from LightingTrasform.
And the alpha value can possibly be set with glBlendColor and glBlendFunc so it doesn't have to be added to the array in LightingTransform.
That should hopefully give a noticable improvement.
If you wanted to go even further later on. Check what of that data is always constant and can be moved to an VBO (texture coordinates are constant).
And finally move the normals and vertices to an VBO too, and apply the bones and lighting in a shader.
That's it. As you see, the complexity quickly grows.
I am looking for a skilled developer to optimize the FPS in our mmorpg game. There are specific areas in the game where the FPS drops significantly, and we need to address this issue. The target specifications for the game are low-end devices.
Ideal Skills and Experience:
- Strong experience in optimizing FPS in mmorpg games
- Proficiency in OpenGL and game development
- Knowledge of low-end device optimization techniques
- Ability to identify and fix performance bottlenecks
- Familiarity with profiling and debugging tools
- Excellent problem-solving and communication skills
The task to follow is the following:
My suggested solution is to use glDrawElements with client side buffers, and avoid glBegin/glEnd in RenderMesh().
As it is now, the unchanging vertices in Mesh get transformed by the Bones, and end up in VertexTransform.
Already there, you can remove glBegin/glEnd, and set glVertexAttribPointer to the right place in VertexTransform.
You also need the elements array for glDrawElements, but you can populate it by looping through Triangles and getting the vertex indices from there. I think that the elements should be unchanging so that could maybe be precomputed in Open2() already.
Drawing with glVertexAttribPointer at VertexTransform and the precomputed elements with glDrawElements, is how I got the performance increase, but with texture and ligting glithces.
For the color you can point glColorAttribPointer to LightingTransform.
The issue is that the texCoords, normals and vertices use different indexes.
So precompute a list of unique vertices. I did it by creating a typedef struct { short v, t, n; } and putting them all in a std::set. Then iterating over the set gives you just the unique combinations.
You can also make a map, that maps old indices to new ones. So when VertexTransform is getting calculated, at the last step, you can efficiently just copy that value to all the new places it also needs to be in.
When you have new lists of texture coordinates, adjusted VertexTrtansform and adjusted LightingTransform, so they all use the same indices, you can then draw them with glDrawElements.
Right at the end in RenderMesh there are a few special cases hardcoded that manually change the data. For them it might be ok to just fallback to the old glBegin/glEnd.
And there are a few things to keep in mind. Liek check if the color is constant, or if it should be fetched from LightingTrasform.
And the alpha value can possibly be set with glBlendColor and glBlendFunc so it doesn't have to be added to the array in LightingTransform.
That should hopefully give a noticable improvement.
If you wanted to go even further later on. Check what of that data is always constant and can be moved to an VBO (texture coordinates are constant).
And finally move the normals and vertices to an VBO too, and apply the bones and lighting in a shader.
That's it. As you see, the complexity quickly grows.