Visible wireframe artifacts after baking normal map with bevel shader (2) #72011
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
21 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#72011
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 Pro
Graphics card: Radeon(TM) RX 460 Graphics
Blender Version
Broken: 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash:
26bd5ebd42, type: ReleaseWorked: do not know
Short description of error
Wire-frame like artifacts on the baked normal map when using bevel shader node
Exact steps for others to reproduce the error
Long description of error
It seems to me that the bevel shader node is affecting the normals across the all shading points on the surface and not just at the place where there is beveling,
which produces easily visible artifacts that follow the mesh wire-frame, especially when using high gloss values.
In the image bellow and in the blend file normal map is shown on a plane to see the issue more easily:
But the issue is visible on the model itself and persists when working with other models and blend files:
Normal map exaggerated with levels in PS for illustration:
Clearly visible artifacts in the places where normals should be flat (pointing up) and shouldn't be affected by the bevel node.
This is why i think (i might be guessing too much) this is the same issue as in https://developer.blender.org/T61916. But the OP never responded to clarify the issue.
As i tried to work around this issue i also found out:
Which is really not a viable option since there is no multi-sampling when baking in blender, and we get other kind of artifacts where normals should simply be flat.
Below is object space map rebaked to tangent space map
Which at first seems as expected result, but when i added gamma node after the vector math node:
Result above suggest to me (i am just guessing as a layman) that the range of bevel shader node effect on the surface normals is quite wider then it should be. Setup i used is provided in "Collection 2" of the blend file.
So is this a bug, an unavoidable side effect of bevel shader, or it can be improved so this effect is masked and doesn't affect places where normals should remain flat?!
bevel_shader_bug.blend
Added subscriber: @Fuxna
#102968 was marked as duplicate of this issue
#70189 was marked as duplicate of this issue
Little update:
Using uncompressed tiff format seems to give better results.
png bake
tiff bake
and with using setup like this one can get rid of most of the artifacts
Tho they are still somewhat present when i tested with other models
Added subscribers: @Stefan_Werner, @LukasStockner, @Sergey, @brecht, @lichtwerk
The baking issues where mentioned in comments from D2803: Cycles: add bevel shader, for raytrace based rounded edges. as well and in #61916 (Visible wireframe artifacts after baking normal map with bevel shader) (which just died because of inactivity).
Not knowing the internals well, I am not even sure if one get around this issue [other than your proposed node setup workaround], interesting point though about tangent vs. object space.
Will confirm for now, maybe cycles wizards can shed some light on this?
CC @brecht
CC @Stefan_Werner
CC @LukasStockner
CC @Sergey
Any news on this?
Added subscribers: @Raytraced, @AndyDavies-3
Added subscriber: @Scrubs
I am having a similar issue with baking the normal from the bevel node to be used in a real time engine. The wireframe becomes very visible when the normal map baked is plugged to the principled shader with no roughness and the metallic input set to 1.
I have the same result when I bake from the latest development version of 2.79 and 2.81a.
Here is the difference between a normal map baked and displayed in Eevee and the result from Cycles (10 samples in the viewport).
Still unsure if this should be called a bug or a Known Issue (and still havent looked at internals...)
But since Cycles itself is able to render this without artifacts, will dare to call this a bug for now...
@brecht: do you think this could be resolved?
Added subscriber: @Redphoenix
~~This is wrong @lichtwerk . ~~
edit here: Might have misunderstood: Yes, it renders fine, but it bakes with issues
I was the one who made @Fuxna aware of this issue in the first place - and I did render my maps in Cycles in 2.8 as well as 2.81, all with the bug.
And I can also reproduce it every single time. On some faces the wireframe isnt as visible as others, but they are there and do compromise the normal map.
Here is another picture of a normal map from a production asset baked with Cycles and the Bevel Shader in 2.8
So far I had this on every model I ever worked on. Question isnt "could this be resolved" - It really should be "how should we resolve this", cause it quite literally is breaking the workflow to bake normal maps with the Bevel Shader.
Not too sure how complex it would be to solve but it is true that this workflow with the bevel node is currently not viable in Blender. The wireframe is "baked" on the normal map as soon as faces are not perfectly flat.
What I meant was that Cycles ( no baking) does not suffer from those artifacts.
Yes, Cycles is perfect :-) which tends to show that the baking process has a bug.
Yeah I know, my brain had a hiccup at that moment hence my edit later.
But it really needs to be looked at. Its painful to get a good, clean bake.
Added subscriber: @fqcArt
Hello everyone, I have the same problem with the unclean baking result.
I'd like it to be fixed cause I really want to use Blender in a production environment, but like the others, the bevel baking methon is unusable
Added subscriber: @BioDestroyer
I'm having the same problem with baked normals.
However, instead of using the Bevel Node, I was using the Bevel Modifier. I'm not sure how these things work (maybe both the Node and the Modifier function similarly), so I just tested doing a bake without using anything "bevel".
I used the Subsurf Modifier on the high-poly cube, and edge loops at the corners to create beveled edges. The normal map baked from it also had these artifacts.
Also, I think this may not be connected to the mesh wireframe. While it also happens sometimes, I've had a case were the artifacts are completely crazy, nowhere similar to the wireframe.
Image: The artifacts on the right side seem to follow the wireframe, but the center ones are an absolute mess.
Also worth noting, I can swear it wasn't happening, and then it suddenly began. I may have gone crazy since then because of this issue, but I wasn't back then.
I was doing the baking for my model and the reflections were not that distorted everywhere, I only had a few artifacts in some areas (these ones appeared related to the wireframe), but then, suddenly, they began. All while in the same session of blender, without even reloading the file or something.
According to the first screenshot I have of this bug, it began in the 7th of January. This post clearly shows that this has been happening since at least November of last year, however it was fine (or much less noticeable) for me in the 7th of January and, IIRC, some days before. This makes zero sense to me.
@BioDestroyer
Bevel Node and Bevel Modifier have absolutely nothing in common. Bevel shader does not modify the geometry, rather its shading effect that modifies normals on render. And please if you already have decided, to take time to share your problem with us, and devs, make sure its on actual bug report that is relevant to your problem. IMO your problem and our problem here are not related. Simply because, this issue is tied to baking with bevel shader as title says, and we didn't have any problems with baking geometry in general.
Your problem maybe of other kind. Not baking properly, or using formats with low bit depth. If your models are going to be shiny and reflective refer to https://polycount.com/discussion/148303/of-bit-depths-banding-and-normal-maps. This might solve your problem.
Anyway, for sake of solving this particular bug (Visible wireframe artifacts when baking normal map with bevel shader), for which this ticket is made for, for the sake of developers time, regardless if your problem is connected or not, finally for the sake of solving your problem, make sure to describe what you did, and steps taken to get to your issue. You haven't informed us on your baking workflow, on the format used for baking, how do you preview normals. Are artifacts visible on the normal map itself(when looking at the image in PS or similar, as we have)? And you haven't attached your blend file.
Sorry if i am dramatizing, but i really care about this issue being solved. And its not going so well so far.
@Fuxna
I used low-poly, high-poly and cage objects to bake the normal map (which was mentioned in the task's description). The artifacts are visible in GIMP after messing with the color levels. I didn't mention these things because it's just like what other comments said, I only said what I did different, but perhaps I should have had mentioned everything.
I didn't attach a Blend file because it happens with everything, even a very basic setup (and I described one attempt in my original comment).
But I'll look at what you suggested and search more about it, maybe there's something for me there and it's truly a different problem.
@BioDestroyer
Well, if that's the case, it might be that baking in blender is totally broken. But then, how this issue wasn't raised before. I am sure people would rage about it. Cause baking geo is done much more often than baking bevel shader. I think people use bevel shader mostly for rendering effects, which works without any problems, so that's why this bug went unnoticed until now. Also being that artifacts are often subtle and only visible on glossy reflective materials didn't help.
So, after extensive testing and research, I've come to many conclusions. I was actually having two problems, and the first one may be related to this one.
My first problem, the artifacts unrelated to the wireframe: Increasing the bit depth (selecting 32 bit float) when creating a new image through the texture node fixed it. (Doesn't explain why it wasn't happening before, but whatever, it's fixed).
Now, the potential connection to this problem: Later, when I was testing your problem, I noticed your normals also had the pixelated-like artifacts mine had, besides the wireframe ones. Then, I checked the color levels of the image in GIMP, and I noticed one thing: The image created in your setup is 8 bits.
If you create an 8 bit image ('32 bit float' not selected), the color level scale is 0-255, however, in a 32 bit image (16 bit, after saving as PNG), the scale is 00,00-100,00. What the actual difference is, I don't know.
I created a new node, then a new image with 32 bits. The bake made in it didn't have the wireframe artifacts. (Note: I also deselected 'Alpha', I believe that shouldn't affect things, but deselect it, just in case. And you can test if it does, just to know.)
So, while our problems were technically different, they appear to be both caused by baking the normals into 8 bit depth images.
My second problem is unrelated to this, so I won't go into depth here, but just in case anyone is curious: It is the normals of the high-poly model itself that get distorted in certain areas after smooth shading. Sometimes increasing the bevel disguises it well, sometimes it doesn't. Here is an image with examples, just to sate any curiosity:
Left: 3 images showing the reflections, and the normal map with color levels modified in GIMP applied as color below them.
Right top: A mesh with bevel modifier levels of 2-6-12 showing it can still be visible with a roughness of .25 (and I've had even worse cases than this).
Right bottom: 3 different copies of the same mesh with different manual bevels applied.
I'll search more about this, but if I don't find a fix, I'll post it here as another task.
Yea, you can look at my second post (click on show older changes to see it) where i did bake with uncompressed TIFF. Tho it gives better results, wireframe is still visible, at least in my test case, and several other guys that did tests on their own have confirmed the same issue. Not having clear reflections and wireframe artifacts might be separate issues, at least from my experience as a 3D artist (which in this case means very little). Having banding issues with lower bit depth is common and known, in other 3D softwares also.
As for "pixelated noise", yes. Tho those only showed if i bake with bevel shader. Not in general - when baking geometry. That's why in my first post i raised the question why is bevel shader affecting normals that are flat or nearly flat.
@BioDestroyer Also your example with "manual bevels" is a problem(not a bug) with vertex normals - which also has nothing to do with issue discussed here, but anyway, if you want clear reflection why not use custom/weighted normals?
defualt smooth shading:
Weighted normals modifier
Or set normals from face to get absolutely clear reflection
Also please, lets not clutter this discussion with unrelated topics, anymore. Cheers
Added subscriber: @Nominous
The duplicate by Max (Raytraced) that was merged to this report forgot to mention that he experimented with increasing the bevel shader samples past 16 (512+) by using a custom OSL node, which seems to solve wireframe artifacts in the normal map bake: https://polycount.com/discussion/comment/2701351/#Comment_2701351 Maybe that would be a good path toward solving this problem?
Edit: I just did some test bakes and the OSL node above with 512 samples produces quite clean results on an object that had wireframe artifacts when using the regular bevel shader.
Regular bevel shader (1k image res, 16 bevel samples, 16 render samples):
OSL Node (1k image res, 512 bevel samples, 1 render sample):
This can be tested on the ProbCube1 object in this blend file. I made both image textures 32-bit and non-alpha for each bake: Bevel Shader Custom OSL Node by sqrRedwend.blend
@Nominous Maybe, but for me computation time was insane.
Anyway, PLEASE fix this bug. Its SO annoying to see non-useable normal maps.
Once again this is a model with a normal map baked in Blender with Bevel Shader
15 - 30 min for baking bevel is not a right solution. Question is why are normal of the non beveled edges affected in the first place. Can't they be masked and mixed with original normals? All we got on this ticket are distractions, and no response from devs at all. Is it a bug, do we don't understand how to use it, is it a known limitation bla bla bla...
@Redphoenix @Fuxna The OSL node took me about a minute to bake on an i5-3570k (4.4 GHz, 4 threads total) using the settings I listed above in that blend file. The most important thing is to set the render sample to 1 in the render properties tab. Setting it higher slows the bake down drastically, but it's unneeded. I still think unlocking the bevel samples in the default bevel shader would be a good experiment and I think the OSL node is a good workaround for now.
@Nominous Just tested, it seems OSL node gives better results. Thanks!
Did some tests:
@Nominous
@lichtwerk
OSL bevel shader(512 samples, 12 render samples):
OSL bevel shader(512 samples, 1 render sample):
Blender's bevel shader(16 samples, 12 render samples):
Blender's bevel shader(16 samples, 1 render samples):
It seems baking with render samples >1 introduces artifacts, both OSL node with 512 samples, from file that @Nominous supplied, and blender's default bevel shader with max 16 samples give pretty much same result in regards to artifacting.
Blender's bevel shader 12 vs 1 render samples (16 samples for bevel shader):
Added subscriber: @realeyez
I tested with the OSL node from @Nominous with 512 Samples - still the same errors.
Please, please do not ignore this....
Even tested with Blender 2.82.7 - Just one Rendersample but 512 OSL Node Samples. Same result
Checked again with the scene from @Nominous
Also after talking with @Fuxna we found out that it only happens if you bake on an angled surface.
See:
And flat:
Here's a .blend file with steps to reproduce the issue.
BakeTest.blend
Observe the normal map on the low poly in Eevee and Cycles has artifacts.
The artifacts are twofold - some follow along interior edges, and some are speckled along boundary edges. Both make this an unusable production workflow, as results vary greatly based on geo when they shouldn't. The meshes used are completely practical for a production scenario.
I sincerely hope this bug gets some attention. This has potential to be an insanely useful workflow, but currently cannot be relied upon for production.
Images of artifacts in question:
Added subscriber: @mrgesy
Any news on fixing this? This shouldn't take ages and could be as simple as unlocking the samples in the default bevel shader.
Added subscriber: @scaramanga
any news on this issue? thanks
Added subscriber: @ahtiandr
Bumping this thread as I am really waiting for this bug fix as it could really speedup my production.
For now I am just taking my assets with creases through zbrush and making the bevels there but thats kinda slow process.
Also I am not sure how to open this custom OSL node with unlimited samples in default blender. Is it even possible?
Added subscriber: @LOLDO
For now you can use the solution posted by sqrRedwend on Polycount at https://polycount.com/discussion/214315/blender-2-8-bevel-shader-normal-map-baking-artifacts-on-flat-surfaces.
I used this to bake at 1024 bevel samples and it got rid of all my artifacts.
Added subscriber: @GavinScott
This is still an outstanding issue which needs to be fixed.
Please, do not forget this. It is really annoying if you have high-gloss surfaces and can see all the render issues.
The only "fix" I have for this is to manually remove all the baking issues in Photoshop.
Please, for heavens sake, take a look at this.
Unfortunately it looks like it has been forgotten. Cleaning up the map after baking is the only viable but time consuming and not accurate solution I have so far as well. That is a bit of a shame especially because I use this feature almost on a daily basis.
Bakes like these are simply atrocious.
I sincerely hope that this will be looked at.
Did you guys try increasing the bevel shader samples to 128? I noticed it has been unlocked and I've been getting way better bakes at this setting.
Same error
It is utter bullshot that I have to paint out these kind of issues in Photoshop..... Its ridiculous, honestly.
This is a straight bake, 4k, 128 Bevel Samples, 1 Render Sample.
Added subscriber: @MpuLse
Yeah I can not stress enough how integral this feature is. Definitely can not be used in production as is. I sincerely hope it isn't forgotten about. Cause this is the one thing that could give Blender a massive edge over a lot of its competition by a land slide. Would speed up workflows ten fold.
Blender 3.1 - Still the case....
Added subscribers: @JiriPospisil, @OmarEmaraDev
Any news on this? I wish this would be fixed, it is so so so annoying to fix the normal maps manually...
Patiently waiting as well and manually fixing the textures whenever it is too visible. So looking forward to get a fix for that one.
After looking into the files linked here a bit, it seems like there's at least three issues here:
One causes the problems directly along face edges, even on perfectly flat surfaces. This can be seen in e.g.
BakeTest.blend. Note that this one only appears at more than one render sample.integrator_init_from_bakefixes this. However, just disabling this also disables antialiasing, so we need a better way of handling it.One causes the Bevel output to slightly deviate from what's expected near edges on concave objects. For example, this can be seen in
bevel_shader_bug.blendeven in viewport rendering with the right shader setup (visualizing the angle between bevel output and the smooth normal, strongly amplified):And finally, the third one is that when baking to byte textures, quantization can amplify tiny differences in noise to the point where they just happen to fall into the next pixel value bin, causing a noticeable discontinuity in the reflection.
bevel_shader_bug.blend- note the difference in the two examples below, the only change is that the second one is baking to a float texture.Whatever you decide on doing - thanks for looking into it and proposing solutions to this annoying issue.
@LukasStockner I see you mentioned this in a commit.
Do you have an idea when we can expect this partial improvement to hit a version for us to download?
@Redphoenix The change should be in any 3.5.0 Alpha build (see https://builder.blender.org/download/daily/) since the date of the commit.
Thanks you!
Seems like baking the bevel down to a normal is completely broken in the latest daily.
Left is what I got when I baked the same scene than the right.
Ah, yeah, can confirm the problem. Looks like
dd9e1eded0caused it.Added subscriber: @HooglyBoogly
@LukasStockner @Redphoenix : can you create a separate report for this? (afraid this might be missed otherwise...)
I've been traveling the past few days and today also, so a separate report would be helpful for me to keep track of it too. Thanks.
@HooglyBoogly @lichtwerk #104334
Unfortunately, the fix for #104334 did not fix this issue. Baked in blender-3.5.0-beta+v35.efc2e5134f5d I still get the following issues:
Marking as high priority so we don't forget to look at this for the 3.5 release.
Just to make sure we're all on the same page, as far as I can tell this ticket now spans three issues:
@LukasStockner If your last point refers to #104334 - that was fixed from what I can tell. The bake looks normal. It does however still have all the artifacts presented in this ticket here.
Hm, so it also still has the arttifacts that only appear with more than one sample?
For clarity, I just wanted to note that errors due to quantisation can't be "fixed" per se when using lower bit depth images, only masked/reduced with something like dithering.
Banding happens because 8bit images don't have enough greyscale values (0-255) to accurately represent the curvature of the high poly surface and when a high poly mesh has low surface curvature there are not enough values to map the small surface gradation accurately. The fix is to use 16bit/float images, or they can be reasonably well masked in 8bit image by dithering between greyscale values. The downsides to this is that the process will naturally add noise to the bake, and as such reflective surfaces with low roughness will show that noise rather than a clean reflection.
I just don't want to get anyone's hopes up, that's all. It's a limitation of 8bit textures in general, rather than something to do with the baking process/bugs. We could potentially mask the issue with dithering, and this might be preferable to banding in many situations, but it's not a 1:1 fix. :)
Yeah, there's no ideal "fix", but clearly the current behavior is an issue so we need to do something.
My idea would have been to add an option to clamp baked normals that differ from the "real" normal by less than X degrees to be exactly equal to the real normal instead - it could be an angle input, a checkmark that sets the threshold to equal the first quantization step for 8-bit images, or maybe even enable it automatically if you're baking normals to an 8-bit image.
I agree that it can be frustrating, but the current behaviour isn't extraordinary and happens in all bakers that bake to an 8bit image. The universally accepted fix is to dither or use 16bit images, and adding a clamp may have unintended consequences for other areas of the bake and will reduce accuracy of the bakes.
The fundamental issue here is that Normal maps should never be directly baked to an 8bit format because there is not enough greyscale values to map the surface accurately. There is nothing wrong with the baker in this sense, it's just that the 8bit format isn't accurate enough to contain all the required information. It's very similar to the stair-stepping you get in 8bit displacement maps.
It's better that we educate artists so they can understand why such issues are happening, rather than reduce the accuracy of the baker for an easily fixable problem that has already been solved.
In regards to the clamp idea, bear in mind that with subd meshes there will always be some kind of low surface curvature due to floating point precision, so we may be potentially moving the issue to other areas or introducing larger discontinuities to transitional areas of geometry where we move from low to high curvature or go over the angle threshold. I wouldn't recommend adding something like this to the baker.
If people are baking for rendering within Blender only, then we should probably consider making 16bit images the default for normal bakes, and if they are intended for game engine, then we should probably consider adding dithering when converting to 8bit images on export (though we should always bake to 16bit at least internally, even if the user selects 8bit as format). Dithering would by far be the simplest way to circumvent this issue when using 8bit images. :)
Setting the priority back because I confused this with the regression from #104334.
@AndyDavies-3 So your best solution would be to simply internally bake to 16 or 32bit and then dither whenever we save to 8bit?
Hi! Yes, 16bit images are pretty much ideal for normal maps. They strike an excellent balance between bit depth and file size. 32bit would work too ofc, but in the majority of cases would be overkill.
Dithering from 16/32bit to 8bit would be the best solution if the user has to export at 8bit. It should be an option however, because it does create subtle noise that is visible (but preferable to banding) in the bake (obviously) and banding is usually only a problem on hard surface objects with low roughness values.
Would it be possible for anyone to work on this task?
Its still a big pain point for myself and a lot of people I work with.
Yes this is incredibly frustrating, was hoping for a fix in 3.5, but I can see now that it didn't happen 😅
So question on this topic... It seems this was closed... but do we have a solution yet or work around for using the Bevel shader for baking? Or a way to drastically minimize the issues with using the Bevel shader to bake down normal maps on to a low poly?
Or is that OSL shader that was posted a while ago in a past linked thread the only known way to reduce the artifacts?
ie.) Looking to see what the current work arounds are if any to reduce the artifacting, as this type of work flow is used widely by some MODO / Houdini Artists to get quick asset production for incredible quick details and would be indispensable for many areas of the industry to have this more ironed out.
Reading the conversation history before commenting helps.
c431b69a8a