Interim Report
Critical Points
XBox Portation
Currently, our Game does not work on the XBox, since we use techniques not available on this platform (eg. Shader Instancing). We will try to port the code as soon as it reaches a more or less stable state, otherwise we need to develop two lines in parallel.Terraforming on GPU
One of the critical points, also tightly related to the XBox portation, is the terrain generation on the GPU. We expect the CPU of the XBox to perform poorly when doing the diffusion on the CPU, since we use floating point values. A workaround for this problem could be to shift it to the GPU. This is not an easy task and also the GPU is not so well suited for our kind of diffusion, where only small parts change. The XBox has only one physical render target, so we must copy around the whole map at all times.Major Changes
Gameplay
Due to the critiques we received for our prototypes, we decided to change the gameplay. We came up with a few alternative gameplay scenarios. We decided to use the Egby (spoken similar to Rugby: igbi) described next:Egby Mode
Welcome to the Inter-Elemental Elympiade on planet E-Topia. Todays sport is Egby, a ball game with two to four teams. The task is to score points by hitting the energy-portals with the e-ball. The E-Ball is a highly fluctuating form, which exchanges its energy quickly with its environment. Only players of an adequate energetic form will be able to carry the ball, and the better make sure, that they move over ground which lets them keep the ball. Other players of the same team might help their current runner, by building up ramps, providing the appropriate environment or hindering their opponents from stealing the ball. The opponents on the other hand might try to literally put stones in the runners way, to steal the e-ball if their energy is closer to the one of the ball or even to shoot their opponents. If the e-ball hits the portal, it will be accepted if the energies comply and the more energy the ball has, the more points the team scores. The goal itself can also be modified in terms of its energy, by changing the environment it resides in. But the assimilation is much slower as for the ball... In this way, an opponent might close its own gThe e-ball might be attracted by the players much like they drain energy from the environment. But one should be careful, since a loaded e-ball might very well do some severe damage. Only try and catch them if you are strong enough!
Workpackages
Terrain
The Terrain is currently still generated and updated on the CPU.LOD
We implemented LOD, which allows for huge landscapes (see figures 1&2).fig. 1: LOD from far out | fig 2. Close-Up to the character |
Supersampling
Even though we implemented supersampling, we are currently not using it. Since the whole update runs on the CPU, supersampling requires a substantial amount of computational time when doing terraforming. The landscape looks nice even without it, if we pre-smooth it. We are thinking on implementing Supersampling on the GPU though.Appearance
Per-Pixel Blending
Per pixel blending is done with 8 textures (some procedural), which requires quite some sampling time. We are thinking of combining the textures into one to prevent texture switching...Multi-Pass Rendering
Since we want transparent water, and even transparent characters, the rendering order is crucial. We currently render into two textures before we render to the screen. The order is as follows:- - Set render target 1
- 1) Render Solid Terrain
- 2) Render Opaque Objects
- 3) Render Main character under water
- - Set render target 2
- 4) Render target 1 to target 2
- 5) Render Transparent terrain (We need to reposition the vertices in the vertex shader)
- 6) Render Billboards behind main character
- - Set render target screen
- 7) Render target 3 to screen
- 8) Render character
- 9) Render Billboards on character
- 10) Render Billboards in front of the character
Transparent Water |
Bump-Mapping
We implemented per pixel bump-mapping, which really improves the quality. Since we have a dynamic terrain, we decided to not recalculate and resend the frenet frame but to estimate tangent and bi-normal on the gpu using some heuristics. It works quite well.Animated Textures
Most of the procedural textures are finished. We have animated water, smoke, fire and lava. Fire and lava glow at night. Fire has to be redone though...Shadows
Dynamic Terrain shadowing is implemented. Lighting is to come...Terraforming
Terraforming is implemented on the CPU. Diffusion works stable and at reasonable speeds.Camera
The camera we implemented is a third-person camera with some DOF-restrictions. It follows the character in an obstacle avoiding and smooth way. In some special cases, it does not behave perfect, there is some more work required.Scene Elements
We have currently only one scene element, but everything is prepared to incorporate more modelsSpecial Effects
Billboard
We implemented a generic billboard system, which can incorporate multiple different billboards. The billboards are frustum-culled and rendered using shader instancing. This might lead to a problem on the XBox, since shader instancing is not available there. A workaround exists though. The billboards are sorted, such that we can use real alpha blending to provide nice volumetric effects. Compositing would be a future option.A problem with larger terrain is the large amount of billboards that need to be managed. This might very well kill the performance completely. Updating, sorting and drawing 30000 Billboards is too much even for a good pc. We are working on a LOD version based on the current quadtree to avoid this problem and have a constant time effort for the billboarding system (except for the drawing).
Billboards are scaled, rotated and translated automatically | With transparency |
Fire/Smoke
We implemented a modified version of the nvidia fire. Applied to our dynamic screen aligned billboarding system, we get nice fires, which cover large areas. We are currently trying to adopt it to our character, where advection comes into playmixed smoke and fire on our billboarding system |
Particle System
We integrated the particle system from the xna creators club, but we are not yet happy with it. More work is required hereSky
We have a sky-box, which can be textured thematically. The sun is moving and so does lighting-direction, ambient light and so on. Of course we also integrated the lens-flare demo. The next step is to change the box to a dome and use (procedurally) animated textures. The problem there is, that the sun should be covered by clouds... and the hardware occlusion query will not recognize that...Rising sun at dawn | High-Noon |
Artwork
We asked some friends of ours to help us with the On-Screen Menu Design. These are some of their proposals:Gameplay
- We implemented a Frag mode - with the sole purpose to kill each other. This was our prototype method to test networking and playability of the terraforming.
- Then we implemented the Nanny mode, where you have to indirectly control your babies and guide them to your nest. This is achieved by modifying the terrain, such that they walk into the correct direction (a bit like lemmings). On the other hand you could also move your nest to collect the babies. This mode has some appeal even as a single player mode. In multiplayer mode, you have to get as many babies as possible into your own nest.
- Our third game-mode is the egby mode (see major changes)
Network
Network support is fully implemented. We use TCP/IP for all transfer. We did not test more than 4 Players yet, but will do so soon. There we will see whether we have to optimize our protocol and maybe use UPD for certain messages (Player position update). Also, we did not incorporate a prediction system, since we target LAN plays and do not expect large delays.Player
Developing a character needed a lot of steps. At the moment, the character, its texturing, rigging and animation is finished.We have animations for all the things an ogre usually does: Run, walk, jump, drain energy, apply energy, ...
These animations are interpolated in the game, such that we didnt have to worry about the alignment of different animations
and we can easily blend from one action into another.
1. Finding a good and convincing concept art: 2. Creating the model by a technique called boxmodellig:
| | |
3. We had to add a subdivision step before the skinning, because the skinning in the
game is done on the GPU, and it is not possible to do a subdivison step afterwards.
4. Skinning. In a first step, the bones are layed out. In a second, the envelopes of the bones
( the regions where they influence the mesh ), are adjusted. And in a last step, the skinning
is finetuned by painting the influence on the vertices.
5. In a next step, texture coordinates have to be generated. This is done by applying different
mapping techniques as planar, cylindrical and spherical, on different regions of the mesh.
6. The texture coordinates can then be rendered on a texture, to visualize where which part is layed out.
7. Using this layout, one can start painting on it in any painting application.
8. We also painted a bump map.
9. And the final character looks as this in 3dsmax. In the game, the green parts are covered
by the current energy texture.
10. Now we created a bunch of animation sequences by keyframing the bones.
Audio
The audio system is implemented and prepared largely. As soon as we receive the sounds, we will start to do some real sound testing.Menu
We have a functional Menu. Nothing fancy though. This remains an open topic...Collision
All major collision detections are implemented. We have currently no player-player collision as well as no collisions with scene Elements. The playtests will show, whether they are required at all. -- ThaboBeeler - 07 Apr 2008I | Attachment | History | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|---|
jpg | ogreBoxModelling.JPG | r1 | manage | 57.3 K | 2008-04-14 - 00:38 | UnknownUser | |
jpg | ogreBoxModelling10.JPG | r1 | manage | 94.6 K | 2008-04-14 - 00:42 | UnknownUser | |
jpg | ogreBoxModelling11.JPG | r1 | manage | 91.5 K | 2008-04-14 - 00:42 | UnknownUser | |
jpg | ogreBoxModelling2.JPG | r1 | manage | 58.9 K | 2008-04-14 - 00:38 | UnknownUser | |
jpg | ogreBoxModelling3.JPG | r1 | manage | 79.8 K | 2008-04-14 - 00:38 | UnknownUser | |
jpg | ogreBoxModelling4.JPG | r1 | manage | 103.9 K | 2008-04-14 - 00:39 | UnknownUser | |
jpg | ogreBoxModelling5.JPG | r1 | manage | 49.3 K | 2008-04-14 - 00:39 | UnknownUser | |
jpg | ogreBoxModelling6.JPG | r1 | manage | 57.8 K | 2008-04-14 - 00:46 | UnknownUser | |
jpg | ogreBoxModelling7.JPG | r1 | manage | 153.5 K | 2008-04-14 - 00:40 | UnknownUser | |
jpg | ogreBoxModelling8.JPG | r1 | manage | 46.1 K | 2008-04-14 - 00:41 | UnknownUser | |
jpg | ogreBoxModelling9.JPG | r1 | manage | 57.8 K | 2008-04-14 - 00:41 | UnknownUser | |
png | topOfTheWorld3.PNG | r1 | manage | 880.2 K | 2008-04-12 - 19:29 | ThaboBeeler |