Idea I had about culling / vis. Quite simple
Blitz3D Forums/Blitz3D Programming/Idea I had about culling / vis. Quite simple
| ||
| Set up a type containing all entities you want to include in the vis operation. Divide the screen into segments - how many is undecided, but too many will cause slowdown. One per pixel would be ideal, but its never going to happen. You *could* do the picks at different points each frame to get more coverage (damn good idea Skitchy) ;) Show all entities. Do a camerapick on the center of each segment. Flag each picked entity as visible. Hide the unflag'd entities if they are a certain distance away from the camera (to avoid any obvious close-up errors). Its not perfect, but I think it will work. I invite anybody to expand/completely destroy the idea ;) dim pickedlist(1000) ;clear the array (important) for count=0 to 1000 pickedlist(count)=0 next for vismesh.typevismesh=each typevismesh showentity(vismesh\obj) next ;alter offsetx and offsety each frame on a loop from 1->32 for x=offsetx to graphicswidth() step 32 for y=offsety to graphicsheight() step 32 camerapick(cam,x,y) if pickedentity()<>0 pickedlist(index)=pickedentity() index=index+1 endif next next min_vis_distance#=20 for vismesh.typevismesh=each typevismesh if entitydistance(cam,vismesh\obj)>min_vis_distance# hideentity(vismesh\obj) endif next for count=0 to 1000 if pickedlist(count)=0 then exit showentity(pickedlist(count)) endif next Code is from my brain and is therefore untested :) EDIT : ahh, sh!zzle. I was hiding the visible entities...fixing now |
| ||
| How fast is it? Try this code I put together.. http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=flynn05042004143034&comments=no |
| ||
| No idea. Completely untested. Thought of it while falling asleep :) |
| ||
| @Flynn - in your showcase entry you said Check 2 is done by casting a ray from the object to the camera, if it hits the terrain then it is occluded. I wrote a small routine using Vectors that does this check (lots faster than Linepick) If you could adapt that code to do the camerapick()ing in my code above we may be onto something big :) The one advantage that I see with my idea is that the number of picks you are doing per frame is fixed. It sounds like you're doing multiple picks per entity, which will slow down the more entities you have. PLEASE don't take that as an insult - I'm just throwing ideas around and I want everybodys input :) |
| ||
| Sounds like it will never work and will be too slow to work effectively. |
| ||
| Riiiiight. Care to elaborate a bit? |
| ||
| I think you would need to bust the segments into sub-segs to get accurate culling. If not you'll end up with some major mesh popin effects as the entites attached to a seg won't be lined up to the segs perfectly. Using a sub segment however would probably limitied this undesireable but raise calcuations and decrease performance to much. It's something to play with but unless we have some form of native culling support I don't see anything happening.. I also doubt blitz3d sees any more updates so...... But nice idea! |
| ||
| For smaller segs you decrease the step values, but its a trade off. How many camerapicks is too many [rhetorical] ? |
| ||
| 500 linepicks (technically not camerapicks, I guess, but close) will definitely slow up my P4-2.5GHz**, which is why I don't think your method will work. You will require at least that many. Wolfenstein 3D and Doom both used a method similar to this to draw the screen but they had very simplified 'maps'. In other words, they were only required to do 'camerapicks' from left to rignt at a resolution of 320 (read as 320 camerapicks) with a known map that didn't have objects at any height or rotation so that they didn't have to worry about any objects behind the first thing the camerapick 'hit'. Your method in a 3D environment that may contain different 3D objects anywhere on-screen and at any rotation would require you to basically do camerapicks from every pixel on the screen (which would be hundreds of thousands of camerapicks). ** This is with about 500 very low poly meshes on screen as well, but I noticed that the linepicks were the significant cause of the slow down. |
| ||
| I can double this. linepicks are slow. |
| ||
| What I found with my system was that when working on 10,000+ objects the occlusion checking overhead was far too great, you might as well just chuck all the polys to the GPU. However, since my system was based for use on terrains if I used the quadtree approach to determine what objects to check I could have produced quite a fast system. |
   |