Generated noise texture is not infinite / looped
Closed, Resolved
Actions

Assigned To

Clément Foucault (fclem)

Authored By

	Acrivec Cevirca (Acrivec)
	Apr 22 2019, 1:59 AM

Description

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: rBb46245470f79

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.blend393 KBDownload

Revisions and Commits

rB Blender
	rBd32a103d53c4 Fix T63789: Precision issues in glsl noise texture

Related Objects

Mentioned Here: rB3c07967ef28e: Fix Cycles crash when trying to load image that does not exist
rB1fa7d51f342a: Eevee: Noise Texture: try to fix floating point accuracy issue

Event Timeline

Acrivec Cevirca (Acrivec) created this task.Apr 22 2019, 1:59 AM

Acrivec Cevirca (Acrivec) updated the task description.Apr 22 2019, 2:08 AM

Acrivec Cevirca (Acrivec) updated the task description.

Acrivec Cevirca (Acrivec) updated the task description.Apr 22 2019, 2:21 AM

Mel Massadian (melmass) added a subscriber: Mel Massadian (melmass).Apr 22 2019, 1:59 PM

As you use procedural textures can't you also scale the uvs when above 5000 scale ?

Acrivec Cevirca (Acrivec) added a comment.Apr 22 2019, 2:05 PM

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.

Stephen Swaney (stiv) added a subscriber: Stephen Swaney (stiv).Apr 23 2019, 1:01 AM

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.

Acrivec Cevirca (Acrivec) added a comment.Apr 23 2019, 1:05 AM

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.

Stephen Swaney (stiv) added a comment.Apr 23 2019, 1:27 AM

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?

Acrivec Cevirca (Acrivec) added a comment.Apr 23 2019, 1:34 AM

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.

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 30.Apr 25 2019, 2:44 PM

Sebastian Parborg (zeddb) added a subscriber: Sebastian Parborg (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?

Acrivec Cevirca (Acrivec) added a comment.Apr 25 2019, 3:04 PM

@Sebastian Parborg (zeddb) yes, lastest build with blend attached

Ray Molenkamp (LazyDodo) added a subscriber: Ray Molenkamp (LazyDodo).Apr 25 2019, 3:05 PM

I get them in the viewport but a cycles render (seems?) fine

Acrivec Cevirca (Acrivec) added a comment.EditedApr 25 2019, 3:10 PM

@Ray Molenkamp (LazyDodo) As I can see you're right. That's viewport bug, not cycles.

Sebastian Parborg (zeddb) added a comment.Apr 25 2019, 4:10 PM

@Ray Molenkamp (LazyDodo) do you also have a Nvidia card? It works for me in the viewport textured view without these problems (linux, AMD).

Ray Molenkamp (LazyDodo) added a comment.Apr 25 2019, 4:13 PM

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.

Sebastian Parborg (zeddb) assigned this task to Clément Foucault (fclem).Apr 25 2019, 4:25 PM

Sebastian Parborg (zeddb) raised the priority of this task from 30 to 50.

Sebastian Parborg (zeddb) added a subscriber: Clément Foucault (fclem).

@Ray Molenkamp (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. @Clément Foucault (fclem) I'm guessing that you can reproduce this with an nvidia card?

Ray Molenkamp (LazyDodo) added a comment.Apr 25 2019, 4:30 PM

sorry, didn't mean to imply mesa support nvidia on windows, it runs llvm/softpipe (mostly irrelevant to this ticket though)

Clément Foucault (fclem) added a comment.Apr 29 2019, 7:03 PM

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 rB1fa7d51f342a 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.

Acrivec Cevirca (Acrivec) added a comment.EditedApr 29 2019, 9:03 PM

@Clément Foucault (fclem) unfortunately on
2.80 (sub 60), branch: master, commit date: 2019-04-29 10:32, hash: rBa57fec986d2d
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.

Jeroen Bakker (jbakker) added a subscriber: Jeroen Bakker (jbakker).May 2 2019, 9:04 PM

Sergey Sharybin (sergey) added a subscriber: Sergey Sharybin (sergey).May 3 2019, 4:34 PM

@Clément Foucault (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...

r = isnan(r) ?0.0: r;

Jeroen (in cognito)

Brecht Van Lommel (brecht) added a subscriber: Brecht Van Lommel (brecht).May 3 2019, 4:52 PM

Cycles uses isfinite(), so it should be r = (isinf(r) || isnan(r)) ? 0.0: r; for equivalent results.

Ray Molenkamp (LazyDodo) added a comment.May 3 2019, 4:55 PM

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.

Stefano Bonicatti (smjert) added a subscriber: Stefano Bonicatti (smjert).EditedMay 3 2019, 6:51 PM

In T63789#670485, @Brecht Van Lommel (brecht) wrote:

Cycles uses isfinite(), so it should be r = (isinf(r) || isnan(r)) ? 0.0: r; for equivalent results.

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):

blender: /home/smjert/Development/blender-git/blender/intern/cycles/kernel/../kernel/geom/geom_patch.h:67: ccl::PatchHandle ccl::patch_map_find_patch(ccl::KernelGlobals*, int, int, float, float): Assertion `(u >= 0.0f) && (u <= 1.0f) && (v >= 0.0f) && (v <= 1.0f)' failed.

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?

Ray Molenkamp (LazyDodo) added a comment.May 3 2019, 7:07 PM

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.

Stefano Bonicatti (smjert) added a comment.EditedMay 3 2019, 7:30 PM

In T63789#670538, @Ray Molenkamp (LazyDodo) wrote:

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:

Thread 28 "blender" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffaa17f700 (LWP 29374)]
ccl::ImageManager::add_image (this=0x7fffde46f900, filename="/home/smjert/HDRI Heaven/HDRI Haven Offline Access/HDRI Haven 1k/winter_river_1k.hdr", builtin_data=0x0, animated=false, frame=0, interpolation=ccl::INTERPOLATION_LINEAR, 
    extension=ccl::EXTENSION_REPEAT, use_alpha=true, colorspace=..., metadata=...) at /home/smjert/Development/blender-git/blender/intern/cycles/render/image.cpp:331
331	    img = images[type][slot];

#0  ccl::ImageManager::add_image (this=0x7fffbdb07700, filename="/home/smjert/HDRI Heaven/HDRI Haven Offline Access/HDRI Haven 1k/winter_river_1k.hdr", builtin_data=0x0, animated=false, frame=0, interpolation=ccl::INTERPOLATION_LINEAR, 
    extension=ccl::EXTENSION_REPEAT, use_alpha=true, colorspace=..., metadata=...) at /home/smjert/Development/blender-git/blender/intern/cycles/render/image.cpp:331
#1  0x000055555bc6b506 in ccl::EnvironmentTextureNode::compile (this=0x7fffbd6e11c0, compiler=...) at /home/smjert/Development/blender-git/blender/intern/cycles/render/nodes.cpp:482
#2  0x000055555bcf38b2 in ccl::SVMCompiler::generate_node (this=0x7fffa607aa10, node=0x7fffbd6e11c0, done=std::set with 1 element = {...}) at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:426
#3  0x000055555bcf3b86 in ccl::SVMCompiler::generate_svm_nodes (this=0x7fffa607aa10, nodes=std::set with 2 elements = {...}, state=0x7fffa607a7e0) at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:471
#4  0x000055555bcf3ceb in ccl::SVMCompiler::generate_closure_node (this=0x7fffa607aa10, node=0x7fffa7528c80, state=0x7fffa607a7e0) at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:490
#5  0x000055555bcf494b in ccl::SVMCompiler::generate_multi_closure (this=0x7fffa607aa10, root_node=0x7fffa7528c80, node=0x7fffa7528c80, state=0x7fffa607a7e0) at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:661
#6  0x000055555bcf4ea9 in ccl::SVMCompiler::compile_type (this=0x7fffa607aa10, shader=0x7fffde45eac0, graph=0x7fffddacb610, type=ccl::SHADER_TYPE_SURFACE) at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:757
#7  0x000055555bcf521b in ccl::SVMCompiler::compile (this=0x7fffa607aa10, scene=0x7fffb037d400, shader=0x7fffde45eac0, svm_nodes=..., index=0, summary=0x7fffa607a9b0)
    at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:831
#8  0x000055555bcf1b94 in ccl::SVMShaderManager::device_update_shader (this=0x7fffde45e880, scene=0x7fffb037d400, shader=0x7fffde45eac0, progress=0x7fffb7c8c920, global_svm_nodes=0x7fffa4076c40)
    at /home/smjert/Development/blender-git/blender/intern/cycles/render/svm.cpp:63
#9  0x000055555bcf747b in std::__invoke_impl<void, void (ccl::SVMShaderManager::*&)(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*), ccl::SVMShaderManager*&, ccl::Scene*&, ccl::Shader*&, ccl::Progress*&, ccl::array<ccl::int4, 16ul>*&> (__f=
    @0x7fffa757c2c0: (void (ccl::SVMShaderManager::*)(ccl::SVMShaderManager * const, ccl::Scene *, ccl::Shader *, ccl::Progress *, ccl::array<ccl::int4, 16> *)) 0x55555bcf19d6 <ccl::SVMShaderManager::device_update_shader(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*)>, __t=@0x7fffa757c2f0: 0x7fffde45e880, __args#0=@0x7fffa757c2e8: 0x7fffb037d400, __args#1=@0x7fffa757c2e0: 0x7fffde45eac0, __args#2=@0x7fffa757c2d8: 0x7fffb7c8c920, 
    __args#3=@0x7fffa757c2d0: 0x7fffa4076c40) at /usr/include/c++/8.3.0/bits/invoke.h:73
#10 0x000055555bcf7226 in std::__invoke<void (ccl::SVMShaderManager::*&)(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*), ccl::SVMShaderManager*&, ccl::Scene*&, ccl::Shader*&, ccl::Progress*&, ccl::array<ccl::int4, 16ul>*&> (__fn=
    @0x7fffa757c2c0: (void (ccl::SVMShaderManager::*)(ccl::SVMShaderManager * const, ccl::Scene *, ccl::Shader *, ccl::Progress *, ccl::array<ccl::int4, 16> *)) 0x55555bcf19d6 <ccl::SVMShaderManager::device_update_shader(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*)>, __args#0=@0x7fffa757c2f0: 0x7fffde45e880, __args#1=@0x7fffa757c2e8: 0x7fffb037d400, __args#2=@0x7fffa757c2e0: 0x7fffde45eac0, __args#3=@0x7fffa757c2d8: 0x7fffb7c8c920, 
    __args#4=@0x7fffa757c2d0: 0x7fffa4076c40) at /usr/include/c++/8.3.0/bits/invoke.h:95
#11 0x000055555bcf6f53 in std::_Bind<void (ccl::SVMShaderManager::*(ccl::SVMShaderManager*, ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*))(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*)>::__call<void, int&&, 0ul, 1ul, 2ul, 3ul, 4ul>(std::tuple<int&&>&&, std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul>) (this=0x7fffa757c2c0, __args=...) at /usr/include/c++/8.3.0/functional:400
#12 0x000055555bcf6bc8 in std::_Bind<void (ccl::SVMShaderManager::*(ccl::SVMShaderManager*, ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*))(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*)>::operator()<int, void>(int&&) (this=0x7fffa757c2c0, __args#0=@0x7fffa607b044: 4) at /usr/include/c++/8.3.0/functional:484
#13 0x000055555bcf67cf in std::_Function_handler<void (int), std::_Bind<void (ccl::SVMShaderManager::*(ccl::SVMShaderManager*, ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*))(ccl::Scene*, ccl::Shader*, ccl::Progress*, ccl::array<ccl::int4, 16ul>*)> >::_M_invoke(std::_Any_data const&, int&&) (__functor=..., __args#0=@0x7fffa607b044: 4) at /usr/include/c++/8.3.0/bits/std_function.h:297
#14 0x000055555bf8b0b2 in std::function<void (int)>::operator()(int) const (this=0x7fffa75170f8, __args#0=4) at /usr/include/c++/8.3.0/bits/std_function.h:687
#15 0x000055555bf8a075 in ccl::TaskScheduler::thread_run (thread_id=4) at /home/smjert/Development/blender-git/blender/intern/cycles/util/util_task.cpp:396
#16 0x000055555bf8ddee in std::__invoke_impl<void, void (*&)(int), int&> (__f=@0x7fffc0ce61d0: 0x55555bf8a036 <ccl::TaskScheduler::thread_run(int)>, __args#0=@0x7fffc0ce61d8: 4) at /usr/include/c++/8.3.0/bits/invoke.h:60
#17 0x000055555bf8d9c8 in std::__invoke<void (*&)(int), int&> (__fn=@0x7fffc0ce61d0: 0x55555bf8a036 <ccl::TaskScheduler::thread_run(int)>, __args#0=@0x7fffc0ce61d8: 4) at /usr/include/c++/8.3.0/bits/invoke.h:95
#18 0x000055555bf8d379 in std::_Bind<void (*(int))(int)>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x7fffc0ce61d0, __args=...) at /usr/include/c++/8.3.0/functional:400
#19 0x000055555bf8cae7 in std::_Bind<void (*(int))(int)>::operator()<, void>() (this=0x7fffc0ce61d0) at /usr/include/c++/8.3.0/functional:484
#20 0x000055555bf8c0fd in std::_Function_handler<void (), std::_Bind<void (*(int))(int)> >::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/8.3.0/bits/std_function.h:297
#21 0x0000555557bc06de in std::function<void ()>::operator()() const (this=0x7fffc036ee10) at /usr/include/c++/8.3.0/bits/std_function.h:687
#22 0x000055555bf8e6ca in ccl::thread::run (arg=0x7fffc036ee10) at /home/smjert/Development/blender-git/blender/intern/cycles/util/util_thread.cpp:52
#23 0x000055555bf8ec3d in std::__invoke_impl<void*, void* (*)(void*), ccl::thread*> (__f=@0x7fffbd348270: 0x55555bf8e690 <ccl::thread::run(void*)>, __args#0=@0x7fffbd348268: 0x7fffc036ee10) at /usr/include/c++/8.3.0/bits/invoke.h:60
#24 0x000055555bf8e934 in std::__invoke<void* (*)(void*), ccl::thread*> (__fn=@0x7fffbd348270: 0x55555bf8e690 <ccl::thread::run(void*)>, __args#0=@0x7fffbd348268: 0x7fffc036ee10) at /usr/include/c++/8.3.0/bits/invoke.h:95
#25 0x000055555bf8f17b in std::thread::_Invoker<std::tuple<void* (*)(void*), ccl::thread*> >::_M_invoke<0ul, 1ul> (this=0x7fffbd348268) at /usr/include/c++/8.3.0/thread:244
#26 0x000055555bf8f121 in std::thread::_Invoker<std::tuple<void* (*)(void*), ccl::thread*> >::operator() (this=0x7fffbd348268) at /usr/include/c++/8.3.0/thread:253
#27 0x000055555bf8f0f6 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void* (*)(void*), ccl::thread*> > >::_M_run (this=0x7fffbd348260) at /usr/include/c++/8.3.0/thread:196
#28 0x00007ffff0324053 in std::execute_native_thread_routine (__p=0x7fffbd348260) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:80
#29 0x00007ffff625ca92 in start_thread () from /usr/lib/libpthread.so.0
#30 0x00007ffff0637cd3 in clone () from /usr/lib/libc.so.6

EDIT:
Oh wait.. I noticed only now that it's trying to add a non existing image hum..

Acrivec Cevirca (Acrivec) added a comment.May 3 2019, 7:45 PM

Well, it's pink, it's clearly not loading some image.

Stefano Bonicatti (smjert) added a comment.May 3 2019, 7:55 PM

In T63789#670544, @Acrivec Cevirca (Acrivec) wrote:

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.

Stefano Bonicatti (smjert) added a comment.May 3 2019, 9:36 PM

Ah 3c07967ef28e5928049647daa0673f9db91d083f fixed the crash.

Germano Cavalcante (mano-wii) added a subscriber: Germano Cavalcante (mano-wii).May 4 2019, 4:10 PM

It seems that the problem is related to the conversion of the floor value to int.
Here are two solutions that I found:

diff --git a/source/blender/gpu/shaders/gpu_shader_material.glsl b/source/blender/gpu/shaders/gpu_shader_material.glsl
index cf7a83e8a87..9b1801a9bfa 100644
--- a/source/blender/gpu/shaders/gpu_shader_material.glsl
+++ b/source/blender/gpu/shaders/gpu_shader_material.glsl
@@ -1163,7 +1163,7 @@ vec3 cellnoise_color(vec3 p)
 float floorfrac(float x, out int i)
 {
   i = floor_to_int(x);
-  return x - i;
+  return fract(x);
 }
 
 /* bsdfs */

or...

diff --git a/source/blender/gpu/shaders/gpu_shader_material.glsl b/source/blender/gpu/shaders/gpu_shader_material.glsl
index cf7a83e8a87..1cbf58f9d16 100644
--- a/source/blender/gpu/shaders/gpu_shader_material.glsl
+++ b/source/blender/gpu/shaders/gpu_shader_material.glsl
@@ -1162,8 +1162,9 @@ vec3 cellnoise_color(vec3 p)
 
 float floorfrac(float x, out int i)
 {
-  i = floor_to_int(x);
-  return x - i;
+  float x_floor = floor(x);
+  i = int(x_floor);
+  return x - x_floor;
 }
 
 /* bsdfs */

(Feel free to commit)

Germano Cavalcante (mano-wii) changed the task status from Unknown Status to Resolved by committing rBd32a103d53c4: Fix T63789: Precision issues in glsl noise texture.May 4 2019, 10:08 PM

Germano Cavalcante (mano-wii) added a commit: rBd32a103d53c4: Fix T63789: Precision issues in glsl noise texture.

Generated noise texture is not infinite / looped Closed, ResolvedActions

Description

Revisions and Commits

Related Objects

Event Timeline

Generated noise texture is not infinite / looped
Closed, Resolved
Actions