How to determine if object is in view

Started by
5 comments, last by GameEngineer_gi 8 years, 9 months ago

We have a flight simulator application where one of the primary views comes from the EO/IR ("skyball) camera connected to the bottom of the "ownship" aircraft. You can gimbal and zoom the camera. The problem is since this camera can zoom (reduce FOV) quite far we see Z-fighting. To address the Z-fighting I move the near plane out a few hundred meters and problem is fixed. However that introduces a new problem. Now you can't see the "ownship" because it is being clipped out by the near plane that is not very near the (air)plane, if you catch my drift! :) So to address that we create silly masks which are nothing more then quads that positioned from the camera's view point. We have to set their positions to cover up the aircraft mesh and then during the game loop we check if the camera's azimuth or elevation (pitch) angles are inside a mask quad, we say that the camera is "masked" by the ownship and therefore pull the near plane back to its normal position of about 0.1 meters.

This hack works pretty good until you are in a masked condition (you can see a wing in the view for example) but you are looking far off into the distance. You get the Z-fighting again because since we are maksed we have to pull the near plane back so we can see the wing or any other part of the aircraft. You can define as many mask (quads) that conform to the aircraft shape as seen from this camera but you can never get it a perfect fit.

But I want to see if we can do this better, without masks. I am using OpengGL 3.3+ and GLSL 330 and want to know if there is a better way to check if an object (the ownship 3d model) is in view, are any of its pixel fragments in the view port at any given time? I am not a GLSL expert so that's why I am coming to the experts.

There is another approach I thought about which eliminates the need for masking altogether but it may not work so well with our shadows. I'll just throw this one out but I want to focus on the current approach first. This approach renders two channels where one channel defines near and far planes close to the aircraft ownship, near == 0.1m and far==500m. The second channel defines the near as 500m and the far as 130000m (flight sim so we need a far far plane distance at a high altitutde). So the 2nd channel draws the further scene where the 1st channel leaves off. I tried this way and it did seem to work however our dynamic shadows have to be attached to only one channel. This requires drawing the scene twice and our scene can get pretty heavy so its not my first choice. That's why we went for the more hacky way first. I may need to work with this approach more, however.

In the mean time I want to pursue improving our current solution. Any ideas would be helpful.

Wow, its been many years since I've been on this site. Lots of changes that look great!

-Steve

Advertisement

What's the resolution of your depth buffer? Check if you're using a 16-bit depth buffer. If so, bump it up to a 24-bit one. Then, move your near and far planes back to how you had them originally.

What's the resolution of your depth buffer? Check if you're using a 16-bit depth buffer. If so, bump it up to a 24-bit one. Then, move your near and far planes back to how you had them originally.

Good call. But we already have the depth buffer max'd out to 24 bits which is supported by the video cards we use. Typical flights sims don't have this problem as bad because you can LOD you far geometry out of the scene, no flicker if not being rendered. But camera view zooming messes up the works.

A co-worker this morning said I would be polishing the horse and buggy wheels if I continue down the masking track even if it used pixel perfect resolution. They suggest I buy a new car and pursue my second approach which is a design change.

But I still am interested in knowing how to detect the object is in view.

This should be handled in the same way as guns are handled in FPS games.
Draw the scene once with depths 500.0-130,000, clear the depth buffer, and draw the plane with depths 1.0-100.0 (or whatever is guaranteed to bound your airplane) over that.
Both passes perform full shadowing, only the objects and depths change.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

What's the resolution of your depth buffer? Check if you're using a 16-bit depth buffer. If so, bump it up to a 24-bit one. Then, move your near and far planes back to how you had them originally.

Good call. But we already have the depth buffer max'd out to 24 bits which is supported by the video cards we use. Typical flights sims don't have this problem as bad because you can LOD you far geometry out of the scene, no flicker if not being rendered. But camera view zooming messes up the works.

Sorry for the off-topic again... what cards are you using?
The best practice for z-fighting (since about ~8 years ago) is to use a 32 bit float depth buffer (DXGI_FORMAT_D32_FLOAT in D3D terms) and to also swap the near and far parameters before you create your perspective matrix (so that e.g. near is 10000 and far is 0.1).
Hardware depth coordinates are hyperbolic, from 0 (near) to 1 (far), where the vast majority of depth values are close to 'far'.
Floating point coordinates are logarithmic, where the vast majority of your precision lies in numbers that are close to 0.
So by swapping the near/far values, the hardware maps most values close to 0 (instead of the traditional convention of most values being close to 1), which results in exceptional accuracy when using a floating point depth buffer format. The only catch is you need to use Greater/GEqual depth testing instead of Less/LEqual depth testing.

There is another approach I thought about which eliminates the need for masking altogether but it may not work so well with our shadows. I'll just throw this one out but I want to focus on the current approach first. This approach renders two channels where one channel defines near and far planes close to the aircraft ownship, near == 0.1m and far==500m. The second channel defines the near as 500m and the far as 130000m (flight sim so we need a far far plane distance at a high altitutde). So the 2nd channel draws the further scene where the 1st channel leaves off. I tried this way and it did seem to work however our dynamic shadows have to be attached to only one channel. This requires drawing the scene twice and our scene can get pretty heavy so its not my first choice. That's why we went for the more hacky way first.

Something along those lines is probably the most robust solution. You can do two completely seperate passes -- one where you render the entire scene except for your own aircraft, and another where you only render your own aircraft... and then layer them over the top of each other.

If you draw your own aircraft first, you can enable writing to the stencil buffer during that pass. Then during the second pass, you can enable stencil testing, such that you only allow writing to pixels where the stencil buffer still contains a zero. That will save a bit of performance as you won't waste time shading pixels that will end up being hidden.

This should be handled in the same way as guns are handled in FPS games.
Draw the scene once with depths 500.0-130,000, clear the depth buffer, and draw the plane with depths 1.0-100.0 (or whatever is guaranteed to bound your airplane) over that.
Both passes perform full shadowing, only the objects and depths change.


L. Spiro

Thanks! To add more details to this I use a third party library called Vega Prime which handles much of the internal graphics rendering. Following their "canned" usage model is what told me you could only have one dynamic shadow generator for one channel. But perhaps with some digging I can figure out how to do as you suggest and render the channel with shadows on both channels without driving the system to its knees.

Sorry for the off-topic again... what cards are you using?

Depends on the customer but typically its NVidia Quadro K2000 or K4200. We even have some Quadro 2000 (no 'K' version). Always Quadro, however. I have no control over that unfortunately.

The best practice for z-fighting (since about ~8 years ago) is to use a 32 bit float depth buffer (DXGI_FORMAT_D32_FLOAT in D3D terms) and to also swap the near and far parameters before you create your perspective matrix (so that e.g. near is 10000 and far is 0.1).

The 32-bit Z-buffer would probably make a big difference however even on recent (NVidia Quadro) cards however I cannot seem to create a 32-bit depth buffer without losing my multi-sample buffer bits. That means no anti-aliasing which makes scene look worse than having Z-fighting.

As for swapping the near and far parameters I remember seeing this talked about in an Outerra article

http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

In my previous reply I add that I am using Vega Pirme and I do not have access to their projection matrix. I would have to take over the rendering pipeline. Which I may have to eventually do but that will not be easy.

So let's say I do take over the projection matrix and swap near and far values, does this solution "just work" given that I change the depth test type? Seems too easy.

Something along those lines is probably the most robust solution. You can do two completely seperate passes -- one where you render the entire scene except for your own aircraft, and another where you only render your own aircraft... and then layer them over the top of each other.

If you draw your own aircraft first, you can enable writing to the stencil buffer during that pass. Then during the second pass, you can enable stencil testing, such that you only allow writing to pixels where the stencil buffer still contains a zero. That will save a bit of performance as you won't waste time shading pixels that will end up being hidden.

This is along the lines of what L. Spiro suggested. Given my limitations with the depth buffer size and projection matrix reversed near/far plane matrix this solution may be my only robust solution even though it costs some in performance.

Based on both of your feedback I have decided to drop further investigation into a "better hack" and pursue the 2-pass render. I tried this a few years ago but after having trouble with the shadows I gave up.... perhaps too quickly. There may be a way to manipulate Vega Prime's dynamic shadow object to swap to both channels or maybe create two dynamic shadow objects. There are pros and cons to working with third party libaries and I may be running into the con as far as what I can do using their system of classes (and not have access to source code).

Thanks so much. I feel encouraged to give the 2-channel (ie 2-pass) rendering another try.

-Steve

This topic is closed to new replies.

Advertisement