Anyone experiencing this issue in Blender 3.2 release candidate where for some wierd reason, assets in the 3d scene get darken albedo all of a sudden without any changes made to the material when rendering with Cycles?
I can’t pinpoint what is causing this issue. Might be a bug?
Just a hunch. Double check your color management. Make sure everything is correct. Also check textures color space.
There has been some changes/improvements to how Blender handles OCIO. This might screwed up with older assets.
1 Like
I think its a material issue. Might have something to do with a material node getting broken. It seems to happen when I select some other meshes.
Might be the Hue/Sauration node. Not sure. Still troubleshooting it.
No it might be not, but if you work with different applications assets or different people you want to avoid a lot of troubles regarding color space conversions etc. .Because even a single component can open a can of worms, and its really hard debugging such issues.
If you client uses aces your answer should be “ok”, and not “but we have something better…but I need 3 hours to explain the in and outs of why …and then you need another week to adapt your pipeline to it” because you can’t communicate that or even enforce it.
And this goes even to one man shows where people simply do not have the time to invest days/weeks/months in learning the in and outs and why it does not work as expected
Its a very complex topic, and if you don’t have the knowledge, you simply want to be on the “secure” side.
And aces provides some kind of security, because its widely supported. So aces is more about avoiding getting into the topic than diving into it.
Look AgX looks really great, and I’m glad development goes into this, by people who knows more about it than me, but we also need to be as flexible as possible to adapt to current and future conditions and piplelines. And a good OCIO/aces support provides that to a certain point
Especially for an open source package, where development in this area might or might not progress in future.
so this is not about beeing better or worser.
Edit: I would be going even further and say that AgX and aces/ocio implmentation do solve two completely different problems.
3 Likes
Lukas Stockner’s report (an alternate title, what we can expect now with a dedicated Cycles engineer who is familiar with the code).
User:Lukasstockner97/Weekly Reports - Blender Developer Wiki
In short; Principled Shader 2.0 is coming, PMJ sampling may soon get better, blue noise reduction is being looked at, and the calculation of tangents is seeing big performance improvements.
18 Likes
This is sadly what I said “If you are forced to use ACES by your clients or your studios”.
If you are not forced to use ACES, don’t touch it.
Don’t confuse “I am forced by the client to use it” with “So it’s actually a good thing”. It is not.
This post confuses me. How are the color management problems in blender related to other software using aces? Color management matters when you use blender to render the final image. The color transform options don’t apply to multi-layer openexr files, and you would use those instead of pngs or whatever if you are going to composite blender’s output in other programs that support aces.
I’m not an expert so bear with me, but if I understand correctly, you may want to render to a broader color range, like Rec 2020. Then even if you render to .exr (in linear), you need to specify that these colors are supposed to represent Rec 2020 values. A 0,0,1 blue in Rec709 doesn’t correspond to a 0,0,1 blue in Rec 2020.
Also, when rendering using say Filmic in blender, you get a certain look. So in the compositing application you need to apply the same transform so the render are similar in both apps.
If not , say you render an exr image in blender using Filmic then composite in Nuke using Aces, you’ll get a really different result. This then get confusing because in comp something may be too bright, but it may be hard to tell in blender.
Hopes that helps, all this is a bit foggy to me !
1 Like
You were right. It was the normal map texture color space that was causing the issue. I have been using the AgX color management for 3.2 so I set it to ‘‘Generic Data’’.
I then opened the file in an older Blender version to use a addon that has issues with the newer version and saved. Then reopened the file in 3.2 and since the older Blender version was using Filmic after I saved it and opened in Blender 3.2, it screwed up the texture color space of the normal maps of some materials in the scene. Should have checked them probably like you said.
1 Like
I wouldn’t put ACES along with OCIO with a slash. AgX depends on Blender’s OCIO implementation, (for example, Blender had bugs with OCIO’s aliases feature, the bug was causing problems for AgX. For example, AgX have some transforms to inverse its view and looks, but Blender has been having some problems to use them with 8 bit images until some recent 3.3 bug fixes. Blender 3.1 has some problems with OCIO’s Grading Primary Transform, so the AgX development was forced to stop until the problem was fixed. Better OCIO implementation enables better suppport for the future better options.)
I have said it in some other threads, but ACES has an OCIOv2 config that is just 17kb in size, if that’s what you want just load the config and use it. The only thing you need to do is to open it with a txt editor and change the version number from 2.1 to 2. And you have your ACEScg as working space and your ACES output transform that you need for your clients.
But for those who really cares about image formation, let’s use the better options.
2022-06-07 Render & Cycles Meeting - Blender Development / Meetings - Blender Developer Talk
Notes
- Blender 3.2 release is imminent, no more changes or fixed planned.
- Intel OneAPI status: work is ongoing to get build and other issues sorted out.
- Apple Metal: Michael will continue work on SVM optimizations. Also there will likely be a patch to tune parameters for specific GPUs.
- AMD HIP:
- Linux RDNA1 bug with certain texture resolutions is still there, we will release Blender 3.2 as is with a note in the release notes, waiting for a driver bug fix.
- For Vega, a new Windows HIP SDK version is being tested that may get this working on Windows.
- Brecht started looking into how to use the geometry nodes fields for new texture nodes on the CPU.
- Lukas will post a design doc for Principled BSDF changes, and worked on various refactoring required for the implementations. He also looked into potential improvements to the sampling pattern, as well as blue noise dithering, though it’s unclear if the latter can be made to work well with adaptive sampling. He also looking into speeding up normal map tangent space computation by multithreading.
- Christophe is looking into adding better IOR support for random walk subsurface scattering, to actually take into account the IOR for rays going into the surface from the viewer.
- Sebastian plans to post a development branch with path guiding support in the coming weeks. Also still needs to meet with Christophe and Olivier to discuss integration with MNEE.
- Alex reports that Cycles is being integrated into Gaffer, as an alternative to Appleseed.
If the GSoC project regarding multi-light also goes well, it will mean the possibility of rendering just about any lighting situation in a reasonable period of time (since Path Guiding also looks to be on the agenda now). That means 2022 could be among the best years ever for the Cycles engine.
13 Likes
And what about this?
- A new bone-less character system by Pixar: https://graphics.pixar.com/library/ProfileMover/paper.pdf
- Ton is contacting Pixar to see if we can collaborate on getting this into Blender.
From https://devtalk.blender.org/t/2022-06-09-animation-rigging-meeting-upcoming/24653
10 Likes
This is the Cycles thread, the animation meeting notes should go in the meetings thread.
1 Like
Ooops! Of course, sorry.
Would you like to develop this further, or perhaps send me somewhere i can read more :). ?
Lightgroups are great addition to cycles feature set, i hope its polishing for production workflow will not get delayed too much. (per-collection lightgroups, T78008) it’s a must for managing scenes with multiple lights.
4 Likes
I am SO excited about this, personally. This addresses most of the problems I have with the current setup. Fantastic!
The new metallic controls, more intuitive SSS, more tinting options, thin surface mode. WOOHOO!
10 Likes
Just a heads up, the multi-light sampling student, in the last week or so, committed light tree support for omni lights, spotlights, area lights, and emissive triangles. It is now possible to test some interior scenes in his branch.
Distant lights meanwhile are slated to be supported this week, so he is moving pretty fast on the objective on getting this into master.
12 Likes
The notes for today’s Render and Cycles meeting.
Notes
- Apple Metal: patch to distinguish between M1 chips with different number of cores will be submitted, as these are incorrectly treated as the same in benchmarks. Patch for shader optimizations was rebased but is still being worked on.
- AMD HIP: patch was submitted for Vega support on Linux and Windows, will need some buildbot updates and can then be committed. The bug with textures for RDNA1 on Linux is being fixed, but no concrete date yet for when this lands.
- Intel OneAPI: plan is to merge this for 3.3 still. Still some issues to solve regarding compilers, licensing, and implementation details, but there is a working implementation.
- Principled BSDF v2: Lukas posted a design doc on the wiki, and made significant progress on the implementation, but still various things that need more work. A branch will be published soon. There was some discussion regarding compatibility with BSDF models in other software, we’ll need to make a more specific comparison of all the parameters so this becomes more clear.
- Many lights sampling: Jeffrey got a basic implementation of the light tree working with point, spot and area lights. Next things to work on would be support for distant/background lights, which could be done by picking a light from the light tree, and then probabilistically choosing between that and distant/background lights by comparing the solid angle and energy. Another thing to check next will be to validate the light tree is working, with some simple synthetic scenes like many point lights over a plane.
- Path Guiding: Sebastian still expects a branch to be published soon.
In Short, Multi-Light sampling is almost ready for wider testing and a branch for Path Guiding is still en-route. There will also soon be a branch for the new Principled Shader.
16 Likes