 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> .... aside from the fact that what you describe *is* cosine weighting (unless
> your approach would be wrong, that is) :)
Yea, I just meant that now we don't have to take the cosine factor into
account anymore when figuring radiance (or whatever) contribution as the
ray distribution handles it by itself. Both give the exact same result.
> doesn't sound too bad (however, performance should be compared with taking two
> random numbers and transforming them to circle distribution using trigonometry
> instead of the monte-carlo approach).
In my Monte-Carlo path tracing renderer the above method was faster than
those using polar coordinates (random phi and theta describing the
angles). It was very clearly faster. I have Core2Duo so things might be
different on other platforms / with other compilers. I use GCC.
Severi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> So yes, that should do: A loop typically taking less than two iterations (the
> most expensive part probably being the RNG) and a square root. Quite
> inexpensive after all.
When you project the point to the hemisphere, you'll probably need three
multiplications and a square root. That's going to be much more expensive
than the RNG. (High-quality RNGs are very fast. They are faster than a LCG,
which consists of one integer multiplication and addition.)
> So it's definitely less expensive than going via a uniform distribution on a
> sphere in any case. Don't know whether that can be achieved without
> trigonometry, and at least it will involve a root somewhere as well - plus the
> math to get either a cosine weighting or a cosine weighted distribution.
The whole idea of the given algorithm (ie. get a random point evenly
distributed on a disc and then parallel-project it to a hemisphere
correspondent to that disc) is that you don't need any trigonometry
anymore, and the points will be automatically distributed on the
hemisphere according to the cosine function. (Square root of multiplications
is equivalent to sin/cos.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmail com> wrote:
> Indeed. But specular is itself a fake, a rough shortcut to the real deal:
> specular is really diffuse reflection on very smooth surfaces.
If I may correct you: They are in fact *specular* reflections on a comparatively
*rough* surface...
> I've seen people advocating the use of (glossy) reflection to more realistically
> achieve that effect.
.... which is why that advocated approach works to very good effect.
The idea is simple: Make all light sources actually visible. Make all your
surfaces somewhat reflective, and rough them up using a "bump" normal, scaled
to dimensions much smaller than two adjacent pixels on screen. Render the
thing, making sure Antialiasing or focal blur take many samples per pixel.
Voila: Blurred highlights done just the same way as mother nature does.
Works great with HDR light probes for sky or backdrop.
Takes a lot of samples though to get flat and comparatively rough surfaces to
look good, so be prepared for overnight renders.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And this is the code I use:
double x,y,z;
do{
x = 2.0 * rNG.randomNumberClosed() - 1.0;
z = 2.0 * rNG.randomNumberClosed() - 1.0;
}
while(x*x + z*z > 1.0);
y = sqrt(1.0 - (x*x + z*z));
There you have it: a random vector inside a hemishere.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> There you have it: a random vector inside a hemishere.
With cosine weighting...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> In my Monte-Carlo path tracing renderer the above method was faster than
> those using polar coordinates (random phi and theta describing the
> angles).
How did you pick phi and theta? Did you pick uniform random numbers and map them
using straightforward functions (needs trigonometry I guess), or did you
monte-carlo them as well?
> It was very clearly faster.
I'd actually expect so, but you never know until you test it :)
> I have Core2Duo so things might be
> different on other platforms / with other compilers. I use GCC.
Don't think so. Not significantly at least.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
>
> The whole idea of the given algorithm (ie. get a random point evenly
> distributed on a disc and then parallel-project it to a hemisphere
> correspondent to that disc) is that you don't need any trigonometry
> anymore, and the points will be automatically distributed on the
> hemisphere according to the cosine function. (Square root of multiplications
> is equivalent to sin/cos.)
Yeah, I know that. That's all the point I'm trying to make. Well, except that I
wasn't aware that it even gets you rid of any trigonometrics at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] notthissaunalahtifiinvalid> wrote:
> And this is the code I use:
> double x,y,z;
> do{
> x = 2.0 * rNG.randomNumberClosed() - 1.0;
> z = 2.0 * rNG.randomNumberClosed() - 1.0;
> }
> while(x*x + z*z > 1.0);
> y = sqrt(1.0 - (x*x + z*z));
> There you have it: a random vector inside a hemishere.
You still have to rotate it so that the hemisphere is tangential to
the surface. Probably requires multiplication with a matrix.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> The idea is simple: Make all light sources actually visible. Make all your
> surfaces somewhat reflective, and rough them up using a "bump" normal, scaled
> to dimensions much smaller than two adjacent pixels on screen. Render the
> thing, making sure Antialiasing or focal blur take many samples per pixel.
> Voila: Blurred highlights done just the same way as mother nature does.
> Works great with HDR light probes for sky or backdrop.
> Takes a lot of samples though to get flat and comparatively rough surfaces to
> look good, so be prepared for overnight renders.
Not very feasible with very complex scenes which may have other
slow-to-render elements, unless you have a couple of years to wait for
the render to finish.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You still have to rotate it so that the hemisphere is tangential to
> the surface. Probably requires multiplication with a matrix.
>
Yes, it has to be transformed properly. Transformation matrix is a
common way to do it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
