Rendering and Default VIS-

I loaded a level with a scene of building-structures. All of them were MDL's .

18 large MDL's

The default.c dbug panel shows vis = 18 when the whole level is behind the camera 'me', and not in view.

Is the vis- bugged or is the engine counting a large area behind and out of the view as visible and rendering it to some extent? It seems a mdl must be quite far behind the camera to not be counted.

I assume it's checking the large BBOX's and the polygon flag doesn't change this.

But still...

These would mean in a MDL level I need to cut up models into smaller mdls that fit well within a square BBOX? Or is this just a odd waste of rendering power to keep 'live' a large space behind the camera?

{UPDATE}
ent - confirms it's rendering

Odd, walk through till nothing is visible and 18 drops to 17, then stand still and pan left or right ->>> Vis drops to 0 and ent drops to 0, then pan back to center vis goes back to 17 and ent as well.

The size of the rendered area center behind the camera is very LARGE!

set your level size correct , secondly draw the bounds to see , you could try setting bounds smaller too if iys the issue , its good to have bounds that divide space equally but depends ..

, yeah I noticed this too a few times, could it be a bug or maybe difficult to optimize?
With my current project I too have the f11 debug window states that some entities (normal character size with correct bounding boxes) are visible/rendered while they are definitely not visible in the camera view angle (e.g. they are north of me while I am watching towards south). ps: dont know if it matters much but I use shade-c.

I'm not. But I'd think with shade-c these ent's are still running shaders at an even bigger waste.

I'm going to ask around for some answers on this.

Did you try moving even further away?
I would expect them to test the view frustum against the bounding boxes and it might be that there are still some overlaps even if you think there shouldn't be, but those should disappear given enough distance of course.
Shaders shouldn't really impact performance for this since the slow part is usually the pixel shader which won't be executed if the object isn't visible.

[quote]
These would mean in a MDL level I need to cut up models into smaller mdls that fit well within a square BBOX?
[\quote]
That's how you do it. The hard part is finding a good balance between effective culling (10k triangles more or less don't really matter for performance, but if you can save 100k it might be worth it) and not having too many objects (lets say ~3000 in total, although this number is somewhat arbitrary) in your scene.

I am not sure about the shape used for culling btw, it might just be the bounding box, but it could also be something bigger like a sphere (makes the check if visible or not quite fast) or whatever...