Generated noise texture is not infinite / looped #63789
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
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#63789
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.17763 64 Bits
Graphics card: GeForce GTX 980 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 425.31
Blender Version
Broken: version: 2.80 (sub 57), branch: blender2.7, commit date: 2019-04-17 19:26, hash:
b46245470f
Short description of error
Generated noise texture is not infinite.
I wanted to have very fine noise in normal maps for this 32 meters wide panel. Can't be.
If there is lack of float numbers available it should do some trick of, for example, mirroring everything around, or simply looping back-to-back.
Exact steps for others to reproduce the error
Just use very big scale for noise generated texture. I expect other generated textures to work same way.
/edit:
Voronoi actually goes good. Noise texture on the attached .blend was cutting black on 5000. Voronoi was good on crazy value of 200^70.
snow.blend
Added subscriber: @Acrivec
Added subscriber: @mel
As you use procedural textures can't you also scale the uvs when above 5000 scale ?
As you can see it's not based on UVs. It's object location.
Also, that would be a workaround, whereas we clearly have a bug here. Voronoi texture was correctly applied for a value of 200^70.
Added subscriber: @StephenSwaney
A couple points:
Computer numbers are not infinite or continuous.
You have an insanely high scale on your noise texture. A better name for 'scale', IMHO, would be frequency. Bigger scale means higher frequency which means smaller features.
It's difficult to tell, but if you look at your noise texture directly (thank you, Node Wrangler!) it looks like the features are so small as to merge into one continuous mess. If the Voronoi texture works better for this, you might want to use it.
If they would blend to one mess they would cover the whole plane, not a part of it, which shrinks with the scale increasing further. It's clearly bugged. It comes to a certain value and then it cuts off generation - thus leaving everything out of it's bounds black.
It should work like voronoi - be continous. And there are enough ways of making numbers to seem continous to do this.
Can you indicate where the discontinuous parts are?
Does turning off the floor in Overlays help?
Do you have the problem using a buildbot version from blender.org?
Just look at the bug report, can't you see black cut off when scale goes up/down? Can't you see there's version given there, too? There's even .blend attached.
And if by floor you mean grid display, then no, it's not helping.
Added subscriber: @ZedDB
I can't reproduce this on my end. I do not get any black borders. Is this still an issue for you with the latest build?
@ZedDB yes, lastest build with blend attached
2019-04-25_15-02-58.webm
Added subscriber: @LazyDodo
I get them in the viewport but a cycles render (seems?) fine
@LazyDodo As I can see you're right. That's viewport bug, not cycles.
2019-04-25_15-10-44.webm
@LazyDodo do you also have a Nvidia card? It works for me in the viewport textured view without these problems (linux, AMD).
Yeah that was on a gtx670, i just tried mesa and that just crashes blender with this file, not sure what is up with that.
Added subscriber: @fclem
@LazyDodo the open source nvidia drivers are not good (much to the fault of nvidia), so I'm not too surprised that is doesn't work.
I think I can mark this as confirmed then. @fclem I'm guessing that you can reproduce this with an nvidia card?
sorry, didn't mean to imply mesa support nvidia on windows, it runs llvm/softpipe (mostly irrelevant to this ticket though)
Can you reproduce this with latest build?
After diving into the cycles implementation it seems that cycles uses SSE intrinsics to make computation faster on CPU. So maybe precision is different in this case. But the base implementation seems to be the same.
I did make the result more safe and checked for infinity in
1fa7d51f34
like cycles does.We cannot however support every GLSL compiler and that is dependent on the driver / hardware vendor. They may be doing special tricks to make optimizations but that is a blackbox to us.
@fclem unfortunately on
2.80 (sub 60), branch: master, commit date: 2019-04-29 10:32, hash:
a57fec986d
it's still broken.
I will try again tomorrow on a newer build.
Anyway it's not a bug that is very high priority - if final render is done peroperly then I'm happy as long as I can see a part of that little square. It would be worse if I'd go for higher scale that caused whole object to be black - then it would force me to use rendered view, and with subdivision it would be terrible
/edit:
Checked on 2019-04-30 build, as expected not working.
Added subscriber: @Jeroen-Bakker
Added subscriber: @Sergey
@fclem we are able to reproduce it at BI.
Seems that the r is nan around this area. checking on nan made it better. Will need to check where the nan comes from...
Jeroen (in cognito)
Added subscriber: @brecht
Cycles uses
isfinite()
, so it should ber = (isinf(r) || isnan(r)) ? 0.0: r;
for equivalent results.I took a quick peek here yesterday, my current theory is with scale at 5000 at having detail set to 16 will get you 5000^16 for the final octaves coords which goes over MAX_FLT. which in turn messes up the normal calculations causing the black band. but i didn't have time to actually prove it.
Added subscriber: @Smjert
I'm intruding :D, but I was trying that too and there's a grey band anyway (in my case it's near the place the 3D cursor is in the scene).
Also, not that I want to hijack the original issue but, since with Cycles it's supposed to work, with the same file if I switch to it I get this as soon as it starts to do the Path tracing (Debug build, Nvidia 1080, ArchLinux):
Also I hit this assert after a while (but I cannot reproduce now and I had scaled up the plane a bit :S):
EDIT:
I also tried to update to today commits (the build I had was from yesterday), and switching to Cycles crashes now.
Do you want me to open a new bug?
When i said cycles works, i meant 'no black ring' , on second look there is some artifacting but not as bad and a different pattern than in the glsl viewport. still pretty sure detail+scale are overflowing, see if the assert goes away if you put the noise texture going into the bump back to 14 from 16.
Don't know if you saw my edit, unfortunately (or luckily?) I cannot get that assert to reproduce, but I get a crash/segfault (not an assert) in a different place when switching to Cycles.
If I dial down the texture detail to 14 Eevee render looks fine, but switching to Cycles crashes anyway:
EDIT:
Oh wait.. I noticed only now that it's trying to add a non existing image hum..
Well, it's pink, it's clearly not loading some image.
Yeah I didn't think about that because I wasn't expecting it taking the whole viewport. Though now it's actually crashing.
Ah
3c07967ef2
fixed the crash.Added subscriber: @mano-wii
It seems that the problem is related to the conversion of the
floor
value to int.Here are two solutions that I found:
or...
(Feel free to commit)
This issue was referenced by
d32a103d53
Changed status from 'Open' to: 'Resolved'