I have looked at jMe library for the first time and while browsing code to get a feel of it, I have noticed some issues. I decided to write them down. If I’m wrong at any point, please tell me, it will help me to get the grasp of inner library workings.
- LWJGL*State classes have a lot of instance variables with state mappings (jMe->LWJGL). Why they are instance instead of static ? It looks like a big waste of memory for each state instance (example LWJGLAlphaState.glSrcBlend)
- Md2Model inner classes are non-static. Why ? Outer class reference is not used anyway.
- In LWJGLRenderer, GL_NORMALIZE is always used. Maybe it would make sense to check if scale of model is different from 1 and enable it only then ? Or even better, implement none/GL_RESCALE_NORMAL/GL_NORMALIZE depending on scaling type ? AFAIK, GL_NORMALIZE is quite expensive operation.
- In FastMath, all coefficients should be moved to static variables outside methods - in other case, they will get allocated every time method is called.
- TriMesh looks a assymetrical to me. On one hand, it supports Vector2/3f/Color for vertices, with FloatBuffer for array access, on other, face indices are organized in plain int[]. Shouldn’t some kind of Face[] or TriangleIndices[] array be used ? Or make vertices reside in float[] ?
- Is there any reason for synchronization of deletedEdges in ClodCreator ? If not, then it might be better to use unsynchronized ArrayList
- LWJGLFragment/VertexProgramState load method is very… interesting. Creating new Byte for each byte of input is a really neat way of testing gc performance
ByteArrayOutputStream for temporary array would be a lot better choice IMHO.
- In Fragment/VertexProgramState, shouldn’t the constructor be new float[96][] instead of new float[96][4] ? Currently, all parameter entries will be initialized to float[4], which is a waste of memory, plus will cause unnecessary binding of 96 variables each call.
- It looks like almost everything implements Serializable. It would probably make sense to specify serialVersionUID for all serializable classes - without it, even compiling library in different environment an cause incompatible changes.
- Do you plan non-static VBO ? For some use cases (like particles) recreating entire buffer each frame looks like terrible waste. Is there some way in which updateable FloatBuffer for geometry could be exposed for DYNAMIC/STREAMING VBO ?