Title: Problem with maps Post by: Patryk Kizny on November 21, 2015, 02:23:36 AM I've got a problem.
I am using simple IBL in my tracer with equirect mapping. IBL is just one of the components contributing to final color. There are other lights. Now what happens is that whenever I turn on IBL maps so that they're mixed into the light, a weird thing happens. Even if IBL contributes to total light at tiny little percent, I am getting artifacts. It looks like for some reason the image renders pixelated in 2x2 blocks. Sub sampling and all biases still work on a pixel level, but they converge towards 2x2 pixel blocks. And it has nothing to do with the resolution of my map - I.e I am not seeing insufficient map res. This is even more visible on edges of objects which look sort of aliased. I don't think it's something obvious with the tracer, rather some internal GL Magic. Any ideas? I'll try to post some examples tomorrow. Title: Re: Problem with maps Post by: 3dickulus on November 21, 2015, 04:07:21 AM Code, need code to test, if your fragments compile with warnings fix them first, there are all kinds of things that can contribute to the problem so eliminate the narrowing, implicit cast and may be used uninitialized warnings, that is where I would start ;) when you are sure that the problem is not with the fragment code then it will be easier to track down.
As this is the first I've heard of this and the texture stuff in the latest version is (essentially) the same as github Fragmentarium-master I would be asking myself "when did this start and what changed at that time". The default "internal GL Magic" for textures is... Code: glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); to change the default behaviour you can add #TexParameter textureName param option valid params GL_TEXTURE_WRAP_S GL_TEXTURE_WRAP_T GL_TEXTURE_MIN_FILTER GL_TEXTURE_MAG_FILTER valid options GL_CLAMP GL_REPEAT GL_NEAREST GL_LINEAR the mipmap option works like this... Code: uniform sampler2D myTexture; file[test.png] parameters and options set this way will be applied to the named texture whenever it is used, this is about all I can tell you about the internal texture stuff, I'm not a GL guru, still learning, enlightenment is always welcomed. Title: Re: Problem with maps Post by: Syntopia on November 21, 2015, 04:49:54 PM Some GLSL operations operate on 2x2 screen space pixel blocks. For instance the dFdx function, which is also used by all mipmapping functionality. So make sure to disable mipmapping (though the default should be to disable it, as 3dickulus write above).
Title: Re: Problem with maps Post by: Patryk Kizny on November 21, 2015, 06:33:03 PM Here's the file of how it looks.
Note the ground which is IBL-lit. Same happens for tiling imperfection on the sky map. The seam itself may be a result of some rounding, but the fact its so pixellated points to the same issue. (https://farm6.staticflickr.com/5721/23181444255_4ba41b13f6_o_d.png) Title: Re: Problem with maps Post by: Patryk Kizny on November 21, 2015, 06:50:46 PM Some GLSL operations operate on 2x2 screen space pixel blocks. For instance the dFdx function, which is also used by all mipmapping functionality. So make sure to disable mipmapping (though the default should be to disable it, as 3dickulus write above). How can I do it exactly? Title: Re: Problem with maps Post by: 3dickulus on November 21, 2015, 07:59:28 PM mipmap is disabled by default internally (C++ side, that's why you need to explicitly use #TexParameter to turn it on)
To disable (this should not be needed!!!)... Code: uniform sampler2D myTexture; file[test.png] as Syntopia states "Some GLSL operations operate on 2x2 screen space pixel blocks. " so... Code: grep dFd Fragmentarium/Examples/*/* if the effect is only on the edge and not across the entire bg-map then double check your bg-map, then double check your code for an off by 1 err on the x axis?, textures also work "nicer" if they are square and size is 2^n, of course without code and data we can only guess at what the problem might be... edit: is this a Synthclipse problem or a Fragmentarium problem? Title: Re: Problem with maps Post by: Patryk Kizny on November 21, 2015, 08:28:29 PM The seam I have is a synthclipse problem as it is not present when compiled and run with fragmentarium.
The pixellation problem is present regardless of whether I use Sc or Frag. Title: Re: Problem with maps Post by: 3dickulus on November 21, 2015, 08:44:30 PM did you alter the value in the rand() function from 43758.5453 to 3758.5453 to fix banding in IQ-Clouds :hmh:
this may affect dither in places Title: Re: Problem with maps Post by: Patryk Kizny on November 21, 2015, 08:49:53 PM did you alter the value in the rand() function from 43758.5453 to 3758.5453 to fix banding in IQ-Clouds :hmh: this may affect dither in places Yeah, batch replaced in all files. Title: Re: Problem with maps Post by: 3dickulus on November 21, 2015, 09:29:07 PM yeah, that's probably the wrong thing to do,
replace only the one that IQ-Clouds uses as this seems to fix banding artefacts, then, replace another one and TEST!, then, replace another one and TEST! etc... being mindful of what parts of the render these should affect, until you find the places where this works for removing banding artefacts. and read https://www.opengl.org/discussion_boards/showthread.php/176425-How-are-dFdx-and-dFdy-functions-implemented for some insight on how the dFd functions work. Title: Re: Problem with maps Post by: Patryk Kizny on November 21, 2015, 09:30:56 PM OKey,
Here's what I figured out: - The problem is definitely present only in Synthclipse (although I had experienced it in the past with Fragmentarium at some point and ignored it). - The problem is caused by the mipmap thing. i.e when I set fragmentarium map using the code: uniform sampler2D myTexture; file[test.png] #TexParameter myTexture; GL_TEXTURE_MIN_FILTER GL_LINEAR_MIPMAP_LINEAR It behaves exactly like the problem I am experiencing with synthclipse. Unfortunately Synthclipse won't let me enter #TexParameter Title: Re: Problem with maps Post by: 3dickulus on November 21, 2015, 09:51:05 PM so, to recap...
the tiling seam imperfection on the sky map is not a Fragmentarium problem because it renders correctly in Fragmentarium. the pixelation problem, also not a Fragmentarium problem but was caused by your global changes to the rand() function. Title: Re: Problem with maps Post by: Patryk Kizny on November 21, 2015, 10:46:42 PM the tiling seam imperfection on the sky map is not a Fragmentarium problem because it renders correctly in Fragmentarium. Correct. It was caused by enabled MIPMAP in Synthclipse.Fixed by disabling it. the pixelation problem, also not a Fragmentarium problem but was caused by your global changes to the rand() function. No, that was NOT caused by that. It was caused by the same issue as above - enabled MIPMAPThanks for help! Title: Re: Problem with maps Post by: lycium on November 21, 2015, 11:59:48 PM Aside: that rand() function is a terrible hack to begin with, and the hacked version is even more dubious with the the lower frequency. If you think about what a random number function does / what you want from it, this function can never work properly...
A basic random number gen can be done in little state with eg xorshift. Title: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 01:06:33 AM @lycium can you make a rand() function for frags using "little state with eg xorshift" that works better than the current hack? Fragmentarium users would be most appreciative :)
@patryk so you have reverted to the original value, 43758.5453, everywhere and used 3758.5453 with IQ-Clouds only and the pixelation still exists when mipmap is disabled (default) ? I do have something you can test, but only in source right now, so far it looks like I will leave it in for the next patch release... added other mipmap parameters... GL_LINEAR_MIPMAP_LINEAR GL_LINEAR_MIPMAP_NEAREST GL_NEAREST_MIPMAP_LINEAR GL_NEAREST_MIPMAP_NEAREST and GL_TEXTURE_MAX_ANISOTROPY you will find these in the Edit->Insert commands menu these images are both at the same location and only render 1 subframe using a 2x2 texture image 1 ansiotropy set @ 1.0 = isotropic (no filter) image 2 ansiotropy set @ 16.0 = maximum mipmap filtering on my card so, the mipmap functions and filtering seems to work Title: Re: Problem with maps Post by: lycium on November 22, 2015, 01:35:21 AM Just read about it and implement it :)
From what I saw here, it uses 4 uints of state: https://en.wikipedia.org/wiki/Xorshift So you make a buffer with 4 uints per thread (which can be lots on a GPU), and pass this buffer to your rand() function. It uses a thread ID to look up its current xyzw values, modifying them as needed before returning the random value. Title: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 02:08:40 AM @lycium tnx for the link :) seed state with time? xorshift128plus() works in shader code?
@Patryk a follow-up image of anisotropic @ 100 subframes 1.0 on the left and 16.0 on the right... Title: Re: Problem with maps Post by: Patryk Kizny on November 22, 2015, 02:14:47 AM Quote @patryk so you have reverted to the original value, 43758.5453, everywhere and used 3758.5453 with IQ-Clouds only and the pixelation still exists when mipmap is disabled (default) ? No, I did not revert as until now I did not see any drawbacks of the replacement.The problem with pixelation is NOT related at all to rand() and has been fixed thanks to disabling MIPMAP. Title: Re: Problem with maps Post by: lycium on November 22, 2015, 02:22:22 AM @lycium tnx for the link :) seed state with time? xorshift128plus() works in shader code? I'm not sure how best to seed xorshift, but you should be able to just use the thread ID as seed. Never used it myself, but I heard it's popular for its small amount of state and reasonably good statistical properties. As for whether or not it works in "shaders", I assume you mean GLSL. I'm not sure about the current standards, but hopefully it should be able to do proper (unsigned) integer arithmetic. Title: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 02:55:45 AM @Patryk mipmap is disabled by default, as near as I can tell no textures use mipmap unless you explicitly turn it on using #TexParameter
upon reviewing Qt GUI docs I find that "Mipmapping is disabled by default." @lycium after a little tinkering I get lots of these... Code: 0(434) : warning C7548: '<<' requires "#extension GL_EXT_gpu_shader4 : enable" before use pow() and shift() ??? Title: Re: Problem with maps Post by: lycium on November 22, 2015, 03:02:48 AM I think those extensions are for integer operations, i.e. exactly what you need.
It's not possible to implement those integer operations to full range in floating point without using double precision. If you can use double precision, you really should be able to use integers :) Title: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 03:11:50 AM using ivec2 for seed and xy never considered double
Code: /* The state must be seeded so that it is not everywhere zero. */ I understand that the above may loose some precision, but this is just a test to try and apply the algorithm, the bit shifts probably exceed ivec2 size. could be adjusted so we have a xorshift64plus() function ? edit: yes I know the above code doesn't work, return value alone is way too random, needs to be co.xy centric Title: Re: Problem with maps Post by: lycium on November 22, 2015, 04:13:04 AM I guess we have very different goals; when I use a random number generator for a statistical process (eg rendering), I want to be able to sleep at night knowing the stuff works as intended :tongue1:
To be more specific: I would check that your uniform distribution (which is what you want from a rand() function) is indeed uniform! Otherwise everything you base on it will be all wonky and wrong... Edit: PS. We should probably split this discussion of random numbers off into a different thread, since it is unrelated to the texture mapping problem Patryk had. Title: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 05:17:54 AM Could a 64bit version have a decently uniform distribution but just in a smaller window, (so to speak), my only goal is functionality, if it is just too sloppy for GLSL or DE in particular, then we leave Fragmentarium fragments as they are and keep looking and testing.
Title: Re: Problem with maps Post by: Syntopia on November 22, 2015, 10:18:59 AM A few comments about RNG's:
In typical cases you draw very few random numbers per shader invocation (per frame). You are probably more interested in a good hash function than in a good RNG. It would be great if we could store the state of the RNG's between frames (for instance when doing progressive rendering or anything with multiple frames), but I don't believe it is possible in GLSL (at least it would be hard: you'd have to write to two pixel buffers: one for the image samples, and another for the RNG state - they would be the same dimensions). The biggest problem is how to seed each thread (~each pixel) on the GPU properly. Just using something like the ThreadID (which is not available in GLSL) or the screen space coordinates will give strongly correlated random number series. This is described in detail here: http://www.reedbeta.com/blog/2013/01/12/quick-and-easy-gpu-random-numbers-in-d3d11/ The 'Wang hash' used to seed the RNG's in the link use 32-bit ints. Since we do not have access to the ThreadID, one possibility would be to use the screen coordinates times the current frame number, and reinterpret that as an int, using 'floatBitsToInt'. Here is some sample code: Code: #extension GL_ARB_shader_bit_encoding : enable The above code is only for generating decent seeds. If you need to get a series of random number the xorshifts could be used starting from these seeds. I have attached a screenshot of rand1 vs wang_hash_fp - this is at zoom-level 100. As can be seen rand1 is sensitive to the input value range. However, if you adjust the input value range rand1 will be suitable for most cases (I use it as a RNG for my path tracers without any visible problems). Title: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 11:38:45 AM Thank you Syntopia for the wang_hash snippet, I think this RNG talk stems from here...
http://www.fractalforums.com/fragmentarium/updating-of-de-raytracer/msg88473/#msg88473 ...the clouds have parts that look like blocky marshmallows, IQ-Clouds uses a vec3 variant of rand1 and it looked like it was loosing bit precision some how so I poked around a bit and found that reducing 43758.5453 to 3758.5453 fixed this blocky artefact but not completely so I put it back and tried something else... the original... Code: float rand(vec3 co){// implementation found at: lumina.sourceforge.net/Tutorials/Noise.htmlCode: float rand(vec3 co){// implementation found at: lumina.sourceforge.net/Tutorials/Noise.htmlTitle: Re: Problem with maps Post by: 3dickulus on November 22, 2015, 11:49:21 AM @Syntopia Q:will the #extention s restrict use to only newer cards?
Title: Re: Problem with maps Post by: Syntopia on November 22, 2015, 02:04:50 PM Yep. Actually a nicer way would be to put a '#version 330' instead.
Title: Re: Problem with maps Post by: Crist-JRoger on November 22, 2015, 07:06:34 PM Syntopia, thank you very much for this code! :)
http://www.fractalforums.com/index.php?topic=20680.msg88919#msg88919 Title: Re: Problem with maps Post by: 3dickulus on November 23, 2015, 12:49:48 AM I tried '#version 330' it complains about all the stuff that is not 3.3 but enabling the '#extension s' does not complain about the current code so I will make an effort to update Raytracer.frags.
@Syntopia is it as easy as I think to create a vec3 variant?... Code: float wang_hash_fp(vec3 pos) bitshifts and logic ops have got to be faster than fract(sin(dot(vec3))) Title: Re: Problem with maps Post by: Patryk Kizny on November 23, 2015, 04:44:26 PM BTW, can you guys recommend any options for less precise but way faster trigonometry?
I was wondering that since sin/cos is that slow and it's used very often for stuff that is not critical, maybe it can be approximated with faster functions? Any ideas? I thought also about maybe using a texture for encoding say 2M values and then interpolate even linearly between them. Would checking a bitmap plus interpolation be faster? Title: Re: Problem with maps Post by: Syntopia on November 23, 2015, 05:14:19 PM Trigonometric function are not slow on the GPU? See e.g. http://docs.nvidia.com/cuda/cuda-c-programming-guide/#arithmetic-instructions.
i.e. 4x the cost of an add, and 2x the cost of bitshift (if you are on Nvidia architecture). Also notice (Fermi architecture): "Special Function Units (SFUs) execute transcendental instructions such as sin, cosine, reciprocal, and square root. Each SFU executes one instruction per thread, per clock; a warp executes over eight clocks. The SFU pipeline is decoupled from the dispatch unit, allowing the dispatch unit to issue to other execution units while the SFU is occupied.". Given the design of a GPU (a massive amount of threads, and free context switch per cycle), that means you in many cases get trigonometric operations for *free*, because other parts of you code can carry on - at least if the SFU is not the bottleneck. Speculating about GPU efficiency is hard, and is often counter-intuitive. Don't assume that branching is always costly (it only is if the warps diverge - and sometimes the Nvidia compile will use predicated instructions), and don't assume trigonometrics is costly. The only sane thing is to try out your ideas, and measure the impact. Even then other GPU's may behave completely different. Title: Re: Problem with maps Post by: hobold on November 23, 2015, 05:42:12 PM And BTW, GPUs may sacrifice some accuracy for speed especially with trigonometry. For example sin() may have low absolute error, but much worse relative error on the GPU. In other words, the popular approximation sin(x) == x for very small magnitudes of x may fail on GPUs, despite the fact that sin() works beautifully for rotation matrixes and the like.
This depends somewhat on the programming environment. For example, OpenCL specifies guaranteed high accuracy for math functions like sin(), but older versions of CUDA don't. I don't know about GLSL. (Of course higher accuracy comes at the cost of speed, so OpenCL also allows use of the sloppy faster versions, if the programmer explicitly asks for them. I'd expect that modern CUDA does the same.) Title: Re: Problem with maps Post by: Syntopia on November 23, 2015, 05:53:54 PM The numbers (4x slower than add) given above were for the fast CUDA functions (__sinf instead of sinf, or when using --use-fast-math). I assume GLSL always use the fast path, since it meant for computer graphics, and not scientific computation.
Title: Re: Problem with maps Post by: 3dickulus on November 24, 2015, 03:09:06 AM @Syntopia I recall, from another thread, you mentioned that you had tried an fp64 (double) version of shaders in Fragmentarium but it was very slow
my question is: was it worth it vis a vis image quality? as an artist I don't care how long it takes to render that "perfect shot" but as an animator I do want max speed. Title: Re: Problem with maps Post by: 3dickulus on November 24, 2015, 05:34:44 AM @Patryk here's something for you...
http://www.fractalforums.com/announcements-and-news/fragmentarium-1-0-10/msg88916/#msg88916 enables anisotropic hardware filter for textures ;) this will also take care of the artefact you had on the edge of your texture (i think, at least it seemed to work in my small 2x2 test) Title: Re: Problem with maps Post by: 3dickulus on December 01, 2015, 03:34:39 AM OKey, Here's what I figured out: - The problem is definitely present only in Synthclipse (although I had experienced it in the past with Fragmentarium at some point and ignored it). - The problem is caused by the mipmap thing. i.e when I set fragmentarium map using the code: uniform sampler2D myTexture; file[test.png] #TexParameter myTexture; GL_TEXTURE_MIN_FILTER GL_LINEAR_MIPMAP_LINEAR It behaves exactly like the problem I am experiencing with synthclipse. Unfortunately Synthclipse won't let me enter #TexParameter just a heads up on mipmaps, setting just one parameter, as you indicated, is not correct, it needs all the right stuff... this is the proper way afaik... Code: /// in a frag this should create a mipmapped texture with 1000 levels Title: Re: Problem with maps Post by: Patryk Kizny on December 15, 2015, 07:42:09 PM Thanks!
Title: Re: Problem with maps Post by: Crist-JRoger on March 23, 2016, 09:02:01 PM Hi! I try to run GI by Eiffie on ATI. So it's noisy renderer and it uses rand() noise for dithering. So question is: how rewrite this code for wang_hash_fp function?
Code: int iRay=subframe Code: //random seed and generator upd.: found another in Sky-Pathtracer. Looks better ;D But wang_hash question still important. Code: vec2 seed = viewCoord*(float(subframe)+1.0); Title: Re: Problem with maps Post by: 3dickulus on March 24, 2016, 02:04:34 AM from http://www.fractalforums.com/index.php?topic=22721.msg88910#msg88910 (ty Syntopia)
Code: #extension GL_ARB_shader_bit_encoding : enable you might be able to just use the above routines or with Eiffie's code it might look like... Code: //random seed and generator or... Code: vec2 seed = viewCoord*(float(subframe)+1.0); just guessing :embarrass: so some experimenting will be required, if you find an optimal configuration I would like to add these routines to the MathUtils.frag :) Title: Re: Problem with maps Post by: Crist-JRoger on March 24, 2016, 07:42:21 PM Something wrong with this code
Code: vec2 seed = viewCoord*(float(subframe)+1.0); 200 subframes (http://orig05.deviantart.net/5fd7/f/2016/084/1/0/gi_ati_wanghash_tmp2_by_crist_jroger-d9wetqd.png) 2000 subframes (http://orig06.deviantart.net/bdd5/f/2016/084/7/d/gi_ati_wanghash_tmp1_by_crist_jroger-d9wetrh.png) This looks much better Code: vec2 seed = viewCoord*(float(subframe)+1.0); (http://orig02.deviantart.net/78e8/f/2016/084/6/3/gi_ati_seed_sky_tmp2_by_crist_jroger-d9wetsv.png) 2000 subframes (http://orig00.deviantart.net/e40c/f/2016/084/f/8/gi_ati_seed_sky_tmp1_by_crist_jroger-d9wetu7.png) The code below is horrible, looks little better than original. I didn't rendered it: Quote //random seed and generator vec2 randv2=fract(cos((gl_FragCoord.xy+gl_FragCoord.yx*vec2(1000.0,1000.0))+vec2(time)*10.0+vec2(iRay,iRay))*10000.0); vec2 rand2(){// implementation derived from one found at: lumina.sourceforge.net/Tutorials/Noise.html randv2+=vec2(1.0,1.0); return vec2(fract(sin(dot(randv2.xy ,vec2(wang_hash_fp(randv2.x),wang_hash_fp(randv2.y)))) * 43758.5453), fract(cos(dot(randv2.xy ,vec2(wang_hash_fp(randv2.x),wang_hash_fp(randv2.y)))) * 23421.631)); } Any ideas to apply WangHash into vec2 rand2() most optimal? Title: Re: Problem with maps Post by: 3dickulus on March 25, 2016, 04:55:40 AM here's 2 images I just rendered @ 200 subframes
1. default is as distributed in Examples/eiffieGI2/eiffieGI.frag 2. using wang hash as described above like... Code: //random seed and generator using nVidia GeForce 760 just going to try Sky-Pathtracer now... Title: Re: Problem with maps Post by: 3dickulus on March 25, 2016, 05:15:41 AM yes, the SkyPathtracer looks like cloth...
Code: vec2 seed = viewCoord*(float(subframe)+1.0); but this does not... Code: vec2 seed = viewCoord*(float(subframe)+1.0); 1. default as distributed in Examples/ 2. modified wang hash 2 although SkyPathtracer looks nice it is very slow compared to DE-Kn2 Title: Re: Problem with maps Post by: 3dickulus on March 25, 2016, 06:26:51 AM as I said, just guessing :embarrass: so some experimenting will be required
the effect of using wang hash does fix the IQ clouds blockyness bug :) Title: Re: Problem with maps Post by: quaz0r on March 25, 2016, 06:58:57 AM Quote from: 3dickulus wang Title: Re: Problem with maps Post by: 3dickulus on March 25, 2016, 11:39:42 AM yeah it's hard to see but...
if images are the same then a divide operation will result in all 1s EGI-200-default / EGI-200-wanghash = ! all 1s Title: Re: Problem with maps Post by: 3dickulus on March 25, 2016, 11:41:34 AM ...same for SkyPath-200 (png was too big so used jpg 99%)
Title: Re: Problem with maps Post by: Crist-JRoger on May 19, 2016, 11:24:36 PM how about this? Is this correct code? I was looking for a elegant solution, but how from a mathematical point of view? :embarrass: I mean use it without seed, sin, fract and a lot of numbers...
Code: vec2 rand2(vec2 pos){Title: Re: Problem with maps Post by: 3dickulus on May 20, 2016, 06:55:30 AM my GPU is currently occupied with some rendering :tongue1: so can't test it right now but a few renders comparing the old routine with this one will tell very quickly if it is good :dink: |