|
Is there a way to disable frustum culling on specific objects? Or perhaps disable it entirely? I'm displacing the vertices in my mesh in a vertex shader. They are displaced to the extent that the original mesh (on the CPU side) is out of the view frustum, whereas the displaced vertices (on the GPU side) ARE in the view frustum. This causes the mesh to suddenly stop rendering and disappear, which is obviously not the desired behavior. I tried solving this by overriding the OnBecameInvisible() method and forcing the renderer to be enabled, but that did nothing. (I had thought that the frustum culling disabled the renderer, but that is not the case.) I wish the isVisible field on the renderer was able to be set. I feel that would solve this issue. Any other ideas? Update: I thought about forcing the bounds on the renderer to be the same size as the maximum displacement, but the bounds property is read-only too. I then tried having a second camera in the scene that is static and moved back enough to always have the displaced mesh in view, but that didn't work either. Apparently each camera does it's own frustum culling, which makes sense.
(comments are locked)
|
|
I've come up with a partial solution. It's not perfect, but it's a lot better than it used to be. In my camera script, at the end of the LateUpdate() method, I added this:
As you can see, it sets the field of view to the standard 60 degrees, sets the shader View and Projection matrices, and then forces the field of view to 179 degrees (the maximum). So, from the shader's point of view, the camera is normal, but in Unity's point of view, the frustum is widened out to the extreme. This means that when Unity does the culling and determines which objects to render, a lot more objects pass the test. Of course, this means that you have to change your shaders to use your own matrix variables instead of the Unity built-in variables, but that's not too bad:
As I said, it's not perfect and some of the displaced meshes still are clipped, but it's only about 1% of the time now as opposed to about 90% of the time before.
(comments are locked)
|
|
I have also had issues with the frustum culling taking place too early / incorrectly. When using the exact same code, the frustum would cull early if the Initialization of the GameObject took place in my Update() call rather than Start(). Very strange. I changed the bounds size to be extremely large and less culling occurred, but it was still bad. When I moved the bounds center to the center of the frustum, it worked every time. To move the frustum I placed the following code at the end of my Update() - after the mesh modification:
Obviously if you need the bounds for anything else you'll run into problems and will want to make a backup before you force the change.
(comments are locked)
|
|
Use RecalculateBounds() after you assign the mesh to a MeshFilter component. So for example in C#: GetComponent().mesh = aMeshObject; aMeshObject.RecalculateBounds(); This way it will recalculate renderer bounds.
(comments are locked)
|
Unity Answers has moved to a new system, and some users may have trouble logging in.