So, Project assignment is due on monday morning 8:30 GMT+1 on the 28th of february, with the exam following the immediate day, on 1st of march.
Today I worked in a somewhat working transparency order for my non-opaque entities, I fixed my shooter entity, so that it would shoot correctly down the spaceship's forward direction vector, and I got well on my way with the particle system. I ended up with particle emitters that spawns where a collision occurs between two entities. It's up to the entities to respond to the collision via components (a Collision event is sent to both entities). It takes the collision impact direction into account, to generate realistic looking dust-clouds depending on where on an asteroid you shoot for instance... though this may look a bit weird when asteroids start to collide. I'll fix those things as I bump into them. Also went over some smaller issues as well that's not really worth mentioning.
Major problem of today was really the transparency sorting. The problem is, that I have ordered my rendering based on materials. That is, I define materials in XML (holds texture, shader, etc definitions). An entity registers itself with a material type (in the entity XML definition)... thus, my entire scene is rendered from a list of materials. This is good at first look, because I can now bind the shader and textures only once per material type, as well as all shared uniforms (like lighting, and specific material properties). I then sort each entity type under those materials in a manager. The manager holds the render data of the entity type, while the entity instance holds it's per-instance uniform information (at current time I'm not using UBO or TBO with glDrawElementsInstanced). Using the manager, I can bind the VAO only once for each entity type, and then in a for loop, I bind uniforms per entity instance and draw based on glDrawElements.
The obvious problem occurs when I need to start sorting entities based on distance to camera (back to front), like you want to do with transparent entities to get proper alpha blending. I ended up with a hack. I will simply not have the time to rewrite my rendering pipeline to solve this issue properly. So, I ended up with the solution, that every entity type manager will calculate the average distance to camera for it's entities, and send that to it's material. The material then calculates the average weight it has received from it's entity types, and cast it to unsigned int. I then sort all transparent materials (which is in a separate list from opaque materials) based on this weight. Greater weight equals further from camera. This works fairly well for the average particle emitter, since it's particles will stay more or less around the same position... but with shooting, where one sprite can be close to the camera, and another can be far, far away (just before being culled/garbaged for reuse), the issue can quickly become quite apparent... especially when you have a sprite in between called the Crosshair, which the bullets are supposed to travel through! I think this issue will be ok enough if I just draw the crosshair using some simple mesh instead of a sprite... The internal sorting of entities within an entity type manager, and the sorting of vertex positions per particle emitter for instance, is easier to handle
Experiments and "good ideas" don't always end up like you expect
In fact, they hardly ever do.... at the first (and second, and third, etc...) try anyway Tomorrow I'll be working more on collisions. I need to get a spatial sorting of the collision bodies in place, because right now the brute-force collision detection is sucking CPU and FPS! Then we'll see... it stands between adding collision testing with discreet steps (ensuring a simulator level collision accuracy for the bounding objects used for testing collision (AABB or Sphere is what I'm using so far)), and working on some particle effects, like the spaceship engine flames, another spaceship gun type, plasma-bomb collision impact particle emitter, etc... guess the first one is more important right now, so I should probably stick to that... though doings things in the "correct" order isn't always the most fun!
