TrisRendered and FPS
Blitz3D Forums/Blitz3D Programming/TrisRendered and FPS
| ||
| Hi, i'm currently working some sort of portal engine. Now i'm a litle bit currious about one fact. If i render the scene from a point where a large amount of Tris must be renderd i got about 90 FPS (15000 TrisRendered), if i switch my portal engine on the trisRendered drops to about 8000 Polys and the FPS increases to 100 FPS. At that point i would aspect some more increase in FPS's ! If i move to a point where about 12000 Polys are rendered i got about 140 FPS ... switching the protale engine on at that point does non optimation due to the architecture. and FPS stays at 140 FPS. Now, i wonder ... why does more Polys (12000) is way faster then (8000) on the other position ? I'm currently switching off the non used geometry with HideEntity. It seems to me that the hidden Object's are stil calculated in some way. Anyone can explain this to me ? Thanks in advance |
| ||
| What kinda hardware you running?..Since with 140 fps im guessing its pretty decent Gpu. Mustang can probably explain better. :) either 1: (unlikely) 8000 polys isnt enough to keep you Gpus vertex caches heated(loaded) and end up loosing a bit of performance becuase your not getting optimum throughput and they still have to be refreshed all the same. 2: (more likey) the hidden surface removal code itself is taking more Cpu cycles than just throwing all the polys at the gpu. remember Gpu's on modern video cards are im most ways faster then the Cpu of your system and they perform better with large chunks of polygons. I bet if you try it on a higher poly level it would work out better say maybe 150-300k polys Zmatrix |
| ||
| i'm currently running on a ATI Radeon 9700Pro with 128MB the hiddem surface removal only occurse when moving from on visibility zone to an other .. that does not occure when i stand still in a corner. I've measured the time consumption of the other code i run in the main loop, but that only cost about 10 FPS and is always at the same level. |
| ||
| Poly count decrease doesn't really yeild much of a FPS increase in my experience. More to do with textures and such. I can get up to 500,000 polys on screen, untextured, at around 67 fps. |
| ||
| i've runned another test with all textures stored in VRAM (flag 256) ... then there is no FPS increase at all with hidden surface removal on ! Well, that points to a texture issue .. but i can't figure out what exactly this can be. Did anyone know more about that internal render stuff ? |
| ||
| Are you using entityalpha, or hideentity? To take away entities from view? |
| ||
| i'm using HideEntity. I've runned another test: I've removed the shadowmaps (assigned to the entity) it does about 10 FPS increasment then i removed the main textures (assigned to the surfaces) this does about 40-50 FPS increasment |
| ||
| Surfaces & textures are the main source of slowdown, i believe in blitz3d programs. How big are your textures, dimention wise? Are they square and in power of 2 sizes? Bed time for me :) |
| ||
| yes, they are square and not bigger than 256 x 256 I've now tested it with the way bigger orginal textures ( 1024x1024) ... then there is nearly no increase in FPS with removal on. But there is no major slowdown due to the bigger textures! well, i'm just a litle concerned about the low FPS on my relativly fast machine ... i developed this removal thing because i've currently have non decoration in the map and this would increase polycount a lot! |
| ||
| What resolution are you using? I think the fluctuations are fillrate related. Polycounts such as 10,000 - 15,000 are too low to properly measure the effeciency of your portal engine on a card like Radeon9700. |
| ||
| It seems to me that fillrate, texture usage, etc. should have nothing to do with it. If I'm interpreting this correctly, turning on the portal system should simply stop certain objects from drawing. Are you taking your FPS measurements from the same camera position? Can you post an example? |
| ||
| I'm running it currently on a resolution of 1024 x 768. The measurement where allways taken from the same position. The source is much to big to post and the portalsystem works entirly correct and does the poly reduction. The only things that i can imagine is that if a lot of surfaces with different textures comes in view the framrate drops ... but in Blitz there is no way to check this out. Would be nice to have some commands to analyse the render process some more. There is a big difference in speed when textures aplied to surfaces instead of entitys ... could the mesh setup be optimized ? Does anyone tested if converting all surfaces to entitys increases performance ? |
| ||
| After re-reading the previous posts, I realize that I misunderstood the problem. I thought you were saying that from certain positions, your framerate was actually dropping when you turned the portal system on !! My apologies. Polycount is just one factor that affects your framerate. So, there ARE situations that dropping more polys will result in less of a frame rate increase. If those polys happen to be part of only one or two surfaces, you're not saving that much. Converting individual surfaces to entities won't help, btw. |
| ||
| Another factor that may be skewing the results of your tests is that the 'TrisRendered' command doesn't accurately report the number of tris that are rendered. Tris that are culled by the minimum and maximum camera range can be reported as being rendered, when they are actually not being rendered, for example. A lot depends on how standardized your testing procedure is. |
| ||
| thanks a lot for all the replys .. btw It seems that i can't do a lot to get higher framrates. I think that the framerate depends on the amount of textures that are used (not there size). I will check that this evening ! @axeman ... i'm currently using a CameaRange that is much greater then the map itself to get the most effect out of the surface removal system. But i'm still a litle bit confused about the results ... i can't truly understand what causes those effects ! Well, i will work on with my system ... i think with more detailed geometry in my map the surface removal will do a good job ... the other thing is a good architecture that allows the system to show it'S strength btw ... sorry for my bad english ... i try as hard as i can ;-) |
| ||
| You're english is fine, keep working hard :). |
   |