The Sane Rendering Manifesto

the_sane_rendering_manifesto.md

The Sane Rendering Manifesto

The goal of this manifesto is to provide an easy to follow and reasonable rules that realtime and video game renderers can follow.

These rules highly prioritize image clarity/stability and pleasant gameplay experience over photorealism and excess graphics fidelity.

Keep in mind that shipping a game has priority over everything else and it is allowed to break the rules of the manifesto when there are no other good options in order to ship the game.

Do not use dynamic resolution.

Fractional upscaling makes the game look bad on most monitors, especially if the scale factor changes over time.

What is allowed:

1. Rendering to an internal buffer at an integer scale factor followed by blit to native resolution with a point/nearest filtering.
2. Integer scale factor that matches the monitor resolution exactly after upscaling.
3. The scale factor should be fixed and determined by the quality preset in the settings.

What is not allowed:

1. Adjusting the scale factor dynamically at runtime.
2. Fractional scale factors.
3. Any integer scale factor that doesn't exactly match the monitor/TV resolution after upscale.
4. Rendering opaque and translucent objects at different resolutions.

Implementation recommendations:

1. Rendering at lower resolution internally, but outputting to native.
2. Render at lower resolution render target, then do integer upscale and postprocess at native resolution.
3. Use letterboxing to work around weird resolutions.

Do not render at lower refresh rates.

Low refresh rates (under 60Hz) increase input latency and make the gameplay experience worse for the player.

What is allowed:

1. In case of a high refresh rate monitors (90Hz, 120Hz, 244Hz etc) it is allowed to render at 60Hz.
2. It is always allowed to render at the highest refresh rate the hardware supports, even if it's lower than 60Hz (for example incorrect cable/HW configuration or user explicitly configured power/battery saving settings).
3. Offering alternative graphics presets to reach target refresh rate.

What is not allowed:

1. Explicitly targeting 30Hz refresh rate during development.
2. Using any kind of frame generation - it does not improve the input latency which is the whole point of having higher refresh rates.

Implementation recommendations:

1. Decouple your game logic update from the rendering code.
2. Use GPU-driven rendering to avoid CPU bottlenecks.
3. Try to target native monitor refresh rate and use the allowed integer scaling to match it.
4. Use vendor-specific low-latency input libraries.

Do not use temporal amortization.

If you cannot compute something in the duration of 1 frame then stop and rethink what you are doing.

You are making a game, make sure it looks great in motion first and foremost. Nobody cares how good your game looks on static screenshots.

In many cases bad TAA or unstable temporally amortized effects is an accessibility issue that can cause health issues for your players.

What is allowed:

1. Ray tracing is allowed as long as the work is not distributed across multiple frames.
2. Any king of lighting or volume integration is allowed as long as it can be computed or converged during 1 rendering frame.
3. Variable rate shading is allowed as long as it does not change the shading rate based on the viewing angle and does not introduce aliasing.

What is not allowed:

1. Reusing view-dependent computation results from previous frames.
2. TAA, including AI-assisted TAA. It never looked good in motion, even with AI it breaks on translucent surfaces and particles.
3. Trying to interpolate or denoise missing data in cases of disocclusion or fast camera movement.

Implementation recommendations:

1. Prefilter your roughness textures with vMF filtering.
2. Use AI-based tools to generate LOD and texture mipmaps.
3. Use AI-based tools to assist with roughness texture prefiltering, take supersampled image as an input and train the AI to prefilter it to have less shader aliasing.
4. Enforce consistent texel density in the art production pipeline.
5. Enforce triangle density constraints in the art production pipeline.

and it seems reasonable to say that you should at least initially plan to target 60 FPS, to use either native resolution or integer scaling, and to render all your stuff in one frame, only allowing one of those things to slip if you need to do it to hit a release date. Don't soften your thoughts where you don't have to.

Fair enough, I've updated that section again.

I agree with that as well, though the question I was posing was more about targeting 30 FPS from the start because you "know" that the hardware can't keep up with 60, which does seem to be a bad thing to do according to this manifesto.

There are Switch games that target 60 FPS from the start, I don't think they look worse or are worse games because of that. When you're targeting 60 FPS you need to do different type of art direction to make up for less fidelity and I think this is largely ok and accepted by the players.

it has to compete with the Playstation, Xbox, or PC, where it finds itself at a disadvantage.

I don't think that the Switch is trying to compete with PC or other consoles, it has found its own niche and largely does not overlap with the rest of the industry. It does have to compete with the Steam Deck though and I think it's going to be a pretty healthy competition in the future if Valve doesn't abandon it.

There are Switch games that target 60 FPS from the start, I don't think they look worse or are worse games because of that. When you're targeting 60 FPS you need to do different type of art direction to make up for less fidelity and I think this is largely ok and accepted by the players.

Agreed - I was mostly referring to the games that do target 30 FPS for the sake of visuals, such as Zelda: Breath of the Wild, Zelda: Tears of the Kingdom, Mario Kart 8 Deluxe in 3- or 4-player splitscreen mode, Animal Crossing: New Horizons, and all of the mainline Pokemon games, as well as some third party ports like Apex Legends and Fortnite. Pretty much all of those have gameplay that markedly improves when accelerated to a steady 60 FPS (even Animal Crossing, which has timing elements for catching bugs/fish and harvesting minerals).

I don't think that the Switch is trying to compete with PC or other consoles, it has found its own niche and largely does not overlap with the rest of the industry.

Agreed there as well, though it ends up doing that a bit anyway be the fact that it connects to a TV at all, and thus competing for the TV user's attention with other consoles and entertainment devices that rely on that TV. Though admittedly, the fact that the Switch can seamlessly transition from docked to handheld lessens that impact (since the TV can be freed up for another purpose without disturbing the game), though then again, that was hurt by the fact that the JoyCon thumbsticks wore down in a matter of months and made handheld play a lot more expensive or subpar than it should have been.

@ThreatInteractive

I took a look, while I admire your passion, it seems to be very early in the brainstorming phase. I'm all about practical application and testing, so I typically dive into in-depth discussions that have some real-world implementation or prototypes to back them up.

I'm going to have to pass on further review unless you have something concrete to show. I'm fairly busy with the projects that are already in motion.

I hope you understand my perspective and I wish you all the best with the implementation. Let me know if/when you have a working prototype.

@ThreatInteractive I don't like the video for the following reasons:

• You don't present any new information/findings, all the stuff you're talking about is relatively common knowledge and there wasn't anything new for me there.
• There are no actionable items, just 20 minutes of non-constructive flaming
• I think you need to calm down a bit, the world is not ending, there isn't some kind of a graphics mafia oppressing everyone - don't be so angry.

Good luck with your game and further research, I sincerely hope that you succeed.

Hi Kirill!
As far as I agree about TAA and temporal effects, myself prefer more MSAA / SMAA, Im not sure I agree about GI solution which should converge over one frame. I've worked with various GI techniques - LPV propagates over frames / RTXGI accumulate irradiance per probe over frames.
I think we still can try to keep geometry as much sharp as we can, however light can be spatially upscaled / temporaly accumulated because we don't have good solution yet, unfortunately.
Also a question, do you know is it possible to make friends MSAA and V-Buffer? If we render geometry and triangle indices into intermediate buffer, Im not sure how we can utilize MSAA here. Feels like SMAA is only option?

@krupitskas In the visibility buffer shading is decoupled from geometry raster, you can render the VB triangle ID into MSAA and then during shading pass you can fetch individual subsamples and shade them as if they were regular pixels and blend the result, this basically supersampling and I'd say it's not going to be practical. In theory it is slightly cheaper than actual supersampling because you render the triangle ID buffer once, but the shading cost is going to be exorbitant.

LPV doesn't have to propagate over multiple frames, you can run more than one propagation step per frame if performance allows.