On 26/07/2015 01:47 PM, Orchid Win7 v1 wrote:
> On 24/07/2015 06:57 PM, scott wrote:
>> Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia
>> Quadro something) and it worked ok.
>>
>> Maybe it's something to do with the length of the shader? You could try
>> reducing the number of samples down to 1 (line 39) and the trace depth
>> down to 2 or something (line 118), that should make the shader much
>> shorter.
>
> I too was able to get this working by turning down the number of samples
> and the trace depth.

I presume it looks weird due to the limited trace depth. (?)

Post a reply to this message

Attachments:
Download 'webgl.jpg' (108 KB)

Preview of image 'webgl.jpg'

On 24/07/2015 06:00 PM, Orchid Win7 v1 wrote:
> On 24/07/2015 04:05 PM, scott wrote:
>> * One of the hardest bits is to get a random number generator running on
>> the GPU that is random enough to not show any patterns after a while.
>> There is still some subtle non-randomness visible, but it's way better
>> than it was originally. That's why there's random bits of code like
>> rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.
>
> Ah yes - it's not like you can just run the Mersenne Twister on a GPU...
> ;-)

...actually, apparently you *can* run MT on a GPU. o_O

Trouble is, it's laughably slow.

Have you seen this? The accepted answer looks simplish...

http://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu

Post a reply to this message

On 26/07/2015 14:19, Orchid Win7 v1 wrote:
> On 26/07/2015 01:47 PM, Orchid Win7 v1 wrote:
>> On 24/07/2015 06:57 PM, scott wrote:
>>> Hmmm odd, I wonder why that is. I just tested it on my work PC (nVidia
>>> Quadro something) and it worked ok.
>>>
>>> Maybe it's something to do with the length of the shader? You could try
>>> reducing the number of samples down to 1 (line 39) and the trace depth
>>> down to 2 or something (line 118), that should make the shader much
>>> shorter.
>>
>> I too was able to get this working by turning down the number of samples
>> and the trace depth.
>
> I presume it looks weird due to the limited trace depth. (?)

Yes it's probably highlighting the limitations in the RNG by only have a 
low trace depth. I uploaded a video of what it looks like here (samples 
40, trace depth 8) - woohoo for compressing noisy video!

https://youtu.be/rXQa5kHspFk

It only works with powers of two because your graphics card only allows 
power of two sized textures, and I'm not doing anything clever to check 
for powered-of-two-ness of the canvas size and creating bigger textures...

Also it's strange after staring at grainy images for a while your 
eye/brain just filters it out and you don't notice it. It's only when 
you then switch to a smooth image you go "wow that's really smooth" :-)

Post a reply to this message

On 26/07/2015 07:16 PM, scott wrote:
> On 26/07/2015 14:19, Orchid Win7 v1 wrote:
>> I presume it looks weird due to the limited trace depth. (?)
>
> Yes it's probably highlighting the limitations in the RNG by only have a
> low trace depth. I uploaded a video of what it looks like here (samples
> 40, trace depth 8) - woohoo for compressing noisy video!
>
> https://youtu.be/rXQa5kHspFk

Damn, your graphics card is *drastically* faster than mine... (When I 
pan the image, it comes out yellow for the first half a dozen frames.)

Apparently it's time to buy a more expensive GPU.

> It only works with powers of two because your graphics card only allows
> power of two sized textures, and I'm not doing anything clever to check
> for powered-of-two-ness of the canvas size and creating bigger textures...
>
> Also it's strange after staring at grainy images for a while your
> eye/brain just filters it out and you don't notice it. It's only when
> you then switch to a smooth image you go "wow that's really smooth" :-)

As I say, I never get to see it completely smooth. But hey, I guess I 
need a bigger stick. ;-)

I wonder... how long will it be before games look like this in realtime? 
(I'm guessing a while, since this scene contains a piffling half a dozen 
bits of trivial geometry.)

Post a reply to this message

> Damn, your graphics card is *drastically* faster than mine... (When I
> pan the image, it comes out yellow for the first half a dozen frames.)

That's because you had to reduce the samples per frame down. That 
variable controls how many samples the GPU averages over for each 
redraw. When you're rotating the scene it continuously redraws from 
scratch so if you've got samples set to 1 it's going to look *very* 
noisy. 40 is about the max I can do (at 1024x512 resolution) and still 
spin around at what looks like 60 fps. Any higher and it starts to 
stutter (even just dragging around other windows start to stutter too!).

Of course once you stop dragging it starts to remember the previous 
frames and average them out.

> I wonder... how long will it be before games look like this in realtime?
> (I'm guessing a while, since this scene contains a piffling half a dozen
> bits of trivial geometry.)

Bear in mind my implementation is about as unoptimised as you could ever 
get, it's just relying on brute force rather than anything clever at 
all. For something far more optimised look at this:

https://www.youtube.com/watch?v=aKqxonOrl4Q
https://www.youtube.com/watch?v=BpT6MkCeP7Y

I'm sure if nVidia designed a path tracing specific GPU today it would 
be plenty fast enough, the trouble is you're trying to shoe-horn some 
algorithm into a chip that was designed for something completely different.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> An unbiased* global illumination ray tracer running in your web browser,
> with a max_trace_depth of 8 and support for shiny, diffuse, transparent
> and checkered spheres. What more do you want!
>
> Just run the attached html on a PC with a fast GPU, you can drag around
> the scene with your pointer. Inside the html file you can change the
> size of the image (right at the end of the file you'll see width and
> height tags), using non-power-of-two values may not work on your
> graphics card.
>
> You can get some pretty cool effects by looking through the glass ball
> into the mirrored ball.
>
> Disclaimer: It works on my machine (Chrome, Win7, nVidia GTX970) but
> I've not tested it on any other machine. Particularly if you have a much
> slower graphics card it may run so slowly that it crashes, or it may not
> run at all. Also make sure you have the latest graphics drivers, no I'm
> not just saying this it often makes a difference. The output should look
> similar to the attached image after a few seconds.
>
> ...
>
> After creating the standalone html5 page for blobs thread above, I
> realised it would allow me to do something shadertoy doesn't - that is,
> reuse results from a previous calculation in the next frame. I already
> had an attempt at a path-tracer in C# (which was in turn translated from
> some C++ code I found somewhere) but it was pretty slow. The main
> sticking point I had was learning how to render to texture using webGL.
> So it renders one "frame" at a time, which actually consists of 10
> samples per pixel, it then averages this with all the previous results.
> It then repeats until you move the viewpoint. The result is that once
> you stop dragging the scene around the noise should disappear eventually.
>
> Your browser will probably limit the speed of updates to 60 frames per
> second, so that equals 600 samples per second. You can increase the
> number of samples per frame on line 39. But I found if you make it too
> high that a single frame takes longer than a second or so the video
> driver crashes.
>
> * One of the hardest bits is to get a random number generator running on
> the GPU that is random enough to not show any patterns after a while.
> There is still some subtle non-randomness visible, but it's way better
> than it was originally. That's why there's random bits of code like
> rng.x = sin(r1 - FrameNumber) in there. It seems to do the job.


I got a "Could not initialize WebGL" message. with a quadro FX3800

Post a reply to this message

> I got a "Could not initialize WebGL" message. with a quadro FX3800

Does WebGL work at all on other sites? Try these:

https://www.chromeexperiments.com/webgl
https://www.shadertoy.com/

Post a reply to this message

> Have you seen this? The accepted answer looks simplish...
>
>
http://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu

Looks promising, I'll save that page and see if I can implement it. It's 
surely going to be better than my trial-and-error bodge.

As highlighted on that page, the main problem is that every single pixel 
runs exactly the same code with the same inputs (apart from pixel 
coordinate). So you need some way of making every pixel generate a bunch 
of random numbers that are in no way related to any other pixels in the 
image (otherwise you get strange patterns like you saw with your 1 
sample image).

Post a reply to this message

On 27/07/2015 11:47, scott wrote:
>> Have you seen this? The accepted answer looks simplish...
>>
>>
http://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu
>>
>
> Looks promising,

Or not. There's a few bits that don't work in WebGL. Specifically there 
is no integer power function, xor operator, bit shifters or unsigned 
ints (only signed ints). Seems like you need the full OpenGL for this...

Post a reply to this message

On 27/07/2015 04:37 PM, scott wrote:
> Or not. There's a few bits that don't work in WebGL. Specifically there
> is no integer power function, xor operator, bit shifters or unsigned
> ints (only signed ints). Seems like you need the full OpenGL for this...

Ouch. Really? Damn...

Post a reply to this message