Slashdot Mirror

Textured Quads are used for leaves because of polygon count.

The whole point of realtime ray tracing is that it scales with O(log(n)) instead of O(n) when it comes to polygons. Which means that you can and should model each leaf as fully polygon. That is actually done in quite a few other examples, such as the sunflower scene or that Boeing model, where every last screw is modeled and yes, ray tracing can handle those just fine.

Now there is of course a cavet, this scalability only works for static scenes and things become quite a bit more problematic when stuff is animated, but never the less the whole point of 'going ray tracing' is because presumably polygon counts are slowly get high enough that ray tracing just outruns rasterization.

I see your 1 million triangles and raise you 349 million more. (Disclaimer: I'm not affiliated with OpenRT, I just think this is a neat demonstration.)

Textures, verticies, and the like take up memory with ray tracing just like rasterization. There's a bit more flexibility with a ray tracer, though, to store non-triangular primitives. Most fast real-time ray tracers just use triangles, though.

As for acceleration structures, octrees have largely been superseded by kd-trees (preferably constructed using a surface-area heuristic), and more recently bounding interval hierarchies, which can be constructed much more quickly than kd-trees.

I think that is the realm of OpenRT instead.

OF course, there's an existing, vendor-neutral raytracing API that is like OpenGL, only for raytracing. Will microsoft implement it? Will they fuck.
http://www.openrt.de/gallery.php

Would a tree with a higher degree of branching would be more efficient? It would reduce the maximum depth of the tree, but would introduce more empty subspaces, so it would depend on whether it is faster to iterate over many empty child volumes of the same size versus descending down the tree at each step.

I was wondering the opposite; octrees have largely been superseded by kd-trees (basically, axis aligned binary space partition trees) for a lot of ray tracing tasks. I suppose the octree is convenient since you don't need to store an axis or offset, and you might be able to avoid a bit of math if all the voxels are perfect cubes. kd-trees can be stored pretty compactly, though. It's hard to know which is better without running benchmarks. By a higher degree of branching, do you mean like 27-branch (3x3x3) or 64-branch (4x4x4) nodes? There would be a lot of wasted space if most of those cells were empty.

And why do you think that is any different with raytracing? Model geometry is very similar and I doubt that you will understand the math behind BDRF (Bidirectional Reflectance Function, a way to describe surface characteristics) or scattering in participating media without some time to study it. In fact they are so similar that OpenRT is a raytracer with an interface quite similar to OpenGL. The shader system is completely different, though as it wouldn't make sense to limit it to GPU-shaders without hardware support.

Raytracer handle big geometry quite well, but if you think you can just throw everything in a naive way at them, you will get a bad surprise on the terrible speed. I don't see that modeling would be much easier, you don't have to model low poly (which is indeed hard), but because of the way raytracers work you often can't get away with a texture but need to have geometry. Also the textures are as muchwork, writing efficient shaders is not a lot different and the complete game logic is the same.

There is a project 'The OpenRT Real-Time Ray-Tracing Project' (not so much open despite name, but noncommercial code available) out there, and presumably Blender should be there soon.

CC.

Other problems I see with raytraced games are the exponential increase of processing with higher resolutions or higher light source counts, the fact that poor raytracing actually looks worse on higher resolutions, the increased production and programming costs and the fact that graphics companies will not like seeing the investments made in their current GPU architectures melt away.

Ray tracing is actually more efficient. With the scene in a proper data structure, ray tracing can be O(log n) for a scene with n objects. Raster graphics is almost always O(n), even with advanced game engines that only draw portions of the game world. Every possibly visible object is rendered into a depth buffer to compose the entire scene, but with ray tracing only the x*y rays need to be traced through a tree of objects and checked for intersections. The tradeoff in ray tracing speed is how many reflections, refractions, and light sources to accumulate. Some complex scenes may require hundreds or thousands of rays for a single pixel on the screen, but that's an absolute maximum given the resolution. It matters much less if the scene has thousands, millions, or billions of objects in it. Look at the stuff OpenRT has done with small (8 to 16 core) clusters of generic CPUs. Some of the demos are faster than GPUs for large scenes, while others do things rasterization just can't do, like the accurate real time simulation of a reflective headlight.

Raytracing has no advantage over rasterizing for opaque surfaces. Rasterizers are faster there, since their performance is not tied directly to the screen resolution. The advantages lie in refraction/reflection/shadows/translucency, which are painful to implement with rasterizers.

Actually, there's a big advantage. Raytracing is O(log n), but rasterization is O(n). OpenRT's demo of a 350 million triangle model of a Boeing rendered in real time on a single PC (without GPU support) is a good example. The entire model doesn't even fit in memory, so visible surfaces are cached. The result is still realtime (although only a few FPS) with incredible detail. Go slashdot the server and watch the movie. Modern raster based cards can only render that many triangles in a whole second with all their fancy hardware, if they're lucky.

8 cores is enough to do real time raytracing of moderately complex scenes. See OpenRT for examples and the systems they've used.

That's the most interesting part of the article for me. Apart from 3-D rendering and folding@home, they are really pushed to find any real-world reason for having 4 cores.

Just wait for real time raytracing. From what I've seen of OpenRT, it only takes about 8 cores to get photorealistic real time raytracing for complex models entirely with software. Combining that with the advanced shaders on the GPU should make for some very visually stunning games with perfect reflections, refractions, shadows, and surface properties.

Maybe if someone got an MP3 encoder working on one of these hot new chips, the more general purpose programmers would be delivering supercomputing to the desktop on these chips.

I'm still waiting for realtime raytracing GPUs.

GeForce 8800 release the first C-compiler environment for the GPU;

Is anyone working on a Ray-Tracing evuivalent of OpenGL?

Actually, yes: OpenRT. Some games which uses it can be found here, although nothing you can try at home unfortunately, only videos available for download.

Here's hoping OpenRT beats them to it.

Ray tracing also tends to do specular well, but isn't as good at diffuse

It's nice that people are working on ray traced games, but please note the following:

Oasen is based on "OpenRT" --- which is entirely proprietary, and is NOT open source. Their FAQ explains that clearly.

I'm sure that I'm not the only person annoyed at their use of "open" to mean "closed".

Time to look for an open-source raytracing engine designed for interative use ...

Source?

I'm not at all sure I buy that. I've never heard of "cone-tracing", but crude raytracing of simple-to-intermediate scenes at almost-realtime framerates is already possible on consumer hardware, and the factors when you start scaling up quality are, I thought, pretty well understood. Samples per pixel and number of "bounces"; both linear complexity.

There's certainly work to be done on improving realism, but it's mostly on the human stuff that we're very sensitive to, particularly hair modelling and subsurface scattering in skin. The general algos strike me as "good enough" already. Animation tends to be the weak link these days.

If you haven't taken a gander at it yet, you may want to take a look at OpenRT and projects using OpenRT such as Quake3 Raytraced. Also take a look at the hardware architecture as well.

Ray-tracing presents a much more detailed rendering of a scene, but was always considerably slower than rasterization. If hardware-accelerated ray-tracing architecture grows in the market, you may see your skyline beautifully rendered in real-time .. with traffic, crowds, etc.

From what I remember from my neural networks days the human brain/neocortex works so well because of its massively parallel nature (not because of the processing power of any one neuron), and that computers simply aren't able to exploit this as they aren't designed to work like this

Computers aren't *normally* designed like this. They can be however, and in recent years have been moving in that direction. When neural networks were first being researched, a Cray supercomputer was about the closest you could get to that sort of parallelism. Fast forward to today and we find that Intel (Pentium), AMD (AMD64), Sun (Sparc), and Sony (Emotion Chip) are all building machines that are highly parallel in nature.

Even more interesting is that today you can build yourself a custom, massively parallel computer on a shoestring budget. All you need is a handful of FPGAs, a PCB layout service like Pad2Pad, a few other parts, and reasonable VHDL or Verilog skills. That's more or less what OpenRT did to build their SaarCORE architecture. :-)

nVidia Gelato
Mental Ray taking advantage of OTS hardware
Dedicated raytracing hardware
Raytraced Quake 3
OpenRT realtime raytracing framework

I had a go some time back. The camera rays were pre-calculated. A bounding box was calculated for each triangle in image space. These were ordered by starting row and column. Lists of the possibly visible triangles were maintained as the image space was scanned. Groups of geometry had bounding spheres. I was getting around 15 seconds/frame.

However, there seem to be many open source real-time ray-tracing projects going on:

OpenRT, with it's own FAQ. This project seems to have several games written for it.

Rearview is another game-engine based on ray-tracing

There's also the Avalon Project. There was also an article discussing the use of SSE Instructions. The Source code to a demo is available at RAVI-Demo. Other projects include RealStorm.

It certainly seems to be an active area.

Raytracing is slower than scanline rendering. Period. No exceptions. If you can come up to an exception to this, I would love to see the renderer that can raytrace a scene faster than Blender could render it.

-jim

Check out OpenRT for, yes, real-time raytacing on computer clusters. They use a 64-CPU grid to raytace complex scenes at 15-30 fps. I have, in fact, personally seen it work (I used to study at that university).

Of course, people also already have photon mapping working on the most recent generations of NVIDIA and ATI hardware offerings, and I think I recall someone from NVIDIA saying at some point that they expected this to be able to work at interactive framerates sometime during the NV4x cycle of GPUs.