toxie wrote:

spooky, but also extremely artsy..

spooky, but also extremely artsy..

Agreed. Quite nice effect! Suitable for stylish avatar pic.

Statistics: Posted by beason — Sat Apr 29, 2017 2:38 am

]]>

Fail trying to use sobol sequences with bidirectional path-tracing.

Statistics: Posted by patlefort — Thu Apr 20, 2017 5:20 am

]]>

ingenious wrote:

The idea ideas not adding a deterministic (blue-noise) number to a random number. In fact, the idea is to get rid of the randomness altogether - you use the deterministic number to post your pattern, instead of using a random number.

The idea ideas not adding a deterministic (blue-noise) number to a random number. In fact, the idea is to get rid of the randomness altogether - you use the deterministic number to post your pattern, instead of using a random number.

Right, I was using "random" loosely. My understanding of this algorithm is that a Monte Carlo renderer where samples are taken per pixel might have a random number generator implemented like

fmod(halton(primes[dimension], sampleNumber) + blueNoise(pixelColumn, pixelRow), 1.0f)

And the halton() function might stand in for the "pixel-indendent random number".

Regarding the (0, 0.99) vs (0, 0.01) issue, the answer is that it depends. If your 1D sampling domain is "wrapped", i.e. 0.99 and 0.01 are next to each other, then yes, you should ideally take this into account in the distance function when you construct the dither mask.

Isn't the wrapping fundamental to the algorithm? If halton() returned 0.5 in the above code, then blue noise values of 0.0 and 0.99 would produce final results of 0.5 and 0.49, respectively.

Statistics: Posted by friedlinguini — Mon Apr 17, 2017 10:30 pm

]]>

Regarding the (0, 0.99) vs (0, 0.01) issue, the answer is that it depends. If your 1D sampling domain is "wrapped", i.e. 0.99 and 0.01 are next to each other, then yes, you should ideally take this into account in the distance function when you construct the dither mask. If the domain is not wrapped, then doing so will be suboptimal, that is, you won't get the best blue noise distribution of the error in your image. So you may want to have two dither masks - one with wrapped values and one with non-wrapped.

In 2D you have the same thing, but with some combinations. A torus light source would benefit from a mask with values wrapped along both dimensions. For a disk light or for hemisphere sampling you would use a mask wrapped along one dimension only. For a rectangular light the optimal choice would be a non-wrapped mask.

For higher dimensions using independent (or independently screen-space shifted) masks use possible, but if there's a lot of variance along all dimensions, then you will get some white noise that might destroy/mask the blue noise from the dithering. So it's not optimal, but it's very practical. Generating higher-dimensional blue noise masks is hard, because achieving high blue noise quality in high dimensions is hard in general.

Statistics: Posted by ingenious — Mon Apr 17, 2017 4:58 pm

]]>

sin(2 * pi * (ps - qs)) * 0.5 + 0.5

OK, that makes no sense. I tried to jam a couple of ideas together without making sure that one didn't break the other.

Maybe c * (x - x * x), where x = ps - qs and c is some constant I haven't worked out yet.

Statistics: Posted by friedlinguini — Sun Apr 16, 2017 8:34 pm

]]>

1. The idea is basically to add the pixel-dependent blue-noise shift to a pixel-independent random number, and subtract 1 if necessary to bring things in the range of [0, 1), right? But during tile generation, the algorithm would think of (for one dimension in both domain and range) a set of values like [0.0, 0.99, 0.0, 0.99, 0.0] to be "good", but [0.0, 0.01, 0.0, 0.01, 0.0] to be "bad", even though they have very similar effects on the result? Maybe some other definition of distance (e.g., sin(2 * pi * (ps - qs)) * 0.5 + 0.5 for one dimension) is more appropriate?

2. Generating high-dimensional blue noise tiles is hard, but can you get a good-enough effect by just using multiple independent 1- and/or 2-dimensional tiles, or even the same tile at a different sufficiently-large offset per dimension?

Statistics: Posted by friedlinguini — Sun Apr 16, 2017 2:19 pm

]]>

We are still working on porting primitives over but this is what we have already:

- an equation solver (solves quartic, cubic, and quadric equations).
- ray-primitive and surface normal code for: Bag o' Triangles (trimeshes), Arbitrary Polyhedrons, Elliptical Hyperboloids, Generalized Ellipsoids, Elliptical Paraboloids, Elliptical Torus, Right Elliptical Cylinders, Right Hyperbolic Cylinders, Right Parabolic Cylinders, Spheres, Truncated General Cones, Torus, and more...

Statistics: Posted by ziu — Thu Apr 06, 2017 9:39 am

]]>

]]>

]]>

Plus also note that its lossy compression (at least thats what i only saw).

Statistics: Posted by toxie — Tue Mar 28, 2017 2:37 pm

]]>

Statistics: Posted by toxie — Tue Mar 28, 2017 2:32 pm

]]>

Personally I can say that Draco's in my backlog and will stay there for the foreseeable future, since it doesn't really help my shoot those precious precious rays.

I doubt that the compression would work for on GPU memory, but if you're interested there are other compressions out there Google Quirin Meyer for a couple of papers on compressing positions and normals.

Statistics: Posted by papaboo — Tue Mar 28, 2017 6:00 am

]]>

Steve

Statistics: Posted by dr_eck — Mon Mar 27, 2017 4:06 pm

]]>

]]>

Steve

Statistics: Posted by dr_eck — Thu Mar 23, 2017 2:09 am

]]>