Jump to content
  • entries
  • comments
  • views

Generating a Cell and Portal Graph from 'TriangleSoup'

Sign in to follow this  


This is my first Journal, so forgive me if I break any conventions.

[heading]What's this all about?[/heading]
As part of the requirements for 'Advanced Diploma in Professional Game Development (Programming Major)' second year, I am expected to spend something like 120 hours researching and developing an industry-relevant project of my own choosing. Of all the things I could possibly choose !!

[heading]What's the topic again?[/heading]
This project will mainly involve geometric analysis - given a 3D scene or 'world' as a 'triangle soup', we will analytically 'discover' the subspaces or 'rooms' in the scene, and the doorways or 'portals' which connect those subspaces. From this information, we will create a 'graph' (something like a tree structure) which describes all the 'rooms and doorways' in the world. This will occur as a 'pre-processing' step, which the end-user will not have to endure.

[heading]Why the hell would I want to do this?[/heading]
Automating the placement of portals takes that responsibility away from the artists and level designers - who may well not understand the technical ramifications of this process.
This leaves the artists to do what they do best, which is making jaw-dropping eyecandy, while giving the programmers a concrete set of design rules under which their code can operate (few or no aberrations), and eliminating one mundane task of the level developers, which is that of identifying and labelling 'sectors' in the scene... everyone gets to work under a common worldspace partitioning system, where the gruntwork is performed by a computer and not a human.
On a purely technical level, the partitioning of worldspace lends itself to optimized rendering and physics, with flow-on effects to reduced network load.
Since we're burning less cpu and gpu time, we have more time for more eyecandy and other stuff, which is always a Good Thing.

[heading]What are the drawbacks?[/heading]
The cell and portal scheme has traditionally been associated with static, unchangeable worlds.
I intend to show that it is quite possible to dynamically punch new holes in the walls, however if the artists decide to make late changes to the world model it will be likely that the model will need to be preprocessed from scratch - so the earlier that the disk-based world model is 'locked down', the better.

[heading]What made you choose this topic?[/heading]
I just love the idea that you can feed in a raw model at one end, and a game-ready structure of linked 'rooms' comes out the other end... ready for the rooms to be 'populated' in some means... without some well-meaning human in the middle to screw things up !! Let the level designers populate the rooms, let the artists create the models, let the programmers get back to iterating over the Fun aspect!
Sign in to follow this  

1 Comment

Recommended Comments


I had a similar idea when I first started working on a world editor. I ended up putting the idea on hold in favour of completing simplified version of the editor but I'm still interested and I'll be watching your journal to see how it goes.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!