Hi,

I'm doing some performance tests for a plugin I'm writing, and would like some clarification on how clipping behaves,
and when does it kick in in 3DGS.

Specifically, I would like clarification on the following:

I have a test level with 240 "guards" roaming around, and have noticed that if I stand in a corner of the map,
and turn around (i.e. I'm not looking at the entities), then the fps goes up...fine, I expected that.

If I look towards the entities, then my fps drops...which I also expected.

However, if I look towards the entities, but have an obstacle directly in front of the camera, which prevents me from
seeing anything, then the fps stays the same?? I was under the impression that this would be the same effect
as "turning around" and facing the wall (i.e. not looking at any entities).

Can someone explain how this works? Is there some kind of flag that I can give the obstacle to "tell" it to clip
whatever is behind it? Does it depend on what the obstacle is (i.e. a model, map entity, etc...)

thanks

depends on varions things. if the obstical is just a block in a single room won't effect it as say 2 seperate room blosk with a path between. the obstical a bock or a map entity/model? the 2 later won't effect it ( actualy increase the face rendering so lowering frames more)

don't use the Detail check box as it makes it soemthing 'transparent' far as blocking rendering view is concerned. so a detailed block is ignored in deterining what to render within the POV.

# of faces (poly count) per mdl effects fps as well because blocks are processed during build time for rendering, lighting,shadows. models are redered at runtime within POV and cliprange

Thanks for your reply Grimber.

In my test level, the obstacle is just a regular block...so if I understand you correctly, this will not
be considered during clipping.

Quote:

---

if the obstical is just a block in a single room won't effect it as say 2 seperate room blosk with a path between. the obstical a bock or a map entity/model

---

I'm not sure I fully understood this previous statement...could you re-phrase that another way please?

thanks

Sorry i was tired when i wrote that. see if i can make more sence of it myself today



I removed the tops off these rooms for an example

Our player is the model is in the blue circle

the blue block circled in white does not go all the way to the ceiling
the round block in red is a map entity
the white block in the far room is set with detail flag

any model, map entity, hightmap, sprite don't calculate into blocking view as far as rendering goes. even if you cannot see behind it, the Engine can so renders it
blocks set to detail, overlay,flare and transparent also fall into this catagory

so out example above the round block in red circle doesn't block engine rendering of anything behind it, the room walls DO block the rendering view of anything in the next room minus the tunnel we have carved out

the white block doesn't block the engine from rendering anything behind it.

now, the booger. our blue block in yellow circle...
this creates some real time rendering issues because it doesn't totaly block the area behind it from view even though it WOULD block the model badguy from view behind it. ( this is also a cuase of why some portal counts go a bit haywire in builds). the engine can see over this block to the area past it ( the corner of the room) so now it has to calculate what is all back that way untill it reaches a defiant stop in visiability range. this will include entities behind the block even though you can't see it it in a sence forces rendereing.

If we take the white block in the backroom, turn off its detail flag and be sure it runs all the way to the ceiling it will do as we want. block the rendering of an entity behind it.

now you may say" well in an outdoor area then putting up visability blockers" won't do much good because i can't realy run my walls all the way into the sky." in a word " yep" but also no. the trick is making the POV blocked, the less distance you ( and the engine) can see beyond a given point the less the engine renders. so less it has to render at a given time the less frame rate loss you get. period.

on an outdoor level area you break up what is visible, by distance and by not placing all your eggs in one basket, or in this case placing all your entities within any one POV posability. shape your levels so the player cannot see or move straight for any length of significant time and so the PoV from oen area to teh next in your level isn't a straight line.

If you want a big flat out open area then you need distance, its where cliprange and fog and LOD come into play bigtime. even reducing the POV angles help on this.


the key is not what you can see but what can the engine see during runtime. remove the objects out that the engine sees through, deterime your POV, factor in the clip range. typical 3D engine on a desktop machine will be stressed past 15k-20k polys in a POV ( aprox 20-30 entities depending on poly counts each) rendered at a given time

I should clairify what i mean on ' blocking' a players POV.

it doesn't always mean placing a physical block in the way, ( but thats a normal way), but also means channeling the players POV.

A 'normal' player will instictively turn away from natural bariers if they know they cannot go over /through them to find way around that obstical. like a mountain or a wall, so they will turn thier POV in order to navigate around it. So to reduce clipping problems ( low frame rate) you spread your entities out so not too many are in a single given view angle then direct the player to not be looking in one direction for long by controling the flow of direction(s) they travel.

Pick up most first person shooter games for example. in many of the more memerable ones here are things you see ( or actualy don't see)

viewing from one room to the next is limited. ( normaly cannot see beyond 3 rooms in a row stand in room x, see into y, and see the entrance area to z)
transitions from one room to the next usualy don't face eachother
to restrict flow through views

large open area usualy don't have too many moving things in them and many larger rooms are broken up with smaller objectc the player has to navigate through. so making the player change pov allot to get around

enemies usualy arn't thrown at you in a BIG cluster but waves in larger fights.
though may not seem like a wave 1 attacks then another, then 1 dies another is brought in and so on. reduces number on screen at any given time but in the end same effect

many transitions in a level up and down block allot of visual range front back, left right

BTW some MMORPGs are bad examples of clipping managment, or you could say good examples of clipping missmanagment. they try to cram too much into any pov, especialy animations which ultimatly kills game play. ( if you ever played EQ ruins of Kunark aroudn the newbie areas, or did an RVR or dragon raid in DAoC then you know. way too much then the engine can handle)

Woah !!!

You did a whole lot more than the simple clarification I was expecting.

I now understand (and know a lot more) about how the engine behaves than I did before. This information will help
me quite a bit in my current (and future) projects.

Thank you very much for your time and effort...very much appreciated!

well i can't say its accurate. only the devs know how the engine works internaly. I've made a few 3d engines ( no better then doom equivalent realy which is just a few steps away from quake).

biggest problem is how is the engine calculating for POV. most 3d engines even today rely on a ray-casting system of some form( direct x and direct 3D just makes it fesable to run a good framerate in realtime) which is a reversed form of your raytracing programs. ray casting is basicly draw a line/vector out from your character pov like going left to right, collids with a an object in the map calculates distance and off known data form the level info knows that its X high z wide.. so can scale the size of it to set the object persective wise on distance away. BSP / portals can precalculate much of this but moving /shifting changing objects ( entities) have to be calculated in run time time .

so anything NOT in your POV is not renedered/calculated. but internaly the program itself updates postional data during runtime.

a model has to be rendered face by face in runtime. mroe faces longer it takes
Now between rendering, data update behind the POV now you should see why most 3d games are made for LOW poly models. all them polys just add way too much exrta calculations to do.

you can pick up a few good books on 3D engine design. its allot of trig
especialy blackbox trig to help speed up the calculations ( like bit shifts and lookup tables)