 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Vincent Le Chevalier
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 12:24:05
Message: <4b4f5335$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nicolas Alvarez
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 14:06:31
Message: <4b4f6b37$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Vincent Le Chevalier
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 14:07:41
Message: <4b4f6b7d$1@news.povray.org>
|
|
|
| |
| |
|
|
Darren New 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.
>
It's using the OpenMP directives
(http://en.wikipedia.org/wiki/OpenMP)... I discovered that last year,
can be pretty useful and makes it quite easy to take advantage of
multiple cores when the algorithms are already mostly suited to being
run in parallel.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
From: Orchid XP v8
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 14 Jan 2010 14:18:53
Message: <4b4f6e1d@news.povray.org>
|
|
|
| |
| |
|
|
>> 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.
It's just shoved together into a very small space, so it's a big awkward
to read.
What I've probably done is got a plus sign instead of a minus somewhere,
or something equally trivial, which has none the less completely screwed
up the math. And damn, it's going to take a while to find it! :-/
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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++.
It is surprising to me that this actually works. I was under the
impression that C does not actually distinguish between pointers and
arrays (and integers and booleans and...)
>> 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?
No, I misread the code. It's actually deciding whether to negate n based
on a function of n, not n itself.
>> 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.
No, it's an argument in the radiance() function, I meant where is it
defined in main().
> 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.
Yeah, I tried that too...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook <z99### [at] gmail com> wrote:
> 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.
Yes, but since 'nl' is of type struct Vec, he would have to define
operator-() for it for that to work. Maybe he wanted to save one line
of code.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> Darren New 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.
> >
> It's using the OpenMP directives
> (http://en.wikipedia.org/wiki/OpenMP)... I discovered that last year,
> can be pretty useful and makes it quite easy to take advantage of
> multiple cores when the algorithms are already mostly suited to being
> run in parallel.
The advantage of OpenMP is that the routine will run in parallel if
the compiler supports it, but if the compiler doesn't support OpenMP,
it doesn't matter: The program will still compile and work properly
(it will just be single-threaded). Compilers ignore #pragmas they don't
recognize (per the standard), so the addition #pragma openmp's don't
matter.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
