Rendering, Rendering Blender Version Compatibility, Rendering with OPTIX, Rendering Determinism

Renderjuice 2.3 was released on March 22, 2024

​

Key Summary

• Improved rendering stability by implementing a new internal application that compares rendered images pixel by pixel.
• Enhanced compatibility by upgrading the system to ensure Blender build versions are better maintained.
• Implemented new code processes for automatic code checking.
• Restructured application to improve scalability and performance.
• Developed comprehensive test suites to quickly identify issues in new features.
• Streamlined internal render farm tooling for easier feature development.
• Addressed OPTIX denoising issues by using OPENIMAGEDENOISE (OIDN) as a fallback.
• Reduced rendering-related issues and tickets by more than half since the release.
• Improved validation phase with better status handling and transitions.

​

Rendering, Rendering, Rendering

Our team has been on a bit of a rendering stabilization tear recently, and we’ve been adding a ton of improvements left and right. We increased general performance and handled a ton of edge cases. We want better determinism when rendering wherever, so you and all of our other users know what to expect when you use renderjuice. While we have a very very strong track record of rendering without issue, this is the crux of our product. So our focus has actually been on vastly improving its core capabilities for 3-4 months now behind the scenes. This is the public release of all of that work. Phew! Couple things we did:

• We wrote a whole new internal application that actually renders a ton of Blender files for us and compares the results pixel by pixel. So that we automatically know when images don’t look correct.
• Similar, but slightly off renders, can happen when Blender build versions are not exactly the same. For example, if your .blend file was built in 3.6.8, but we use 3.6.9. So we’ve vastly improved our system for better upkeep of Blender versions.
• We’ve introduced new internal code processes to auto-check code.
• Restructured big parts of the application to scale better and perform faster.
• We’ve written many many suites of tests that force us to immediately know when things are going awry in new features.
• New internal tooling so that we can run our own render farm much easier. We use this farm to develop new features for you!
• Improved how we handle denoising and investigated a couple tricky OPTIX denoising issues. We’ve unfortunately found that this is actually an NVIDIA driver bug and can’t do much about it, but wait. But we smoothly now force renders that must use OPTIX renders to use OPENIMAGEDENOISE (OIDN). We’re pretty proud of this and hope you enjoy too. Since launching this (this was written post-release), we’ve seen issues and total number of tickets related to rendering get cut down in more than half. I might even risk saying we’re very stable now. Huge kudos to the team 🤝 . Please give them a shoutout whenever you’re chatting with them, they deserve it!

​

Validation

The validation phase should be a bit smoother now, we’ve added a new status, and handled transitioning statuses better.