Tuesday, March 8, 2011

Unity GPU Noise & Unity Issues

It's amazing how much time keeps slipping by without any posts. Another 5 months have somehow passed since my last post. That means that I have only written 2 posts in the past year! I need to get back to my good update schedule.

GPU Noise in Unity

First, I'd like to show a simple demo I made of various types of noise on the GPU in Unity. You can check out the live demo on the web by clicking on the image below. You need to have a Shader Model 3.0 GPU in order to run the demo.

As you can see, there are 9 different types of noise in the demo and they are all implemented in Cg shaders on the GPU.
  • Perlin - "Standard" Perlin Noise (1 octave)
  • fBm - fractional Brownian motion summation of Perlin Noise (8 octaves)
  • Turbulence - fBm variation that sums the absolute value of the noise result (8 octaves)
  • Ridged - fBm variation from the book "Texturing and Modeling: A Procedural Approach" that performs a special ridge function on the noise result (8 octaves)
  • Voronoi (F1) - A "noise" type that uses a field of random 3D points and determines the distance to the closest point
  • F2 - Voronoi that determines the distance to the second closest point
  • F2 - F1 - Voronoi that determines the difference between the first and second closest points
  • (F1 + F2) / 2 - Voronoi that averages the distance between the two closest points
  • Crater - Voronoi variation that makes crater-like structures

Have fun messing around with the sliders and seeing how the noise can be manipulated on the fly!

Unity Issues

After completing the GPU noise demo in Unity (it's actually been done since November), I started proceeding with implementing a procedural planet generator in Unity. It quickly introduced me to some of the issues and limitations that Unity has.
  • Cannot disable/control view frustum culling.
    This is the worst issue I ran into. The way I implement the planet is to have a small cube that is "blown out" to form a sphere and then offset with noise all on the GPU (à la displacement mapping). Unity has a camera system that determines which objects are inside each camera's view frustum and automatically culls (doesn't draw) any objects that are outside of the view frustum. The problem is, while the small cube is not in the view frustum, the final displaced planet is in the frustum. This causes the planet to suddenly stop rendering if the camera is pointed a certain direction.

    I tried several fixes such as blowing the cube up to be the same size of the planet and forcing the view angle to be the maximum value (179 degrees) when Unity does the frustum check. Neither of these got rid of the problem entirely and just reduced how much it happened. In order to fix it, game developers should have control over which objects should be culled, or be able to disable frustum culling entirely.

  • Cannot run editor scripts when paused.
    This problem stems from another problem in Unity. Unity doesn't send the View matrix (by design) or Projection matrix (current bug) to the shaders, so you need a script to send them manually. Because of this, you need to have this script continually updating the shader variables even when the game is paused. If they are not updated then the objects render in the same place on the screen no matter where you move the camera. This is a horrible problem with no real fix.

  • Cannot create a custom collider.
    Unity provides no simple way to create your own physics collider object. You can inherit from their built-in Collider class, but you cannot override any methods inside of it. As you can see from the link, I came up with a work-around for what I specifically was trying to accomplish: make a spherical planet collider. It is very similar to what I did in Bullet in the past.

  • Cannot write depth in pixel shader. (Also explained here.)
    I tried implementing a logarithmic depth buffer, but I was greeted with a Cg compilation error when trying to write to the depth register. This is actually a bug in the Cg compiler. It's been fixed in the compiler, but Unity is still using an old version of the compiler which has the bug. I need to test the latest releases of Unity to see if this is still a problem.


ippo said...

Hi there. Intaresting post, thanks for sharing this.
1. For some reason ( check # pragma exclude glsl in the compiled shader ) the player cannot render a thing in Mac ( black sphere ).

2. Thanks for sharing references. Could you please share some implementation ? A reference to some hlsl implementation would be very helpful.

Thanks !

Patrick said...

You're very welcome!

1. Yeah, I was having issues getting it to compile in GLSL, so I had to exclude it. I'm going to try and solve that problem.

2. My plan is to release it via the Unity Asset Store. I need to clean it up a bit first and fix the GLSL issue.

Kodify_or_not said...


You do realize... we'd clean it up for you. n.n People scratch their own itches. Is it your itch to have a clean version available to us, or ours?

Cool... unity has an asset store. Even cooler, it has free stuff!

Kodify_or_not said...

Forgot follow up comments. XD

dspnerd said...
This comment has been removed by the author.
George R said...

Was the logarithmic depth buffer thing addressed in the latest Unity release (3.4) ?

Patrick said...

Kodify: Yeah leaving comments on the actual post you're referring to is much better. :-) Regarding the procedural city code, I haven't touched it since Nov 2010 (See my Nov 15, 2010 post). I guess I could just throw the code up and let people do whatever they want with it.

dspnerd: (Are you and Kodify the same person?) Don't worry, I received your email that you sent. I haven't replied because, frankly, you were rude and demanding. Try actually being a nice guy and it'll get you further in life.

George: I haven't tried out the logarithmic depth buffer in Unity 3.4 yet. I'll try it soon and I'll definitely post if it works now.