🔒 Locked

Portal Engine

Started by WizHarDx Mar 14, 2005 at 6:13 AM 2 replies 800+ views

Original Post

Mar 14, 2005 at 6:13 AM

Hi, I am currently developing an indoor/outdoor engine. I want it to be like hitman 2 graphics. My current idea is to have a portal engine and every portal is divided into its own octree. This will allow the whole outdoor section to be one zone and still render effciently because of the octree. Do you think this will work or am I missing anything ? If what I assume is correct this leads me to the current problem. I understand the mathmatics and algorithms needed and I want to implement them. But I am having real trouble getting the data as there is so much needed I find im spending to much time inputting it into a file. There are usally errors and its simplicity may lead to me thinking that the HSR algorithms are working when they are not? I don't particularrly want to spend a week looking up docs loading some complex file format. Thank-you very much in advance Iain Fraser

ptl

Mar 14, 2005 at 7:37 AM

Hello,

Your idea is a good way to handle things, ie a portal visibility system with a tree inside each cell (if you look at some articles on portal visibility you'll seen that the portal is the "window" between cells). Many indoor/outdoor visibility systems handles visibility like this. However, you should think about using a kd-tree instead of an octree, because it is less restrictive on the split position/axis and can give better performance if used correctly (the commercial package dPVS uses a kd-tree for exemple).

I don't really understand the second part of your question, it seems quite confuse : do you want to find a file format that can handle enought polygons to have a very large world, so use efficiently HSR algorithms ? The better solution is to use your own file format so you can use every information you need inside of it, available for exemple as a 3ds max exporter.

Hope it helps,
ptl

OrangyTang

Mar 14, 2005 at 7:49 AM

One of the nice things about portals is that you can use them as a high-level PVS, and still easily plug-in some more specific methods further down. So you can divide areas using portals into sectors, then each sector can have its own local spatial tree. A sector could then just be a brute-force poly soup (for when your portals are dense enough) or a BSP, or a quad-tree (for outdoor terrain).

A simple way to test how well your portals are rendering is to log how many polys are being rendered with and without portal culling. Although you will need some proper test data at some point.

WizHarDx

Mar 14, 2005 at 8:23 AM

thanx for the response guys.

Ya Im just looking for some temporary data. I will making my own file format later as we are making a complete game from this engine. But I just need some data to test my hsr alogrithms.

At the moment ive got a few cubes connected with a square hole as the portal. But this isn't going to really push my algorithm to the max. so im just looking for a temporary maps / data to load that is easy to understand and convert for what I need. Hope this clarfies what im looking for?

thanx again
Iain Fraser

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.