|
Post by marscaleb on Jun 24, 2017 14:17:58 GMT -5
So I'm still new to Quake 2, and I'm not sure of the intricacies of handling some things properly.
I've been planning out some ideas for some outdoor environments, and I'm not sure exactly how to go about making them efficient for this engine.
Fundamentally I am creating a large outdoor environment, but using cliffs and such to box in the areas to effectively create rooms and corridors that work well for a low-poly environment. Nothing that hasn't been done before, so far. But rather than have a bunch of cliff edges that look like walls and make everything feel like players are boxed-in, (like in the first level for Q2 The Reckoning, or in the first Turok game,) I want to carve more natural geometry with less-dramatic slopes and shorter walls, enough to actually keep the player from going outside the area but make the different areas feel connected. If you see a hill blocking your way, people in another area will see the other side of that hill.
The problem is efficient rendering. In some engines I could just make the large outdoor area as one big room and manually set visibility so that if you are in one given area you only really render that one area. And if someone uses cheat codes to get up on a hill they could see everything and it would bog down their computer but I don't care you're a dirty cheater, the regular game runs just fine. In some engines I could even set it so that if you stand on a high perch you can see everything below but it is drawn at a lower LOD.
But since Quake 2 has all the visibility pre-calculated automatically, I worry that I might run into some odd situations where it will calculate the wrong thing. My first concern is that I might bog things down with calculating unnecessary visibility checks for places the player can never reach, but technically exist. My second concern is that I might wind up rendering too much if I stand at the wrong location and the game thinks I might be able to see geometry if I move in a way that I can't.
So there are basically two things on my mind.
One, exactly how does VIS operate? if I can understand how it calculates visibility I can build to accommodate it and avoid situations where I render too much in one area.
Two, is there anyway to manually tweak visibility? A program that let's me adjust visibility by hand, or another visibility program that might give me different results, or a way to set things up in the map so that VIS calculates certain areas differently? Or really any other options at all.
|
|
|
Post by knightmare on Jun 25, 2017 23:35:05 GMT -5
VIS operates by processing the .prt (portal data) file output by qbps3 and calculating which nodes are visible from where. The VIS time increases exponentially with the geometric complexity of the map. I haven't really dug deep into its source code to examine all the details of its operation. The VIS data is in a binary form and no manual editing tools that I know of exist.
What you want to do when optimizing your map is make brushes that don't block line of sight have the detail attribute. This makes VIS ignore them, usually decreasing VIS time by an order of magnitude or more. It can also prevent errors in the VIS tables (known as HOM, or Hall Of Mirrors) that cause disappearing faces. You can also tweak visibility in some cases by using hint brushes to force primary BSP splits at bends in hallways.
Gensurf is one good way to create to create more natural-looking outdoor geometry. It can create brush-based terrain either randomly or from grayscale heightmaps. It's available as a plugin for both QERadiant and GTKRadiant, and possibly others.
As far as big outdoor areas go in Q2, you can improve performance by running qbsp3 with the -chop 1024 parameter (kmqbsp3 has this set by default). This will cause fewer surface splits and larger polygons, and thus usually result in higher framerates. You will also need to run your map with a modified engine that supports such large surfaces, such as KMQ2, the v3.24 patch (OpenGL mode only), Quake2Evolved or Quake2Max.
If efficent rendering of LARGE outdoor areas is your primary concern, you will need to require a modified Q2 engine for your map. Q2's engine was not originally designed for such large outdoor areas, most likely due to hardware limitations at the time of its release. Also, the multitexture rendering path in Q2's OpenGL renderer was very poorly coded. It has bad scaling issues with high world poly counts on most graphics hardware, particularly if lightstyles or dynamic lights are involved. KMQuake2 fixes these issues, and also adds support for maps that extend beyond Q2's +/- 4096 coordinate range.
One more issue is the sky render distance. This is set quite close by default in the original version of Q2, causing level geometry to disappear into the skybox if any sky surfaces are visible. Most modified engines increase this, and often make it an adjustable cvar as well (r_skydistance in KMQ2, v3.24 ref_gl and Quake2Max).
|
|
|
Post by marscaleb on Jun 26, 2017 2:26:29 GMT -5
VIS operates by processing the .prt (portal data) file output by qbps3 and calculating which nodes are visible from where. The VIS time increases exponentially with the geometric complexity of the map. I haven't really dug deep into its source code to examine all the details of its operation. The VIS data is in a binary form and no manual editing tools that I know of exist. The BSP calculation generates portal data? Maybe I'm making the wrong assumptions about what that means, but it really makes me want to have manual control; set up the portals myself within the map. What you want to do when optimizing your map is make brushes that don't block line of sight have the detail attribute. This makes VIS ignore them, usually decreasing VIS time by an order of magnitude or more. Wow, that is a VERY important detail I haven't seen mentioned in any of the tutorials I've seen. Just thinking about the concept has given me an idea, though. Would it be possible to "hide" the sight blocking brushes under detail brushes? Like if I had a large complicated wall-ish structure, could I put a simple flat brush in its core, and mark all the brushes surrounding it as "detail?" Or if I had a large hill with many faces to round out a curved shape, would it make sense to hide a simple block inside of it, and all the blocks outside marked as detail, thus the vis calculations can operate off of a simple box shape (or small series of boxes) rather than the many potentially-complex surfaces of the hill? As far as big outdoor areas go in Q2, you can improve performance by running qbsp3 with the -chop 1024 parameter (kmqbsp3 has this set by default). This will cause fewer surface splits and larger polygons, and thus usually result in higher framerates. You will also need to run your map with a modified engine that supports such large surfaces, such as KMQ2, the v3.24 patch (OpenGL mode only), Quake2Evolved or Quake2Max. Already on it. Honestly it seems really odd to me that a game which needs to cut poly counts so incredibly low would put a limit on the size of its polygons, effectively adding more polys into the scene. One thing that was not quite addressed is having large inaccessible areas. "Complex" areas make for more difficult calculations, that sounds reasonable. But what about large (but geometrically simple) areas? And more to the point, here is a more detailed explanation of what I was thinking of doing. I'd like to know if this presents any problems or not. Rather than making each section a self-contained "room" with sky for the ceiling, I'd like to create a large room with a a single sky. What we see in the drawing is a side view. The blue lines are surfaces marked as sky. The two hills in the middle would be too steep/high to be able to scale, so they serve as walls. But with the tops not actually touching the sky they form a more-natural effect that makes the world feel more inter-connected. The whole upper half of this example would be space that exists, but is inaccessible by the players. In a more-complicated example I would have more variance in heights, perhaps add some geometry that can be seen from several areas like a tall tower, but for the moment let's take a look at just this simple example.
|
|
|
Post by knightmare on Jun 26, 2017 16:17:43 GMT -5
Would it be possible to "hide" the sight blocking brushes under detail brushes? Like if I had a large complicated wall-ish structure, could I put a simple flat brush in its core, and mark all the brushes surrounding it as "detail?" You sure can. This is known as a VIS hull. One thing that was not quite addressed is having large inaccessible areas. "Complex" areas make for more difficult calculations, that sounds reasonable. But what about large (but geometrically simple) areas? Only the geometric complexity of the structural (non-detail) brushes matters, not size. Honestly it seems really odd to me that a game which needs to cut poly counts so incredibly low would put a limit on the size of its polygons, effectively adding more polys into the scene. This chopping up of the world surfaces at regular intervals and at intersecing brushes was done for the software renderer. They were kept small (240x240 pixels) to allow for smaller in-memory caches and 8-bit registers in the optimized assembly code to be used, as well as avoiding overdraw. The Q3 engine (OpenGL only) ditches all of this subdivision for much larger surface polygons that aren't chopped up.
|
|
|
Post by marscaleb on Jun 27, 2017 12:49:00 GMT -5
You sure can. This is known as a VIS hull Does the VIS hull need to be visisble at all? Like if I had detail brushes completely enclose the VIS hull, will it still work? This chopping up of the world surfaces at regular intervals and at intersecing brushes was done for the software renderer. So... KMQuake2 doesn't have a software renderer... So if I were creating a project that was designed to run only in KMQuake 2, wouldn't it make sense to chop up my surfaces into even larger sections? Theoretically, infinite? I mean, it would be nice if I could have my work run in any version of Quake 2 the player prefers, but from what I've been reading, it looks like the only way I can add new weapons and things is to edit the source code, so what I'm making has to be distributed with a custom exe.
|
|
|
Post by knightmare on Jun 27, 2017 21:35:40 GMT -5
There's very little benefit to increasing -chop values beyond 1024, as you probably wouldn't want surfaces that large in an outdoor area anyway- too flat and boring. Also, you'll eventually run into the limits of the s_blocklights array. I made it much larger than stock, but not infinitely large. Further, I've more recently added surface batching to KMQ2 so it can render multiple surfaces in a single call, so surface subdivision doesn't have quite the same impact it used to.
You can add monsters, weapons and entities via the game DLL source, which has been available practically since the game's release. KMQuake2 requires specially compiled game DLLs, due to its underlying changes.
|
|
|
Post by marscaleb on Jun 29, 2017 3:16:06 GMT -5
There's very little benefit to increasing -chop values beyond 1024, as you probably wouldn't want surfaces that large in an outdoor area anyway- too flat and boring. Not necessarily. Something I might want is to have large structures that can be seen from a distance. Or take a look at this render I recently found from Goldeneye's Dam level: Technically, the lake is "flat and boring," but the outer rim of mountains is not. And you really could not have properly pulled off that important section of the map without filling so much space. Granted, I'm not trying to recreate this exact scene, but the point is that there are occasions where you do want surfaces that large. Also, you'll eventually run into the limits of the s_blocklights array. I made it much larger than stock, but not infinitely large. I don't know what this is. You can add monsters, weapons and entities via the game DLL source, which has been available practically since the game's release. KMQuake2 requires specially compiled game DLLs, due to its underlying changes. G** d*** it, am I just looking in the wrong spot, or what? I can't even fart without discovering that I don't know some basic scrap of information critical to making a Quake 2 mod. Seriously, I can think of a dozen other games I've done maps or mods for and I've never had problems like this.
|
|
|
Post by quakeulf on Aug 10, 2017 2:11:28 GMT -5
>ctrl+f "MAX_PATCHES" >no results
Well, MAX_PATCHES is the worstest thing to work around when making large levels for vaniller Quake 2. That's probably the only thing I'd like to get a limit break on.
So with MAX_PATCHES in minds, having large, flat areas with no detail and texture scale perhaps multiplied by 2 or 3 or even more, will help to allow it, otherwise you'd have to do some serious arghrad-tweaking with regards to lighting accuracy. Usually I work around by sacrificing water patches and sky patches, but you will notice it once the numbers get large.
|
|