Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by ClusterGL Team, posted on October 07, 2001

Image Description, by ClusterGL Team

ClusterGL is a Real Time Ray Tracing library with an OpenGL like API, developed at University Of Salerno by Rosario De Chiara and Ugo Erra.

The CPU power needed to obtain real time performance with an computationally heavy algorithm such as real time, is provided by a cluster made up six PCs (PIII 650Mhz) on a 1.28Gbit LAN(Myrinet) under Linux.

ClusterGL uses the SEADS (Spatially Enumerated Auxiliary Data Structure) to speed up the ray-triangle intersection and obtain a load balancing among the nodes. ClusterGL can manage shaded, mirrored, trasparent triangles and colored light.

In ClusterGL is implemented a subset of OpenGL commands that permits fast traslations for simple OpenGL sources. ClusterGL is full CPU power no 3d accellerator needed.

More to come:
  • Texture mapping
  • etc...
  • Contact address:
    Rosario De Chiara
    Ugo Erra
    ClusterGL Team

    Image of the Day Gallery


    Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
    Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

    October 07, 2001, 10:51 AM

    Yeah! More 3d-shots!!!

    (being sarcastic)



    October 07, 2001, 11:33 AM

    Interesting comment...
    (being sarcastic)

    A question guys, in which way do you use the cluster to speed up rendering: each PC has it's own geometry or you subdivide the screen and asign a region to each pc?

    Seems that if you dubdivide the screen you may end with only 2 computers doing all de work while others only trace "a few rays", since all the geometry is concentrated in one part of the screen.

    Oscar Blasco


    October 07, 2001, 12:17 PM

    you need six PCs to raytrace 3 cubes in realtime?

    John van der Burg

    October 07, 2001, 12:25 PM

    Well, that is why for example Maya hierarchically subdivides the screen into little rects, and using some algo it determines where the most time consuming parts on the screen are. And when just splitting up the work into parts on the screen, you can then still let both computers do first parts on the screen where there is actual geometry.
    So that solves the problem you mentioned I think.

    - John


    October 07, 2001, 12:41 PM

    You can also break things up in a more "random" way, like by assigning every pixel with an odd y coordinate to one computer and every pixel with an even y coordinate to another. Most graphics cards do something like this in order to evenly distribute the load between their rasterizers.


    John van der Burg

    October 07, 2001, 12:50 PM

    Yeah, that's a cool idea too indeed.

    - John


    October 07, 2001, 01:02 PM

    Why don't you use Athlons to render instead of Pentiums?
    They are a lot faster and cheaper :)

    The images are cool though, but what will be the purpose of real time ray tracing WITHOUT a 3d accellerator?


    October 07, 2001, 01:06 PM

    Do you have plan to use the Geforce 3 programmable logic for raytracing ?



    October 07, 2001, 01:17 PM

    afaik there's no practical way to do raytracing in HW, not even with GF3..
    but hey..
    you should be able to trace that bareass simple scene on a single 400 mhz in realtime.. i can do that :)


    October 07, 2001, 01:19 PM

    Raytracing is a lot more efficient than normal DirectX or OpenGL Rendering (Can't remember the correct expression for that at the moment). I'm pretty sure the future lies in realtime Raytracing and designing an API for that is a very good idea and a step in the right direction :o)



    October 07, 2001, 01:27 PM

    One question I have is: how big are the images that are being raytraced in real-time? Times for raytracing are directly proportional to the size of the image. Another question is what's your definition of real-time? Several frames per second? 30 fps? 60 fps?

    NeoKenobi: raytracing is really purely mathematical and can't take advantage of a lot of features of 3d hardware such as scan-conversion and what not. Typically, raytracers are implemented without any support from special purpose hardware. There's also practically no coherency between rays cast for different pixels which makes it a trivially parallel task although there are issues to consider such as granularity when dividing up the image.

    I'm assuming that this is a fully functional raytracer and not the dumbed down versions that people claim are real-time raytracers. There's been work in the past on creating a parallel implementation of POVRay. Do you have any idea how your work compares to that implementation? Did you make your own special purpose message passing system or are you using something like PVM or MPI?

    Manuel Astudillo

    October 07, 2001, 01:28 PM

    Well, actually, you dont need to create a new API for raytracing, you could use OpenGL API or DirectX API to render raytracing, since the only difference lies in how you render the poligons, but the api could be the same.

    my two cents.



    October 07, 2001, 01:32 PM

    Thec, you're the smartest person I've ever known.
    (being sarcastic)

    Real-time Raytracing, that's catchy ;) But I doubt we'll see it in games anytime soon. Very cool though, good job.


    October 07, 2001, 01:53 PM

    What are you talking about? How do you do reflection/refractions in opengl? and what about perfect spheres?

    Manuel Astudillo

    October 07, 2001, 02:43 PM

    yes, well. Dont take me wrong. I mean that you OpenGL (for example) could use a raytracer to render the poligons. Of course you would need to add some extensions to take advantage of the things that you can do with raytracing. But, for example, in terms of API you already have things like gluSphere (), which could be used to define "perfect spheres". And for the reflecions you just need a few more parameters in the materials...


    Wim Libaers

    October 07, 2001, 03:52 PM

    Why use a raytracer for single triangles? I think that's pointless. The benefit of a raytracer is that you can use it on a whole scene and get things like shadows relatively easily.
    OpenGL, as an immediate-mode API, doesn't know about scenes. It has some state, which can be as limited as the framebuffer, some variables to determine how things should be rendered (the matrices, the shading,...), and enough memory to contain all data for just one primitive. Yes, I know that in practical implementations, you can get better performance by grouping primitives, but in principle enough room for one primitive is enough.
    OpenGL calls could be translated to scenes, by buffering all primitives into a scene and then raytracing that scene when some command is given. So you translate the scene internal to the program to simple graphics primitives, then translate those to a scene, and raytrace that. Seems like a waste to me.
    Of course, this could fail in some cases. For example, an OpenGL program that draws an infinite amount of random triangles can't work in such a system.


    October 07, 2001, 04:01 PM

    awesome... RTRT rules.

    can't wait for afrigraph (, ingo wald will show his system there (8m triangle scenes, realtime).


    October 07, 2001, 04:09 PM

    Not trying to rag on anyone, but I distinctly recall having MUCH more complex scenes running at frame rates of about 5-10 fps back in 1996 on a 486dx4/100 .. and I distinctly recall other people doing the same. You'd think with six p3/650s you could do a little more than a box and a plane..



    October 07, 2001, 04:20 PM

    ahem, just a point: doesn't having a subdivision scheme hurt performance in rtrt if you have such simple scenes (come on, i can *count* the triangles), because of the overhead? also the networking must be a huge overhead in such a small scene...

    i've implemented rtrt myself, and for such scenes it was not uncommon for me to get 15fps at 400x300 on my celeron2 750, so the acceleration structure and hardware supporting it might be slowing you down :)


    October 07, 2001, 04:25 PM

    Why should we discuss this topic now, the implementing of raytracing in games is years away.
    Unless Nvidia decides to implement something like that in their new hardware, raytracing is useless for games. By the way, there isn't much difference in the way the details of a scene rendered by a ray tracing engine or an api. What the new Nvidia hardware (Quadro) can do is just amazing!


    October 07, 2001, 04:30 PM

    btw, i've written an article about rtrt, available online here (i think it's valid, not just a shameless plug):


    October 07, 2001, 04:43 PM

    Extensions, of course. ;-)


    October 07, 2001, 04:51 PM

    i want hw accelerated fire before hw ray tracing ;)


    October 07, 2001, 06:48 PM

    Sorry if I offended anyone with my first post, what I really would like is more shots from gameboy advance, gameboy color, software rendering, new cool games there graphics isn't the prior thing, like the previous post befor this one etc.

    I'm amazed by the content of the post, but I think we shouldn't start to lift up the bar to high, I would still like to see some less advanced code do some funky stuff, preferably on another platform than the PC.

    I didn't mean to offend anyone, sorry.

    Albert "thec" Sandberg
    ICQ: 9901455,


    October 07, 2001, 07:11 PM



    October 07, 2001, 07:29 PM

    Just one little hint for those guys who are impressed by these simple scenes being rendered in realtime : Get "Heaven7" by Exceed and "Nature Suxx" & "Nature Still Suxx" by Foundation Against Nature (from the demoscene).

    Dean Harding

    October 07, 2001, 07:33 PM

    what I really would like is more shots from gameboy advance, gameboy color, software rendering, new cool games there graphics isn't the prior thing

    Dude, this is software rendering...

    Warren Marshall

    October 07, 2001, 08:26 PM

    Just a note: Something doesn't have to be the latest, greatest or even the best to be impressive.

    David Olsson

    October 07, 2001, 08:39 PM

    It's just have to be at bit funky.


    October 07, 2001, 10:45 PM

    You guys might be complaining about the scenes - but a couple of things - A) They are rendering all these at once. B) They are less hacky than most of the recent demos (A lot of them trace a fair bit of the time at the corners of 8x8 tiles etc). C) The final thing - these are all triangles (not faster primitives) and they are done using OGL commands.

    Not bad in my opinion.

    This thread contains 47 messages.
    First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.