PVS Culling

Electron · Post by **Electron** » Tue Mar 01, 2005 9:11 pm

I have implemented PVS culling with Irrlicht

Note that my system requires a sector based world. I recommend using my Portal System (discussion about it herehttp://www.irrlichtnx.mmdevel.de/phpBB2 ... sc&start=0 See the website in my sig to download the portal rendering code)

PVS and Portal Demo available here http://crucibleofstars.sourceforge.net/ ... g_Demo.exe (sfx archive)
Be sure to read included readme.txt for more information. It's nearly identical to my Portal Rendering demo.
If you want to use pvs yourself, all the code you need is in pvssystem.h and pvssystem.cpp.
I do have a PVS calculating tool and will release it soon.

When using pvs and portal my framerate is about 60-100% higher. The speed bonus given by these techniques depends greatly on the density of the level

niko · Post by **niko** » Wed Mar 02, 2005 8:25 am

Cool. Very useful for people who want to do huge levels.

Electron · Post by **Electron** » Wed Mar 02, 2005 10:42 pm

glad you approve, niko

Cool. Very useful for people who want to do huge levels.

Yeah, one nice thing about using portal and pvs techniques is that your framerate is nearly completely dependent on hte density of your scene. The world can be infinitely large and distant portions can be culled very very quickly. Mine is not a completely perfect system (is still some overdraw), but it greatly can reduce the cost of a large level by greatly reducing overdraw. Octrees and bsp (except for leafy bsp used for occlusion culling) cannot do this. They cull only things outside the view frustum, but do nothing to minimize overdraw within the view frustum

Electron · Post by **Electron** » Sat Mar 05, 2005 12:25 am

ok, pvs compuation tool up. Not fullymature, not terribly featured. Let me know of any bugs or complaints
http://crucibleofstars.sourceforge.net/pvs.exe

no gui, all keyboard input. Be sure to read readme.txt. If you want to compile editor yourself you will need to use my modded TraingleSelector files (included) which allow the octree triangle selector to do raycasting taking advantage of the octree structure.
Note that pvs compuation is horribly, horribly slow (time grows nearly exponentially with triangle count, not quite that bad because of octree triangle selector, but definitely worse than linear. Each triangle needs several raycasts to determine if it is not visible and raycasts take longer with more triangles. Using SceneCollisionManager raycast method the time taken would be exponentially proportional to the number of triangles (for a given number of sectors and culling points)

The computation tool is poorly documented, so feel free to ask if any trouble using it.

Note that nearly all of the real code is in pvssystem.cpp (in both the pvs computation tool and culling demo downloads) and main.cpp for the compuation tool really has to deal with very little. If you don't like mypvs compuation tool it should be easy to make your own (maybe with a better gui)

puh · Post by **puh** » Tue Mar 08, 2005 6:14 pm

Hi, Electron.

Do not know in which forum should I post the questions, so I post both here and http://www.irrlichtnx.mmdevel.de/phpBB2 ... =1663#1663

I try to understand your pvs-system. Some questions:
1. In file CPVSOctTreeSceneNode.h there is included pvsoctree.h. I haven't found it in the downloaded code. Is it OK

2. The main question for me now - how many points should I use for calculating proper pvs? I try to find info about it, and found some, but it didn't help me to understand pvs-logic. Is it possible for you to make some overview how it works in your app?

Thank you in advanced.

Electron · Post by **Electron** » Tue Mar 08, 2005 11:06 pm

ah, I should have responded here since that other thread really should be about portal rendering, but I read that one first and so answered there. My fault for starting talking about pvs there in the first place. In the future, though, you can post about pvs here and not there. In keeping with that, I deleted my response in the portal thread.

Here's what I said there:

1. In file CPVSOctTreeSceneNode.h there is included pvsoctree.h. I haven't found it in the downloaded code. Is it OK

Yes, it's perfectly fine. I did not even mean to include CPVSOctreeSceneNode.h, it is not needed. It was for an earlier attempt of mine to do pvs. This earlier attempt was based onIrrlicht's octrees and was much faster to compute because it only computed visibility for octree nodes, not each individual triangle. The problem was that Irrlicht's octree construction does not seem to be wonderful (a totally separate issue for someone to investigate if they've got time) and too many polys got stuck in the upper nodes of the octree and thus were not eliminated with the pvs culling since the largest nodes are visible almost anywhere in a level. In short, don't worry about it and don't include it in your project. It's worthless.

2. The main question for me now - how many points should I use for calculating proper pvs? I try to find info about it, and found some, but it didn't help me to understand pvs-logic. Is it possible for you to make some overview how it works in your app?

I should include something in the readme, since it is not obvious. There is no hard and fast rule. The pvs system calulates the pvs for each sector. When you create a computation point for a sector (p key) the camera's current position is used as the computation point. You must store enough camera positions for each sector (that is, every triangle triangle that may be able to be seen from anywhere in the sector should be visible from at least one of the camera positions that you entered as a computation point. I find one point from the middle of each doorway and from slightly to each side of each doorway works well. Therefore the number of compuation points needed for each room will be roughly equal to num_doorways_in_room*3. After the calculation has finished, set which sector's pvs is being used for the camera (u key) and wander around that room. If any triangles are missing from the view anywhere in the room, add another compuation point from that position. You can then press the 'a' key to compute pvs from the new points and add it to the already computed pvs.

A last note: Calculating pvs is very,very time consuming. I may not be using the most efficient method, but I think any method is going to take a long time for a decently large/dense level. I recommend not trying to do it all at once. Create all the compuation points for a sector or two and let it run. Then save the result (s key) though is saved to autosave.pvs after compuation. You can then compute the rest right then or at any other time by loading the mesh and the pvs data file, then adding new computation points + pressing 'a'. Experiment around with it to see how much you like to do at a time. One reason for doing it a bit at a time is if you enter a computation point for a sector that doesn't actually exist there's no way to delete it

Oh, also, what do you think of the editor? I know it's kinda limited and clunky. Any technical issues/crashes?

puh · Post by **puh** » Wed Mar 09, 2005 9:14 am

Thank you, Electron, your explanation really helped me a lot! Now the whole process is nearly clear for me.

Any technical issues/crashes?

Well so far I just found that if I open Sector PVSCalc.exe and close it immediatly by pressing X button - the program closes but crash at the end.

But anyway I need to make my own editor as my app is xml-loaded, not one-file-loaded-as-one-level, but many-files-loaded-as-one-level.

Electron · Post by **Electron** » Thu Mar 10, 2005 12:52 am

Well so far I just found that if I open Sector PVSCalc.exe and close it immediatly by pressing X button - the program closes but crash at the end.

Doesn't sound serious but I'll look at it if/when i get some time

But anyway I need to make my own editor as my app is xml-loaded, not one-file-loaded-as-one-level , but many-files-loaded-as-one-level .

Ok, should be fairly easy as the pvs calculating stuff is in the CPVSSystem class, not in my editor's code,though you'll have to change the file load/save stuff. I'm not sure I fully understand what your saying about the multiple files thing though. The .pvs file contains only pvs info, it's not supposed to be one file with everything about a level, though I do realize it's not xml.
One major problem with the loading code in CPVSSytem is that it does not use Irrlicht IReadFile's so cannot read out of compressed archives. The problem is, I disliake Irrlicht readfiles because they can't do any sophisticated i/o stuff (like getting a single line, scanf type functions, etc). Whenever I use them I find I have to copy everything into a string and do read operations on the string.

puh · Post by **puh** » Thu Mar 10, 2005 8:32 am

I'm not sure I fully understand what your saying about the multiple files thing though. The .pvs file contains only pvs info, it's not supposed to be one file with everything about a level, though I do realize it's not xml.

Actually I meant that my level loading system consists of xml-file with path for each element of the level. Here is some strings from config.xml:

Code: Select all

<texture texture1="media/plitka03.jpg" A="0" R="180" G="180" B="180" MaterialType="12" />
<skybox top="06.png" bottom="05.png" left="02.png" right="04.png" front="01.png" back="03.png" />
<nodeSOLID mesh="all1.3.lmts" useTri="1" useFog="1" X="0" Y="0" Z="0" />
<nodeSOLID mesh="all-winb.3ds" sector="1" useFog="1" X="0" Y="0" Z="0" textureN="1" textureR="0" />

If you are interested I did release my demo here: http://www.irrlichtnx.mmdevel.de/phpBB2 ... .php?t=313

does not use Irrlicht IReadFile's so cannot read out of compressed archives

It's a pity, as I plan to archive almost all data except executable, dll and xml. But I try to adopt your code anyway.

Electron · Post by **Electron** » Thu Mar 10, 2005 9:23 pm

It's a pity, as I plan to archive almost all data

yeah, I regret it. I may redo it. I just didn't think of it at the time and I don't like IReadFile's