view Occlusion blocker

#1 Very interesting. I would love further information on this. Nice work

#2 Fun! I'll have to check this out!

#3 Well done! Now, that's useful.

#4 How hard would it be to make it occlude hidden triangles instead of the whole shape thats behind it?

#5 @Adam That would be very computational expensive, if it were even possible. I recall reading at one time about video hardware that tried to do just that but it never paned out. Logically the render engine would now need to 'think' about each and every triangle and decide weather or not to render it, spending even more time then just spitting all the triangles out.
In the very end, it is not rendering the polys who slow down the FPS, as much as all the other FX(shaders dynamic light...) on top of the polys who need to be computed. The 'view Occlusion blocker' wins back the FPS by basically saying "dont even bother with whats behind this magical VehicleBlockerObjectType shape."

@Andrew This is basically like any 'render blocker' found with several other much more expensive game engines.

The line:

if (gClientContainer.collideBox( localCamPos , pObj->getBoxCenter(), VehicleBlockerObjectType, &rinfo))

Is essentially a cast ray checking for VehicleBlockerObjectType(I picked this as an unused yet already engine integrated class who had an defined object type). If one were inclined to build a new object type for the "view Occlusion blocker" this is where the check would be placed.
We then have;

if ((pObj->getType() & TerrainObjectType) == 0)

So we can be sure NOT to block TerrainObjectType object type in the case it is caught between the view and a "view Occlusion blocker"- an early bug i had with the TGE version, here is where one would add other object types they wish to NEVER occlude.
Finaly with;

PROFILE_END();
		   return true;

We tidy up the PROFILE and return to SceneGraph::treeTraverseVisit with a TRUE (in the case all the IF checks worked out). TRUE is saying, 'Yes this object is blocked from view please dont render it', actual it do not do any obj->prepRenderImage for this object, as the case is.

If you look below the 'view Occlusion blocker' code, you will see the ONLY place where Torque ever actual do any type of object occlusion, checking for objects hidden by the terrain useing if (pBlock->castRay(start, end, &rinfo)). If you wish for more precise occlusion tests this would be where to tweak it alternately if you wish to optimize even more,this bit of code could handle some at the expense of a few false positive occlusions (dont check each corner before tossing the object as hidden, but just test the center; would be a 3/4 speed improvement but only if you were already truly lugged down by mass amounts of objects).

#6 Very nice! Can this can be enabled/disabled like other mission objects?

#7 You mean like Vblock.setEnabled(false)? That would be cool, or even a distance from player behavior, so it turns on or off if the player is near or far. Possibility's are truly endless! But right now, no. If take a look at vehicleBlocker.cpp, its such a simple little thing, could easily add any functionality you need.

Its in my notebook to change the way one edit the actual VehicleBlocker shape dimensions, so it updates in world editor; but it is inline behind 2 bug fix(not related) and an world editor improvement attempt.

#8 Yeees! The proper name for the ol antiportals. You get my vote for awesome.

In your last sentence did you mean TGEA?

#9 'Antiportals' that is what Unreal called them. Thanks, for the life of me i could not remember that name.

About TGEA, i build this version in TGEA1.8.1, but it is so simple in nature (unlike my earlier TGE version) that it should work with any of the Torque engine that have a sceneTraversal.

#10 Portals for "outside"!

#11 So as to have an 'render always' BOOL and not add any new code, i add a test for receiveLMLighting once false, it become a render always and will not be effected by view Occlusion blocker.

RayInfo rinfo;
   if (gClientContainer.collideBox( localCamPos , pObj->getBoxCenter(), VehicleBlockerObjectType, &rinfo))
   {
	   //// Test for things we want to always see...
	   if (pObj->receiveLMLighting)
		   if (((pObj->getType() & TerrainObjectType) == 0))
		   {
			   PROFILE_END();
			   return true;
		   }
   }

Now one may easily hide view Occlusion blocker inside a piece of mesh scenery.

#12 Excellent resource there Caylo. I am probably going to add a few things to this and I will post those changes once I get done. There is a minor change to get this into T3D as well. Another thing to mention is it is probably a good idea to take the check out of the terrain occlusion check so this will work in zones without a terrain. Works good with the dungeon kit since it has some issues scaling out become of all of the dts stacking behind each other. Place a few of these and rotate them properly and it works like a charm.

--Josh

#13 2 questions:

1. You said "Find the lower RayInfo rinfo; and comment it out."

Do I comment out just that one line, or all the code below it as well?

for (U32 i = 0; i < 3; i++)
   {
      Point3F start = (xBaseL0_s * checkPoints[i]) + localCamPos;
      Point3F end   = (xBaseL0_e * checkPoints[i]) + localCamPos;

      if (pBlock->castRay(start, end, &rinfo))
         continue;

      pBlock->getHeight(Point2F(start.x, start.y), &height);
      if ((height <= start.z) == aboveTerrain)
         continue;

      start = (xBaseL1_s * checkPoints[i]) + localCamPos;
      end   = (xBaseL1_e * checkPoints[i]) + localCamPos;

      if (pBlock->castRay(start, end, &rinfo))
         continue;

      Point3F test = (start + end) * 0.5;
      if (pBlock->castRay(localCamPos, test, &rinfo) == false)
         continue;

      PROFILE_END();
      return true;
   }

2. Once I get this compiled, how do I add an Occlusion Blocker to my mission? I don't see any examples for that...

#14 Well, I figured it out...

1. ALL that code gets commented out.

2. I used the commented out section in your code above to get the ability to make the object in the editor. What threw me off is that you used the term 'VehicleBlocker' which made me think that was optional code to allow your occlusion blocker to also block vehicles...

I have to suggest you change that name! VERY misleading!

#15 What would be the disadvantages of using TerrainObjectType instead of VehicleBlockerObjectType? Tested a little and it seemed to work nice. Would need to exclude WaterObjectType so far is all I have found.

#16 One may use any object type they wish as the view blocking object. I expect using the terrain could lead to situations where very tall objects beyond a hills apex would be falsely occluded. It truly comes right down to your level design.

I used the VehicleBlockerObjectType simply because it was already in the engine as vestigial leftovers. Exaptation seem the best way to example the Occlusion Blocker in the most flexible manner.