Blood Run [Release Candidate 1]

[Whirlingdervish]

I put it up on IRTDM2 for testing and it seems to work flawlessly on my server with OSP tourney 2.75 w/ gladiator bots

just ran a test match on it. I like the changes, and the structural work looks good.
Some of the movement feels a lot slicker now, although I can't put my finger on exactly why.

I think it's a combination of the higher ceiling in mega area and the stairs in most places seeming to work better for ramp jumps than they did. I'm able to get up some good speed and not lose it due to clipping on a step here and there.

good work! I'll try it vs people later and get some feedback

[X7]

I put it up on IRTDM2 for testing and it seems to work flawlessly on my server with OSP tourney 2.75 w/ gladiator bots

just ran a test match on it. I like the changes, and the structural work looks good.
Some of the movement feels a lot slicker now, although I can't put my finger on exactly why.
 
I think it's a combination of the higher ceiling in mega area and the stairs in most places seeming to work better for ramp jumps than they did. I'm able to get up some good speed and not lose it due to clipping on a step here and there.

good work! I'll try it vs people later and get some feedback

You got the nude Bots on?

 


X7

[Barton]

There's quite a few parts of the map that are laggy (hyperblaster room, RA room and RL room). It gets really bad if someone shoots chaingun, rockets or hyper in those areas too. 

Maybe it's me though? q2next1 lags slightly on my computer too even though I'm on a quad core and have a fairly new gfx card.

[themuffinman]

I put it up on IRTDM2 for testing and it seems to work flawlessly on my server with OSP tourney 2.75 w/ gladiator bots

just ran a test match on it. I like the changes, and the structural work looks good.
Some of the movement feels a lot slicker now, although I can't put my finger on exactly why.

I think it's a combination of the higher ceiling in mega area and the stairs in most places seeming to work better for ramp jumps than they did. I'm able to get up some good speed and not lose it due to clipping on a step here and there.

good work! I'll try it vs people later and get some feedback

 

Yeah mega ceiling is 8 units higher. More of the stairs now have side ramps for the ramp jumps (I might just put ramp clipping to all stairways, but that might be a bit much though). Quad/HB room has had major proportional changes since it was very flat compared to what it should be (which would make it feel different there too).

There's quite a few parts of the map that are laggy (hyperblaster room, RA room and RL room). It gets really bad if someone shoots chaingun, rockets or hyper in those areas too. 

Maybe it's me though? q2next1 lags slightly on my computer too even though I'm on a quad core and have a fairly new gfx card.

It runs alright on my old Celeron M notebook, I'm running all stock assets though, so custom models can affect performance.

I'm not too experienced with Q2 mapping but I might be able to optimise things a bit more for next release. Right now we're getting about a maximum of 4,000 - 4,500 in r_speeds in most areas with almost 7,000 in the Quad/HB room while on the window deck facing the rest of the room. Nowadays in Q3 a 20,000 r_speeds is acceptable, but Q2 might be a different story since it renders things differently. q2next1 maxes out at around 1,700. So I don't know whether someone here can tell me what a good r_speeds is in Q2? I do know that the bsp is getting quite big and is bigger than most other maps available in TS. Brush count is pretty much optimised. Optimising portal clusters might be the next thing to consider although I'm not sure how to do that in Q2.

Anyone else having performance issues?

[fdrjk]

Is the map on the tourney servers? I would love to play 2s on it. 

EDIT: It says I'm missing textures common/caulk.wal. 

[Whirlingdervish]

fader: I put up a texture on irtdm2 for that. you could just copy any texture and rename it that and put it in the folder. afaik, it is never visible in the finished map.

TMM: maximum usable r_speeds in q2 tend to be muuuch lower than q3. In the sub 1000 neighborhood will be smooth as glass. Up to 1200-2000 can work ok with only a minimal drop in fps given the right conditions. A lot of the time it will depend on map loadout and the other tris drawn (models and such).

2 players on 1500 tris isnt so bad. Put 8 in there and have them shoot stuff around, and you'll see significant performance hits.

a few things I know  that will help with high r_speeds are:

Original brush shape and overlap in editor:
The biggest changes I have seen in overall r_speeds and vis time and map performance, have come from correctly building a map from brushes in the first place. If you can minimize the number of times that a brush intersects with another in the editor, qbsp will have less problems cutting up the map into portals and tris and usually it will not make more cuts than needed. (creating exponentially more tris than needed) Using a standard sized grid (8, 16, 32 etc) in the editor and locking the vast majority of the maps brush points to whole number grid points will make the math involved in the automated bsp process much more efficient and error free.

Say you have 2 walls/trims/floors/brushes coming together into a corner, end both brushes exactly on the same grid point in the editor and adjust them so they meet up perfectly and dovetail together like you are a master woodworker.
Once qbsp picks the plane on which a shape is being cut it will use this plane to cut adjacent tris as well, which can cause you untold headaches if you don't consider it ahead of time. (high rspeeds, lighting errors etc..)

The effect in the map is not even noticeable visually, but to qbsp, which cuts everything up into the shapes the renderer will work with, it is hugely different:

ex:



Hint brushes:
The correct use of hint brushes can make a world of difference in q2 to minimize the useless tris cut from your brushes
(excessive cutting of the map by qbsp into way more tris than needed to draw the same thing)
They can be used to intentionally set the planes upon which portals and thus tris are cut up to make the .bsp.

Sadly, explanations on correct hint brush usage are few, far between and not always clear.
I will try to find some on the forum here, and you might want to look on the q2c forum as well, as I recall there being a couple decent tutorials around.

edit: found one I saved from Rust: Game Design forums -

http://dervish.tastyspleen.net/rust/tutorials/hint/hint.htm


Details flag and func_wall usage:
Other options are use of the detail flag on brushes that make up decorative bits, and in some cases I have had good results from taking large set pieces and making them into func_wall entities to entirely remove the excessive cuts on the wall where they are located from the portal creation process.

edit:

this thread had some good shit in it:

http://tastyspleen.net/quake/forums/index.php?topic=12348.msg127146#msg127146

[themuffinman]

Most of my geometry is detailed, just a simple outer shell is structural. If you decompile the map you'll see that I prevent the whole T-junction and overlapping brushes issues etc. with my brushwork as well. I don't say it's perfect though - there's still places where I can improve.

Yeah hinting is what I should do. It's just time consuming to get it right. I had already tried splitting up rooms via area portals earlier in development but for some reason they don't draw anything beyond them when they're in the line of sight, so they act more like hints.

I've got a bit of work to do to get that 1,500 count 

[Barton]

It runs alright on my old Celeron M notebook, I'm running all stock assets though, so custom models can affect performance.

I'm not too experienced with Q2 mapping but I might be able to optimise things a bit more for next release. Right now we're getting about a maximum of 4,000 - 4,500 in r_speeds in most areas with almost 7,000 in the Quad/HB room while on the window deck facing the rest of the room. Nowadays in Q3 a 20,000 r_speeds is acceptable, but Q2 might be a different story since it renders things differently. q2next1 maxes out at around 1,700. So I don't know whether someone here can tell me what a good r_speeds is in Q2? I do know that the bsp is getting quite big and is bigger than most other maps available in TS. Brush count is pretty much optimised. Optimising portal clusters might be the next thing to consider although I'm not sure how to do that in Q2.

Anyone else having performance issues?

Looks like it's me. Apparently my gfx driver or something doesn't like r1gl. I have no noticeable lag with opengl.

[themuffinman]

Not to worry though, I've improved performance considerably. For instance r_speeds in HB room has gone from 7,500 down to about 1,500 now. The rendering performance is roughly 60-80% improved for the next beta.

[themuffinman]

Release Candidate 1:

Changes:
- Drastically improved rendering efficiency (r_speeds max at around 1,500 now)
- Aesthetics practically complete
- Working locations file
- Only one map now: bloodrun.bsp. Uses DM layout as default, use included tourney entity override if desired
- A bunch of other minor changes

To-Do:
- Fix spawn issue in OpenTDM
- Fix a few shadowing glitches
- A few other really minor things
- and...?

Download:
http://www.mediafire.com/?3iduc51ye8m31tw

[st1gmata]

wow! awesome work. would be nice to use 32bit textures. please use it for yours map man!

[themuffinman]

wow! awesome work. would be nice to use 32bit textures. please use it for yours map man!

The reasons I used stock textures:
1. ztn tended to only use stock textures
2. it's time-consuming to put together a good set of hi-res textures, and won't look much better in Q2 anyway.

In any case, you can use hi-res replacement textures.