Interim Report

hotPool.PNG

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 g
The 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).
LOD.PNG LOD2.PNG
fig. 1: LOD from far out fig 2. Close-Up to the character

LOD.PNG LOD2.PNG
LOD.PNG LOD2.PNG

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

Its also very important when to enable depthbuffers. The result is shown in the following figures.

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...
shadowMap.PNG shadowMap2.PNG

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 models

Special 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 play

mixed 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 here

Sky

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:

Eismo_Ogre_by_EnterPraiz.jpg

2. Creating the model by a technique called boxmodellig:
| ogreBoxModelling.JPG | ogreBoxModelling2.JPG | ogreBoxModelling3.JPG

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.
ogreBoxModelling4.JPG

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.
ogreBoxModelling5.JPG

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.
ogreBoxModelling6.JPG

6. The texture coordinates can then be rendered on a texture, to visualize where which part is layed out.
ogreBoxModelling7.JPG

7. Using this layout, one can start painting on it in any painting application.
ogreBoxModelling8.JPG

8. We also painted a bump map.
ogreBoxModelling9.JPG

9. And the final character looks as this in 3dsmax. In the game, the green parts are covered
by the current energy texture.
ogreBoxModelling10.JPG

10. Now we created a bunch of animation sequences by keyframing the bones.
ogreBoxModelling11.JPG

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 2008
I Attachment History Action Size Date Who Comment
JPEGjpg ogreBoxModelling.JPG r1 manage 57.3 K 2008-04-14 - 00:38 UnknownUser  
JPEGjpg ogreBoxModelling10.JPG r1 manage 94.6 K 2008-04-14 - 00:42 UnknownUser  
JPEGjpg ogreBoxModelling11.JPG r1 manage 91.5 K 2008-04-14 - 00:42 UnknownUser  
JPEGjpg ogreBoxModelling2.JPG r1 manage 58.9 K 2008-04-14 - 00:38 UnknownUser  
JPEGjpg ogreBoxModelling3.JPG r1 manage 79.8 K 2008-04-14 - 00:38 UnknownUser  
JPEGjpg ogreBoxModelling4.JPG r1 manage 103.9 K 2008-04-14 - 00:39 UnknownUser  
JPEGjpg ogreBoxModelling5.JPG r1 manage 49.3 K 2008-04-14 - 00:39 UnknownUser  
JPEGjpg ogreBoxModelling6.JPG r1 manage 57.8 K 2008-04-14 - 00:46 UnknownUser  
JPEGjpg ogreBoxModelling7.JPG r1 manage 153.5 K 2008-04-14 - 00:40 UnknownUser  
JPEGjpg ogreBoxModelling8.JPG r1 manage 46.1 K 2008-04-14 - 00:41 UnknownUser  
JPEGjpg ogreBoxModelling9.JPG r1 manage 57.8 K 2008-04-14 - 00:41 UnknownUser  
PNGpng topOfTheWorld3.PNG r1 manage 880.2 K 2008-04-12 - 19:29 ThaboBeeler  

Page URL: https://twiki.graphics.ethz.ch/bin/view/GameClass/TeamEInterimReport
2024-03-28
© 2024 Eidgenössische Technische Hochschule Zürich