HW raytracing!

Thats cool, but it says on the gallery page that those images were generated using a pure software emulator.

In fact, this is from the page showing the soft shadow image..

quote:

---

Render time (software emulator): 5 hours, 51 minutes, 5.3 seconds

---

So not exactly realtime. Although if they could get that running on the actual HW in realtime that would be incredible.


[edited by - treething on December 22, 2003 7:36:47 AM]

>>So not exactly realtime. Although if they could
>>get that running on the actual HW in realtime
>>that would be incredible.

Well yeah... the speed difference between CPU and GPU rasterization is damn huge, so I hope the difference in ray tracing would be somewhat as huge.

I feel a little bit skeptical though, because the gallery page doesn''t show off "real world" rendering (read: triangles). Furthermore, it''s pretty much the same thing as with SaarCOR: great plans, but seeking for hardware manufacturers probably ain''t that simple. I don''t think it''s easy to implement HW ray tracing (compared to HW rasterizing), but there exists one real, commercial, HW raytracing card already (for offline purposes, though).

- Mikko Kauppila

The gallery pic is fully unoptomized. We also have a lower-quality render that is done with photon mapping in roughly 40 seconds. However, that time figure may change drastically as we refine the photon mapping process.

The gallery page is still very preliminary, and since we don''t have a professional artist, we''re going to be rendering simpler stuff for a while. However, I''m confident that once people see the power of procedural geometry we''ll start seeing a shift away from tesselated models. Procedural geometry is faster to render (since you don''t need thousands of polys to get good surface details), takes a lot less storage space, and is generally a lot nicer to work with. The CSG demos that we''re working on next will show a lot of the capabilities that come with procedural geometry.

We''ve got a very good plan of attack for dealing with the hardware, and our search for manufacturers is sort of back-burner right now until we polish off the global illumination features. Although "version 1" may not be doing fully realtime GI, we''re going to definitely be able to do realtime raytracing, meaning >30 FPS at 800x600. Parallelization and near-instant conditionals in hardware will make the rendering a lot faster; the software version has so many cache misses and mispredictions it isn''t funny. Of course, the emulator is not optimized for software at all; if we started using SIMD, or optimizing to fit into the cache, etc., we could probably quadruple the current speed with minimal effort. So I''m confident that hardware will be a fairly straightforward step once the time comes.


Anyways, I could spend all day rambling about my little baby, but work must be done

---

PiQ Software - Tiny KeyCounter - Freon 2/7 Raytracing Accelerator

Triangles are a bit wastefull ...but AFAICS developers of modeling packages aren''t usually very forthcoming with the algorithms they use for surface description and animation.

Yeah, looks good but I kinda agree with uutee, it''s hard to get excited about a bunch of spheres or a ring

We want more shots!!

Something like a house interior would be nice, that would show some true potential (or would that be prohibitive in the simulator?).

Sorry ApochPiQ, I have to disagree strongly.

If you look at the CG industry these days, it''s all triangle-based rendering, really. This fact won''t change even though procedural models would be faster. You might get nicely perfect spheres using procedural models, but how would you copy the Diana/David statues from Jensen''s book using procedural models? Not too easy I think. Also, if the geometry data comes from simulations, it''s most probably triangle-based (think cloth simulation, for example).

Of course there''s a slight toy factor in blobby modeling, but trust me, it''s not the way Serious World works.

Still, I think even procedural geometry would be a great achievement from the first real-time oriented ray tracing chip. Good luck!

uutee.. you forget something:
you''re only thinking of human created data.

real nature out there is about always procedural generated, even for movies. and then, there is no need to find a solution with triangles. grass, stone, wood, forest, water, all those don''t need any triangles to get displayed. of course today they get all mapped to triangularised solutions..

our world is highly procedural. because of the limit of most artistic packages, triangles are the only way to communicate, and interoperate..

but they are definitely not the only (and by far not the best) way to represent everything..

just think of volumetric data.. wich, in fact, all data really is:D

people worked out solutions to most problems (or approximations to the solutions), with triangles. doesn''t make the fact true that the world is not based on triangles. there is no reason to rely on them, making them the unit of the pc world.

without them, you can do much more.

architecture only needs primitives and higher order surfaces most the time.
nature needs prodecural geometry, good noise functions are essencial for it. recursive solutions can automagically add lod to trees and all.

triangles just got handy, and people are trained to them.. but they are by far not the best, or only solution, to the real world.

---

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

quote:

---

Original post by JuNC
Yeah, looks good but I kinda agree with uutee, it''s hard to get excited about a bunch of spheres or a ring

We want more shots!!

Something like a house interior would be nice, that would show some true potential (or would that be prohibitive in the simulator?).

---

well.. try to get soft shadows and caustics like those of the ring on a rasterizer....

Er.. that wasn''t quite the point I was making..

The point I was trying to make was that for realtime GI to be effective you''ll need to be able to render scenes of far more complexity than those shown in the shots. Of course it is understood that a hardware simulator is very likely far slower than a direct software implementation so it is understandable if highly complex scene demos are infeasible (Apoch please prove me wrong ).

This is something I''ve always wondered about. How much control do you have over these procedural generated objects? It just seems to me like you may be able to do a tree procedural, but are you able, without resorting to triangles, to add those little touches that gives models their pesonality?

dunghill.dk - desensitized homepage - desensitized project page

yes you are, as always..:D by finding a good way to expose your stuff..

a wellknown idea for example are displacement maps on top of procedural meshes..

other ways are possible. how do you do the same for polygonal meshes? they are just procedural as well, but you define each step of the "function".

---

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

Well, let''s be honest about triangles for a second. I think we all agree that there are much better ways of representing a surface. However, triangles are the norm right now. The important thing, though, is why they are the norm: because current algorithms are focused on making polygon rasterization faster, and hardware acceleration is, for all practical purposes, exclusively rasterizers. I think polygons are king right now because of the hardware, not because of any inherent virtue; and because of that, when better hardware arrives, polygons are bound to go away.

Its only a matter of time before someone comes up with a vastly better way of representing surfaces; in fact, I would bet a fair amount of cash that such a method already exists to some degree, but nobody has capitalized on it because polygons are king.

Our team currently does not include an artist, so we really can''t exploit procedural geometry to the degree that I''d like. I''ll be doing a scene for the gallery that is a simple room scene, which will show off some of our more potent features. However, it is still programmer art, and we all know what that means

Can procedural geometry represent real-world objects? Yes. I did some amateur raytracing art a few years ago (which got me into the whole raytracing scene to begin with, and got me interested in RTRT) and, if you have patience, you can do some amazing stuff. Granted, complex curves like a Corvette or a fighter jet are difficult if not impossible to do well with spheres and cylinders and such; but as polygons have proved to us already, the eye pays much more attention to good texturing and good lighting than perfectly realistic contours. Again, its just a matter of time before someone comes up with a good procedural model for surfaces, at which point we will be poised to implement it.

As for simulation speed... our engine is already an order of magnitude faster than any full-GI package that I know of. Again, complex demos aren''t really impossible; we just don''t have the talent to design the scenes at the moment. I''m fully confident in the engine''s capabilities, I just can''t prove them to you

---

PiQ Software - Tiny KeyCounter - Freon 2/7 Raytracing Accelerator

Well, in polygonal meshes you are free to move vertices around.
I see the neat aspect of procedural objects (infinte details, well perhaps not in practice. And low disk/ram use).
But I just don''t see how you define an object like, let''s say, a table with a broken leg unless you convert it to triangles and remove it youself (perhaps adding little splinters and such details). How would you go about this with procedural objects?

Maybe I''m just misunderstanding something fundamental.

dunghill.dk - desensitized homepage - desensitized project page

Define "broken leg"? A table is easy enough using surfaces of revolution to simulate wooden legs turned on a lathe, and the top can be done as a scaled cube or superquadric (rounded cube) for a rectangular table. To take off a chunk of a leg only requires some crafty CSG; to create the matching chunk that can be removed at will takes a bit more, but it can be done. Granted, you can''t do fully deformable geometry with it - but then, I''ve yet to see good deformable geometry in a polygon-based system, either.

---

PiQ Software - Tiny KeyCounter - Freon 2/7 Raytracing Accelerator

I think the term "procedural objects" can be extended to include displacment mapping (as davepermen mentioned) - this would allow greater control by the artist...and with a number of surfaces with displacment maps, you could generate any kind of model i think. This I think is where I the whole system would really shine.

Problem with this is that there is no 3d editor that allows easy manipulation of displacment maps (that I''m awear of). 3DS Max does support it - but last time i tried it out, it would only show the displacment map in action when you do a render, and not in the editor windows.

Anyone who has seen those Matrox Parhelia videos will agree that displacement maps surely are the future...
http://www.hardocp.com/article.html?art=Mjg4

ApochPiQ: Please have it so you can use displacment maps

Sadly displacement mapping is extremely difficult to do with raytracing, let alone doing it fast. If displacement mapping ever arrives on the scene, it will be in "version 2."

---

PiQ Software - Tiny KeyCounter - Freon 2/7 Raytracing Accelerator

>>Its only a matter of time before someone comes
>>up with a vastly better way of representing surfaces;
>>in fact, I would bet a fair amount of cash that such a
>>method already exists to some degree, but
>>nobody has capitalized on it because polygons
>>are king.

Remember that polygons are a very *general* kind of surface representation. This is very desirable property in computer programming. There are probably various other kinds of surface representations available, with their own pros and cons, but triangles can do it all without too bad an overhead.

Also, with triangles pretty much all problems come down to simple linear algebra, whereas with procedural models different operations can be a royal pain in the ass (I''m not talking about pure rendering).

And finally: a very common way of a raytracer to render high-order (even cubic) patches is to simply subdivide it to polygons (the exact analytical intersection formulas are either too hard or impossible to derive.)

All this said, I find it hard to say that the current reign of triangles is only due to inertia.

- Mikko Kauppila

I''m sure people said the same thing about the geocentric model of the universe, too...

However, it seems best to simply agree to disagree. I feel that tesselation in any form is a hideously ugly hack; eventually a better way will show up. We may be long dead before it happens, but it will appear nonetheless

---

PiQ Software - Tiny KeyCounter - Freon 2/7 Raytracing Accelerator

The kind of surfaces ye average RT raytracing demo coder wants to see get popular, those which can be analytically intersected, wont ever get popular for defining macro-scale shapes because they are by their very nature too restrictive for end users ... even CSG cannot help there (since it cannot help with curvature and continuity problems).

You could try approximating more usefull HOS's (from a modeling point of view) with such surfaces ... but it is so futile, in the end most stuff will have surface detail added anyway (with fur, or displacement mapping). I think the best (but restricted) use of simpler easily intersected surfaces is for very fine detail, such as segments of hair for instance (better a tube than a box).

BTW what is the use of a raytracer (hardware accelerated or not) which wont work (well) with scenes provided by existing modeling tools?

[edited by - PinkyAndThaBrain on December 24, 2003 4:28:25 AM]