This week Lukas Stockner visited the code quest to finish some of the Cycles improvements he’s been working on, and to discuss and plan future Cycles development. The main focus was on adding UDIM support to Blender, Cycles and Eevee.
UDIM
UDIM is standard for UV mapping different parts of a model to different images. Rather than a single very high resolution image, for example a character’s head, body, hands and feet can be mapped to their own image. Each image can have a different resolution depending on the detail needed for that part of the model.
This is a standard supported by many texture painting applications, and to goal is to make it easy to apply and edit UDIM textures in Blender. During this week Lukas rewrote an earlier implementation to integrate it more deeply with Blender tools and improve usability. While it is not fully finished yet, it’s getting close to ready to go into the 2.8 branch.
Briefly, in Blender a single image can now consist of multiple tiles, with each tile corresponding to an image file. This tiled image can then be used as if it was a single high resolution image for file loading/saving, material setup and texture painting.
Image files are expected to follow the UDIM naming convention, with tile numbers ranging from 1001 to 1099 (for example koro_basecolor_1001.exr).
UDIM in Eevee viewport
Currently there is support for:
- Creating, loading and saving tiled images
- Rendering in Cycles and Eevee
- 2D and 3D texture painting
Some features are still being worked on, like UDIM support for single texture display mode, modifiers, and some other parts of Blender.
Ambient Occlusion Shader
This week we also improved the Ambient Occlusion shader, so that it can output colors for procedural texturing. This was one of the most requested features for Cycles. It can for example be used to add weathering effects to just the corners of a mesh.
This is now available in the master and 2.8 branches.
Rust blended into corners based on AO (model by Emiliano Colantoni)
More Features
A number of smaller features were added as well:
- Support for adding more render slots than the default 8, and clearing render slots. (in 2.8)
- Auto detect importance sampling resolution for environment textures. Previously users would have to manually set an appropriate resolution to reduce noise, now it’s automatic for the typical cases. (in master and 2.8)
- Ground work for rendering in wide gamut color spaces. Cycles now has basic OpenColorIO integration to handle wide gamut colors correctly for shader nodes like the sky texture and wavelength. (in master and 2.8)
I am wondering if you guys are working with Armorpaint, especially for UDIM support for PBR 3D texture painting? Algorithmic Substance Painter is now Adobe property and has likely locked UDIM support behind subscription only, which has people looking for open alternatives such as Armorpaint with Blender.
Great news yes !!! Do you know when it will be in Blender 2.8 ? Is it possiible right now with beta ?
Thanks
“Chants” UDIMS, UDIMS, UDIMS!
The work around Blender 2.8 is so amazing! I love playing with eevee when it behaves lol. Can’t wait for the beta in August!
Thank you to all developers for making this software even more amazing.
As a photographer, I often use photographic content for images and textures in Blender. Unless I convert that content to sRGB IEC61966… in a program like Photoshop, the color response is no longer valid, or at least not the same.
With OpenColorIO being implemented, does this mean that color profiles such as Adobe (RGB) or ProPhoto RGB, (with their larger color spaces) can be used natively?
On a side note, are there any plans to extend the Filmic implementation in Blender to allow custom LUT’s to be used? The ability to pre-visualize color-grading schemes in Blender would be quite valuable I would think. I have to go through a number of hoops to try and pre-visualize the colors of rendered content, based on my library of LUT’s.
Thank you for all your work :)
I could kisss you Lukas this is amazing work this is very important for workflow in the industry
Yay for UDIMs this will be really useful. I love the improvements. Keep up the good work :)
I guess this could be used to optimize memory usage. Will the automatic UV unwrapping tools support automatic unwrapping to multiple tiles/files?
Cool stuff. Looking forward to UDIMs!
Nice, UDIM’s going to be great!
Oh I’m curious about OCIO for shader nodes. What exactly does that change?
Is the Sky Texture node now giving a more convincing, higher dynamic range lighting? Or is the dynamic range the same, but the wider gamut allows for greater saturation? Or what?
I noticed the standard Sky Texture model, in Cycles while using Filmic, gives pretty dark results unless you crank the brightness a lot), but the other one (the one without extra Albedo option) is far brighter. Are they more equal now? And/Or more sensible at default settings?
Sorry to disappoint, but with the default config the result is absolutely identical.
The point of these changes is to properly support non-sRGB working spaces. For example, let’s say you’re rendering with a custom OCIO config that uses DCI-P3 for the Scene Linear role. Of course, a blackbody of 5000K has a precise physical meaning, so it always has to look the same. However, in the different colorspace, you need different RGB values to get that exact color.
That is what this change does – instead of just assuming that Scene Linear is sRGB, Cycles now actually looks up the transformation from XYZ (which is a colorspace that has an absolute definition since it’s defined through color matching spectra) to Scene Linear in your OCIO config. Since the default Scene Linear *is* sRGB, though, nothing changes for probably like 99.9% of users.
this is fantastic news! are the other areas, where sRGB is assumed, being handled as well? I believe there are a few hidden source code corners where they still linger around
Yeah, it’s all over Blender. For now, I’m focusing on Cycles since that’s what I am most familiar with.
In Cycles, there are two problematic areas left. The blackbody node currently uses a set of fitted functions to directly evaluate the sRGB values, I’ll have to replace that with a XYZ fit and the proper transform.
The second one are image textures – currently, images are only converted from whatever Colorspace they are set to in Blender to Csene Linear if they’re float images and packed, otherwise Cycles just assumes they’re sRGB.
I plan on fixing both of those very soon, though.
Thanks for the explanation. Well that’s great too, even if it doesn’t affect the specific use case I mentioned. In anticipation of upcoming technology (such as HDR screens), it’s gonna be a very important change, right?
And presumably also for more complex multi-application workflows where you wish to use specific, wide gamut work spaces to preserve more details throughout what ever modifications you want to do before going to what ever final color space.
Should have read “Make Cycles colour managed”.
Beautiful
Great news! I love good surprises. Keep up the good work, guys.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.