Generated noise texture is not infinite / looped #63789

New Issue

Acrivec Cevirca · 2019-04-22T01:59:47+02:00

Acrivec Cevirca commented

2019-04-22 01:59:47 +02:00

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

**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. ![kCquPCt- [x].png](https://archive.blender.org/developer/F6965365/kCquPCt_1_.png) ![lp6ZXn0- [x].png](https://archive.blender.org/developer/F6965368/lp6ZXn0_1_.png) 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](https://archive.blender.org/developer/F6965373/snow.blend)

Acrivec Cevirca commented

2019-04-22 01:59:47 +02:00

Added subscriber: @Acrivec

Mel Massadian commented

2019-04-22 13:59:41 +02:00

Added subscriber: @mel

Mel Massadian commented

2019-04-22 13:59:41 +02:00

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

Acrivec Cevirca commented

2019-04-22 14:05:10 +02:00

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.

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 commented

2019-04-23 01:01:47 +02:00

Added subscriber: @StephenSwaney

Stephen Swaney commented

2019-04-23 01:01:47 +02:00

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.

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 commented

2019-04-23 01:05:51 +02:00

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.

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 commented

2019-04-23 01:27:43 +02:00

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?

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 commented

2019-04-23 01:34:05 +02:00

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.

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 commented

2019-04-25 14:44:46 +02:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-04-25 14:44:46 +02:00

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 commented

2019-04-25 15:04:17 +02:00

@ZedDB yes, lastest build with blend attached
2019-04-25_15-02-58.webm

@ZedDB yes, lastest build with blend attached [2019-04-25_15-02-58.webm](https://archive.blender.org/developer/F6975807/2019-04-25_15-02-58.webm)

Ray molenkamp commented

2019-04-25 15:05:46 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2019-04-25 15:05:46 +02:00

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

Acrivec Cevirca commented

2019-04-25 15:10:34 +02:00

@LazyDodo As I can see you're right. That's viewport bug, not cycles.
2019-04-25_15-10-44.webm

@LazyDodo As I can see you're right. That's viewport bug, not cycles. [2019-04-25_15-10-44.webm](https://archive.blender.org/developer/F6975833/2019-04-25_15-10-44.webm)

Sebastian Parborg commented

2019-04-25 16:10:02 +02:00

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

Ray molenkamp commented

2019-04-25 16:13:51 +02:00

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.

Clément Foucault was assigned by Sebastian Parborg

2019-04-25 16:25:37 +02:00

Sebastian Parborg commented

2019-04-25 16:25:37 +02:00

Added subscriber: @fclem

Sebastian Parborg commented

2019-04-25 16:25:37 +02:00

@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?

@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?

Ray molenkamp commented

2019-04-25 16:30:03 +02:00

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

Clément Foucault commented

2019-04-29 19:03:59 +02:00

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.

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.

Acrivec Cevirca commented

2019-04-29 21:03:03 +02:00

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

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

Jeroen Bakker commented

2019-05-02 21:04:05 +02:00

Added subscriber: @Jeroen-Bakker

Sergey Sharybin commented

2019-05-03 16:34:14 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2019-05-03 16:34:14 +02:00

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

@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; ``` ![image.png](https://archive.blender.org/developer/F7003500/image.png) Jeroen (in cognito)

Brecht Van Lommel commented

2019-05-03 16:52:07 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-05-03 16:52:07 +02:00

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

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

Ray molenkamp commented

2019-05-03 16:55:40 +02:00

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 commented

2019-05-03 18:51:28 +02:00

Added subscriber: @Smjert

Stefano Bonicatti commented

2019-05-03 18:51:28 +02:00

In #63789#670485, @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?

> In #63789#670485, @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): ![cycles_all_purple.png](https://archive.blender.org/developer/F7003667/cycles_all_purple.png) 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 commented

2019-05-03 19:07:15 +02:00

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 commented

2019-05-03 19:30:06 +02:00

In #63789#670538, @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..

> In #63789#670538, @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 commented

2019-05-03 19:45:10 +02:00

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

Stefano Bonicatti commented

2019-05-03 19:55:07 +02:00

In #63789#670544, @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.

> In #63789#670544, @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 commented

2019-05-03 21:36:52 +02:00

Ah 3c07967ef2 fixed the crash.

Ah 3c07967ef28e5928049647daa0673f9db91d083f fixed the crash.

Germano Cavalcante commented

2019-05-04 16:10:49 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2019-05-04 16:10:50 +02:00

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)

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)

blender-admin commented

2019-05-04 21:44:44 +02:00

This issue was referenced by d32a103d53

This issue was referenced by d32a103d53c46317ca2dd8bcf7c666782c05562f

Germano Cavalcante commented

2019-05-04 22:08:50 +02:00

Changed status from 'Open' to: 'Resolved'

Germano Cavalcante closed this issue

2019-05-04 22:08:50 +02:00

Sign in to join this conversation.

12 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#63789

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Generated noise texture is not infinite / looped #63789