Hiding Unused Meshes
Blitz3D Forums/Blitz3D Programming/Hiding Unused Meshes
| ||
| Is it better to do entityautofade or to do a scan with entityinview and then hide/show meshes? Which is faster? |
| ||
| The answer is not exactly straightforward: http://66.249.93.104/search?q=cache:M2eEYhYXhGQJ:www.blitzbasic.com/archive/posts.php%3Ftopic%3D17199+hideentity+entityalpha+faster+blitzbasic&hl=en&gl=uk&ct=clnk&cd=1 |
| ||
| I've found on really old machines, like my AMD 500 Mhz with a Geforce 2, it is faster to completely free the entity and when needed simply create a copy from a 'master copy' of the entity that you keep in memory throughout the game/level. This is particularly the case with animated meshes, not so much of a problem with static meshes. |
| ||
| Kill completely and renew - 'tis tidier in the long run and faster to boot |
| ||
| Are you kiddin? It takes a lot of time to load things. Especially the textures of the meshes. My advice is: don't worry about EntityInView. DirectX will automaticly skip meshes from rendering when they are out of the camera range or behind the cameras back, aka not in view. Hiding meshes will disable their collision detection, something that could be a problem (imagine you're walking backwards and the stuff behind you will not react on collsion). Autofade is a good thing for stuff like grass. Other things like parts of the map, entrire buildings etc. should be handled by the camera range or a homebrew Hide/Show system, many times discussed under topics like "VIS Occlusion". It's still not so clear what's the best VIS system. It really depends. EG: I was working on a VIS System for my engine. It turned out it worked at the best speed when I simply clusterized the mesh and didn't hide/show anything manually. I used to write a VIS Compiler that was capable of storing visability data for every cluster, watched from every clusters viewpoint. When I used this Data to dynamicly show and hide things, it was even slower. Using a map that is made of a reasonable number of clusters or parts seems to be very important. Loading a level as a single mesh is a massive bottleneck. In that case you may use some kind of clusterisation as seen in the code archives. (althouh to design a level based on clusters in the first place will surely help to reduce the surface count) |
| ||
| jfk - I was not suggesting loading data on the fly but keeping a reference mesh/entity from which all other copies are made from, and freeing the copies when they are not in view, and copying from the reference mesh/entity when they come into view again. It is actually a lot faster on my old machine to do that than it is to allow blitz to cull animating entities from the view when they are not in view. EDIT - this method I am suggesting is for creatures and other objects in the game for which many instances may exist not so much for actual 'level' geometry as usually that is not cloned... |
| ||
| Killing completely is faster - as Matty said, there is no re-loading of textures etc. involved once your reference entity object is loaded at the beginning. It can save huge amounts of memory on lesser specced machines too. I got 15-20 frames more out of a amd duron 800mhz with crappy 32mb geforce2 mx by re-writing my hide/show code into kill create...but having said that the difference on a more modern machine begins to disappear (in my own case)...but still, it's always best in my opinion to consider your minimum spec's performance - get it right there and you're laughing. |
| ||
| Also if you setup collision on a pivot which an entity is attached, then killing it won't mess up collisions if you only kill the mesh. |
| ||
| Ok, I was wondering, what is the best way to clusterize a mesh in milkshape? Say I have a mesh terrain made in milkshape, how do I clusterize it? Do I have to have a seperate surface for every cluster? Will it work if everything is grouped to gether, or does every cluster have to be a separate group? I guess my main question is, will clusterization do any good if all clusters belong to the same surface? |
   |