Is your feature request related to a problem? Please describe.
When you have too many entities on screen, your FPS will drop. This happens because draw calls are expensive in DX9. This issue must be resolved before implementing #869. It's related to #635.
Describe the solution you'd like
Any entity that is created more than once, we can use instancing. This solution is only applicable to entities which have the same materials. Let's say if you have a normal infernus and a modded infernus (different textures), then this solution cannot be applied to the modded entity.
I talked to Jusonex, he suggested that we can batch the vertex buffers of entities and use a texture atlas to reduce the draw calls. In my opinion, this is a perfect solution. It makes much more sense than instancing since we have given access to scripters to mod game entities.
Describe alternatives you've considered
Additionally, we can use a secondary thread for rendering. We'll have two kinds of meshes:
A non-static mesh gets updated every frame or frequently, and we'll need to keep 2 copies of the vertex buffer, this means there will be 3 vertex buffers for a non-static mesh which is being rendered. The memory will be freed if it's not in sight. Examples of a non-static mesh are vehicles, peds, animated objects, etc.
The 1st vertex buffer will be used by the main thread to update, the other will remain in the command list if update completes before the render thread, and the final one will be used by the render thread.
A static mesh is static, it's guaranteed to remain the same during run-time, so we'll have only 1 vertex buffer and no extra copies are needed. Majority of the entities in game are static, for example, trees, roads, buildings, interiors, houses, etc. So if we are using 3 vertex buffer for non-static meshes, it's okay because non-static meshes are few in numbers.
The render thread will wait for main thread to complete if it completes execution before the main thread. If the render thread takes more time to execute than main, then the main thread will update the second buffer for non-static animations and move on to the next frame, when the render thread is done executing it will copy the data from the second vertex buffer of dynamic entities to the 3rd vertex buffer and pass it to the draw call.
Additional context
Since I want to fix this problem using solution 2, we will need to write some code for creating a texture atlas of models. It's probably better to convert them by ourselves and instruct the players to download our custom gta3.img to save CPU time. It should be optional, of course. We can simply check the MD5 of gta3.img to see if it belongs to use or not.
Wouldn't there be a copyright issue with distributing a custom gta3.img?
Wouldn't there be a copyright issue with distributing a custom gta3.img?
I had the same thought. I think to avoid the copyright issue MTA must be able to convert the gta3.img and create the custom gta3.img on client side. Sadly, I'm not a law expert. I think someone should check for a way to avoid the copyright issue.
Wouldn't there be a copyright issue with distributing a custom gta3.img?
I don't know, but it's possible.
I had the same thought. I think to avoid the copyright issue MTA must be able to convert the gta3.img and create the custom gta3.img on client side.
Yeah, I was thinking the same thing. A custom gta3.img should be created on client side to avoid downloading.
Wouldn't the instancing perfect for things like trees, etc?
Wouldn't the instancing perfect for things like trees, etc?
Yeah, we'll use instancing wherever possible, but in most cases, we'll use batching as most objects are modded on servers nowadays.
The gta3.img can be downloaded on many websites, some are modded and some are original ones, honestly i dont think that R* gives anything about yet another floating gta3.img in the web.
But it would be a more secure solution to have a tool (or something) that can be downloaded and converts the gta3.img, if thats possible. I dont know what needs to be changed with that file.
>
But it would be a more secure solution to have a tool (or something) that can be downloaded and converts the gta3.img, if thats possible. I dont know what needs to be changed with that file.
Yeah, I'm working on it. MTA should generate the custom gta3.img like proxy_sa.exe.
Related to #1061
Most helpful comment
I had the same thought. I think to avoid the copyright issue MTA must be able to convert the gta3.img and create the custom gta3.img on client side. Sadly, I'm not a law expert. I think someone should check for a way to avoid the copyright issue.