Sabrina Kilian wrote:
> Stephen wrote:
>> Darren New wrote:
>>> nemesis wrote:
>>>> It was also the basis for SmallptGPU:
>>> Hey, I have an idea. Has anyone ever considered porting POV-Ray to the
>>> GPU? I bet it would be a lot faster.
>>>
>> Nice one! What a good idea. ;)
>>
> 
> Hey, I bet it couldn't take more than a few minutes to move all the code
> that direction. I mean, it can't be too much larger than 99 lines of code.

Not being a coder myself I will have to take your word on that. I’m sure 
Chris could do it standing on his head or at least upside down ;)

-- 

Best Regards,
	Stephen

Post a reply to this message

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.]

Post a reply to this message

Darren New wrote:

> Cute. Hard to read, but cute. :-)

Wait... THE WALLS ARE GIANT SPHERES?! o_O

Well that's *one* way to cut down the code size... No ray/plane 
intersection test to code.

44:  double n=sizeof(spheres)/sizeof(Sphere);

Well... that's... one way to figure out how big an array is. :-.

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))"?

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

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

Post a reply to this message

> 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.

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

Line 82, after the x=0 definition.

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

I guess so.

Post a reply to this message

>> 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.

Ah, wait, I misread that as calculating something, assigning it to n, 
and then checking whether n is negative and if not negating it. On 
closer inspection, that's not what this does...

>> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
>> places, but I can't find a definitions.
> 
> Line 82, after the x=0 definition.

Wait - you can define MORE THAN ONE variable in a loop initialisation??

Post a reply to this message

> 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

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