> 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

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

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

Invisible escreveu:
> 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

perhaps you just fail at translating crazy C++ code, which is perfectly 
fine.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> perhaps you just fail at translating crazy C++ code, which is perfectly 
> fine.

I don't find it really crazy, actually I was expecting far worse before 
opening the file...

It uses some tricks to achieve compactness but it's still mostly 
legible. I've seen far worse as far as variables names are concerned, 
for instance :-\

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:
> I don't find it really crazy, actually I was expecting far worse before 
> opening the file...

Me too, honestly.  You can see what it's doing, and you could probably 
translate it by hand into some other OO imperative language without even 
knowing what it's trying to do.  It's not obfuscated as much as terse.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Invisible wrote:
> 44:  double n=sizeof(spheres)/sizeof(Sphere);
> 
> Well... that's... one way to figure out how big an array is. :-.

That's the usual way to figure out how big an array is in C and C++.

> Evidently my C++ is weak, but... how is
> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
> different from "nl = -abs(n.dot(r.d))"?

In the lack of needing to define the abs() function?

> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
> places, but I can't find a definitions.

Line 48. It's an argument to the function. Note that text search will 
usually answer that sort of question on a C program, and often on a C++ 
program too.

Not always, mind, but usually.


> Line 79 means each row of pixels is computed in parallel, right?

Got me. It looks like someone is asking the compiler to do that if it can.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Line 79 means each row of pixels is computed in parallel, right?
> 
> Got me. It looks like someone is asking the compiler to do that if it can.

http://en.wikipedia.org/wiki/Openmp#Work-sharing_constructs

Post a reply to this message