Conversation
|
@ds5678 I would honestly not advise making a change like this without a full regression test. Stride stores cubemaps with Z mirrored against world space, so the +Z face is meant to hold what the camera sees looking toward world -Z. Every consumer undoes the mirror when sampling: The other four faces carry the same mirror. +Y uses up +Z where Direct3D wants -Z, and +X renders its image columns toward world +Z where Direct3D wants -Z. This patch makes the six face centres map as identity but leaves those axes mirrored, so front and back would swap for skybox generation, light probes and the editor cubemap preview. Important: nothing tests this file. TestCubemapRendering.cs is excluded at csproj#L18, and LightingTests.SceneSkybox* never reaches it because its skybox asset is already a cubemap, so CubemapFromTextureRenderer is skipped. A green CI run says nothing here. If your ISceneRenderer shows the faces backwards, I would check for the missing -z on your own sampling direction. Happy to look if you post it. |
|
🤖 Draft PR — automatic CI is skipped to save runner minutes.
|
|
I reviewed everything in Stride: since we use right-handed coord system (with Z negated), everything is consistent in Stride. I will add a few comments in the code at specific spots (CubemapRendererBase, CubemapUtils, etc.) so that it's clearer to people who interact with cubemap. I will close this PR as won't fix. Feel free to keep discussion if you still think something is wrong. |

PR Details
I noticed this while working on an
ISceneRendererimplementation for rendering cubemaps in my game.Issue
The code for the Z direction appears to have been backwards.
Types of changes
Checklist
I made the changes in
github.dev. I did not test them in any way, but I'm confident that they're correct.