IdTech 1/2/3/4 BSP/PVS

Discuss the construction of maps and the tools to create maps for 3D games.
Post Reply
Spiney
Posts: 63
Joined: Mon Feb 13, 2012 1:35 pm

IdTech 1/2/3/4 BSP/PVS

Post by Spiney »

Hey guys, I've been thinking for a while of doing some big art farty maps with large open spaces and detailed geometry.
There's no gameplay involved, it's a purely visual thing and shader wise it would be really simple, all about simple aesthetics.
One thing I've been wondering is, which BSP version is best to use nowadays? All other things not considered.
I only understand the technical sides of this in broad conceptual terms, so I'm asking since there's more qualified people here.
I'd like to not have to worry too much about optimizing occlusion culling, but I also want fairly flexible texture alignment and vis times that are managable.

So, as I understand it:
Q1 BSP is old and the vis times are potentially extreme. The upside is that it's fairly straightforward when using something like BSP2, no caulking/hinting/areaportals etc.
Q2 BSP I never used, but it seems to be in disuse and it has all kinds of finicky optimisations that might be deprecated or inefficient for modern GPU's?
I know Q2W has improved Q2 BSP, so that might be worth looking into? I'm slightly intrigued about it :P
Q3 BSP is newer, decent tools, decent vis times. Downsides are it seems to lag when the vis isn't carefully optimized. Especially in large outdoors where Q1 for instance doesn't seem to have much issue. I made a big open map a while ago and the performance just didn't cut it once I started stacking too much stuff in. Curved surfaces are nice, but no huge deal. Manual caulking is no huge deal to me, but not having to bother is nice also. FBSP (qFusion) is like Q3 but with bigger lightmap page size?
D3 BSP I haven't tried yet, but from what I gather it does everything with manually placed portals? How does this compare to other more precomputation heavy methods? I read a couple of times it's supposedly bad at outdoors, but is that due to PVS issues or due to the lighting? I recall some sluggish outdoors in Prey where I turned off shadow volumes and the FPS just went into tripple digits.

Also, are there other options I didn't list?
If it turns out old fashioned BSP is too prohibitive I might look into other venues, such as doing everything in a modelling app and use something like Unity or UDK, but in that case I'll need to learn some new tools/engine in the process. That might be worh it, however I still like BSP because it has less of a 'random poly soup' feel than a lot of modern engines which stick a bunch of modular meshes together. BSP also seems to allow for more liberal texturing (including consistent texture scaling, etc). Would be good to get some mapper as well as programmer input... maybe there's other people who wonder about this stuff. There's the workflow and the technical limitations/advantages to consider. I can always design around limitations, but it's certainly nice to have things 'just work'.
jitspoe
Posts: 217
Joined: Mon Jan 17, 2005 5:27 am

Re: IdTech 1/2/3/4 BSP/PVS

Post by jitspoe »

The reason some of the BSP versions don't handle large, open spaces well is because they chop up the geometry every X units, so the more units you have, the more polygons you end up with. This chopping can be reduced by scaling the texture up. I'm not sure how bad it is in idTech 3 and 4, but 1 and 2 get chopped up quite a bit. I know in 3, small brushes are less likely to split things -- that's another big issue with BSP. Say you have something like a detailed pole (cylinder) touching the ground. With 1 and 2, it will split the ground for each plane on the pole, adding a bunch of extra polygons. In 3, the compiler is a little smarter and should avoid this. I've never tried anything with 4.

Oh, one other thing -- 1 and 2 spaces are limited to 8192 units (140-150 meters-ish, I think).

As PVS, if your map is a large, open space, it's probably not going to benefit from PVS at all, since all areas of the map will be potentially visible.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: IdTech 1/2/3/4 BSP/PVS

Post by Spike »

Q3bsp doesn't do lightstyles. the other potential disadvantages are due to the tools. you can often aproximate them with shaders although its not the same. shader switching is possible with quake3, but not particuarly convienient.
Curved surfaces are nice, but you might as well just use polysoup instead. doom3 certainly did.
Visually, Q2bsp isn't really any different from Q1bsp. Just external textures, some 33%/66% transparency flags, skyboxes instead of weird scrolly skies, and built-in lit support. Its not really any harder to get a software rendering q1 engine to support q2 bsps as it would be for a gl engine.
doom3 has no lightmap support at all. lighting is either flat or realtime, which makes it either crap or slow. It should be good at batching (yay for complex scenes), so long as its pitch black. Support for frustum culling may be lacking. Shouldn't really be a problem if your gpu can do all that on-chip.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: IdTech 1/2/3/4 BSP/PVS

Post by qbism »

What existing maps do you like, what sort of atmosphere, and how do you like to map? This is more important than the format nowadays. Recent Q1 and Q2 compiler tools and engines have reduced the limitations. See Maric's recent kmquake2 map with scenery models and Tyran's new Q1 compiler with detail brush support (func_wall with shadows!) as examples.

If you're looking for doomlike normalmapping, shaders, etc., it can be had in Q1, Q2, and Q3 flavors.

I've been playing with Trenchbroom map editor, a fun way to sculpt maps directly in 3d. Q1 only for now, but looks like coding is happening for a plugin system possibly leading to more formats.
Spiney
Posts: 63
Joined: Mon Feb 13, 2012 1:35 pm

Re: IdTech 1/2/3/4 BSP/PVS

Post by Spiney »

No normalmapping/lightstyles.
What I'm having in mind at the moment is something like Lunarans's latest floater http://www.lunaran.com/images/maps/large/lun3dm5_9.jpg
...so that level of complexity but with a NPR texture style leaning more towards illustration/graphics design.
Actually I just remember I haven't ran the map with the GL2 renderer in the newer ioQ3. It was performing horribly on stock Q3A, as it was with most people from what I gather.
So that's giving me some concern, it's not very detailed by modern standards, yet enough to bring Q3 to it's knees.

One of the scenes I'm planning is a vertical shantytown. With lots of protrusions and vistas, but also subterranean sections.
I would prefer lightmapping so I can do soft ambient fill lighting, but the hardness of shadow volumes might not be a bad thing since the textures are supposed to have an inked look.

[update]
Actually I just tried Lun3DM5 on nightly ioQ3's GL2 renderer and it runs perfectly smooth. Guess that does it... I can keep my current workflow and have decent framerates on geometrically complex maps. Now I feel stupid for making this thread.
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: IdTech 1/2/3/4 BSP/PVS

Post by leileilol »

jitspoe wrote:The reason some of the BSP versions don't handle large, open spaces well is because they chop up the geometry every X units, so the more units you have, the more polygons you end up with. This chopping can be reduced by scaling the texture up.
Understandable as that's necessary for the software renderer to mip and span on, and the texture scale affects lightmap. It's more dependant on lightmap texels than unit grids since the the the drawspans code expects divisions of 16 at the most and this falls in line with the mipmap code and the surfacecache etc, and I probably can't think of the proper terms to mention it right now. Anyway, software.

This was oen of the big things dropped in Q3BSP. If Q3 ever had to have a software renderer it would need to be done with entire polyblobs for everything instead. I'd still like to see abrash quake assembly code whacked into a q3 renderer somehow someday :P
i should not be here
Jay Dolan
Posts: 59
Joined: Tue Jan 22, 2008 7:16 pm
Location: Naples, FL
Contact:

Re: IdTech 1/2/3/4 BSP/PVS

Post by Jay Dolan »

Spiney wrote: I'd like to not have to worry too much about optimizing occlusion culling, but I also want fairly flexible texture alignment and vis times that are managable.
...
I know Q2W has improved Q2 BSP, so that might be worth looking into? I'm slightly intrigued about it :P
Don't be :P Q2W's BSP improvements, as far as the format itself goes, are only to increase a few hard-coded arbitrary limits, and to add a couple of new lumps: vertex normals and deluxemaps, to be precise. These allow you to do per-pixel lighting, but they're not really unique to Q2W. DarkPlaces supports a modified Q3BSP format with the same additional information, and the added efficiencies of Q3's triangle soup.

Q2W's BSP compiler does fix a number of issues that the legacy Q2 tools suffered from, but to be totally honest with you, there's little reason to consider Q2W's BSP and compiler for a new project. You'd be much better off using idTech3 / DarkPlaces, idTech4, etc. If I were starting Quake2World today, that's what I would do.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: IdTech 1/2/3/4 BSP/PVS

Post by Spike »

nice necro!
leileilol wrote:If Q3 ever had to have a software renderer it would need to be done with entire polyblobs for everything instead. I'd still like to see abrash quake assembly code whacked into a q3 renderer somehow someday :P
ignoring trisoup, just generate edges at load time or something.
at the end of the day, you have to remember that software rendering is basically using megatexture - lightmap resolution rules accelerate ONLY that. you could implement q3 shader effects using some worker thread or something.
trisoup does make things more awkward, yes. trisoup is generally detailed enough that walking edge lists for each triangle would not help, drawing them like an mdl is not unreasonable. you just have to hope that they're vaugely megatexture friendly (as a group).

Jay, if you really feel that way about Q2W's bsp format, why don't you add support for q3bsp as well? note that you don't have to add support for everything at once, and that q3bsp isn't all that much different from q2bsp really, on the condition that you don't bother with patches just yet. non-solid trisoup is easy too (assuming you already have index lists per surface instead of depending upon polygons). you'd need to redo lightmaps a little (I assume you don't support lightstyles or r_dynamic any more, so you don't loose anything), but this should be simpler than q2's lightmaps, and would give per-material lightmap resolutions, which could significantly reduce your bsp file size.
the problem with doom3 is that it pretty much mandates realtime lighting. while you could make a tool to add static lightmaps to it, there's no existing infrastructure to make it easy. on the plus side, pure trisoup is where modern games are going. on the plus side, realtime lighting ensures that specular etc responds properly to lights instead of getting weird darkening effects due to deluxmaps only supporting a single lighting direction.
Which reminds me that I still need to work on FTE directly loading .map files...
Post Reply