wrong NG i know! but hey :P

I have a pet project on the go, a small raytracer that will fit on a C64 and
render a simple scene, 3 spheres and a plane!

I am looking for code to small raytracers, 4k demo entries and any guides to
making a very simple stripped down, bare bones raytracer

There are conciderable platform limitations, I only have about 40k to play
with and 1mhz cpu to do it with, not to mention 16 whole cols, and an
incedably low graphics resoloution.

Any help?

Rick

Post a reply to this message

Rick wrote:
> 
> wrong NG i know! but hey :P
> 
> I have a pet project on the go, a small raytracer that will fit on a C64 and
> render a simple scene, 3 spheres and a plane!
> 
> I am looking for code to small raytracers, 4k demo entries and any guides to
> making a very simple stripped down, bare bones raytracer
> 
> There are conciderable platform limitations, I only have about 40k to play
> with and 1mhz cpu to do it with, not to mention 16 whole cols, and an
> incedably low graphics resoloution.
> 
> Any help?
> 
> Rick

My housemate wrote a ray tracer in BASIC for the C-64 many years ago. 
Greyscale, only did planes.  Not sure whether he has the code anywhere,
though he did stumble across some printouts a few months back, which he
showed off with great pride.

Graphics Gems IV has the C code for a minimal ray-tracer.  It's written
in C and runs just over two pages.  Unfortunately, it gives absolutely
no consideration to speed, since most ray-tracing optimization
techniques ultimately involve a space-time tradeoff, and they were
shooting for minimal space.  Still, it's a place to start.  The source
code is included in an archive that can be found at
http://www.acm.org/tog/GraphicsGems/gemsiv.zip

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Mark Gordon wrote:
> 
> Rick wrote:
> >
> > wrong NG i know! but hey :P
> >
> > I have a pet project on the go, a small raytracer that will fit on a C64 and
> > render a simple scene, 3 spheres and a plane!
> >
> > I am looking for code to small raytracers, 4k demo entries and any guides to
> > making a very simple stripped down, bare bones raytracer
> >
> > There are conciderable platform limitations, I only have about 40k to play
> > with and 1mhz cpu to do it with, not to mention 16 whole cols, and an
> > incedably low graphics resoloution.
> >
> > Any help?
> >
> > Rick
> 
> My housemate wrote a ray tracer in BASIC for the C-64 many years ago.
> Greyscale, only did planes.  Not sure whether he has the code anywhere,
> though he did stumble across some printouts a few months back, which he
> showed off with great pride.
> 
> Graphics Gems IV has the C code for a minimal ray-tracer.  It's written
> in C and runs just over two pages.  Unfortunately, it gives absolutely
> no consideration to speed, since most ray-tracing optimization
> techniques ultimately involve a space-time tradeoff, and they were
> shooting for minimal space.  Still, it's a place to start.  The source
> code is included in an archive that can be found at
> http://www.acm.org/tog/GraphicsGems/gemsiv.zip

AFAIK it's far easier to translate and then optimize a small pice of
code you understand, than to translate a larger, more optimized pice of
code you don't understand(Nothing personal, but optimized code can be a
hell to understand if it isn't well commented).

Just some thoughts..

//Spider

Post a reply to this message

Spider wrote:
> 
> Mark Gordon wrote:
> >
> > Graphics Gems IV has the C code for a minimal ray-tracer.  It's written
> > in C and runs just over two pages.  Unfortunately, it gives absolutely
> > no consideration to speed, since most ray-tracing optimization
> > techniques ultimately involve a space-time tradeoff, and they were
> > shooting for minimal space.  Still, it's a place to start.  The source
> > code is included in an archive that can be found at
> > http://www.acm.org/tog/GraphicsGems/gemsiv.zip
> 
> AFAIK it's far easier to translate and then optimize a small pice of
> code you understand, than to translate a larger, more optimized pice of
> code you don't understand(Nothing personal, but optimized code can be a
> hell to understand if it isn't well commented).

You're correct that it's not as clear as it might be, but it's not as
obfuscated as one might expect, either.  The version that fits on an
index card, now THAT'S obfuscated!  It could be worse; it was optimized
for a minimum number of tokens in the source code, so it's actually
optimally simple, with no incentive to use non-intuitive variable names,
for instance.  It's also not as obfuscated as some of the loop
optimization I've seen.  The comments are a bit sparse, but it contains
such functions as the following:

double vdot(A, B)
vec A, B;
{return A.x*B.x + A.y*B.y + A.z*B.z;}

The coding style is unorthodox to say the least, but the intent is
pretty clear.  And hey, he asked for "VERY small raytracers".  That's
the exact focus of the article I cited.  Be careful what you ask for;
you just might get it. ;-)

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Mark Gordon wrote:
> 
> You're correct that it's not as clear as it might be, but it's not as
> obfuscated as one might expect, either.  
Hehe, since I'm not all that much into C I haven't looked at the source,
but... I can recall a few demo contests where the target wass to do a 
raytracer for a sphere... next time it wwas a waterfall.. (I actually
coded one, but not in time..)

> The version that fits on an
> index card, now THAT'S obfuscated! 
yeah... like warp's .sig :)

> It could be worse; it was optimized
> for a minimum number of tokens in the source code, so it's actually
> optimally simple, with no incentive to use non-intuitive variable names,
> for instance. 
*nods*
> It's also not as obfuscated as some of the loop
> optimization I've seen. 
hehe, love the inline assembler in pascal there... *recalls* all loops
were recoded into asm just for speed sake.. (why did it place it on the
stack in each for() looop??)

> The comments are a bit sparse, but it contains
> such functions as the following:
> 
> double vdot(A, B)
> vec A, B;
> {return A.x*B.x + A.y*B.y + A.z*B.z;}
hmm, not the worst I've seen, but still :)
 
> The coding style is unorthodox to say the least, but the intent is
> pretty clear.  And hey, he asked for "VERY small raytracers".  That's
> the exact focus of the article I cited.  Be careful what you ask for;
> you just might get it. ;-)
Yeah..

Hmm, anyone got the source for reality? No? strange... I'd like to patch
it :)

//Spider

Post a reply to this message

Even further OT: I once saw a ray traced image (mirror sphere & checkered
plane) that was raytraced in Postscript. The PS file was only about 1 k
long.

Seriously, Rick - if you want to do *exactly* 3 spheres and a plane, you can
leave out most of the code by hardcoding the sphere locations, textures,
setting the plane as z=0, etc. If at most one sphere is reflective you could
simplify things more. (You *will* be making one reflective, won't you?)

    -Robert Dawson

Post a reply to this message