Cycles: Different results of the same scene on different computers #95895
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#95895
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.65
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.65
Blender Version
Broken: version: 3.1.0 Beta, branch: master, commit date: 2022-02-18 21:28, hash:
93cc892470Worked: 3.0.1, branch: master, commit date: 2022-01-25 17:19, hash:
dc2d180181Short description of error
I discovered strange behavior. I am rendering the same scene on two different computers with a different result.
Exact steps for others to reproduce the error
I will try to isolate the issue into a simple scene.
Please compare the pictures. Both are GPU rendered on different RTX cards with the same Nvidia driver.
RTX 3080 mobile
RTX 3070Ti (tested on 4 systems with the same configuration)
Reflections and emission results look different. Same result when rendering with CPU.
+++ UPDATE +++ Works with Blender 3.01 release.
Added subscriber: @Renderbicks
#95894 was marked as duplicate of this issue
Testing on other computers.
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.09 + GTX 1080Ti
Conclusion:
Blender 3.1 Beta renders a different result with the RTX 3070Ti for unknown reasons.
Blender 3.01 Release is rendering the same result as my other configurations.
Added subscriber: @ThomasDinges
Changed status from 'Needs Triage' to: 'Needs User Info'
Hi,
an example file would be helpful, maybe you can simplify your scene?
Do you use OPTIX on both systems? Or CUDA? Can you try the other method and check if the issue persists with that as well?
Tested on three systems with CUDA/OptiX. I will upload a simplified scene.
I was able to identify the reason for the difference. It's the Subdivision Modifier. I am using "Crease" with "Subdivision Modifier" for the parts. For an unknown reason, the "Subdivision Modifier" result of Blender 3.10 Beta is broken on the computers with RTX 3070Ti and i9-11900K.
Scene
Tron_Grid_v030_Reference_ShadDiff_Simple.blend
RTX 3080
RTX 3070Ti
Blender 3.01 gives the same result.
Screenshot 3.10 Beta on RTX 3070Ti
Modifier ON
Modifier OFF
Added subscriber: @kevindietrich
@Renderbicks Thanks for the scene and the investigation!
@kevindietrich Hey, can you take a look at this report please?
Changed status from 'Needs User Info' to: 'Confirmed'
It's a pleasure to support the best developer team of the century of the digital revolution. ;-)
Here's the system info for the RTX 3070Ti computers.
DxDiag_RTX3070Ti.txt
Additional Info:
The main difference between the three systems is the CPU.
https://developer.blender.org/rB56407432a6aae92dc272f7c8b37fc664e8d2108d
Looks like it's the GPU acceleration. It's turned off when I render with 3.01.
Added subscriber: @SteffenD
While trying to reproduce the problems I noticed that there's quite a combination of things that can influence and break the shading:
I don't know why the geometry even renders smoothly without GPU while flat shading is on. This will be a hell to debug or fix because the whole normals situation is currently so convoluted in Blender.
And this might come into play as well https://developer.blender.org/D12770
Added subscriber: @brecht
What do you mean by this exactly? There exists no GPU subdivision option in 3.0.1.
Are you saying that the difference between these two machines was that in Blender 3.1, one had the GPU subdivision on and the other off in the preferences? Or that you assume because there was no GPU subdivision option in 3.0.1 and there is one in 3.1, that explains the difference? Or something else?
Sorry for the confusion. GPU subdivision doesn't exist in 3.0.1. Therefore it's "turned off" compared to 3.1 and higher.
Cycles does not make use of GPU subdivision. It could be that some data is missing from the mesh wrapper as the modifier evaluation is outside of the regular modifier evaluation code. But it could be that the issue is somewhere else. I guess the first thing to do is to render the scene with GPU subdivision turned on and off in 3.1 and see if the result is different.
The results are different in 3.2 master depending on whether GPU subdivision is used or not. GPU subdivision shows the faceting (coming from the fact that the mesh has custom split normals and is set to flat shading, I guess that GPU subdivision doesn't handle this case correctly?) while non GPU renders smoothly.
I think we should disable GPU subdivision if custom split normals or autosmooth is used.
Supporting them with OpenSubdiv on the GPU is probably difficult, and I'd really consider them distinct workflows (explained more in #68893).
Added subscriber: @juang3d
Wait a minute… I’m missing something I think.
Practically EVERY OBJECT in any scene has Auto Smooth enabled, the case where Auto smooth is not used is soooooo smal that is practically marginal, so disable it would render GPU Subdiv useless, or nearly useless.
It’s not the same as custom hard edges or custom normals, but Auto Smooth is general and widely used / required
There is a bug report about autosmooth not working with GPU subdivision already (#94921), I tried looking into it on Friday, but it's really not clear how it would work. If this is also the root of the issue, then we could merge the reports and I'll make a patch to disable GPU subdivision in this case.
@juang3d I am not too familiar with autosmoothing, but your preferred workflow might not be the general case. Really, any type of custom normals should be avoided with OpenSubDiv, as it is expected that limit normals will be used for shading. Even Alembic and USD do not provide a default normals attribute in their subdivision objects (which are a separate type than regular meshes, with explicit normals).
In Blender Studio production files and our benchmark scenes it's rare to have both a subdivision surface modifier last in the stack and autosmooth enabled.
In most cases it's a waste of time and memory, and I don't know of any renderer that supports rendering that kind of surface directly. It's unfortunate we don't have a good UI yet to make that distinction clear, but I think the right solution is to discourage this rather than trying to support it.
Mmm maybe both of you are right, but then how do you get a perfect cube with correct normals if you don’t have auto smooth?
Or maybe you rely in SubD amount, I mean if you get a high SubD level geo you may not need auto smooth, but with a lower amount of SubD without auto smooth you would get weird interpolated normales in the corners.
However if it should not be supported, in the end we are talking about SubD, then a warning in the SubD modifier could help to communicate this, because it’s not that is my preferred workflow, is that I know very little people that don’t make use of custom normals or at least auto smooth, basically because when you go into edit mode without SubD enabled the geo looks difficult to interpret, and SubD modifier is not something taken into account to disable auto smooth, when given what you say, it should be.
In my experience OpenSubdiv (or subdivision surfaces in general) don't use custom normals because the algorithm itself is responsible for generating its normals on the limit surface. If you want a perfect cube, use creases.
2022-02-22 14-40-31.mp4
I think in high end animation or VFX you simply don't want to see perfectly sharp edges anywhere. Of course that requires enough subd levels and realism is not what everyone is going for, but it's what OpenSubdiv, file formats and renderers are designed around.
We could have a message in the modifier if GPU subdivision is disabled for this reason. Long term I think we need #68891 and #68893 to clarify the intended usage.
Perhaps it would still make sense to somehow do per-corner normals for perfectly sharp creases, if an efficient implementation can be found. But that's certainly not for 3.1. Auto smooth angles just don't make a lot of sense because the creases already define what is sharp.
Even in high end vfx you have to save memory where ever you need to.
The case I said for the cube is this one, to get something plausible you need 6 levels of SubD
And this is using creases, with 3 levels you get this without AutoSmooth (3 levels is already a TON of geometry):
I know this is an absurd case, but it's just a simple example, even in high end animation and vfx you may tend to use Bevel in the shader before using support edges or actual geo bevel, and yes, you can use creases (you must use creases) but those don't replace auto smooth, even with 4 SubD level it's impossible to use the shader properly, because it delivers this result, remember that this is a forced corner case to use as example, but you can be in production and find this case in very common situations, the problem is that the artist is incapable to identify the origin of the shading artifact (or it can be identified but it starts as something wrong with the shading):
So I get your point, but in something like, let's say Vera, or PJ Masks or Barbie, you don't want to go to Marvel level of detail, and in those situations, that is IMHO a good example of the usage of Blender, you need Auto Smooth to avoid millions of polygons that are not actually required.
Anyways, IMO two possible solutions are here if they cannot be implemented (apart from automatically disabling them with GPU Subdivision), a warning informing from this to the user and an option to disable them at render time from the SubD modifier, that way you could allow the user to decide if that specific object has to use GPU SubD or if it has to use CPU SubD because it actually needs that feature, I think this would ease the possible problems users can find because of this.
EDIT: @SteffenD you actually have shade smooth enabled... I'll look into this and why I don't get the same result as you, as you can see in my examples
EDIT2: Ok, I tested it, without GPU SubD enabled your example does not work, I mean no normals are being generated, but with your example normals are as in my example up to 0.99 of crease intensity, but at 1.0 it actually make the sharp normal.
Is this difference expected?
Also that sharp edge works in viewport, but it does not work at render time, examples:
No-GPU SubD:
GPU Sub-D Viewport:
GPU Sub-D Render time:
This difference from the viewport result and the render result is probably not expected by the user, I assume is not normal that this happens.
(in every example no auto smooth enabled, no custom normals)
@juang3d You are of course right. I never actually build hard surface stuff from SubDs that's why I didn't bother rendering my example ;)
But the rest is still true: Custom normals and SubDs aren't best friends. Still funny why the GPU viewport shows this result.
Yes, I imagine that the GPU SubD Viewport result is the correct one and there is something missing in the render code?
I would assume that GPU SubD Viewport is the correct result, that way you can ignore auto smooth in most cases, and something is missing in GPU SubD render time, CPU SubD Viewport and CPU SubD Render time.
Closed as duplicate of #94921