Rotating reflection probe?

It seems the reflection probe bounds are always axis aligned with world space? Is it possible to rotate it somehow to fit rooms that are rotated?

This is something I'd asked previously in the beta forums. It's not something that's currently supported and may not be due to the extra shader complexity for what is probably an uncommon use case.

Thankfully I was able to convince them to expose the reflection probe a renderer is currently using (renderer.closestReflectionProbe) so that it's possible to get and provide the rotation data to a custom shader. For my purposes the rooms that have probes will be rotated only 90 degrees around the Y axis so my shader only needs to accommodate swapping and inverting the XZ normal data. Arbitrary rotation support would require supplying the probe's rotation matrix to the shader and multiplying the normal by that matrix. This would probably best be done by modifying UniversalCore.cginc in the FragmentGI function.

Alternatively, should it arrive soon enough and work well, you could ignore it and wait for runtime Reflection Probe updating to be added. Not sure if it's going to make 5.0, but it should be done by 5.1 by the sounds of it.

How can this be an uncommon use case? Say I have an exterior environment, with a few houses that have interiors. I'd surely like to set up a probe for the interior of these houses, without having to have them align to the world space axis. Sounds to me like this would be an enormous constraint, or am I missing something here?


I've asked about this multiple times as well. I really hope they implement something.

Also I'd like cylindrical and spherical projections. For some reason I've always liked designing circular rooms.

I totally agree with you.

The probe system is great but the way you can set-up their respective influence zones is extremely limited. :-/

In my opinion, a custom mesh option like we can use for colliders/triggers is mandatory: this would allows the user to limit the probe influence to the room concerned.


I expect the thinking is that this sort of runtime level generation would utilise the runtime probe capture once it's ready. I believe they expected to have runtime updating in for 5.0 so they didn't necessarily expect to have to handle this case.

I somewhat agree with Unity's current stance on this as the extra matrix multiplication in the shader doesn't seem like the best option when a rotated probe is probably not going to be common (should never be needed in static scenes for example). Also, a one time update at level creation (or whenever the house is instantiated) allows for other elements of the environment to be included if there are open doors or windows. This is all assuming the runtime probe capture and convolution is fast enough to not be an issue.

There does need to be a better way to handle it at the moment. Outside of what I mentioned in my other post, other alternatives include potentially recreating the cubemap at runtime with GetPixel and SetPixel commands and accounting for the rotation (which would be even simpler if just 90 degree rotations where you just need to swap faces around). If there are limited rotations for your houses then you could capture all possible rotations in separate probes and then use just use the correct one at runtime. It would of course potentially use more RAM and disk space so it's not ideal.

A more complicated shader branch with the matrix multiplication could also be only used when a renderer is using a probe that is rotated, and perhaps that's something Unity could do as well.

quote=", post:6, topic:554919"

OK so I am missing something it would seem, can you tell me why not?

The way I understand it, if I continue with my last example, lets say I have an exterior and a rotated house with an interior, I place a reflection probe inside the house to capture the interior. This is all static and in the editor, and I bake the scene, probes and all.

Then at runtime a dynamic object with a reflective material comes along, and when it moves inside the bounding volume of the probe, it gets the reflections from this probe. My problem with this is that it could get the cubemap from the interior while still outside the house, because the volume has to extend beyond the house since it can't be rotated.


I agree with Steego. It seems ridicules that we need to design our towns with all the buildings aligned to the cardinal axes.

1 Like

I also agree with Steego.

I also understood it the wrong way at first, like MattCarr, thinking it was about rotating the "camera" of the probe while it is about the probe's field of action (the yellow box).

Like I said earlier, replacing it with a custom mesh would be the best way.

Also, the handles of the default box are way too small and transparent. They can even become impossible to select when on the same spot as a translation axis.


I think this have been fixed in U5b10, it should be easier to edit the probe with b10.

This subject has been mentioned many times on the forums, but I've never seen a member of the Unity team respond.

Makes me worry.

Also I'd like to know how fading between probes for dynamic objects is going. So much silence!

Let's wait and see, cause right now, there aren't any dynamic reflections, or probe fading.

Yeah, I misunderstood what steego was after. Not rotating the reflection probe, but rotating the reflection probes box projection volume.

Ultimately it's the same issue, the extra matrix multiplication in the shader (and maybe some more CPU complexity in determining containing volumes for objects). The volume needs to be world axis aligned currently so that the shader's box projection mapping math can be used on renderers inside the volume. The purpose of the volume is not just to act like a trigger volume to define which probe a renderer is using, but also how the cubemap projection works based on the renderer's position inside the volume. A custom mesh wouldn't make too much sense because the volume needs to be a box for the box projection to work correctly.

I don't see too much of an issue with supporting rotation that would allow the box projection volume to not be axis aligned and also handle runtime rotation of reflection probes (what I originally thought this topic was about), it should just be a matter of transforming the reflection vectors into the probe's space in the shader. How or if Unity chooses to handle this in terms of conditional optimisation I don't know, but I expect they'll need to address it eventually.

I'll look into getting it working for my project and report back. I currently have crossfading between reflection probes working fine in my modified shaders so adding this would solve all issues I have currently with probes.


What about a situation when your walls are single meshes (very typical situation) and you want to achieve proper reflections for the inside faces of the walls and outside faces of the walls too?

Looks like it's impossible with the actual approach because the reflection probe affects whole mesh instead of just the faces/parts of faces inside the probe.

I really have no idea how it can work this way.

When we will put a wall inside a reflection probe that gathers its cubemap from the inside of your building it will affect whole wall so in effect we will get very unnatural reflection for the outside part of this wall. In most common case the outside part of a wall will reflect the interior of the building instead of the skybox.

It can work with 'cube' reflection probes that affect whole object for meshes that aren't exposed to two different surroundings at once (a table in the room for example) but what if there is a mesh like wall or something different that also has one part of the mesh inside the building and another one outside?

Yeah, just gotta use a separate object for each side of the wall shrugs I can work around that.

or wait until they add SSR.

1 Like

Marc Saubion, MattCarr - you're right. The way to do it is to keep cubemap images axis-aligned, but rotate probe's box projection volume and activation areas. This approach does not incur cost on GPU unless box-projection is being used - which is very important for low-end hardware.

For now we prioritized blending between probes instead, which is coming to you very soon. We will implement probe rotation afterwards.


@ReJ_1 Wow! Thanks you! I'd honestly given up hope that any member of UT was going to comment on these issues. I'm glad to hear that probe blending is going well.

Can I ask whether spherical and cylindrical projections are anywhere on the road map? I often design circular rooms :)

1 Like

I was about to ask the same thing at least maybe spherical projections :smile: