I suspect the main factor in these lengthy compile times are all of the little brush solids I am using for detail model props to have their shadows be cast in the game-world. In my experiments, model props do not cast shadows if they are only entities, but if there is a brush that roughly coincides with the body of the model, a shadow in the shape of the model will be casted.
I have been reading up on what 'Potentially Visible Set' really is and basically it is the set of brush solids in the game-world that are visible to the player within a particular region of the map. In the process of computing these sets, the map is divided into regions and for each region the PVS program computes all solids which would be visible to the player. This is done for the sake of accelerating the performance of the rendering of the game-world. With my experience as a computer programmer, I imagine that these calculations are redundant, which leads me to think that maybe the process could be accelerated using a GPU which I know are super efficient for executing the same instruction many times at once. I am not sure quite frankly, is this possible? How can it be done? If it is not possible, how else can the compilation process be accelerated?
Unfortunately, I don't know a good way to accelerate the computations: If I did, I would have implemented it years ago. Another problem is that PVS information is quasi a prerequisite for (efficient) Radiosity light computations (they work without PVS, but slower).
Running the original PVS algorithm on a GPU is certainly possible, but it would require a huge effort for a brute-force result that would not principally improve the situation.
One option to improve the PVS computation speed would be to make it coarser. For example, we could have the map designer add PVS portals (or in fact, BSP cells) explicitly. This would make the time that is needed for the computations to become negligible, but require at least some technical knowledge of the map designer.
Another option would be to abandon the classic PVS approach (and along with it, the Radiosity lighting) entirely: modern OpenGL and DirectX implementations can give a feedback when every pixel on the screen has been rendered, so a classic z-buffered front-to back approach is possible with minimal effort. Also, lighting techniques such as shadow mapping only depend on normal rendering speed and don't need expensive precomputations.
Unfortunately, nothing of this is currently implemented in the Cafu engine. Ideally, we would work towards an implementation where the map editor and the game itself are closely interwoven, quasi in the same program. I'll support anyone working on this, but I currently have no time to implement it all by myself.
Can you elaborate on this? How does a map designer manually add PVS portals? With brush solids and a special texture? I want to add buildings to large terrain maps and I am very sure that this would probably result in bad engine performance BUT if I could separate the interior of the buildings in other parts of the game-world and partition those parts as PVS portals then I think it might be practical to have the exterior of buildings in open spaces while the interior of those buildings are in another location in the game that the player reaches via a teleport.Carsten wrote: ↑2019-07-28, 09:52..One option to improve the PVS computation speed would be to make it coarser. For example, we could have the map designer add PVS portals (or in fact, BSP cells) explicitly. This would make the time that is needed for the computations to become negligible, but require at least some technical knowledge of the map designer...
Regarding PVS, note that the interior of buildings is usually not a problem: the algorithm can work efficiently with indoor areas such as those in the example maps.
The most problematic case is when a lot of detail brushes exist that barely occlude anything. For example, for a forest or a room with many pillars the algorithm would generate thousands of BSP cells and the PVS algorithm would attempt to establish exactly their mutual visibility, even if it was clear that the pillars don't effectively obstruct anything.
We currently have not support for adding PVS portals manually (if implemented, it would work as you described), but we have this:
Code: Select all
d:\Dev\Cafu>build\win32\vc14\x86\debug\CaPVS\CaPVS.exe *** Cafu Potentially Visibility Set Utility, Version 05 (Oct 28 2017) *** USAGE: CaPVS Path/WorldName.cw [OPTIONS] OPTIONS: -maxRecDepthSL n : Leaves that are stored in the BSP tree and have a greater depth than this value get combined in a common SuperLeaf that is created at this depth value. -minAreaSL a : BSP sub-trees whose non-detail faces have a common area of less than this value get combined in a SuperLeaf. -onlySLs : Do not compute the PVS, just print out how many SuperLeaves would be created. Used for estimating the above parameter values (speed vs. quality).
While I implemented this years ago, I don't have any studies on it's effectiveness and thus can only recommend trying it out and experimenting with it.
My experiments have revealed a problem with this design, it seems that when there are two non-contiguous spaces in the map CaBSP will only compute the bsp for the room that has the info_player_start_entity so the other room is not processed or rendered. This leads me to think that CaBSP begins the fill operation from the origin of this entity, although I have not read the source code for the BSP compiler yet so I may be wrong. Even so, when I put another info_player_start entity in the other room, CaBSP processes the geometry of that room and the player is able to reach the other room via teleport. So it seems that the info_player_start entity can be used to make CaBSP process the geometry of other sealed csg volumes. This is what I have done in another map: there are two csg volumes, one is the volume containing the terrain and the player_prototype while the second is another volume elsewhere in the CaWE gridspace outside of the first volume also containing a player_start entity and a teleport. CaBSP and CaVIS seem to process BOTH of these volumes but when the map is loaded the screen is totally black and the player does not spawn. I do not have an explanation for this result, my question is can you explain this problem?
Users browsing this forum: No registered users and 1 guest