Fog, clipping plane included?

[Emon]

I know for some games, they use fog in huge open areas to cover up the details in the background and improve framerate. It usually (I think) does this by not rendering the faces in the opaque areas of the fog, improving framerate. Does JO do this same thing?

[idontlikegeorge]

maybe... i noticed in the scripts they give you in the 2d pack, in the yavin_canyon/range_1 script there is:

set ( /*@SET_TYPES*/ "SET_VISRANGE", 4000.000 );

 

???

[Karshaddii]

Actually what the fog is is a cover up for the vision range. Volumetric fog by itself makes the fps go FPHUMP--oh wait, your Emon--you probably already new this = )

[Emon]

The regular fog brushes aren't volumetric. The volumetric fog is like the fog above the water on the Yavin Swamp, it has volume to it. It's also extremely slow.

 

I'm pretty sure it does help, because in tons of other games like Rogue Spear and Ghost Recon, they use the same thing. RS uses a old fashioned clipping plane with fog over it (optional depending on the map) and GR uses just fog.

[idontlikegeorge]

 

so was the question answered?

[Karshaddii]

Yes.

 

See, all you have to do to answer Emon's questions is post something blatantly stupid or wrong--and he will correct you and solve the problem for himself.

 

"think outside the box"

 

or was it....

 

 

But seriously--Yeah--a TON of games use fog to speed things up--in fact--I'm having trouble naming one that doesn't...

 

But Emon--to be....philisophical...?...My in my sp level, Massassi Catacombs--on the top in the swamps I filled a large area with fog--and the frame rates dropped--even thought it covered up a BUNCH of polygons. I am not quite sure why--but it did...and yes...my video card can handle fog QUITE easily

 

[Emon]

Okay, I was asking a question, that's all. I'll do some tests later to get some real results.

[Drakewl]

Karshaddii, how much polys did you hide behind the fog?

 

i ask this because of the following

 

 

i know a similiar case, this time with visibility culling (polygons behind other polygons won't be rendered in realtime processing).

 

First i have to say, that visibility culling needs a base amount of processing capacity, no matter if it has much to do or almost nothing.

 

You have two large rooms, one with 10 pillars, the other one with 100 pillars. Visibility Culling in the first room has almost nothing to do, but its eating performance, this way, you would get a better performance when switching off vis culling. But in the room with 100 pillars (many polygons) the vis culling will increase your performance remarkably in contrast to the same scene but this time without vis culling.

 

 

So maybe its the same with fog, who knows

[RichDiesal]

Except that JO doesn't do realtime visibility culling... that's what the VIS process does during compile, to prevent the processor from needing to use those cycles during gameplay.

 

Thus, fog works the same way. It in no way affects triangles visible to the engine, as all of that is calculated at compile. Other game (Medal of Honor and Grand Theft Auto 3 come to mind) use realtime visibility calculations (a dynamic movable clipping plane) and draw fog beyond that plane. JO (in fact, the Q3A engine in general) does not support this.

 

Fog in JO is a particle effect, not an actual visibility function, and thus does not affect framerate in that way (although the high particle count will very likely decrease framerate).

[Emon]

Bah! There isn't any way to make a clipping plane yourself or emulate it, is there?

[fourwood]

This is why you need foghulls. ...bwahahha.

[Emon]

What?

[Karshaddii]

How many polys?

 

Heheh, lets see.

 

I had *about* 200 brushes I was hiding. BUT--those were heavily altered brushes using the vertex tool--each brush having anywhere from about 8 sides to 15 sides. Plus I had exactly 15 tree models.

 

And Emon, I wasn't trying to be mean

[Drakewl]

look at this, i think we have a clear answer to emons question now

 

 

http://zerowing.idsoftware.com/archives/gtkradiant/2002-February/002103.html

 

 

 

and some corresponding threads from quake3world-forums, just use the search function for "foghull":

 

#1

http://www.quake3world.com/ubb/Forum6/HTML/019997-20.html

#2

http://www.quake3world.com/ubb/Forum6/HTML/019997-21.html

[Emon]

!!!....!!! I'M GOING TO TRY THAT RIGHT NOW!

[Drakewl]

much success on it, should work hopefully

 

and pls tell us your results

 

thx

[Emon]

I wasn't sure about that one because, the link he posted...

 

 

Instead I tried the distancecull key of worldspawn, set it to 384, not far, I know. I tested it in the duel_valley level that comes with the second SDK, and it works, and it's much faster than without it. Only problem is that it creates HOM. I'm trying to solve this now by using global fog which will be opaque before the distance cull, that HOM clipping plane is never seen, and you still get a huge FPS boost!

 

I'll let you know how the results are.

[Drakewl]

aahh, i didnt read the threads of the links i posted very carefully, wasnt aware of the point that they are referring to ydnars q3map that doesnt has jko support yet. But now reading all those posts, i want q3map2 more and more

 

 

back to culling

 

in the days, i did my first attempts on radiant, i made a group of large rooms and used the distance cull parameter, which resulted in the HOM effect, that i didnt know much about, i was just wondering what happened to my map . then i was deleting the parm and not discovering its function some more, i had other more weighting problems at this time

 

 

but it seems, we will get out performance boost with fog

[Emon]

Worldspawn ambient fog seems to make my level entirely dark... I'm trying just a huge fog brush right now.

[Drakewl]

by the way, ydnar gave some words on the progress he made on jko/sof2 support of q3maps

 

 

  Quote

I have done preliminary work on SOF2/JKII support, but nothing further. The two games use a different BSP format (RBSP rather than IBSP) with some extensions to the various components. The hard part will be supporting > 1 BSP format internally, as the code is currently hard-wired for the Q3/Wolf/EF BSP format.

 

On a side note, -game ef now supports Elite Force (preliminary). I haven't worked out the per-game surfaceparms yet, so the EF forcefield won't work properly.

[Emon]

I think I got it working. Just use distancecull XX for the number of units to cull, then use a fog with an opaque distance just less than that, and it'll look seamless. I was using a fog with 4000, and it removed the HOM, and stuff still culled at my 384 units, but it was ugly. The fog was fine but stuff would cull, and when it did it just disappeared into nowhere, ya know? So if you disguise it with fog you'll never know!

[RichDiesal]

That is quite slick. Mmm...may hafta take advantage of this in the near future.

[Emon]

I can't imagine it having a practical use unless your map is huge and open, like mine will :-)

 

I'm not sure what these foghull think fourwood speaks of, but it's probably something that won't happen until Q3MAP2 support for JO...

 

Damn I can't wait for that! Faster compiling, more reliable auto-cull than SOF2MAP, fixed MP metalsteps, better lighting. Hmmm...sexy.

[RichDiesal]

Eh, I'd rather wait for the Doom III editor.

 

New screens out on Gamespot, by the by... the fully dynamic lighting effects look slick.

[Emon]

I was talking about Q3MAP2, the compiler, not an editor...

 

Doom III will probably be all brushes like Q3, so that sucks ass. Sector and brush combinations like the Unreal Warfare/Unreal engine are the best, no doubt.