Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

340 Neutral

About Trefall

  • Rank
  1. Trefall

    It's been a while...

    Glad I could be of some help Best of luck, it sounds like a cool project!
  2. When I woke up today, still exhausted, I shot a youtube video of the project, and we went down to the visualization lab at the uni, where we will defend our project on the exam tomorrow. It's a huge screen run by an nVidia workstation. That's approximately four meters wide, which is pretty epic to experience when you've worked so hard and so long on something! It ran smooth and with no problems, so I'm really excited for the exam tomorrow now! And though it might be a bit early to look back at how I've tackled this project, I still want to give that a try. First thing first though, the project's source code: http://code.google.com/p/ste6245physicsgame/ I started the project on January 16th. We had just come off a rather crazy start of the year, where I crunched in a big project on fluid mechanics visualization in a week with barely any sleep, so this project started a bit slow as I was recharging batteries. First off, the assignment required that we'd use Qt. I don't find it very suiting for game programming, but since it was a requirement, I had to run with it. I tried to use as little of the framework as possible, and thankfully the new 4.7.1 version supports creating an OpenGL3 context! This all took a while to figure out, and the guys at freenode (irc) #Qt and #OpenGL were awesome helping me out! On january 21st, I had the base application up and running with opengl rendering and updates flowing through my base game engine. The work on this game engine started about two years prior to starting my master's here at the university, but it's first now during these school projects, where we focus on one project for about a month and a half before we go to the next one, that I've been able to rapidly improve and refactor the engine for each new project. Always grinding in features at the end of each project, finding weaknesses in my API, thinking out possible solutions that I could use on the next project, etc. It's been a great learning experience, and the game engine has really grown into something that's pretty usable for smaller game projects. I then focused on getting AssImp in for loading meshes, and with it I found that I might as well incorporate DevIL as well for texture loading. Now things started to pick up. It was a lot of excitement getting these libraries working so fast (big thumbs up to AssImp for being such a simple API to work with!), and I quickly got to add in lighting and working on shaders. I never spent a great deal of time before making sure all my matrix and lighting calculations were handled correctly. But this time around i figured I might as well do it properly, because I knew I had some bugs in there. So, I fixed my normal matrix, turns out the you really have to only transpose over the 3x3 version of the modelview matrix for this to work! I then also did quite a few experiments in shader with using object space light shading and tangent space light shading, and ended up with tangent space, since all the normal maps loaded from textures were stored in this space... At the very end of january, I got this idea though, that I should really try to optimize my rendering. That is, I really wanted to improve on my OpenGL 3.3 spec correctness, remove redundant state changes, and overall lessen the number of calls to opengl. The idea that came to me was a material-driven rendering pipeline. If I sorted the entities by material, I would be able to bind shaders and textures for entire groups of entities, as well as bind uniform values like projection matrix, lighting, coloring,etc. Each entity type would then have a manager. It was in the manager that the VAO, VBO, IBO and all that mambo jambo was defined and loaded, while each entity instance of a type would only bind uniforms specific to itself, like the modelview matrix. The entity type manager idea was ideally set up for handling instanced rendering, but I never got around to it... A material was defined in XML, and here's an example material: 0.0,0.0,0.0 1.0,1.0,1.0 1.0 8.0 Mesh/FEROX_DI.tga Mesh/FEROX_AO.tga Mesh/FEROX_SP.tga Mesh/FEROX_BU.tga Mesh/FEROX_IL.tga Skybox/Nebulea.png mesh_default ferox Entity types in the engine was also defined in XML, and it was here that entities chose their material. A typical entity xml file would look something like this: Ferox Mesh Ferox InputThruster FileName Ferox/Ferox.3DS Position 0,0,-10 MaxThrust 40.0 ThrustAccel 3.0 This was very cool to work with during development. A lot of the time I was simply working over a compiled release-mode executable and tweaking values in xml files, shaders and Lua scripts. This was very efficient for progress, and also a great way to force the C++ engine to stay general and clean, while specialized code was in the resource files. However, I did find a great weakness in my Material-driven rendering pipeline design that I hadn't thought about. Transparent entities! I was rendering the scene by iterating over materials, and for each material, I rendered the entity types hooked up to it. How would I then sort back to front all transparent entities? Of course, I wouldn't be able to properly solve this without rewriting my pipeline, but at this point there was simply not enough time left... I had to let it go and be ok with the fact that I could only sort entities per material. I did sort the materials too based on the "weight" applied by the entities it owned with respect to distance from camera, but this was an ugly hack at best and only improved the blending mildly. Quite a few blending bugs is still present in the application today. In the end, I don't really regret my decision to try this design. Being a student and having a ton of projects like these is a great opportunity to experiment with ideas, and I learn a lot from each and every experiment and idea that I try to implement, fail or success. I will definitely never make this mistake again in an API A slightly cool thing I implemented, was the crosshair mechanic. I was trying to adapt the approach Starfox has, where the spaceship always follow the crosshair. I decided to render it as a sprite in worldspace instead of drawing it as a GUI element. This had some problems, especially the issue of ensuring that the crosshair never left the bounds of the screenspace. My solution was to convert the position to screenspace coordinates, then clamp it within the screen bounds, then convert it back to world space, and this worked very well CL_Vec3f IGuiMgr::clampToScreenSpace(const CL_Vec3f &pos) { CL_Mat4f modelMat = CL_Mat4f::identity(); modelMat[12] = pos.x; modelMat[13] = pos.y; modelMat[14] = pos.z; float w = (float)getWidth(); float h = (float)getHeight(); CL_Vec3f screenPos = coreMgr->getCam()->worldToScreen(pos, w, h); //-1 to 1 if(screenPos.x > w-2.0f) screenPos.x = w-2.0f; else if(screenPos.x < 2.0f) screenPos.x = 2.0f; if(screenPos.y > h-2.0f) screenPos.y = h-2.0f; else if(screenPos.y < 2.0f) screenPos.y = 2.0f; CL_Vec3f worldPos = coreMgr->getCam()->screenToWorld(screenPos, w, h); return worldPos; } CL_Vec3f Cam::worldToScreen(const CL_Vec3f &worldPos, const float &w, const float &h) { //Transformation vectors float fTempo[8]; //Modelview transform fTempo[0] = viewMatrix[0] * worldPos.x + viewMatrix[4] * worldPos.y + viewMatrix[8] * worldPos.z + viewMatrix[12]; //w is always 1 fTempo[1] = viewMatrix[1] * worldPos.x + viewMatrix[5] * worldPos.y + viewMatrix[9] * worldPos.z + viewMatrix[13]; fTempo[2] = viewMatrix[2] * worldPos.x + viewMatrix[6] * worldPos.y + viewMatrix[10] * worldPos.z + viewMatrix[14]; fTempo[3] = viewMatrix[3] * worldPos.x + viewMatrix[7] * worldPos.y + viewMatrix[11] * worldPos.z + viewMatrix[15]; //Projection transform, the final row of projection matrix is always [0 0 -1 0] //so we optimize for that. fTempo[4] = projMatrix[0] * fTempo[0] + projMatrix[4] * fTempo[1] + projMatrix[8] * fTempo[2] + projMatrix[12] * fTempo[3]; fTempo[5] = projMatrix[1] * fTempo[0] + projMatrix[5] * fTempo[1] + projMatrix[9] * fTempo[2] + projMatrix[13] * fTempo[3]; fTempo[6] = projMatrix[2] * fTempo[0] + projMatrix[6] * fTempo[1] + projMatrix[10] * fTempo[2] + projMatrix[14] * fTempo[3]; fTempo[7] = -fTempo[2]; //The result normalizes between -1 and 1 if(fTempo[7] == 0.0f) //The w value return CL_Vec2f(0.0f, 0.0f); fTempo[7] = 1.0/fTempo[7]; //Perspective division fTempo[4] *= fTempo[7]; fTempo[5] *= fTempo[7]; fTempo[6] *= fTempo[7]; //Window coordinates //Map x, y to range 0-1 CL_Vec3f screenPos; screenPos.x = (fTempo[4] * 0.5f + 0.5f) * w + 0.0f; screenPos.y = (fTempo[5] * 0.5f + 0.5f) * h + 0.0f; //This is only correct when glDepthRange(0.0, 1.0) screenPos.z = (1.0f + fTempo[6]) * 0.5f; //Between 0 and 1 return screenPos; } CL_Vec3f Cam::screenToWorld(const CL_Vec3f &screenPos, const float &w, const float &h) { CL_Vec4f in, out; //Calculation for inverting a matrix, compute projection x modelview CL_Mat4f mvpMat = viewMatrix * projMatrix; CL_Mat4f inv_mvpMat = CL_Mat4f::inverse(mvpMat); if(inv_mvpMat == CL_Mat4f::null()) return CL_Vec3f(0.0f, 0.0f, 0.0f); //Transformation of normalized coordinates between -1 and 1 in.x = 2.0f * (screenPos.x - 0.0f) / w - 1.0f; in.y = 2.0f * (screenPos.y - 0.0f) / h - 1.0f; in.z = 2.0f * screenPos.z - 1.0f; in.w = 1.0f; //Objects coordinates out = inv_mvpMat * in; if(out.w == 0.0f) return CL_Vec3f(0.0f, 0.0f, 0.0f); out.w = 1.0f / out.w; CL_Vec3f worldPos; worldPos.x = out.x * out.w; worldPos.y = out.y * out.w; worldPos.z = out.z * out.w; return worldPos; } The component system was a great asset to rapid development of game mechanics. All components were scripted, and could listen to events, or even bind itself to receiving updates every frame. At one point I did the optimization that a component had to register which events it was interested in, and would only receive events that it had registered itself to. The update function was slightly harder to limit however... The only optimization I could think of would be to move some of those components over to C++, but the game was performing well after the event optimization, so there was no real need for it. I spent a day trying to implement atmospheric scattering, but I couldn't do it. There's something magical about this shader that I haven't quite been able to weave yet. Guess I'm no arch wizard yet like Sean O'Neil At this point there were like four days till deadline. The only physics I had was a hacked together Lua scripted component I called RigidBody... I moved the logic into a C++ physics system, and also implemented angular physics. For a spherical shape, angular physics is really easy to implement... I never found the time though to try my hand at approximating the inertia tensor for a complex mesh, but I think that would've looked really cool with collision response when shooting asteroids! I also added a pretty bad particle system. It was a simple point cloud that was sent to shaders along with an attribute buffer or random directions. I would overload these random directions in the geometry shader via a uniform force direction vector. It worked "ok" for displaying dust clouds when shooting asteroids, but it was far from good enough to be used for things like engine flames, etc... Thus I didn't find time for that last bit... At one point towards the very end, my program suddenly started crashing in the Gui code. After some investigation, I found that I had gone beyond the number of supported shader programs! Thankfully I could solve this by implementing a shader manager that made sure that no duplications of shaders were made. This was in the last couple days before deadline though, and I had to spend a day on it all! This is definitely something I should have foreseen and implemented (for good api) long ago! On the last day I really had to work on my collision detection. The assignment clearly specified that we should have a very solid collision detection for spheres, to the point where we would have to look at all collisions occurring during a timestep, then sort the order of those collisions, calculate the response of the first collision pair and calculate physics up to the time of impact... we'd then have to run the collision detection again, to make sure that this new physical state wouldn't cause more collisions... if it did, we had to look for duplicates in the list of collisions already stored for the timestep and only keep those that occurred first... Potentially this could really damage the framerate, since very complex branches of collision could potentially occur during a timestep... As it turned out, with my implementation I didn't really have to worry about this at all... asteroids didn't spawn dense enough to cause mass-chain-reactions of collisions. Finally, I finished off the project by converting Bill Lowe's html /css gui design to libRocket's rml and rcss format. It didn't go as smoothly as I had hoped, but I got it up and working after a couple of tries. I then quickly, via script, bound some gameplay logic to these HUD elements. When you thrust the spaceship up to speed, the speed percentage hud element would respond with numbers complementing this. The gun got attached to the energy level, where each shot would drain a given amount of energy from the ship, and when energy got below the gun energy drain level, you couldn't shoot. For each frame, the energy level would slowly recharge. It was pretty cool to see that my scripting system was flexible enough to tie all this logic together with the HUD elements without touching a single line of C++ code! In the end I must say that it felt really good submitting the project three hours before the deadline. I could probably have added some more minor features and polish in that time, but I was simply too exhausted and tired at that point... and I really didn't want to introduce any misbehaving logic that close to the finish line! Now I'm very excited for the exam tomorrow and hope everything will go well! [media][/media]
  3. Finished three hours before deadline! But I can barely stay awake any longer... head hurts, eyes hurt... I think my body wants some sleep! I'll come with the full report and youtube video tomorrow!
  4. It's Saturday evening... deadline is in 36 hours! It will be a crazy run to the finish line if I want to finish in style! So, I figured out what the bug was that I experienced yesterday. Apparently, my GPU (2 x 8800 GTX M) doesn't support more than 64 shader programs, because when I tried to do glUseProgram(67), it failed with invalid value! This forced me to spend time now writing a proper shader manager, which I should have done ages ago anyway Basically it book-keeps shaders that's been loaded, preventing duplication of vertex, fragment and geometry shaders, plus shader programs. This solved the problem! Bill's html file didn't convert directly to libRocket's rml format, so I still have a little bit of work to do in that department, but I'll have to set up the priority list carefully for tomorrow... First, I'll riding the bus for 6.5 hours to my university (I study remote), then I'll have to spend a couple of hours focusing on the collision detection, this is a requirement if I want to land the best grade, so it's just stupid that I haven't focused on it earlier! I then have to also write a short report and land in some polish here and there... How well I'll finish will largely depend on how fast I can implement the collision detection! Wish me luck!
  5. A little late with this entry, but here we go! So, yesterday I stumbled into some problems that slowed me down... First, realistic mass calculation for rigid bodies proved to be very hard to control. I ended up with some asteroids that would go into a spin frenzy and fly away faaaaast! I would then have some other, bigger asteroids that wouldn't feel the impact of gun shots at all! Perhaps choosing that asteroids should be made of pure iron ore wasn't such a good idea but it was simply too difficult to control this beast. I ended up starting back at scratch, where everything had a mass of 1.0f. I then started tweaking a uniform asteroid value, until I landed on something that was ok to work with. 100.0f felt ok. I then added randomness to an asteroid's mass based on the random scale it gets when spawned, but with clamping control of the upper and lower limits. I got my control back, and the angular and linear physics reactions to collisions now feels good. Still an issue is the fact that I use an AABB vs AABB for collision detection, then I calculate the collision response based on a spheric shape (direction of impulse spawned by collision + offset position of collision)... With asteroid, that's neither "boxy" nor "spheric", this ends up looking a bit strange. I'd have to have some kind of convex collision shape to make this work realistically, but there's just no time for implementing such detection algorithms now! After I got physics to a stable place yesterday, I was going to quickly implement some UI elements into my libRocket-driven gui system that Bill had made. Well, I got the strangest crash, glGetUniformLocation returning -1 on me for no apparent reason. After some testing, I found that glGetError was returning 1281 on me... after some detective work I pinpointed the location to the previous UI element's render function, that tried to glUseProgram(67)... this was weird, because I could bind both uniforms and attributes to that shader program, and it had linked ok and everything... well, I didn't get any wise last night and went to sleep. Whether I managed to solve it, and todays efforts will come later this evening... but needless to say, I didn't get anywhere close to where I wanted to be yesterday... with simulator-level collision detection remaining on my TODO list, time is running out FAST!
  6. Today has been a slow day. I had got to the point where a good night sleep was more productive than hitting an early start for yet another day. The day didn't go quite as planned though, with some Real-Life emergencies occurring, but I did get some minor work in. I went over my physics calculations once more today and added in a density measure for each rigid body. I also added in a spheric volume calculation based on the radius found for each rigid body, plus I used this info to calculate each rigid body's mass. These calculations are in meters and kilograms, and I'm working through my code, making everything consistent. volume = (4.0f/3.0f) * M_PI * (radius*radius*radius); mass = density * volume; I then went and fixed my angular physics some. I had done it a bit wrong when I was adding in the angular velocity to the new orientation. So, in the end, here's how my physics calculation works (unless I find that I'm doing more things wrong, though I think this should be it): void PhysicsMgr::addTorque(IEntity *body, const CL_Vec3f &force, const CL_Vec3f &position) { for(unsigned int i = 0; i < bodies.size(); i++) { if(body->getId() == bodies->entity->getId()) { const CL_Vec3f &body_pos = body->GetProperty("Position").Get(); CL_Vec3f torque = CL_Vec3f::cross(position - body_pos, force); bodies->torques.push_back(torque); return; } } } void PhysicsMgr::update(float dt) { for(unsigned int i = 0; i < bodies.size(); i++) { CL_Vec3f P = bodies->position.Get(); CL_Vec3f V = bodies->velocity.Get(); CL_Vec3f L = bodies->angular_momentum.Get(); const CL_Mat3f &R = bodies->rotation_matrix.Get(); const CL_Mat3f &I_inverse = bodies->inertia_tensor; const float &M = bodies->mass.Get(); CL_Vec3f F = CL_Vec3f(0.0f, 0.0f, 0.0f); CL_Vec3f A; CL_Vec3f T = CL_Vec3f(0.0f, 0.0f, 0.0f); CL_Vec3f W; //Angular velocity bool updateLinearVel = false; if(bodies->impulses.size() > 0) { F = sumForces(bodies->impulses); bodies->impulses.clear(); updateLinearVel = true; } else { F = sumForces(bodies->forces); updateLinearVel = true; } bool updateTorque = false; if(bodies->torque_impulses.size() > 0) { T = sumForces(bodies->torque_impulses); bodies->torque_impulses.clear(); updateTorque = true; } else { T = sumForces(bodies->torques); updateTorque = true; } if(updateLinearVel) { A = F / M; V += A * dt; } P += V * dt; if(updateTorque) L += T * dt; CL_Mat3f iI = R * I_inverse * CL_Mat3f::transpose(R); W += iI * L; bodies->pitch = bodies->pitch.Get() + W.x * dt; bodies->yaw = bodies->yaw.Get() + W.y * dt; bodies->roll = bodies->roll.Get() + W.z * dt; bodies->velocity = V; bodies->position = P; bodies->angular_momentum = L; } } void Mesh::updateMatrix(float dt) { CL_Mat4f mat; CL_Quaternionf q; qPitch = CL_Quaternionf::axis_angle(CL_Angle(pitch.Get(), cl_radians), CL_Vec3f(1.0f, 0.0f, 0.0f)); qHeading = CL_Quaternionf::axis_angle(CL_Angle(yaw.Get(), cl_radians), CL_Vec3f(0.0f, 1.0f, 0.0f)); qRoll = CL_Quaternionf::axis_angle(CL_Angle(roll.Get(), cl_radians), CL_Vec3f(0.0f, 0.0f, 1.0f)); q = qPitch * qHeading * qRoll; rot = q.to_matrix(); mat = qPitch.to_matrix(); CL_Vec3f fwdDir; fwdDir.y = mat[9]; q = qHeading * qPitch * qRoll; mat = q.to_matrix(); fwdDir.x = mat[8]; fwdDir.z = mat[10]; leftDirection = CL_Vec3f::cross(fwdDir, upDirection); forwardDirection = fwdDir; } Right now, I think the mass and velocity at which my spacecraft shots fires at, is too much for the system... either that, or I have to increase the mass of my asteroids, because when I hit them, and add a force impulse and torque impulse, they start spinning like crazy Obviously there's some overhead in how I add forces to bodies, in that the entities themselves doesn't have the functionality for physics internally. Instead, at a collision for example, the two entities involved in the collision will be sent to the physics system through the AddImpulse and AddTorqueImpulse functions, with the force and center-of-mass offset position of the collision. So I have to look up the rigid body in the physics system before I can add the impact to the body's list of forces. This is still fast enough for the scope of my project for the exam though! Tomorrow I plan on getting up real early and have at it. I'm first going to stabilize my angular physics, so that hitting them won't send them in a mad spinning frenzy by adding correct masses for the bodies. Then, I'll have to look at my collision detection algorithm. We're expected to add simulator level collision detection between spheres. This means that if I detect a collision, I'll have to run the simulation again, and check that this change of events didn't impact any other objects (thus causing more collisions). I'll also have to make sure no collisions happen within the time-frame of delta-time. Simply checking for a collision at dt isn't enough... this doesn't sound like it will hold up in a game... I'm afraid that in a dense asteroid field, this will simply slow down the performance too much, so I'll make sure to add the ability to turn it off completely, and I also only plan on adding this level of collision detection / simulation to the closest body (determined by LOD threshold). Once this is in, it's all pollish left. Add some UI elements, get in some simple gameplay mechanics, etc I really hope that I can finish off the necessities tomorrow, so that on saturday and sunday I can focus on making it somewhat a game and not just a tech demo of shooting at asteroids without purpose! So, though I don't have any updates to show for today... in respect to what will follow on this project after the exam, here's some simple sketches made by the artist on this project, Bill Lowe!
  7. Today I actually managed to force myself into starting on physics right away! I ported my quick n' dirty RigidBody component, which was my entirely scripted physics logic, to C++. I also integrated angular physics. So today I feel like I've really been a good student for a change... Angular physics turned out to be rather simple to implement, well, for solid sphere anyway The inertia tensor for a solid sphere i symmetrical and follows the simple formula I = (2/5) * M * R^2 or in proper C++ code: float inertia = (2.0f/5.0f) * body->mass *body-> radius * body-> radius; body->inertia_tensor = CL_Mat3f::identity(); body->inertia_tensor[0] *= inertia; body->inertia_tensor[4] *= inertia; body->inertia_tensor[8] *= inertia; body->inertia_tensor.inverse(); I inverse at the end there, since it's only the inverse we use during calculations. But, of course, the response from asteroids when I shoot them, when the mass distribution acts as though it's a solid sphere, isn't realistic. It's a lot better than nothing for a class that focus on physics and collision detection/response in game/simulator development, but it's not sufficient to achieve anywhere near believable angular behavior when I shoot at my asteroids. I guess I'll have to go ahead and calculate a tetrahedron-based inertia tensor from the mesh. I also fixed some long-time bugs I had laying around from some old experiments in my shaders. They now calculate stuff in tangent-space, like they should due to tangent-space bumpmap textures, and I fixed my specular calculation. Tomorrow I'll have to work on collision detection with "simulator" precision, plus look at doing engine flame particle effect.
  8. Atmospheric Scattering is really difficult
  9. I wonder how this got into my head... but I woke up this morning thinking it was a great idea to attempt Sean O'Neil's Atmospheric Scattering implementation for my planet, when there was six days till deadline! As if my bloom filter implementation yesterday wasn't bad enough... will I ever learn??? So I started the day by adding a new C++ mesh entity type I called Atmosphere. The shader needs so many variables this was the easiest way to do it. So I set up the variables, exposed to both property layer (lua scripts, xml) and the uniforms sent to shader. I added a component that allowed me to alter the variables during runtime. Well, as I seem to remember, the atmospheric scattering algorithm is really fragile where you really have to hit just the right variable combination in order to achieve the color scattering result you want... My planet is also moving with the player, so O'Neil's shader that expects the planet to be in origo had to go through some minor modifications... In the end, I didn't manage to get it working today... After quite a few hours of variable tweaking and shader experiments with the famous shader variable to color debugging, trying to achieve my goal, I gave up on getting it to work... so I started to focus more on using some of the variables to achieve "some" form of scattering Well, for a long day of work, the end result is laughable... and I really felt like I wasted an entire day on this. Tomorrow I will most definitely get started on more physics/collision related stuff, as that's very important on the exam. One can't always come out on top...
  10. Trefall

    Space-Shooter project, six days to go

    Thanks a lot for the encouragement Aardvajk! Appreciate it
  11. Ok, so... starting a full post-process system implementation when there's only seven days till deadline might not have been the smartest move I've made... Well, at least I knew that when I started, guess I don't take no for an answer! If nothing else, I resisted the urge of creating a new PostProcess XML format that would make the definition of post processes more data-driven... though, I did integrate it fully with my Entity and Material XML format That was kind of cool, because it allowed me to integrate it "rather" fast without too many hacks... well, without enormous amounts of hacks at least... so now my Materials support definition of "generated" textures and one can define them as RTT materials. Further, one can set which order the material should get in the MaterialManager's list of RTT materials... because, of course, when you're rendering a RTT texture attached to a fullscreen quad, that has to go through my Material system... Though it did take a while longer to implement than I thought, it wasn't too bad to wrap my head around... though I do see that I have some refactoring to do on my design once the exam is over So, behold! I expected my scene to turn up with a really nice bloom post-process filter... I really, really love it when OpenGL throws these things at me... the rendering "kind of works"... but not really So, I fired up gDEBugger, my friend in need when I bump into rendering issues (and it sports a free license at the moment!!!). It told me I was making some redundant and deprecated calls in my FBO code for the post processing, but fixing those up didn't really change anything... so gDEBugger didn't really offer me much support... so, I found that maybe it was a good idea to check the status of the FBOs after I created them! Finally some progress! The status check was throwing GL_FRAMEBUFFER_UNSUPPORTED at me. A quick google of the web lead me to OpenGL.org's Common Mistakes wiki page, which states the following under it's Render To Texture section: [quote] [font="sans-serif"][size="2"]Warning: NVIDIA's OpenGL driver has a known issue with using incomplete textures. If the texture is not texture complete, the FBO itself will be considered GL_FRAMEBUFFER_UNSUPPORTED, or will have GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. This is a driver bug, as the OpenGL specification does not allow implementations to return either of these values simply because a texture is not yet complete. Until this is resolved in NVIDIA's drivers, it is advised to make sure that all textures have mipmap levels, and that all glTexParameteri values are properly set up for the format of the texture. For example, integral textures are not complete if the mag and min filters have any LINEAR fields.[/font] [/quote] Fair enough, so I fixed my issues. I was indeed using LINEAR filtering for my FBO textures, that, when I think about it, doesn't make much sense when you're rendering to a screen sized texture that will only get rendered on a screen sized quad later I also added mipmapping (though not sure if that was really required)... and, magic! It works! "Just" one of seven days wasted on a Bloom post-process filter!!! That's pretty amazing waste of time here at the very end... oh well, at least I can show off some sparkling sun reflection on that spaceship metal hull now! That ought to count for something!
  12. Trefall

    Space-Shooter project, seven days to go

    Thank you There's obviously still a lot more work to be done on this. Lighting lacks a ton, the planet texture looks very boring and flat, no shadows on the asteroids, spaceship looks flat too, not enough filler (asteroid clutter) and other misc effects. Hopefully I'll be able to improve on these details, and still land robustly on the school's focus on simulator-physics/collision-detection!
  13. I started today by adding event subscription for components, so now all my scripted components subscribe to the events they need, and thus components (both C++ and Lua scripted) will only get event calls when an event they have subscribed to occurs. This had a very good impact on performance! I then started on some design thinking. I know I should have focused on optimizing collisions and adding more advanced collision detection routines, but I got inspired, so what can I do So, the idea is that the scene must have a huge planet in the distance. You're flying through it's asteroid belt. The tunnel walls should hold textures that creates an illusion of a vast asteroid belt, and then I'll spawn asteroid sprites ahead of the camera that fly by (but can't be collided with) + the fully fledged 3D mesh asteroids that will spawn in your path, that you can shoot and collide with and have to navigate around. Then, I started implementing a planet. That went fast. I just had to create a new Material XML for it, a new Entity XML, and a specialized fragment shader, and I could add it in the scene initialization script. To create an illusion of scale, but without killing my depth buffer, I added a component to it that maintains the Z distance to my spaceship, thus no matter how fast my spaceship moves, I'll never get closer to the planet... I really felt this illusion worked. Next, I kind of felt that I needed to add a sun to the scene... it's a cool thing to have after all So I hacked a sprite from the net, and in it's shader (geometry and fragment) I added a distortion animation to it's texcoord lookup, making the sun appear as though it's wrought in fire. The sinus behavior is still a bit obvious, but it's better than just a static sprite image... but then I though... man, this would look so much more awesome if I had bloom post process filtering! ... so I started on a Post Process system... and I'm still working on it Man, I suck at staying true to my priority list!
  14. After ending my coding late yesterday, I overslept this morning and didn't get up until eleven. That really hurt, because I had to work at the grocery store from one pm, and then it's a saturday evening, so I want to spend that socially with my wife. As such, I only got in an hour or so of work today! I figured there was no point on starting a quad-tree implementation, so I went through the code and did some smaller optimizations. One trick I stumbled upon by accident recently was doing erasing from std vectors like this: //O(1) removal list = list.back(); list.pop_back(); I also have some Lua components now that subscribe to OnUpdate(), thus each of those components, for each instance of them, will require a transition between C++ and Lua. I suspect there's more overhead to this than my game really should like... so it might soon be time to move some of those components over to C++ code. Also, currently, components don't "subscribe" to events. If a scripted component has an OnEvent function declared, it will receive all events sent to it's entity via C++... Most components only care about a single specific event, maybe two... so needless to say, there's a lot of overhead here as well! I should really exchange this for a subscription-based event handling, so that the component's OnEvent function is only called when an event occurs that the component is going to use. Tomorrow should be more productive
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!