Occlusion using EntityVisible()
Blitz3D Forums/Blitz3D Programming/Occlusion using EntityVisible()
| ||
I've been pondering over the idea of using EntityVisible(entity,camera) to perform simple occlusion.;Simple Occlusion If EntityVisible(entity,camera) ShowEntity entity Else HideEntity entity EndIf I'm curious has anyone else tried this command for this purpose and hows the performance? |
| ||
| Once you've hidden the model, it cannot be visible to the camera, can it? So the first time it's not visible, it will stay hidden forever :D |
| ||
| Fredborg, Thats a good point and I'm going to have to play with this. |
| ||
| From what I know about the EntityVisible() Command, this works diffrent. |
| ||
| >Once you've hidden the model, it cannot be visible to the camera, can it? So the first time it's not visible, it will stay hidden forever :D how about this: Make entity visible each time at before occulsion checkin. If it is visible to camera it stays that way if not it's hidden for this frame and so on. Next frame the same thing, you unhide it before checking and so on. This should work for simple occulsion, no? ;reset ShowEntity entity UpdateWorld ;perhaps this update here so EntityVisible can see it? ;Simple Occlusion If EntityVisible(entity,camera) ShowEntity entity Else HideEntity entity EndIf UpdateWorld RenderWorld you reset the entity each loop, and if camera doesn't see it you hide it, if it does see it it stays visible, this should work good I think ;) right? |
| ||
| Setting EntityAlpha to zero will also occlude the object from the Blitz3D rendering pipeline. |
| ||
| Is Blitz not doing this automatically? If it knows you can't see the entity, why is it drawing it? |
| ||
| Yeah. I think Blitz has some basic frustrum culling in. This is one of the reasons TrisRendered() changes without you adding any geometry (the other being terrains). |
| ||
| Blitz 3D really needs an occlusion system. You only start to realise how important occlusion is when your level maps start going over 25,000 polys. I tried, with not much success, to create a simple occlusion system using EntityDistance(). Something along the lines of this:
range = 200
For object.TObject = Each TObject
If (EntityDistance(camera, object) => range)
EntityAlpha object, 0.0
Else
EntityAlpha object, 1.0
Endif
In fact, you could ramp the alpha value up or down gradually, thus avoiding abrupt pop-ups. Regards, Rogue Vector |
| ||
| You better use HideEntity in that case, when Collision of the invisible parts is not required. Because EntityAlpha 0 keeps checking Collisions and that slows down as well. But hey -when you use a simple distance based occlusion system (as I do as well, btw.) then you only have to set the camerarange to a low value, eg. cameraRange cam,0.1,50.0 . This makes things real fast. But it requires the Mep Design to be pretty limited. No long halls (no matter how lowpoly they are) etc. You cannot use ENtityVisible for Occlusion since it only checks for the visibility of the center pivot of an object. When an object is partially visible, but it's logical center is not, entityvisible will still return zero. I already tried to use this (slow anyway) EntityVisible Command for the precalculated Visibility Array Method. The best thing you can get is a working portal system that will use 10 thousand tris or something per portal. This way you can use huge worlds and still have a bearable Occlusion of 90% of the level. I already described somewhere else how I would implement this. the easiest thing would be a manual placement of Zone-Boxes. Once you have defined a number of zone boxes, it's up to the program to split a level in a number of parts, one for each box. Depending on the player position in the game, zones will be hidden or shown. Usually the current zone plus the surrounding zones may be shown. It depends on the level design, and the Designer needs to make it useful. Eg: if you add an s-shaped corridor between two zones, you'll be able to hide one of them properly because you cannot see from one place to the other. So Room 1 would be a zone, the cooridor and room 2 are further zones. |
| ||
| I have been trying something similar to "Frank Taylor's" idea but I found with 'If EntityVisible(entity,camera)' then the entity was always seen regardless of where, so I used EntityInView (entity,camera) instead this actually works especially for indoor levels with the camera range short. Am I doing something wrong? I can't get 'EntityVisible(entity,camera)' to work, but 'EntityInView (entity,camera)' works. |
| ||
| Remember that when using entityvisible you need to set up objects as occluders (trees, houses etc..). Do this by setting the EntityPickMode ie. EntityPickMode entity,pick_geometry[,obscurer] ; the obscurer bit is what you need to set. HOWEVER this is very sloooow, essentially a linepick cast from the camera to the object, if the pick does not hit the object then it must be obscured!!! |
| ||
| You've hit upon the problem with most of the occlusion systems I've tried to implement in Blitz 3D. They're so slow that any gain is slight. In some extreme cases, when I removed the occlusion system, I got a higher frame rate. Of course, it could just be that my code was crap. Regards, Rogue Vector |
| ||
| True, it's often faster just to chuck all of the polys at the GPU and let it deal with it. |
| ||
| PortalPal, even in a worse case scenario, gives you twice as many frames per second. |
| ||
| well is this pp out? if not then it's not of any use right now ;) |
| ||
| The point is that it can be done, and that it is worth doing. I often hear people say "just throw it at the GPU, it will handle it", and while this may be true of newer and newer hardware, it is also true that you will still speed things up if you occlude as much as possible in the first place. |
| ||
| This may not always be true. If you occlude as much as possible, you need to create multiple copies of surfaces to be able to hide and show map-parts dynamicly. Then, when you show a number of them, there may be a high number of double surfaces in the render pipeline and the number of Polys is not significant lower. You need to find a good balance between surfaces and polys. Don't worry about a few hundred polys, and when your level has no more than 20 Tirs, then you shouldn't even waste a thought about occlusion. It is nice when you have a real big level, >100 thousand tris. |
   |