Do hidden polys affect framerate
Blitz3D Forums/Blitz3D Beginners Area/Do hidden polys affect framerate
| ||
| I am just testing a level i created with Maplet (about 3000 polys so far) and everything is running fine at about 130fps ( I have an old PC ) but when i turn the camera in certain directions i get a drop of about 40-50 fps. I swithched on the wireframe view and noticed that it only occured when i was facing a staircase (almost a 1000 polys alone) that was in another part of the level but was not visible to the camera. So my question is, does Blitz render polys that are not visible and without splitting up my level into single rooms/corridors, how do I avoid this slow down. |
| ||
| Whole models are culled, ie, if your level is a single model everything will always be rendered. Blitz will automatically cull stuff that is out of the camera range, ie, behind the camera or off the sides. Blitz will NOT automatically cull stuff that is behind other stuff, ie, a statue behind a wall. |
| ||
| Thanks Rob, It is a whole model, so that means the whole model is being rendered, but why then does it only occur when I turn to face in the direction were there is a high number polys. |
| ||
| Don't know... Blitz may cull surfaces... not sure though. |
| ||
| Doubt it, TrisRendered() ;) [edit] More useful: Blitz will put it in the render pipeline, but if theres no pixels to be filled by it, the card wont render it. Objects behind walls that are in view WILL get drawn by the card first, this slowing it all down. If somethnig is off-screen, Blitz will still process it, but it wont be drawn. So if theyre hidden theyer still impacting speed, just not as much... |
| ||
| . |
| ||
| The sort answer is YES. If you are looking at a solid wall, but there is a staircase behind it the camera can see it just fine, and it is drawing it, but you can't see it, because you only get to see the finished scene. When polygons are drawn, the distance to each pixel is compared to the pixel in the zbuffer at that position. If there is no pixel, or if the pixel there is farther away than the pixel you're triyng to draw, then a new distance is saved for that pixel, and the pixel color overwrites the old pixel color there. So, the stairs get drawn, and then the wall is drawn over them. So they're invisible to you, bu tthe camera had to draw them anyway. Even if the stairs get drawn last, the camera still has to compare them to the zbuffer, so they'll still slow things down. Therefore you can speed things up greatly if you can figure out which parts of your level can safely be hidden. I would do this by making each room a seperate entity, and then for each room making a list of all other rooms which can be seen from that room. Then you can hide all rooms that are not potentially visible. (You would want to figure out which room a player is in by creating bounding boxes and figuring out which bounding box the camera is in.) Also, even if the polygons aren't on the screen, Blitz may still attempt to draw them if they are in front of the camera. I don't know exactly what it does, but I do know that if you create a large 2D-like plain of entities in a grid pattern and you can only see one of them, others will also get drawn even if they are off the screen. I made a 3D starfield that used this technique, and I found that it was much faster if I actually told Blitz which entities to show than if I just let it try to figure it out on it's own. So you should definitely try to hide stuff you know isn't visible from a particular location, even if you think the camera can't see it. |
| ||
| but why then does it only occur when I turn to face in the direction were there is a high number polys. Fillrate. If you look towards the wall that has nothing behind it and compare that to a situation where you have many walls behind the wall you're looking at, 3D-card still have to "draw" everything [whole model] in both cases but the 3D-card discards the polys that are behind the camera or have normals that face away from the camera just before rendering in the DX pipeline and doesn't actually draw them... but those walls-behind-the-walls it has to, and if they fill large part of the screen it slows down the framerate obviously. You can try to control this FPS fluctuation if it's too bad for example by hiding and un-hiding blocks [with somekind of visibility code] from the level geometry - this is usually called as having "portals" or "BSP". |
| ||
| Thanks Guys, I knew everything was going to easy for me, Pathfinding/node editor done Basic AI done Particle effects done control system done Make level(s) with easiest to use modeller (I have no artistic talent) partially done and already knocking chunks of my fps. Oh well, back to the drawing board. |
| ||
| Nexus, theres code in the archives just added that will do the hide/show thing simplistically for you, so if you want a quick fix that works, use that :) [edit] http://www.blitzbasic.com/codearcs/codearcs.php?code=1343 |
| ||
| Thanks Cygnus, Im at work at the moment, its 4:20pm, I've had enough, im going home. I'll download the code when I get home, thanks again. |
   |