Hi there! I have a weird effect that I’d like to play on any number of objects in my world, provided they fall inside of a number of volumes that I would be able to control/move.
Is there a way of stashing a arbitrary number of colliders, perhaps, to some sort of 3D on/off map that a shader could use to simply lerp against?
I have no idea how I might represent this map, or how a shader might read it.
Yes and no.
You’ll want to look into signed distance fields. If your shapes are all boxes and spheres, those can be done analytically fairly inexpensively. For more complex mesh shapes you’d need to use a signed distance field stored in a 3d texture, or maybe a height map.
very interesting… Thanks (again) bgolus. You seem to be the shader savior around here.
I’ll dig into this and see if I can make heads or tails of it. Simple shapes are fine. I dare not tempt fate.
If you stick to spheres you can very easily pass an array of float4 values with world position and radius^2 to iterate over. For boxes you’ll need an array of 4x3 matrices to transform the pixel’s world position into a local unit box position, or stick with world axis aligned boxes with min/max extents to test against.
See this tutorial:
But be sure to read the 5.4+ follow up before getting too far in:
Note, you’ll want to make the c# arrays as large as the number of volumes of a particular type as you think you’ll ever need as you can’t change the size after the first time you call Set*Array() for each shader property.
Oh man this is perfect! Yeah, Arrays in shaders is exactly what I need. I wasn’t aware you could even have iterated loops in cg.
Question: How optimized is this? How do GPUs handle iteration? having all of my world geometry iterate through a… let’s say 30 length array to get the right value at that pixel… for ever pixel on the screen… I wonder (since its okay if this is somewhat low resolution) if it would be better to dump my spheres & cubes to a 3D texture on awake and have my shaders just do a lookup to that global texture. I think I could get the effect I needed while only loading one 256^3 into memory at any given time.
That’s multiple questions …
First - How optimized is this?
Not at all, but GPUs are fast, and as long as the tests are simple (like iterating over 100 spheres using a radiusSqr value to avoid doing a sqrt) then you’re roughly doubling the overall complexity of a shader vs. lighting alone when using the Standard lighting model.
How do GPUs handle iteration?
Depends on the class of GPU. If you’re trying to do this on an old OpenGL ES 2.0 mobile device (or D3D 9 desktop hardware, which isn’t supported by Unity anymore), then the loop is unrolled. That is to say there’s no such thing as a dynamic loop on those GPUs, so it’ll iterate over a fixed number of elements as if they were written out in the shader.
For example:
for (int i=0; i<100; i++)
color += colors[i];
Turns into something like:
color += colors[0];
color += colors[1];
// ...
color += colors[99];
If you have the loop running from a uniform property, like this:
for (int i=0; i<_colorCount; i++)
color += colors[i];
Well, GLES 2.0, and even GL 3.3 will technically just croak on this. It can only use fixed iteration counts. This is totally valid for OpenGL 4.0 and for Direct3D 11 though. For older OpenGL specs the loop is still unrolled, but using some magical guessed fixed iteration count which I have no idea how it’s determined, and the code becomes something like this:
fixed4 tempColor0 = color + color[0];
color = 0 < _colorCount ? tempColor0 : color;
fixed4 tempColor1 = color + color[1];
color = 1 < _colorCount ? tempColor1 : color;
// ...
fixed4 tempColor99 = color + color[99];
color = 99 < _colorCount ? tempColor99 : color;
You get the idea.
Now I mentioned OpenGL 4.0 and Direct3D 11. For those GPUs are totally capable of using dynamic loops like this and it “just works”. There’s some overhead to having a dynamic loop vs an unrolled fixed iteration loop of the same size, but it’s not too bad.
A 3D texture
The loop iteration can get expensive, so a 3D texture would absolutely be cheaper to sample from in a lot of cases, especially with a lot of shapes. You might need to try both and see which one ends up being faster as generating the 3D texture to begin with won’t necessarily be that fast either. But, as you said, a low enough resolution 3D texture may result in a big win overall. Really, the shader code for doing this on every on screen pixel vs into a 3d texture will be pretty similar if you wanted to use a compute shader to fill in the 3d texture. Otherwise you could do it from c# if it’s not going to be updated often.
Unity doesn’t use Cg anymore. Everything inside the cginc files and CGPROGRAM blocks is straight HLSL.
I am now 1% more enlightened.
Thank you sir :). This is incredibly useful.
Example.
Source:
CS script:
using UnityEngine;
using UnityEngine.Rendering;
public class VolumeRenderTexture : MonoBehaviour
{
public ComputeShader VolumeShader;
public Material VolumeMaterial;
RenderTexture VRTA, VRTB;
float cx, cy, cz;
bool swap = true;
void Start()
{
RenderTextureDescriptor RTD = new RenderTextureDescriptor(256, 256, RenderTextureFormat.ARGB32);
RTD.dimension = TextureDimension.Tex3D;
RTD.volumeDepth = 256;
VRTA = new RenderTexture(RTD);
VRTA.enableRandomWrite = true;
VRTA.Create();
VRTB = new RenderTexture(RTD);
VRTB.enableRandomWrite = true;
VRTB.Create();
cx = cy = cz = 0.5f;
}
void Update()
{
if (Input.GetKey(KeyCode.W)) cy+=0.001f;
if (Input.GetKey(KeyCode.S)) cy-=0.001f;
if (Input.GetKey(KeyCode.A)) cx+=0.001f;
if (Input.GetKey(KeyCode.D)) cx-=0.001f;
if (Input.GetKey(KeyCode.Q)) cz+=0.001f;
if (Input.GetKey(KeyCode.E)) cz-=0.001f;
VolumeShader.SetFloats("Center",new float[3] {cx, cy, cz});
if (swap)
{
VolumeShader.SetTexture(0, "VolumeReader", VRTA);
VolumeShader.SetTexture(0, "VolumeWriter", VRTB);
VolumeShader.Dispatch(0, 256 / 8, 256 / 8, 256 / 8);
}
else
{
VolumeShader.SetTexture(0, "VolumeReader", VRTB);
VolumeShader.SetTexture(0, "VolumeWriter", VRTA);
VolumeShader.Dispatch(0, 256 / 8, 256 / 8, 256 / 8);
}
swap = !swap;
VolumeMaterial.SetTexture("_Volume",VRTB);
}
}
Compute shader to generate data:
#pragma kernel CSMain
Texture3D<float4> VolumeReader;
RWTexture3D<float4> VolumeWriter;
SamplerState _PointClamp;
float3 Center;
float circle(float3 p, float3 c, float r)
{
return step(length(p-c)-r,0.0);
}
[numthreads(8,8,8)]
void CSMain (uint3 id : SV_DispatchThreadID)
{
float3 uv = float3((float)id.x/256.0,(float)id.y/256.0,(float)id.z/256.0);
float k = circle(uv,Center,0.03) + VolumeReader.SampleLevel(_PointClamp,uv,0);
VolumeWriter[id] = float4(k,k,k,k);
}
Shader to render 3D texture
Shader "Volume Render Texture"
{
SubShader
{
Cull Back
Pass
{
CGPROGRAM
#pragma vertex VSMain
#pragma fragment PSMain
#pragma target 5.0
sampler3D _Volume;
void VSMain(inout float4 vertex:POSITION, out float3 world:WORLD)
{
world = mul(unity_ObjectToWorld, vertex).xyz;
vertex = UnityObjectToClipPos(vertex);
}
float4 PSMain(float4 vertex:POSITION, float3 world:WORLD) : SV_Target
{
float3 ro = mul(unity_WorldToObject, float4(world, 1)).xyz;
float3 rd = normalize(mul((float3x3) unity_WorldToObject, normalize(world - _WorldSpaceCameraPos)));
float3 tbot = (1.0 / rd) * (-0.5 - ro);
float3 ttop = (1.0 / rd) * (0.5 - ro);
float3 tmin = min(ttop, tbot);
float3 tmax = max(ttop, tbot);
float2 a = max(tmin.xx, tmin.yz);
float tnear = max(0.0,max(a.x, a.y));
float2 b = min(tmax.xx, tmax.yz);
float tfar = min(b.x, b.y);
float3 d = normalize((ro + rd * tfar) - ro) * (abs(tfar - tnear) / 128.0);
float4 t = float4(0, 0, 0, 0);
[unroll]
for (int i = 0; i < 128; i++)
{
float v = tex3D(_Volume, ro+0.5).r;
float4 s = float4(v, v, v, v);
s.a *= 0.5;
s.rgb *= s.a;
t = (1.0 - t.a) * s + t;
ro += d;
if (t.a > 0.99) break;
}
return saturate(t);
}
ENDCG
}
}
}
Example configuration:
I use voxel sphere as brush to “sculpt” virtual geometry inside 3D render texture. 256x256x256 and fps is still high.
Key configuration inside CS script.
Oh damn! that’s fantastic!
Thanks very much Przemyslaw, I can learn a lot from this.
