if you know what I mean. 

Screw The "R_speeds Thread
#25 posted by Trinca [89.180.152.44] on 2008/04/17 01:05:52
we want PORNO!!!/i>

Every time I screw the R-speeds, they turn around and bite me on the ass. 

distance fog culling baby
and I leave it to you to find out how to do that (yes you can) 

you could easily hack vis to exclude leafs based on distance rather than using portals. 

I experimented with that briefly speeds... I figured if I used the -visdist option (if that's the one) and had some fog in the level it might work.

In reality the limited vis distance thing seemed a bit unpredictable (I guess it depends on how large the leafs and stuff are etc). Perhaps with a larger distance set it'd be useable (I tried something small like 512).

I also don't quite know how Quake fog generally works, since I've never used it in a map myself. Is it possible to set it up so that it does completely obscure vision beyond a certain distance?

Of course, I didn't play around with it much and you're probably talking about a different method anyway! 

obscure vision beyond a certain distance.

type "fog 1" to enable very dense fog. It works the same as r_wateralpha, 1 is completely opaque and 0 is completely transparent (off), so "fog 0.2" would give quite thick fog. For a subtle fog effect try "fog 0.02" for example. You can set the colour too: "fog 0.02 0.5 0 0" would give thin red fog. It's "fog density r g b"

Here's the readme from AguirRe's engine:

http://user.tninet.se/~xir870k/readmegl.txt

I dont know how much of the syntax is compatible with FitzQuake, but the simple "fog density r g b" command works in AguirRe's and FitzQuake - That's the command I was using to enable fog in the "pit" area of The Hand That Feeds You.

Go experiment! If you want thick fog try anything above "fog 0.5". Infact that will be VERY thick! "fog 0.2" is quite thick . . . 

There are two main issues with fog culling.

1. Distance-based culling works in a sphere around the camera, but opengl fog uses the "depth" to calculate fog thickness, and that means you can only safely cull stuff that is on the far side of a plane that is parallel to the viewplane. In other words, objects on the edges of the screen might be outside the sphere but inside the far clipping plane. Another way to see this is that you can see objects clearer if you turn so that they are in the corner of the screen.

2. Linear fog eventually gets to fully opaque, but exponential fog never quite does. Though I guess it gets close enough, so maybe this isn't quite an issue. 

Yeah! Use fog culling so the huge maps don't show their hugeness. That's exactly what map-penis-aware mappers want!


Btw most engines render fog differently (and ugly). 

If you mean the current version of DP, try using an older (less bloated) version with support for the format or the nehahra engine. Though I wonder how big of a task it would be to port bare bones Q3 support to fitz/aguire. 

The only other thing needed for distance vis/fog would be a skybox of the same same (flat) colour.

That'd solve artefacts with metslime problem #2 and ones in the skybox for #1 (since there'd be no visible sktbox). But it'd still reveal geometry if you turned your head.

TuroQuake! 

is it "gl_farclip" command?

Couldn't you use that to make sure you can't see anything past a certain distance? 

Linear fog eventually gets to fully opaque, but exponential fog never quite does. Though I guess it gets close enough, so maybe this isn't quite an issue.

I guess this is what I was wary of... some implementations of fog I've seen do the latter (never quite go fully opaque) and this certainly would be an issue if you had a limited draw distance, and everything beyond that was not rendered (HOMtastic!)

To use the technique I mentioned earlier, you'd need:

- carefully chosen visdist parameters combined with intelligent brush placement to encourage the desired BSP chopping
- probably some very good vis blocking in addition to that anyway (or let's say player line-of-sight blocking, at least)
- fine control over fog settings (e.g. ensure that it goes fully opaque at a specified distance from the camera)

Would it be worth it in the end? Probably not, even if it worked. It might be fun to experiment with this on a small scale first though, to test the waters. 

http://speedy.planetquake.gamespy.com/screens/fogcull2.jpg
the map also was like 10k x10k units running in DP only. on a 300mhz cpu + voodoo3

oh dear, this is dated 2003 /me cries 

and on a serious note 2000k r_speeds ELEK`s cathedral map ran fine on that very same old 300mhz in MHquake. cause it doesnt have any monsters.
people always look at w_poly, but its often e_poly going over the roof with AI, collision and dynamic lights from all those monsters that bogs down the performance

Does anyone still have something like 500mhz celeron? would be interesting to do some testing.
Or whoever here has the slowest PC - lets set him as a benchmark. whatever`s playable for him would be playable for everyone else. 

somewhere in my 'cupboard'. Under a big pile of old clothes and empty boxes....

...I could use that!

Anyone wanna go lower?

Also in all seriousness is there a way of benchmarking demo playback in Quake1?

If so we should pick a map + demo for the purpose!! 

timedemo demoname

whats the highest r_speeds map with the most monsters?
could try the final arena of 5river land - that wasnt very smooth even on my athlon 2.2 

http://shub-hub.com/files/maps_singleplayer/lr.7z
(lrb.bsp with 1200 monsters)


http://urre.quakedev.com/stuff/spcscr_test1.pk3
(that DP only ´largest map´) 

those are disqualified for crashing fitzquake! 

You know you can up the edicts limit. What was the command to do that?

I know this might sound tarded but how about Slave? r_speeds are quite high but it'll run in any engine . . . Also there's a couple of speed runs already made....

The fact that it uses Quoth2 - this could be a problem? Thos who have played it - I think the worst area is the walkway leading across the side of the outdoor area, where the Feind jumps across. 

Slave? huh does it have any really bad places?
its not about overal map testing, more like finding out at what r_speeds it gets unplayable (~ below 25 fps) on and old pc like that, so just try to see the worst places.
I reckon that overall the fps would be good 

The area out side which the player starts in is the worst. You end up in that area a few times as you progress through the map. Whan I made it I was aware i was making a bit of an "unoptimized pig" of an area, so I went to great lengths to make sure that the rest of the map has good vis blocking. And it does! But try it Speeds, the very first door you approach, what are the r_speeds there (high if I remember correctly).

I dunno, it's a suggestion. We should probably maybe go for something which uses standard progs I guess....

Wasn't Hrimfaxi's Cappuccino quite bad in places (somebody mentioned it when ranting about one of my levels)? 

http://www.speeds.quaddicted.com/lolslave.jpg
well, you should`v closed the roof or just placed some skybrushes there. lots of stuff being drawn that you cant possible see.
still 2600 woply and something like 10000 epoly of the idle monsters is not that horrible 

Hence the name of the map. 

http://www.speeds.quaddicted.com/screw_r_speeds.jpg

12k wpoly is as much as I got w/o breaking 32k marsurfaces limit. unvised. 48 monsters, collision hulls optimised tho. still runs at ~33 fps on my athlon xp 2.2 and bambus has ~30 on atthlon xp 1.8 in fitz

who uses a slower PC to play quake? 

http://www.speeds.quaddicted.com/maps/rspe.zip