Cell

Published November 05, 2006
Advertisement
Long time, no update.

Progress is being made. So many changes and fixes since the last update, not sure where to begin.

I solved an interesting issue with the portal system today. This has been an issue in the back of my mind for a while, but I finally figured out a solution today.



What you see here is an overview of one of our mayan-themed levels. The blue cubes are cells, and the green quads are portals. In the middle-left of the screen there is a chunk of background mountains.

The problem with these mountains, meant to be seen from all over the level, is that it is not in any cell. The portal culling system works by finding the cell or cells containing the camera, then proceeding through visible portals into other cells, adding them to the visible cell list.

Then the visible cell list is potentially reduced by anti-portals.

During rendering, a chunk of world geometry or an object is tested to see if it touches at least once cell. If not, it is not drawn.

With this scheme, outlying objects not in any cell, or not in a cell connected via a series of portals to the camera cell are culled.

I first considered tagging background meshes such that they wouldn't be portal culled, but that seemed a bit of a hack, and wouldn't scale nicely to other things like entities.

Instead, I was going to define a new class of cell, called a Visibiliy Cell. The idea is that a Visibility Cell would only be tested via the view frustum and anti-portals, and not be culled based on portals at all. Putting a Visibility Cell around the mountain chunks would prevent them from disappearing from view.

Because I'm using the incredibly poor Managed C++ from vs7.1, I dread going into the level editor and making changes needed to make a new cell type, so I thought of a simpler way - simply find any cells with no portals attached, and treat them as the VisibilityCells.

Only took a few minutes to fix once I had the idea...


A partial list of things fixed since last update :

Dual-weapon support
Both the player and enemies can have two distinct weapons at once

Attachment scaling
Weapons can now be scaled to match up to the dude holding them

Better laser-sight jitter

Yet more fixes to the physics lerping system

Physically reactive vines that drive a skeletal vine mesh
(also could be used for cloth, plants, etc. )

Many design items finalized

Code to compute formulas from .csv files for RPG system

In-game UI designed

RPG system semi-finalized




Previous Entry ...
Next Entry Item Menus
0 likes 4 comments

Comments

Ravuya
That's interesting -- I had no idea all the rooms were square.
November 05, 2006 12:24 PM
SimmerD
The rooms are not all square in general, but we are trying a new prefab-type approach to level building to cut down on time by improving re-use.

The cells themselves are bounding boxes, but they don't have to be axis-aligned, although they are more efficient if they are.
November 05, 2006 12:39 PM
roel
Cool, now I saw your update I recalled that I dreamed that I was playing your game. Neat.
November 06, 2006 02:24 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement

Latest Entries

1.2 Almost ready...

1118 views

Sound Paths

1335 views

Stately Progress

1137 views

State Lines

1287 views

Pulsing

871 views

Return to The Ship!

1011 views

Cameras & Boxes

1128 views
Advertisement