Hi everybody,

> Thank you all for the recommendations.  I've been spending some time

Yes, let me also use this opportunity to express my gratetude to the
helpful people around here. Ingo: I am looking very much forward to read
your latest paper, it seems like the kind of research I'd like to
conduct during my masters year (as a thesis). =)

[OS independency]
> Unfortunately, my computers are currently all running Windows.

Now that is a shame. =) For cross platform computer graphics, I can
recommend SDL (http://www.libsdl.org/). Quoting from the home page:
"Simple DirectMedia Layer supports Linux, Win32, BeOS, MacOS, Solaris,
IRIX, and FreeBSD". Although I never tried it under anything else than
Linux, I still vouch for it. It is extremely simple to use (exception
handling removed):

SDL_Init(SDL_INIT_VIDEO);
SDL_Surface *screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE |
SDL_DOUBLEBUF | SDL_HWACCEL);
Uint32 *buffer = (Uint32 *)screen->pixels;
buffer[y * 640 + x] = 0xRrGgBb;
SDL_Flip(screen);

This piece of code initializes SDL, opens a window (fullscreen also a
possibility), sets a single pixel, and flips the buffers. =)

> 4) Is there a good profiler I can use with this?  (Again, is the
> Windows version better/worse?)

I am using GNU gprof (http://www.gnu.org/manual/gprof-2.9.1/), which
gives me all details I need, and then some. =)

best regards,
Daniel
http://www.cs.auc.dk/~daniel/

"neoakata" <tranderson@...> wrote Thu, 11 Apr 2002 20:24:14 -0000 :

> Taking your advice, I'd like to write this to be as OS independent as
> possible.

> 1) I've written graphics applications for DOS4GW & Windows (and some
> other out of date operating systems) but never linux.  I know that
> even doing something as simple as setting up the resolution and
> plotting a single pixel on the screen can be a difficult thing to
> figure out when you are just getting familiar with doing graphics in
> a new environment.  Would anyone happen to have a silly little plot a
> pixel program that runs in linux?  (or know where I can find some
> code that would help?)

Ok, using the SDL will make this soooooo intricate.
This program will compile & run under unix, windows, macos, beos and even
playstation 2, and will take advantage of most available  hardware
accelerations when copying the buffer into video memory.

1st.c:
********************* CUT HERE **********************************
#include <SDL/SDL.h>

unsigned long *buffer = NULL;
unsigned int L,H;

void putpixel(unsigned int x,unsigned int y, unsigned long clr) {
         buffer[x+y*L] = clr;
}

int main() {
         SDL_Surface *ecran;
         char quit = 0;
         int i;

         L = 640;
         H = 480;

         SDL_Init( SDL_INIT_VIDEO );
         ecran = SDL_SetVideoMode( L,H,32, 0 /*SDL_FULLSCREEN*/ );
         buffer = (unsigned long*)ecran->pixels;

         memset(ecran->pixels,0xff,640*480*4);
         for (i=0; i<200; i++)
                 putpixel(i,i,0xff00ff);

         SDL_Flip( ecran );

         while (!quit) {
                 SDL_Event event;
                 if ( SDL_PollEvent(&event) )
                         switch (event.type) {
                                 case SDL_QUIT:
                                         quit = 1;
                                         break;
                                 case SDL_KEYDOWN:
                                         switch (event.key.keysym.sym) {
                                                 case SDLK_q:
                                                 case SDLK_ESCAPE:
                                                         quit = 1;
                                                         break;
                                         }
                                         break;
                         }
         }

         SDL_Quit();

         return 0;
}
********************* CUT HERE **********************************
And you have a window, with graphism, keyboard and window-closing button being
handled.


To compile:
gcc    -c -o 1st.o 1st.c
gcc -lSDL  1st.o   -o 1st

> 5) In general, for cross platform graphics development, what IS the
> best OS to develop in?

The one you prefer. But for cross-platform, never use VC+: lots of standard
stuff
not supported, and lots of non standard stuff integrated.
For example in my case I stick to Linux, but only because it is my favorite
development
environment.

>
>
>
>1) I've written graphics applications for DOS4GW & Windows (and some
>other out of date operating systems) but never linux.  I know that
>even doing something as simple as setting up the resolution and
>plotting a single pixel on the screen can be a difficult thing to
>figure out when you are just getting familiar with doing graphics in
>a new environment.  Would anyone happen to have a silly little plot a
>pixel program that runs in linux?  (or know where I can find some
>code that would help?)
>
i'd start with glut. use the glut-functions to open your window and for
input handling,
raytrace your image into a memory region, and display that as a texture.
there should be some demo-code for such simple programs somewhere, though
i don't have them. its a little bit weird to use oepngl/glut for
displaying a raytraced
image, but glut has some nice set of very convenient functions.

the next step would be to use x-shared-memory images. you just raytrace
into the shared memory
of the x-server, and display the final image. however, opening windows
aso is
not really nice with x11. there should be some example code in almost
every x11-intro-book,
but again, i cant point you to one directly. if you don't find it
anywhere else, i might dig it out
from somewhere.
anyway, with x11 - _never_ try to set a single pixel (if you want to
finish in finite time),
always render to a buffer (image or texture) and put the whole thing on
the screen after its done.

>
>2) If I were to consider purchasing a new machine for this (gotta
>keep the cost low though), does it make sense to purchase one with
>multiple processors?  I've written a parallel ray tracer using an SGI
>Origin so I know firsthand that you can get linear speedup with a
>properly load balanced scene.  I also found that implementing task
>stealing continues this linear trend even with higher numbers of
>processors (32).  The reason I'm still asking this question is, if
>the real bottleneck seems to be related to the memory fetches, and
>I'm planning on using the SSE, would multiple processors still give
>me a linear speedup on a shared memory architecture (the PC)?
>
well, for pcs, theres basically the quesion on dual vs single, your
unlikely to get more CPUSs....
and for our system, we get exactly the expected speedup. a dual-pc is
exactly twice as fast a single pc....
you have to take care of your datastructures though, in order not to
overload your caches.

>
>3) Does the Intel compiler have a good IDE? (Is the Windows version
>better/worse than linux for this?)
>
the linux ide is a command-line (not better nor worse than gcc) ;-)

>
>4) Is there a good profiler I can use with this?  (Again, is the
>Windows version better/worse?)
>
there is vtune, which is supposed to be very good. there are many other
linux-tools, too,
though most are not very easy to use.
again, ides are virtually not available for linux. e.g. the ide for
vtune only runs on windows

>
>5) In general, for cross platform graphics development, what IS the
>best OS to develop in?
>
depends on personal belief. once you got used to linux, you don't want
any cross-platform
development any more, anyway ;-)
many people work under windows, though, because of the ide issues, and
because its easier to get
professional programs...

     Ciao

         Ingo

wald@...
http://www.openrt.de

Thank you all for the recommendations.  I've been spending some time
reading through all of the old RTRT messages and in particular - Ingo
Wald's excellent papers!

Taking your advice, I'd like to write this to be as OS independent as
possible.  Unfortunately, my computers are currently all running
Windows.  It would make sense then for me to set up linux somewhere,
but I'm getting a bit out of my comfort zone here.  I've done a lot
of unix coding in c, but it's mostly been database stuff.  So with
that, I have a few more questions:

1) I've written graphics applications for DOS4GW & Windows (and some
other out of date operating systems) but never linux.  I know that
even doing something as simple as setting up the resolution and
plotting a single pixel on the screen can be a difficult thing to
figure out when you are just getting familiar with doing graphics in
a new environment.  Would anyone happen to have a silly little plot a
pixel program that runs in linux?  (or know where I can find some
code that would help?)

2) If I were to consider purchasing a new machine for this (gotta
keep the cost low though), does it make sense to purchase one with
multiple processors?  I've written a parallel ray tracer using an SGI
Origin so I know firsthand that you can get linear speedup with a
properly load balanced scene.  I also found that implementing task
stealing continues this linear trend even with higher numbers of
processors (32).  The reason I'm still asking this question is, if
the real bottleneck seems to be related to the memory fetches, and
I'm planning on using the SSE, would multiple processors still give
me a linear speedup on a shared memory architecture (the PC)?

3) Does the Intel compiler have a good IDE? (Is the Windows version
better/worse than linux for this?)

4) Is there a good profiler I can use with this?  (Again, is the
Windows version better/worse?)

5) In general, for cross platform graphics development, what IS the
best OS to develop in?

Thanks again!

-Tom

> if you do it under linux, definitely go for the intel compiler.
> for linux, it can be downloaded for free, and can be up to two times
> as fast as gcc. (in our  case, it mostly is [;-)] , though not for all
> programs)

As far as I know Intel compiler is available for win32 too (don't know if
it's free).

My opinion (expressed in a mail this list never received, because yahoo is
quite lame) is that you have to forget about dos, and in particular forget
about any OS.
OS is good just to load your demo and give you some buffer's addresses. The
rest must be os-independent.

--*PaN!*

Hi Tom!

>  Anyone ever take a stab at a web enabled demo?
What exactly do you mean? A Java applet (or similar)?
If so,
http://equinox.planet-d.net/
have some rather nice java-applet demos. Even some that do raytracing,
although they aren't fast enough to deserve the name 'realtime raytracing'.
Also I recommend surfing www.planet-d.net and www.ojuice.net for demo
thingys.

Regards,
Thomas

>
>
>
> I have an old Watcom C++ compiler, Visual C++ 6.0, or g++.
>
> Does anyone have any recommendations for what compiler is best (for
> speed and portability)?  Should I be writing this for DOS, Windows,
> both?  Anyone ever take a stab at a web enabled demo?
>
if you do it under linux, definitely go for the intel compiler.
for linux, it can be downloaded for free, and can be up to two times
as fast as gcc. (in our  case, it mostly is [;-)] , though not for all
programs)

also, it has good support for exploiting sse extensions via intrinsics
and somtimes
even automatic sse generation.

i don't know wether its free for windows, though.

    Ciao

        Ingo





[Non-text portions of this message have been removed]

I'm interested in writing a demo and I noticed that most of the demos
run under DOS.  Is this the standard, or does this have more to do
with the fact that many of the demos are a bit dated?

I have an old Watcom C++ compiler, Visual C++ 6.0, or g++.

Does anyone have any recommendations for what compiler is best (for
speed and portability)?  Should I be writing this for DOS, Windows,
both?  Anyone ever take a stab at a web enabled demo?

Thanks!

-Tom

Hi..

Yes, they do add overhead to simple scenes.  However, these are
generally VERY simple scenes.  For even a few (2 or 3 thousand)
polygons, a spatial sub-division would give you a great boost.

Bye..

Hi....

First time I write here...
Well im working on a RTRT (like almost everyone here) and I'm
planning on implementing spatial subdivision... son guy told me they
add to much overhead for simple scenes... any of u has tryed any
spatial subdivision scheme and could tellme if he got any
significant speed improvement high deph reflective and refractive
rendered scenes?

and.. what algorythms did u guys use to compute what are the
possible objects that are inside the "3d cell"


btw here is my new page about rtrt (still under construction)
http://www.geocities.com/morbidpixel/

Hey all,
just two links:
lRay was updated and seems to have implicit surfaces now, looks
pretty nice:
http://www.cfxweb.net/~lyc/lray.html

Also check out this nice 256b, with source too! (it does raymarching
actually, but how good for a 256b!):
http://www.256b.com/search.php?find=lattice&what=demo

\Piero

Hi guys,

   Thanks for all the pointers to root solvers and torus intersections.
I finally have some donuts spinning in a test program. I implemented
the method I said I was working on where the torus is represented as
2 vectors and 2 radii. I'm still writing it up, but it's quite fast
because half way to getting the quartic in t there are a couple early
exits - equivalent to testing against a bounding cylinder and slab.

   The quartic is actually simpler to generate than to solve. For now I'm
using the GGems solver, but I'll still be writing something more optimal.
On the up side, I just dropped it in and it worked. This allowed me to
find bugs in MY code knowing that the root solver was working properly.

My donuts still need some things added to be fully integrated into the
rest of the code, but I won't keep asking how to handle them every couple
months any more. I'm still interested in general cubics & quartics...

Thanks all,
Paul

Short version: there's a pointer to code at the end of my note.

Piero writes:

>Afaik the two most used methods (RT-wise) are
>1) some flavour of the general analytic quartic formula
>2) root isolation through Sturm, and then some approximation steps a-
>la Newton-Rhapson.
>Both ways are imho pretty slow...


Avoid Sturm, it's wicked slow for quartics, vs. the closed form. The closed
form thing is touchy (use doubles! and the epsilon can still burn you in
some cases, as I recall).

Searching on www.raytracingnews.org, here's my addition to the discussion:

http://www1.acm.org/pubs/tog/resources/RTNews/html/rtnv7n3.html#art8

http://www1.acm.org/pubs/tog/resources/RTNews/html/rtnv3n3.html#art16

http://www1.acm.org/pubs/tog/resources/RTNews/html/rtnv5n1.html#art11

http://www1.acm.org/pubs/tog/resources/RTNews/html/rtnv3n2.html#art7


and here's Cychosz's code:

http://www1.acm.org/pubs/tog/GraphicsGems/gemsii/intersect/inttor.c

which calls:

http://www1.acm.org/pubs/tog/GraphicsGems/gemsii/intersect/intsph.c

and Schwarze's quartic root finder:

http://www1.acm.org/pubs/tog/GraphicsGems/gems/Roots3And4.c


Eric

> > Does anyone have a fast Quartic solver? I'd like to pass the
> > coefficients and a pointer to 4 doubles and get back the number
> > of real roots and have the roots in the doubles of course.
> I "optimized" a "standard quartic solver" I found somewhere. I'll
let you
> know something as soon as I get home =)

Wasnt it from GGems? :)

Afaik the two most used methods (RT-wise) are
1) some flavour of the general analytic quartic formula
2) root isolation through Sturm, and then some approximation steps a-
la Newton-Rhapson.
Both ways are imho pretty slow...

> > I looked at some a while back, but I wasn't terribly impressed
with
> > what I saw. I would still prefer a general quartic primitive, but
I
> > still haven't seen a great way to handle them.
> Me neither...

That´d be come handy, but would also obviously be a lot slower than
just exploiting the torus simmetry.
In the torus equation most terms vanish, especially when raytracing.
Throw in some projective geometry and you get a fast exact solution.

Anyway you can look at Numerical Recipes for polynomial root finding
(i.e. http://lib-www.lanl.gov/numerical/bookcpdf.html but be sure to
read the caveats at http://math.jpl.nasa.gov/nr/nr.html ).

Also Weisstein´s World of mathematics (http://mathworld.wolfram.com)
has come recently back online, so you can search for quartic
equation, root (lots of links here:
http://mathworld.wolfram.com/Root.html), newton-rhapson method, sturm
theorem, graeffe´s method...


\ Piero

>   Last night I was looking at the torus again. I've sketched out a nice
> way to do the intersection test and I'll be writing it up for general
> consumption soon. I represent the torus as its center point, a vector
> pointing through the middle, and the major and minor radius. This is
> simple to translate and rotate, but it doesn't stretch or skew. It also
> looks fairly simple to get the 4th order poly in t (that's the part
> I need to write up). So my question to you all is:

It's exactly what I'm doing in my rtrt engine =)
It works well.

> Does anyone have a fast Quartic solver? I'd like to pass the
> coefficients and a pointer to 4 doubles and get back the number
> of real roots and have the roots in the doubles of course.

I "optimized" a "standard quartic solver" I found somewhere. I'll let you
know something as soon as I get home =)

> I looked at some a while back, but I wasn't terribly impressed with
> what I saw. I would still prefer a general quartic primitive, but I
> still haven't seen a great way to handle them.

Me neither...

--
*********************************************************PaN!**
The information and opinions contained in this message do not
constitute an official position of Marco *PaN!* Foco and are
communicated by the some rebellious neurons in his name. This
message is not addressed to anyone in particular, but if you
think you're the intended recipient, then please inform the
sender (formerly Marco *PaN!* Foco) by replying to this e-mail.
**!Ngd*********************************************************

Hi,

   Last night I was looking at the torus again. I've sketched out a nice
way to do the intersection test and I'll be writing it up for general
consumption soon. I represent the torus as its center point, a vector
pointing through the middle, and the major and minor radius. This is
simple to translate and rotate, but it doesn't stretch or skew. It also
looks fairly simple to get the 4th order poly in t (that's the part
I need to write up). So my question to you all is:

Does anyone have a fast Quartic solver? I'd like to pass the
coefficients and a pointer to 4 doubles and get back the number
of real roots and have the roots in the doubles of course.

I looked at some a while back, but I wasn't terribly impressed with
what I saw. I would still prefer a general quartic primitive, but I
still haven't seen a great way to handle them.

Thanks,
--
<pre>
  ___   __   _   _  _
|   \ /  \ | | | || |       phkahler@...     Engineer/Programmer
|  _/| || || |_| || |__     " What makes someone care so much?
|_|  |_||_| \___/ |____)      for things another man can just ignore. " -S.H.

> Does anyone know if there has been research applicable to raytracing an
> animated character, for example?  Let's say you have a character with
> 50-100 joints and 1000-5000 triangles.  What is the best way to maintain a
> bounding hierarchy that effectively balances the cost of updating the
> hierarchy every frame and the cost of shooting rays at the hierarchy?  My
> guess is that raytraced movies have had to deal with this, though they
> might have just done a ton of preprocessing, since they always know what
> animation is to be played and where the character is moving.
>
> Also, there's the general question of handling triangle meshes -- are
> there special tricks for generating bounding hierarchies for a mesh, or do
> you just treat it as a big pile of individual triangles?

This is one of the reasons I chose an Octree. I don't analyze the entire
scene to build the tree. Some people subdivide the nodes if there are
more than one object inside. I just allow the object to determine which
nodes it will be in. Doing this mean that a node may contain objects AND
still have child nodes. The nice thing is that there is no need to rebuild
the whole tree when something moves. You still need to trim the tree back
if deleting an object creates an empty node, but that's OK.

In rtChess, the knight is made of 3000 triangles. Ray went ahead and used
them for the round base instead of making it CSG like the other bases :-)
It's hard to tell if the knight moves any slower than the other pieces
because drawing still takes much longer than updating the tree.
--
<pre>
  ___   __   _   _  _
|   \ /  \ | | | || |       phkahler@...     Engineer/Programmer
|  _/| || || |_| || |__     " What makes someone care so much?
|_|  |_||_| \___/ |____)      for things another man can just ignore. " -S.H.

>Does anyone know if there has been research applicable to raytracing an
>animated character, for example?  Let's say you have a character with
>50-100 joints and 1000-5000 triangles.  What is the best way to maintain a
>bounding hierarchy that effectively balances the cost of updating the
>hierarchy every frame and the cost of shooting rays at the hierarchy?  My
>guess is that raytraced movies have had to deal with this, though they
>might have just done a ton of preprocessing, since they always know what
>animation is to be played and where the character is moving.

You might check
http://www1.acm.org/pubs/tog/resources/RTNews/html/rtnv14n1.html#art3 and
the article after this one for some tidbits, if you haven't already done
so. Coming up with a good efficiency scheme for dynamic stuff is definitely
one of the challenges of RTRT.


>Also, there's the general question of handling triangle meshes -- are
>there special tricks for generating bounding hierarchies for a mesh, or do
>you just treat it as a big pile of individual triangles?

Yeah, I'd be interested in this, too. Grids around individual objects works
nicely, with each grid object then nested in a world grid or somesuch.
Steve Hollasch has an interesting scheme in which he does a rapid ray/mesh
intersection test: the basic idea is that he treats the ray as a plane at
first, and so can identify all vertices in a mesh as being above or below
the plane. Now you can look at each triangle: if its points are all to one
side or the other of the plane, toss it, else do the full test of it.
Steve: do you want to explain this better? (I've no doubt missed some
details). There's undoubtedly some break-even point where if the mesh is
huge enough a hierarchy is more worthwhile than this linear walk through
the triangles, but I don't have any sense of what such a point would be
(10? 100? 1000?).

Eric

I've been lurking for a while, reading through the archives while I've
been working on my realtime raytracer, but I just subscribed, so I thought
it's time to introduce myself.

I've been a videogame programmer for the past 5 years or so, and I've been
interested in raytracing off and on for the past 10-15 years.  I remember
about 10 years ago working out with a friend how long it would take before
we could do a simple, but fully-raytraced game on a PC (we extrapolated
from the time it took to render a simple spheres-and-checkerboard image on
my 486).  Well, now we're there, or nearly, at least.  I've been following
the papers from the University of Utah (where I got my M.S.) and Saarland,
and I was very pleased to be able to play with rtChess.

This inspired my to start working on my own RTRT -- I went out and bought
Peter Shirley's book "Realistic Raytracing" and set to work getting a
simple raytracer working (btw, I really liked how he laid out the design
of a raytracer in nice incremental steps without code).  After a few
nights of clean up and optimization, I now have a simple raytracer that
handles triangles and spheres, shadows and reflection (though no
refraction yet), has a simple non-automatic bounding sphere hierarchy, and
allows you to interactively fly the camera with mouse and keyboard around
a 100,000 sphere sphereflake at 100x100 getting between 4 and 14 frames
per second (I double up the pixels to get 200x200).

I still have quite a few features to add and of course quite a few
optimizations, but I had some questions.  First of all, realtime
raytracing is a subset of raytracing, but interactive raytracing is
a subset of that, and what I'm interested in is a further subset --
interactive raytracing with highly dynamic objects.  This of course means
that whenever I read the raytracing literature and they get all excited
about speed-ups based on heavy pre-processing, I probably can't really use
it. And even in the realtime raytracing literature, it seems a lot of
people are exploiting tricks that work great for static or nearly-static
scenes, but might be too costly if much is moving in the scene.

Does anyone know if there has been research applicable to raytracing an
animated character, for example?  Let's say you have a character with
50-100 joints and 1000-5000 triangles.  What is the best way to maintain a
bounding hierarchy that effectively balances the cost of updating the
hierarchy every frame and the cost of shooting rays at the hierarchy?  My
guess is that raytraced movies have had to deal with this, though they
might have just done a ton of preprocessing, since they always know what
animation is to be played and where the character is moving.

Also, there's the general question of handling triangle meshes -- are
there special tricks for generating bounding hierarchies for a mesh, or do
you just treat it as a big pile of individual triangles?

Thanks a lot for any pointers.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the realtime_raytracing
group.

   File        : /Demos/vaahto11.zip
   Uploaded by : wally@...
   Description : English version of Vaathoka from Assembly 2001

You can access this file at the URL

http://groups.yahoo.com/group/realtime_raytracing/files/Demos/vaahto11.zip

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

wally@...

> Frankly, I don't think that's it at all.  Rather, the simple reason
that
> commercial packages still include scanline support is that ray-
tracing the
> eye rays isn't in fact faster than a good scanline algorithm.
Obviously
> this depends on how good the ray-tracer is versus how good the
scanline
> algorithm is, but I think that the gap is pretty significant, if
you're
> comparing with a scanline algorithm that does good occlusion
culling, etc.

Hmm, it´s a lot simpler to write a basic raytracer than a full
scanline system with occlusion culling and so on...   on scenes
over only about 1M polys even unoptimized raytracers get already
pretty competitive.

Not that i´m denying the advantages of "advanced" scanline
algorithms, but honestly only relatively few renderers around seem to
have´m.

>Particularly when you need to sample a pixel area very well, e.g. in
order
>to get smooth motion blur or good anti-aliasing of fine geometry
(think
>hair), ray-tracing just doesn't make sense, efficiency-wise--tracing
>hundreds of rays per pixel just takes too much time.

Oh well, I was talking about the mass, how many renderers handle good
motionblur anyway? You can probably count them on one hand only,
two at the most...

For good antialiasing ofcourse noone wants to just blindly
supersample when raytracing...  there are many ways to get the job
done differently (see my next paper ;).

Scanline and eye raytracing can be thought kinda like inverse
mappings of eachother (world->pixel vs pixel->world approaches) and
many algorithms can therefore get "mapped" likewise from one setting
to the other (maybe one could even "map" to raytracing the
whole PRMan pipeline? i should look into this...).
And since raytracing is inherently simpler and more prone to low level
optimizations...
Maybe I´m a strong supporter of the KISS principle in graphics? :)

Sincerely
           Piero

Whooops, sorry for the huge delay! Work is eating all my free time...

> I hope you mean CPU bandwidth and not memory. When I was messing
with my
> crude terrains I found memory access not to be an issue. I went
from my
> old slow-cache Athlon to one with faster cache and saw no
improvement.
> Also, if the scene is stored reasonably coherently in memory I
could even
> let things swap with little impact on performance. Then again
performance
> is not very spectacular :-)

Well, dont have much experience about AMDs so i guess there you´re
right.
Anyway, improve some more your algos, eventually move to assembly and
it´s practically sure that you´ll start worrying about cache
issues.
On Intels this is already the case in C.

Still i got the most notable example with SSE, where one of my
triangle intersectors takes 60 clock cycles worst case when data is
in cache, 230 otherwise. This on a 650mhz PIII, and i guess on faster
cpus the gap would get even more dramatic...
(and NO, it´s not the plückerian test, that´d be also much
worse :)

> I used to think curved surfaces were really cool, but it's not easy
to flex
> and squish them. Triangle meshes are looking better all the time.
For
> static scene geometry you can just use more of them, since there is
little
> penalty for doing so (other than storage of course). I'm still not
> convinced about the best primitive - we're looking at something else
> actually. Just need to get the Chess game out the door first...

Hmm, in the end the main issue is memory
(atleast not to swap on big scenes if you forget cache :).
Not much can beat polygons on versatility, is there anything
comparable and more compact?

> BTW, if you hadn't noticed before, I AM fairly convinced that the
Octree
> is the best spatial index. I understand this is still open to
debate.

Octrees ofcourse have some advantages in terms of computations,
but on the other side clearly lose on the adaptation level.
It´d be interesting to have some analysis and statistics on the
latter point, to focus then on the actual algos only... but as
long as there arent many real scenes (i mean, actual
production+industry stuff) to use freely it´s all quite hard
to do openly.

> > But one side question... why do people keep including scanline
rendering in commercial packages when even with actual medium sized
scenes and unoptimized engines raytracing is faster?
> Because change takes time. First you have to convince people, THEN
they
> can change the software :-) Generally you must SHOW people in order
to
> convince them, which often involves showing them with their own
system.
> That means one of their own developers has to become convinced (on
their
> own of course) and have time to do a prototype to show management.
> There is also the "if it ain't broke, don't fix it" problem.

Whops, mine was just a provocation :)
Well, almost.
I mean, there are so many new renderers coming out *these days*, and
some of them keep including scanline rendering.
I can understand this in the cases where they have some clever
algorithms letting you take advantage of this setting on many sides
(as i guess is the Entropy case... are you using Reyes or something
similar Matt?), but sometimes it´s simply cause the raytracer is
even slower.

\ Piero

Hi,

   The first rev of rtChess is now available for playing. Surf over to
http://www.newimage.com/~rhk/rtchess

Windows and Linux versions are available.
Give us a little feedback. I'd like to hear what people think of our
approach to improving performance while rotating the board among
other things.

Thanks,
--
<pre>
  ___   __   _   _  _
|   \ /  \ | | | || |       phkahler@...     Engineer/Programmer
|  _/| || || |_| || |__     " What makes someone care so much?
|_|  |_||_| \___/ |____)      for things another man can just ignore. " -S.H.

Paul Kahler <phkahler@...> writes:
> > But one side question... why do people keep including scanline rendering
> > in commercial packages when even with actual medium sized scenes and
> > unoptimized engines raytracing is faster?
>
> Because change takes time. First you have to convince people, THEN they
> can change the software :-) Generally you must SHOW people in order to
> convince them, which often involves showing them with their own system.
> That means one of their own developers has to become convinced (on their
> own of course) and have time to do a prototype to show management.  There
> is also the "if it ain't broke, don't fix it" problem.

Frankly, I don't think that's it at all.  Rather, the simple reason that
commercial packages still include scanline support is that ray-tracing the
eye rays isn't in fact faster than a good scanline algorithm.  Obviously
this depends on how good the ray-tracer is versus how good the scanline
algorithm is, but I think that the gap is pretty significant, if you're
comparing with a scanline algorithm that does good occlusion culling, etc.

Particularly when you need to sample a pixel area very well, e.g. in order
to get smooth motion blur or good anti-aliasing of fine geometry (think
hair), ray-tracing just doesn't make sense, efficiency-wise--tracing
hundreds of rays per pixel just takes too much time.

-matt
--
Matt Pharr    |    Exluna, Inc.    |    <URL:http://graphics.stanford.edu/~mmp>
===============================================================================
We do more anti-aliasing before breakfast than most people do all day.

> Most of the material should be known to you all, except maybe ongoing research
presented by Tim Purcell of the SHARP ray tracing architecture, focusing on the
SMART memory chip being currently developed at Stanford.
> Promises are high, since the actual bottleneck for RTRT - bandwidth - shouldnt
be a problem on that hardware anymore.

I hope you mean CPU bandwidth and not memory. When I was messing with my
crude terrains I found memory access not to be an issue. I went from my
old slow-cache Athlon to one with faster cache and saw no improvement.
Also, if the scene is stored reasonably coherently in memory I could even
let things swap with little impact on performance. Then again performance
is not very spectacular :-)

> (hmm, not that i 100% like this, after all the research i´m doing on cache
issues :).
> We might end up again focusing on smarter traversal and intersection
algorithms (yeah, i believe there´s still space for improvements), wich should
be in some way more pleasing than having to face primarly hardware issues.

I have a good traversal algorithm, but it still has room for improvement.
So I agree, there is room for improvement.

> The annual raytracing roundtable sadly didnt bring much new stuff on the table
this year...
> some discussions on the best primitive to use, on reprojection methods, on the
future of RT and some tentatives to unveil Pixar stuff :)

I used to think curved surfaces were really cool, but it's not easy to flex
and squish them. Triangle meshes are looking better all the time. For
static scene geometry you can just use more of them, since there is little
penalty for doing so (other than storage of course). I'm still not
convinced about the best primitive - we're looking at something else
actually. Just need to get the Chess game out the door first...

BTW, if you hadn't noticed before, I AM fairly convinced that the Octree
is the best spatial index. I understand this is still open to debate.

> But one side question... why do people keep including scanline rendering in
commercial packages when even with actual medium sized scenes and unoptimized
engines raytracing is faster?

Because change takes time. First you have to convince people, THEN they
can change the software :-) Generally you must SHOW people in order to
convince them, which often involves showing them with their own system.
That means one of their own developers has to become convinced (on their
own of course) and have time to do a prototype to show management.
There is also the "if it ain't broke, don't fix it" problem.

Just my thoughts and rants.
--
<pre>
  ___   __   _   _  _
|   \ /  \ | | | || |       phkahler@...     Engineer/Programmer
|  _/| || || |_| || |__     " What makes someone care so much?
|_|  |_||_| \___/ |____)      for things another man can just ignore. " -S.H.

> > quite odd way losing spatial coherency. No smart caching nor else.
> > But if someone could enlighten me a bit; why are they doing that?
> > There must be a reason...
> For load balancing. In path tracing you have to bounce a ray off
the
> surface and if you're importance sampling the brdf you're not quite
> sure where it will end up and every surface could potentially
> interact with every other surface. Randomly splitting the database
> helps to distribute the scene geometry evenly over several PCs.

Hmm, ofcourse it gets balanced but as far as i can see this merely
makes all running processes as slow as the slowest one.
If you spatially subdivided youd still get the same amount of geometry
on each machine to trace, and get spatial coherency as a plus
bringing in no disadvantages.
This way it does also get traced faster in any case (and thus even in
the bottleneck slowest one) than by splitting randomly.

\ Piero

> Afair they just split the scene among the various pcs...   and in a
> quite odd way losing spatial coherency. No smart caching nor else.
> But if someone could enlighten me a bit; why are they doing that?
> There must be a reason...

For load balancing. In path tracing you have to bounce a ray off the
surface and if you're importance sampling the brdf you're not quite
sure where it will end up and every surface could potentially
interact with every other surface. Randomly splitting the database
helps to distribute the scene geometry evenly over several PCs.

The why is as I said before, to handle the case ('complex mode')
where the geometry doesn't fit into the memory of one PC. They also
have a mode (they call it 'simple mode') where it functions like a
regular path tracer if everything fits into the memory of one machine.

> I think the problem wasn't speed but getting the geometry or photon
> map to fit into the memory of a single machine. Their approach was
> interesting in that it could render scenes in which the database
> didn't fit in the memory of one machine.

Afair they just split the scene among the various pcs...   and in a
quite odd way losing spatial coherency. No smart caching nor else.
But if someone could enlighten me a bit; why are they doing that?
There must be a reason...

\Piero

I think the problem wasn't speed but getting the geometry or photon
map to fit into the memory of a single machine. Their approach was
interesting in that it could render scenes in which the database
didn't fit in the memory of one machine.

> The biggest delusion came imho from the Kilauea project (Square´s
renderer)...
> massively parallel but in the end getting practically average
single pc performances...
> and quite a clumsy architecture as i see it.

So well, Siggraph is over. What about this year?

Ofcourse of major interest to us was the Interactive RT course organized by
Slusallek and featuring also Parker, Pfister, Purcell and Reinhard.
Most of the material should be known to you all, except maybe ongoing research
presented by Tim Purcell of the SHARP ray tracing architecture, focusing on the
SMART memory chip being currently developed at Stanford.
Promises are high, since the actual bottleneck for RTRT - bandwidth - shouldnt
be a problem on that hardware anymore.
(hmm, not that i 100% like this, after all the research i´m doing on cache
issues :).
We might end up again focusing on smarter traversal and intersection algorithms
(yeah, i believe there´s still space for improvements), wich should be in some
way more pleasing than having to face primarly hardware issues.

The annual raytracing roundtable sadly didnt bring much new stuff on the table
this year...
some discussions on the best primitive to use, on reprojection methods, on the
future of RT and some tentatives to unveil Pixar stuff :)
(did i forget anything?)
Well, next year should be more interesting, after all there´s quite some
movement around now.

Also nice was the Monte Carlo methods course. Not exactly realtime, but... :)
Especially interesting was Pharr´s clear explaination of Metropolis. If you´re
just getting into the topic then better start from his notes than from the
original Veach paper.
And impressive as usual (16 paths per pixel without filtering sound scary to
me... ok scenes were nearly custom and images a bit noisy, but still...) was
Arnold, Fajardo´s renderer also outlined in the course.

The biggest delusion came imho from the Kilauea project (Square´s renderer)...
massively parallel but in the end getting practically average single pc
performances...
and quite a clumsy architecture as i see it.

Couldnt get the time to see Entropy, can anyone here say a word about it?

Anyway as usual the most stunning stuff was behind the scenes... a couple of
indipendent projects we´ll probably see at next siggraph should make the
realtime
global illumination dream much nearer...

But one side question... why do people keep including scanline rendering in
commercial packages when even with actual medium sized scenes and unoptimized
engines raytracing is faster?

Oh well, enough non-technical stuff for this month :)

\ Piero


--

_______________________________________________
Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free!
http://www.net2phone.com/cgi-bin/link.cgi?143