Occulsion idea

I remember a good while back, someone suggesting rendering the 3d scene and colouring the entire level mesh black (0,0,0). Transparent entities would be made see through. Then rendering whatever you want to check for camera visiblity, white (255,255,255)

The biggest problem was checking all the pixel on the screen, as this was a very slow process even if rendered in a lower res, like 640x480.

BUT, what about rendering the camera in a super low res mode. like 64x48 pixels? This would be alot quicker to check. AND, since the colours of the pixels should be blended, then, you are only checking for anything OTHER THAN black. If this is detected, then you entity is visible to the camera.

Anyone tried this out at such a low resolution? I think it might be a workable solution.

Assuming antialiasing could be counted on being there, this still wouldn't work, because antialising only generally samples the scene at 2x the res on each axis at most, so at BEST you could use this method for a 4x speedup. But it wouldn't be reliable because people can disable antialiasing and some cards don't have it and some report that it's on when it's not, etc etc.

But surely, if you reduce the camera resolution, wouldn't the camera render the pixels and mix the colours? Or would it just completely miss it out? Not to question you, cause you usually know what your talking about with these matters :o)

It would completely miss the pixels.

Rendering a 3D scene without antialiasing (or textures) is for all intents and purpouses the same as casting a single ray through each pixel in a raycaster. Anything that falls between the rays gets missed.

Full screen antialiasing simply renders the scene at 4x the res, and then averages it down to normal res again. So now you have four rays where before you had one, but each of those rays can miss stuff that falls between them just the same.

What you're proposing on the other hand is exactly the opposite of antialiasing. You're proposing to greatly reduce the number of rays being cast to maybe one per every 16x16 pixel square, as that's what happens when you lower the camera's resolution.

Enabling antialising after you've done this will get you some of those rays back, but only as many as you'd get if you rendered at twice the horizontal and vertical res. In the end, even with antialiasing, you're still working with way fewer rays than you had to begin with.

And that means anything small enough to fall between rays, such as things in the distance, will dissapear and reappear as you move around.

..well..what Im doing is creating pivots and storing them in to list(during loading time) on the edges of the bounding box around each object on scene..later in runtime i do raypick with each of them and regarding pick happen or not, i turn on off specific object related to that pivot..however B3D raypick is way slow fot his, so im now playing with Physics raypicking wich is way faster...

So that's why you were wanting that ;o)

Ok then, so: If i rendered the scene to a texture, in full resolution, THEN, applied the texture to a sprite, and moved the sprite away from the camera, or scaled it, the resulting mipmap would do what i need, by blurring and decreasing it's size? Then all i would need to do is read the small area in the centre of the screen for colour information?

I will need to do some tests on that...

..heheh..yes..thats why i use to ask about NuclearGlory library..I did registered on their web site but never received confirmation email..sighh...I really wanna buy that thing, but just cant get membership activation...

Why don't you just skip all these tricks and use hardware occlusion queries?

My guess would be that they're using Blitz3D, where hardware occlusion queries are not available. On a more general note, hardware occlusion queries are useless in my opinion. They're asynchronous, and in order to make them as fast as more traditional occlusion methods like portals, you have to optimize them an awful lot, and even if you manage that, it still won't provide any performance improvement over the traditional methods for most people. Of course, if you're the kind of person who thinks that FPS is the only genre that has existed or ever will exist, then you might well notice some benefit, assuming you can optimize them sufficiently.

Ross:
I thought of that, and it might work, assuming the mipmap filters on cards are all they're cracked up to be, AND none of the bilinear/trilinear/anistropic filters screws it up, and the user doesn't have some other card feature enabled/disabled like sharpening to screw it up...

...but even then, copying the entire screen at high res to a texture might kill your framerate.

But, it would still be quicker than reading all the individual pixels. You could render the screen at half the res, as i don't think the player would notice 1 pixel being visible.

Something to try out i reckon. I take on board your point about various texture filters though. That could trip you up...

And yep, we're talking about blitz3d. Maybe the rendertotexture function in the FastExtend lib might help.

Occlusion queries are very efficient. You don't even have to run a fragment program. I don't know what you are referring to when you call them "inefficient", or what you mean when you say they need to be "optimized".

Render a bounding box bigger than the occluded object. This will give a little leeway to cope with the delayed frames after the query is drawn but before the results are available.

I also don't see how occlusion culling is specific to the FPS genre.

I believe you because your leadwerks engine is very fast. ^^

Pity you can't use them for blitz3d :o(