MovingBlocks/Terasology — pull request #659 by Xanhou (2013-07-18 21:22:35+00:00)
Title: Framerate stabilization (during railgun use), minor performance boost and various improvements/additions

If required I can try to make separate pull requests for the separate changes.

Changes and additions:
- 1. Added netbeans files to .gitignore
- 2. Added a class that sort entities based on their distance to the player. It does so in a background thread.
- 3. Added above class to MeshRenderer and BlockParticleEmitterSystem. Currently the maximum number of entities to be drawn is set to 20 for opaque, 20 for gelatious and 10 for particle effects.
- 4. Added javadoc in various classes.
- 5. Added example usage to javadoc of EntityRef.getComponent
- 6. Added a new getter to the LocalPlayer class for the position
- 7. Added a minor optimization technique to GLSLShaderProgramInstance
- 8. Changes the TIntIntMap for the uniform in GLSLShaderProgramInstance to a HashMap
- 9. Added a debugging key (the ; key) to switch between rendering the nearest entities only or rendering all entities to show the major differance between the two.

Motivations:
- 1. I use netbeans ant don't want you guys to have all my netbeans project files. This also makes it a little easier for people to set up the project for netbeans.
- 2. Many entities to draw causes lag spikes. Drawing the first X entities may cause nearby entities to disapear in favor for far away entities. Hence sorting is needed to set a limit to the amount of entities to be drawn. The main goal of this commit is therefore framerate stabilization.
Because the sorting happens in the backgrond, there are not guarantees on the sortedness of the entities returned by the new class. However, it does guarantee a stable performance.
- 3. The MeshRenderer and BlockParticleEmitterSystem are the two renderer classes that cause half of the lag when spamming the railgun. By limiting the amount of entities to draw for these classes the framerate is much better when spamming the railgun.
- 4. Javadoc can never hurt, unless it is lying about the implementation.
- 5. For most hobbist, a method like EntityRef.getComponent is not normal. Although the method is easy to understand, a simple example helps a lot.
- 6. The existing getter forces the creation of a new vector. This version saves a little bit a memory.
- 7. Previously for every entity each float constant of a shader would be set again. Now this constant is not set again if it did not change. Simple tests have shown me that the performance boost is a small but relevant one. Especially because the new HashMap only needs to contain about 13 elements at the moment. This number might become a little higher in the future but does not grow to a significant size.
- 8. There are two reasons for this. The first: Although before hashing the uniforms they are all unique, it does not guarantee that after hashing they are too! The build in java HashMap solves this issue, but the TIntIntMap does not. While the chance of ever seeing this bug is near zero, it can happen and therefore will happen. The performance and memory gain for using a special map are near zero since the maximum amount of elements in this map so far is only 13! This number may grow a little but will never explode. The second: The TIntIntMap return 0 when no value is in the map. But 0 is a valid uniform location and hence should be interpreted as a valid uniform location. Hence the current version uses less openGL calls.
- 9. Usefull for testing the differance between the orginal and current performance and looks.

Possible improvements:
- Make the sorting process discard any invisible objects (objects ouside the perspective view of the player). This will cause more objects to be on screen but may cause nearby objects to pop-up out of nowhere when quickly turning around.
- Allow user defined maximum values for the amount of entities to be drawn.
- Change the ; key to a text command or allow the user to change the key. (Added as TODO)

Side note:
With these changes the post-processing and physics are the biggest causes of low fps. Post-processing can be turned-off, but physics cannot. Well I guess you cannot simulate a nuclear explosion in TS (where all removed blocks become dropped and added to the physics engine).