 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Wait - you can define MORE THAN ONE variable in a loop initialisation??
Don't see why not, would be a pointless limitation to put in on purpose that
just reduced the flexibility, should anyone want it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Evidently my C++ is weak
Anybody got any theories on line 55?
if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p);} else return obj.e;
if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
I can't decide which "if" the "else" belongs to. o_O
(I also have approximately no idea whatsoever what f=f*(1/p) is in aid
of...)
Post a reply to this message
|
|
| |
| |
|
|
From: Vincent Le Chevalier
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 08:14:58
Message: <4b4f18d2$1@news.povray.org>
|
|
|
| |
| |
|
|
Invisible wrote:
> I can't decide which "if" the "else" belongs to. o_O
The else always belongs to the closest if at the same scope level...
Which means it's:
if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
I think it's part of the Russian Roulette method (which is what the
comment R.R. stands for I suppose). I don't remember the details but you
can probably look it up by yourself...
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vincent Le Chevalier wrote:
> if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
Ouch. This isn't going to be pretty...
> I think it's part of the Russian Roulette method (which is what the
> comment R.R. stands for I suppose). I don't remember the details but you
> can probably look it up by yourself...
Clearly it flips a coin to decide whether to process further [all of the
code paths beyond this point involve sending out a new ray] or just stop
here. However, "f" is the object colour, and I have absolutely no idea
why it's being scaled by the reciprocol of the brightest component...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> 53: Vec nl=n.dot(r.d)<0?n:n*-1;
>>
>> different from "nl = -abs(n.dot(r.d))"?
>
> a?b:c evaluates to b if a is true, or c otherwise.
LPC might be a little different, but can't you negate a variable by
saying a=-a;? Saves a little CPU cost.
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> LPC might be a little different, but can't you negate a variable by saying
> a=-a;? Saves a little CPU cost.
I think he would have to define the unary minus operator for the vector
class before he could write -n instead of n*-1.
Post a reply to this message
|
|
| |
| |
|
|
From: Vincent Le Chevalier
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 08:58:32
Message: <4b4f2308@news.povray.org>
|
|
|
| |
| |
|
|
Invisible wrote:
> Vincent Le Chevalier wrote:
>
>> if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
>
> Ouch. This isn't going to be pretty...
What do you mean?
> Clearly it flips a coin to decide whether to process further [all of the
> code paths beyond this point involve sending out a new ray] or just stop
> here. However, "f" is the object colour, and I have absolutely no idea
> why it's being scaled by the reciprocol of the brightest component...
I think that it's the part that makes the method unbiased. You have to
scale the rays that you keep in order to account for the fact that you
don't keep them all, or something like that.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
>>
>> Ouch. This isn't going to be pretty...
>
> What do you mean?
I mean implementing this in a language where the else-part is
*mandatory* for all if-blocks makes this slightly tricky to do. (But not
as tricky as I thought; I've found a clean way to do it.)
>> However, "f" is the object colour, and I have
>> absolutely no idea why it's being scaled by the reciprocol of the
>> brightest component...
>
> I think that it's the part that makes the method unbiased. You have to
> scale the rays that you keep in order to account for the fact that you
> don't keep them all, or something like that.
Well, we'll see I guess...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> nemesis wrote:
>
>> yes. I wonder how it'd look like in Haskell. ;)
>
> In any language, I suspect the answer will depend on:
>
> - Which libraries are you allowed to use? [Get a ray tracing library and
> the program surely becomes trivial...]
>
> - How fast does it have to be? [A highly-efficient program is likely to
> be a lot bigger than a program written specifically to demonstrate how
> terse you can be.]
That's what I'm willing to know. That piece of code is not using a
"raytracing library", just implementing algorithms from well-known papers.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
From: Invisible
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 11:33:41
Message: <4b4f4765@news.povray.org>
|
|
|
| |
| |
|
|
nemesis wrote:
> yes. I wonder how it'd look like in Haskell. ;)
I had a go at implementing this, but I have clearly screwed up the math
somewhere, because the program is behaving very strangely.
(I've turned off all the fancy stuff until it's just a normal depth-1
ray tracer, and the image still just consists of a few bent lines.)
So far I've found at least a dozen bugs in the ray/intersection code, a
typo in the cross-product (typed an X instead of a Z), and I'm still
finding more. What can I say? I fail at math! o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
