What does Occlusion Geometry actually do?

BeigeAlert · September 2013

Now I want to clarify: I understand that it's there to help optimize the map and prevent things that can't be seen from eating up precious system resources by being needlessly rendered. I understand that, but still can't quite wrap my head around why it's needed. I've looked at the stock maps, and for the most part, the occlusion geo seems to be almost completely flush with the visible geo. How is this helping? Also, in some parts (like the cylindrical walls of Gravity in Descent) the occlusion geo is pretty dense, so I don't understand how that's helping performance, considering that, again, the visible walls are just as complex.

Okay okay, maybe that's just over my head, but at the very least, I want to know how lazy/diligent I need to be when making my occlusion geometry for my map. Does it need to match up perfectly with the walls, or can it be very loose?

Thanks for your patience, and sorry if it seems like I've been posting A LOT of questions on these forums.

SamusDroid · September 2013

It doesn't really matter how close it is to the wall it is. The closer the better, the more the better.

BeigeAlert · September 2013

I'm guessing there's diminishing returns for just HOW precise you are, correct?

Kouji_San · September 2013

OccGeo is simply giving the engine information about what to render and what not to render. As in helping the engine calcuate what is visible from the player's perspective.

The OccGeo itself isn't rendered, it's only there to serve as a informational mesh for the engine. And if you don't add it, the engine will render the entire map from any point.

Complex OccGeo causes more calcuations to be done afaik and is more accurate, in some areas cube based OccGeo will suffice.

BeigeAlert · September 2013

Thanks guys for your help! I think I understand a little bit better how to use it.

EDIT: Huh? Why's this in the "new player" forum? Did it get moved? I could have sworn I'd posted in the mapping section... sorry!

Kouji_San · September 2013

BeigeAlert wrote: »

Thanks guys for your help! I think I understand a little bit better how to use it.

EDIT: Huh? Why's this in the "new player" forum? Did it get moved? I could have sworn I'd posted in the mapping section... sorry!

Fixed

WorthyRival · September 2013

To best understand OCC I recommend opening a map in game
Then turn on cheats in console. by typing cheats 1
then turn on the wireframe view by typing r_wireframe
You will see the map being rendered as a wire mesh and you can now see through the walls in this view.
you will see exactly how the OCC works as you run around the map as it loads only portions of the map in your field of view in the distance as you move.

Without the OCC the entire map is rendered and is very taxing on your PC.
Hope this helped clarify how it works.

Good luck with your mapping.

Dr_Random · September 2013

If I remember my graphics classes correctly, I might be able to shed a bit of light here regarding complexity at least (please correct me if I misspeak). Beige, you're absolutely right in that there's diminishing returns on precision in occlusion geo. As Kouji_San mentioned, more complex occlusion means more calculations, so you want to avoid it being too complex. A good thing to keep in mind is that I'm pretty sure occlusion geo doesn't do anything unless it blocks all of a prop. So if you have a long prop that you can just see the corner of around occlusion geo, the whole thing still gets drawn. I don't know how this translates to drawing regular geometry (the r_wireframe thing WorthyRival mentioned can help find out, I'm sure). Generally I think you want to avoid adding any complexity to occlusion geo that doesn't block anything worthwhile (so not inside a narrow pillar perhaps, but certainly in a large wall between two rooms).

BeigeAlert · September 2013

Dr_Random wrote: »

If I remember my graphics classes correctly, I might be able to shed a bit of light here regarding complexity at least (please correct me if I misspeak). Beige, you're absolutely right in that there's diminishing returns on precision in occlusion geo. As Kouji_San mentioned, more complex occlusion means more calculations, so you want to avoid it being too complex. A good thing to keep in mind is that I'm pretty sure occlusion geo doesn't do anything unless it blocks all of a prop. So if you have a long prop that you can just see the corner of around occlusion geo, the whole thing still gets drawn. I don't know how this translates to drawing regular geometry (the r_wireframe thing WorthyRival mentioned can help find out, I'm sure). Generally I think you want to avoid adding any complexity to occlusion geo that doesn't block anything worthwhile (so not inside a narrow pillar perhaps, but certainly in a large wall between two rooms).

I figure it probably just goes polygon by polygon for regular geo.

I guess it just confused me that the occlusion geo in Gravity Control in Descent was so dense at that one spot. Why not simply have a big box around the cylinder? Oh well...

YerMom · June 2014

Old thread, but hopefully we can bump.

I'm having issues with my Occ Geo in tgns_tanith.

Let's focus on Sat Comm for now. I have made a box that goes around that room. It is slightly too tall, and I can adjust that, but it's basically just a cube that goes around the entire room. Before I wrapped Sat Comm I was drawing 7000-9000 in r_stats. Now that I have wrapped it, I am drawing 3000-4000. If I copy and paste the geo and flip the faces, I draw 300-500, but I am getting glitching in the room where half the room disappears randomly.

The occ geo is far enough away from the wall to not cause this, as far as I know.

Does anyone know why a single occ geo face is only performing at 50% efficiency in this situation?

Mom

BeigeAlert · June 2014

Send me the .level file and I'll take a look at it.

YerMom · June 2014

It's public. ns2_tgns_tanith on workshop is most recent version with issues listed above.

BeigeAlert · June 2014

I opened up your map. First off, the outward-facing box you duplicated isn't assigned to the occlusion geometry layer. I deleted this all-together, and that brought the draw calls in that area down to the reasonable 1000-1800 range.

Also, just as a convention, use the blue dev texture for occlusion geometry (search "dev" in the materials browser).

YerMom · June 2014

So, 1000-1800 is acceptable?

I wouldn't agree simply because that's where the draw was before I started redoing the occ geo and people were complaining about FPS drops.

Pretty sure I read somewhere or heard from someone that numbers like 500-800 are more in the acceptable range, obviously depending on where you are in a map.

I was like 99% that outside box was occ geo. Maybe I messed that up.

I'll give this a go tonight and see what happens.

Mom

deathshroud · June 2014

you only need to go into complexity with heavily detailed rooms, a basic box geometry is perfectly fine in most cases, the main issue is making sure there are plenty of corners within your level to reduce the amount of rooms rendered along a corridor otherwise you will get performance dips even with occlusion geometry due to poor level design

before i did occlusion geometry on my map it was spiking to 4000,

with occlusion geo its at less than 900 with the occasional spot at 1200

so it clearly makes a huge difference when done right.

SamusDroid · June 2014

Lava works good for making occlusion, really easy to see it. 1000-1800 has room for improvement.

BeigeAlert · June 2014

YerMom wrote: »

So, 1000-1800 is acceptable?

I wouldn't agree simply because that's where the draw was before I started redoing the occ geo and people were complaining about FPS drops.

Pretty sure I read somewhere or heard from someone that numbers like 500-800 are more in the acceptable range, obviously depending on where you are in a map.

I was like 99% that outside box was occ geo. Maybe I messed that up.

I'll give this a go tonight and see what happens.

Mom

I'm not 100% sure why the draw calls are still that high though... yes, 1000-1800 is decent, but like Samus said, lots of room for improvement. I'm wondering if it might be due to the way you've constructed your occlusion geometry. It looks like what you've done here is make a series of boxes and just cut holes in those boxes for the entrances. It seems to be working, but I'm wondering if the resulting overlapping polygons is causing something of a performance hit as well? Try this on Satellite Relay: extrude the exit geometry out so you get a little bit of a hallway, rather than a sharp-edged cut on the box. I've never had a problem with occlusion geo in my levels, and the way I do it is I basically make a box around each major area (a box, or blobby shape... w/e to fit the shape of the room), then drill holes in each entrance, similar to what you've done here, but then I connect the routes with occlusion geo as well, rather than giving the hallways their own separate box.

What does Occlusion Geometry actually do?

Comments