What are you working on?

[Jay Dolan]

Currently setting up Jackhammer config and converting id1 textures to .wal format, with the endgoal of converting episode 1 into Q2BSP format. Jackhammer config testmap looks coool so far with rad.

Learning a lot about Q2 mapping in the process, probably post a guide or something later once I get it all figured out. Amusingly, regular light ents now give off an infernal reddish light... >=D

Whoa, really? That's super cool! Would you have any interest at all in porting Episode 1 to Quake2World? Because I've been absolutely dying to get dm4, dm6, start, and e1m2 into Q2W. It'd be like porting them to Quake2, but you'd use high-res textures and normalmaps (QRP, Rygel, ..). Please let me know if you're at all interested in this. I'd love to work on it with you.

As for what I've been working on lately, here's a video showing off the new shadows in Quake2World. These are planar projection shadows with per-pixel attenuation. They're poor-man's shadow volumes

http://youtu.be/GtZLPJkrcs4

[Dr. Shadowborg]

Whoa, really? That's super cool! Would you have any interest at all in porting Episode 1 to Quake2World? Because I've been absolutely dying to get dm4, dm6, start, and e1m2 into Q2W. It'd be like porting them to Quake2, but you'd use high-res textures and normalmaps (QRP, Rygel, ..). Please let me know if you're at all interested in this. I'd love to work on it with you.

This is primarily targeted at FTEQW, not Quake2 proper.

I don't really know much about Quake2World, much less anything about normalmaps, so talk about that will have to wait until later. (I have a LOT to learn at this point, LOL)

I do plan on releasing the map sources once they've been cleaned up / ported. Ran into a bit of a snag though, most third party map compilers don't support the Valve 220 / Jackhammer .map format. (which means I'm either going to have to find somebody willing to port the tyrutils / BJP Valve 220 stuff to the dewan / jitspoe compiler, or do it myself at some point...)

Also, noticed that FTE might not support some surface flags (flowing) at this time...have to ask spike about that stuff later.

[Jay Dolan]

This is primarily targeted at FTEQW, not Quake2 proper.

Oh! So.. why Q2 BSP then? What's the advantage, besides colored lighting (which is possible without moving to an entirely new BSP version)?

[Spiney]

As for what I've been working on lately, here's a video showing off the new shadows in Quake2World. These are planar projection shadows with per-pixel attenuation. They're poor-man's shadow volumes

http://youtu.be/GtZLPJkrcs4

Any reason to do them planar? I guess it saves a crapload of fillrate, but I assume it's pretty involved to get them robust enough? Looks great though!

[Dr. Shadowborg]

Oh! So.. why Q2 BSP then? What's the advantage, besides colored lighting (which is possible without moving to an entirely new BSP version)?

MANY, but this is the biggest reason for me at this time:

1. QBSP / BSP2 / 2BSP only supports THREE hull sizes for world collisions. (point, player, shambler) VERY annoying, if you want to do real crouching, and well, monsters that have sizes between or larger than those three sizes. Q2BSP is NOT limited by this.

Q3BSP isn't really viable for my needs in making a freeware standalone game due to it's lack of lightstyles, and FBSP's lightstyles are somewhat limited.

Somebody once did a breakdown of the different BSPs with what you gained / lost with each format somewhere on I3D, but I've forgotten what thread it was in.

[Jay Dolan]

Any reason to do them planar? I guess it saves a crapload of fillrate, but I assume it's pretty involved to get them robust enough? Looks great though!

Yes! I am not smart enough to implement shadow volumes These are _reasonably_ robust, not great, but they're cheap and they look good most of the time.

It's funny, most fast-paced shooters have completely punted on shadows these days, and now I fully understand why.

[Barnes]

Shadow volumes ideal thing for closed levels. But if we need add shadows from bsp-bmodels, otherwise the shadow will "break through" the wall (like q3 with cg_shadows 2)

[Jay Dolan]

Oh! So.. why Q2 BSP then? What's the advantage, besides colored lighting (which is possible without moving to an entirely new BSP version)?

MANY, but this is the biggest reason for me at this time:

1. QBSP / BSP2 / 2BSP only supports THREE hull sizes for world collisions. (point, player, shambler) VERY annoying, if you want to do real crouching, and well, monsters that have sizes between or larger than those three sizes. Q2BSP is NOT limited by this.

Q3BSP isn't really viable for my needs in making a freeware standalone game due to it's lack of lightstyles, and FBSP's lightstyles are somewhat limited.

Somebody once did a breakdown of the different BSPs with what you gained / lost with each format somewhere on I3D, but I've forgotten what thread it was in.

I'm not aware of any implicit collision limits in either Q1BSP or Q2BSP. That's purely up to the collision model implementation. You're right, Quake2's implementation uses arbitrary bounding boxes, but there's nothing baked into the BSP that facilitates this. As far as collision goes, for all 3 engines, the BSP is just a tree of planes. Q3 goes farther and includes bounding box as well as spherical collision models (I think).

Maybe I'm wrong, but I've spent an awful lot of time with the Quake2 code base..

[Jay Dolan]

Shadow volumes ideal thing for closed levels. But if we need add shadows from bsp-bmodels, otherwise the shadow will "break through" the wall (like q3 with cg_shadows 2)

Yea, you're right; shadowmapping or shadow volumes are no doubt technically better. However, I wasn't kidding when I said I'm just not a strong enough programmer to pull them off -- or certainly not in any reasonable amount of time. So I took the planar shadows idea and made it a little better by:

1) Writing a pseudo-unique value for each plane to the stencil buffer as world surfaces are drawn.
2) Using the stencil test to clip shadows to the appropriate planes when rendering them.
3) Creating a shader to attenuate the shadows to the radius of the light source.

With this in place, shadows don't hang over ledges, very rarely bleed through walls, etc.

Mesh models in Q2W can have up to 8 light sources (illuminations) and cast shadows onto as many as 8 planes. These aren't 1:1, tho. A given illumination from a strong light source might produce 3 or 4 shadows, if it casts to that many planes.

In order to resolve impacted planes for a given illumination, I perform a handful of traces from the light source through the bounding box of the mesh. I accumulate up to 128 shadows for each mesh, and then sort them to keep only the strongest 8.

Illumination and shadow information is cached on the client entity structure, and only updated when entities are added, translated or rotated. So for pickup items and static models, this is a no-op once the map loads. For players, it results in a couple dozen traces per frame, per player. Not too bad.

[Barnes]

I not seen your code more time ago, remember what it was all very cool optimized for rendering. I studied like you did deluxe maps, but i make my version, and without any compiler But i wanted shadows from all objects and.... make like d3 engine...

[Dr. Shadowborg]

I'm not aware of any implicit collision limits in either Q1BSP or Q2BSP. That's purely up to the collision model implementation. You're right, Quake2's implementation uses arbitrary bounding boxes, but there's nothing baked into the BSP that facilitates this. As far as collision goes, for all 3 engines, the BSP is just a tree of planes. Q3 goes farther and includes bounding box as well as spherical collision models (I think).

Maybe I'm wrong, but I've spent an awful lot of time with the Quake2 code base..

Hull sizes are baked into the qbsp and engine. Yes, I could try to change / add extra hull sizes via modification to the engine and compiler...but why do that when it would be much better and easier to just use Q2BSP anyway?

[Spike]

the difference between Q1BSP and Q2BSP collisions is simply this:
Q1BSP is just a load of planes.
Q2BSP has the planes stored in convex brushes.

that is, Q1BSP uses the BSP tree itself for the collision, while Q2BSP merely uses it to find the appropriate brush.
This means Q2BSP can expand the size of the brushes for the collisions (after walking the bsp and following more nodes than strictly required), while Q1BSP cannot and thus can only support point-sized collisions.
Which is why Q1BSP actually contains 3 separate BSP trees (HL contains 4, H2 contains about 6). Each BSP tree is build from pre-expanded brushes, which is why they can't be changed other than by hacking the qbsp and recompiling.

[Jay Dolan]

Wow! I did not know that. I've spent thousands of hours in the Q2 code base, but only a handful in Quake or Quake3.

Learn something new every day!

Edit: This means Quake likely doesn't contain the hell that is CM_TraceToBrush

[jitspoe]

Haven't posted in a while -- here's a video of some of the waypoint AI stuff I've been working on

https://vimeo.com/116576240
https://www.youtube.com/watch?v=jphSKHwGjOw

(Same video, different sites).

[qbism]

AI - the realtime feedback on node placement and bot summoning is cool. One of the crates appeared to be offset a few units from the palette below, creating a thin ledge. Was that tripping-up the bot ?

q2bsp vs q3bsp - q2bsp lighting is additive, q3 is a multiplier. The q3 method is faster but dynamic lighting fails in dark areas. Anything x 0 = 0.