raytracing vs rasterisation

[mirv]

Just starting a thread to discuss some more on raytracing vs rasterisation, now that OpenCL is available in some places (no doubt that ray tracers will benefit from OpenCL - quite a few were done using CUDA I hear).

So.....do people think ray tracing will replace traditional rasterisation (such as with OpenGL)?

I'm of the opinion: no, won't replace it. An approach combining the two would be more likely - ray tracing is very good at some things (lighting, shadow calculation, and some others that I can't think of at the moment), but is traditionally slower with soft shadows, and requires quite a bit of computational power (not very useful for mobile devices). I'm also not sure how well ray tracing handles particle systems.

[L33F3R]

not replace, work with? i hope so. If history serves as any indicator, computing power will increase.

[V!NCENT]

I believe ray tracing has the potential to replace OpenGL in the near future (3 years) for rendering 3D scenes, games and such. But OpenGL will remain for desktop compositing. That would be nice to have because dedicated GPU's on CPU's would be capable and responsive enough. The money that you saved from not buying a graphics card could be spend on a faster CPU that will increase overall system performance and responsiveness even more, reduces the energy bill and gives longer batterylife and less heat on laptops, removing the need to extra cooling, prolongs batterylife even more...

The future is full blown ray tracing, but we need a good implementation. I have been subsribed to Intels graphics research and read many papers about different aspects of ray tracing and everytime I sratch my head and think; what were thinking? It seems people with great inteligence but zero insightfulness are thrown at the problem and I think that I can do it at least 100 times better than every attempt that has been tried so far.

If you look at SourceForge there are countless ray tracing renderers without any kind of vision whatsoever and the closest thing that comes to a vision is the closed source, triangle rendering OpenRT.

Hybrid rendering is too complex to code, suffers from terrible synchronisation problems, can still only render triangles and only gets slower the mroe detailed the scene gets at zero benefit, except for some cool triangle cruved shadows... Sounds to me like a vision of the future that is totally not thought threw...

[mirv]

Hybridised rendering techniques definitely suffer from a lot of problems, that much is sure, and it's not at all clear that it would be worthwhile trying to overcome them. I did have interesting thoughts on replacing triangle representation with something else, but otherwise keeping the current rendering pipelines, but that kind of thing belongs as uni research papers or something (not something I have the time to look into).
The problems with ray tracing more or less comes down to raw computing power and memory limits, as far as I see it (I'll confess not having written a ray tracing engine myself - though I have written some physics ray-intersection stuff). So if enough computing power can be put together, and at reasonable power requirements, it might be feasible, but that still looks to be a (very) long way off.

[V!NCENT]

I did have interesting thoughts on replacing triangle representation with something else, but otherwise keeping the current rendering pipelines, but that kind of thing belongs as uni research papers or something (not something I have the time to look into).
Voxels?

So if enough computing power can be put together, and at reasonable power requirements, it might be feasible, but that still looks to be a (very) long way off.
Don't forget that raytracing scales really well. It takes 20 AMD 1800s to get playable framerates by replacing all effects in OpenGL 2.0 with ray tracing counterparts (OpenRT, "Quake 3 Ray Traced"). According to my own calculations based on Intel's roadmap we'll have that very power in 3 years. The latest Sun Sparcs are probably already capable of doing OpenRT at playable framerates (64 threads @ 2.6gHz)...

[rohcQaH]

sure, computing power increases. But assuming that we don't have anything better to do with that power than to do ray-tracing is absurd.

So in a few years, computers will finally be able to play Quake 3 with raytracing. Or play Crysis with traditional rendering. I wonder what'll look better.

[L33F3R]

The latest Sun Sparcs are probably already capable of doing OpenRT at playable framerates (64 threads @ 2.6gHz)...

why the hell are we using x86 cpu's anyways?!?! God damn we are linux users i say!

i say!
i say!

we should use whatever we damn well want! :D



On a side note. L33F3R predicts that ray tracing will become a big thing in the porn industry.

[nanonyme]

why the hell are we using x86 cpu's anyways?!?!Because we are cheap bastards who want CPU's with as high clock frequency as possible with the least cost?

[V!NCENT]

why the hell are we using x86 cpu's anyways?!?!
Solely because of Microsoft...
PS: Single thread execution is the fastest and most efficient on Intel x86 CPU's.

[mirv]

Voxels?

Not really voxels....

With the trend to programmable pipelines, I can see software renderers making a comeback. That would allow more than simply triangles to be processed, and perhaps even more of a "description" of objects than object data (think svg for images).

[RealNC]

why the hell are we using x86 cpu's anyways?!?!

Feel free to go spend 20 thousand bucks for a new desktop :D

[V!NCENT]

That would allow more than simply triangles to be processed, and perhaps even more of a "description" of objects than object data (think svg for images).
NURBS? I mean if you don't take that format then you'll just end up without a single modelling tool for your renderer/engine ;)
PS: Can't wait for the mathematical calculate intersect collision detection pr0n :D

[mirv]

NURBS? I mean if you don't take that format then you'll just end up without a single modelling tool for your renderer/engine ;)
PS: Can't wait for the mathematical calculate intersect collision detection pr0n :D

Basically, yes, but not exclusively. Professional modelling tools already do this kind of thing anyway, so it's not that far of a stretch to have geometry generation done in real time.

[V!NCENT]

Basically, yes, but not exclusively. Professional modelling tools already do this kind of thing anyway, so it's not that far of a stretch to have geometry generation done in real time.
Geometry generation! :D I thought about that too! Procedural though; give each objects some data and enhance it's surface.

For example: a wooden tabel
The wooden table has basic geometry and texture but then when a ray is about to hit the table some data linked to that model is read. In this case a 'carved surface'. So the surface of the table gets to become dynamicaly detailed, depending on how far away the camera is. This is my raytracing counterpart to light shaders and height maps.

This also reduces a lot of work for game developpers and time saving and simplicity is key to open source games because people tend to be less skilled and have less time.

The model will have additional data such as 'reflective', 'glass', etc so ray data can be modified (color correction, HDR, etc) and directions corrected.

This also adresses next-gen content because games seem to become more and more expensive over time because it requires more- and profesional artists.

The entire idea list doesn't end here at all! All the 'work' I am putting into it getting it all together in one picture. Code architecture in combination with threading needs to be perfect, extendible and also done in such a way that I can create a lot of dummy code so I can at least get some working stuff out of the door with not too much effort. This is to avoid vaporware nightmares and blocking the ability for future ideas like DMM (http://en.wikipedia.org/wiki/Digital_Molecular_Matter) for example. And dynamicaly add features when CPU power increases for more demanding stuff. When everything is in place and so abstract that it is future proof, then I will start the coding (vision? ;)). Untill then I will only code some simple tast cases while I learn to program for Haiku.

Yes; I will do this NASA style: http://www.fastcompany.com/node/28121/print
PS: found some cool video about realtime DDM: http://www.youtube.com/watch?v=YRMltf04rhs&feature=related

[L33F3R]

Feel free to go spend 20 thousand bucks for a new desktop :D

I was actually looking at the IBM z10 for my daily computing needs.

http://www-03.ibm.com/systems/z/hardware/z10bc/index.html

[curaga]

The thing is, there are a lot more linux users running those kinds of desktops than windows users (including tech-adept high end gamers). Yet, even 32-core x86 is nothing compared to the more exotic and expensive sets.

And on topic, good luck V!ncent on your goal. It sounds like something very nice so far.

[V!NCENT]

And on topic, good luck V!ncent on your goal. It sounds like something very nice so far.
Thanks :D Although it only exists on paper for now :P

Is there is anybody interested in joining the thinktank? :P Maybe setting up a wiki or something?

[mirv]

interested? yes.
time? no.
Sadly I've got about 1, maybe 2 hours a day to spend on hobby project programming, and they're already being used.

[Heiko]

Geometry generation! :D I thought about that too! Procedural though; give each objects some data and enhance it's surface.

For example: a wooden tabel
The wooden table has basic geometry and texture but then when a ray is about to hit the table some data linked to that model is read. In this case a 'carved surface'. So the surface of the table gets to become dynamicaly detailed, depending on how far away the camera is. This is my raytracing counterpart to light shaders and height maps.

This also reduces a lot of work for game developpers and time saving and simplicity is key to open source games because people tend to be less skilled and have less time.

The model will have additional data such as 'reflective', 'glass', etc so ray data can be modified (color correction, HDR, etc) and directions corrected.

This also adresses next-gen content because games seem to become more and more expensive over time because it requires more- and profesional artists.

The entire idea list doesn't end here at all! All the 'work' I am putting into it getting it all together in one picture. Code architecture in combination with threading needs to be perfect, extendible and also done in such a way that I can create a lot of dummy code so I can at least get some working stuff out of the door with not too much effort. This is to avoid vaporware nightmares and blocking the ability for future ideas like DMM (http://en.wikipedia.org/wiki/Digital_Molecular_Matter) for example. And dynamicaly add features when CPU power increases for more demanding stuff. When everything is in place and so abstract that it is future proof, then I will start the coding (vision? ;)). Untill then I will only code some simple tast cases while I learn to program for Haiku.

Yes; I will do this NASA style: http://www.fastcompany.com/node/28121/print
PS: found some cool video about realtime DDM: http://www.youtube.com/watch?v=YRMltf04rhs&feature=related

That sounds like it can be achieved with tesselation (found in DirectX 11 and also in a slightly different form on DirectX 10.1 cards from AMD), which provides dynamically detailed surfaces (possibly depending on the range to the object, or the power of the hardware).

I don't think pure ray tracing will replace rasterization. A hybrid will be much more feasible I guess. Why? Rasterization is basically using cheap tricks to let something look nice and shiny. Using cheap tricks will always be cheaper than using physically correct rasterization.

Even if todays rasterization effects can be achieved with hardware ray-tracing in three years: think about which effects can be achieved with rasterization at that point. My point is: for the next couple of years rasterization will always be ahead on ray-tracing because it just doesn't need that much computation power.

On the other hand you will see a trend that will go like this: the cheap tricks used in rasterization will grow ever more expansive to look good. There will probably be some point at which the advanced rasterization tricks will be equally expansive to compute as the ray-tracing. At that point it gets interesting to start using ray-tracing.

For some effects this turn over point will be reached earlier, for some it will be reached later. For others maybe it will never be reached. So... personally I expect we will see more hybrids in the coming years.

[V!NCENT]

Rasterization is basically using cheap tricks to let something look nice and shiny. Using cheap tricks will always be cheaper than using physically correct rasterization.
The advantage of raytracing is that it scales extremely well with cores up to the point that it will very soon surpass the power of traingle rendering on graphics cards. Raytracing is not only easyer and faster to code (less expensive in terms of money, time and required skill) but it also presents better graphics that surpass triangle rendering by far and graphics are insanely popular these days.

PS: Tesselation is repetitive and therefore boring. It also doesnt adress the problems of textures in the first place: lack of power to calculate surface detail.
PS2: Tesselation also comsumes more time to design stuff that could be better spend elsewhere

[movieman]

The advantage of raytracing is that it scales extremely well with cores up to the point that it will very soon surpass the power of traingle rendering on graphics cards.

I seem to remember that was going to happen 'very soon' for at least ten years now (just like we've been going to run out of oil in twenty years for about forty years).

Ray-tracing does little that rasterisation can't do much faster; so unless you really want to make a game based on mirrors and marble spheres, there's very little to gain.

[V!NCENT]

I seem to remember that was going to happen 'very soon' for at least ten years now (just like we've been going to run out of oil in twenty years for about forty years).
I get 3-6fps with a raytracing benchmark with global illumination and depth of field and all that stuff, running on one core on my AMD Phenom X4 9950 at 640x480. If it would take advantage of all 4 core I would get 12-24fps on my CPU. Now look at the Intel roadmap and in 3 years or so raytracing would be usefull at higher resolutions. Then double that in 3 years. I won't be getting a ray tracer out of the door tommorow so I plan to look ahead for about 3-6 years. It probably takes that long to make a good one for gaming so what better time to start now when I can test it?

Ray-tracing does little that rasterisation can't do much faster; so unless you really want to make a game based on mirrors and marble spheres, there's very little to gain.
Let's start with the geometry. Truly round objects, beautiful refraction of water and water has been a problem with gaming thus far, but now it can look good with the right geometry. Now look at games such as Crysis and MMO's where you get a massive slowdown if you have too many trees and models of players in a town where you spawn. There is a lot to be gained actually! It is a technical gain if the geometry itself allows for awesome collision detection and it paves way for easyer integration with stuf such as DMM just to name one out of the gazzilion other things that it could make possible.

Then the lightning... It could make Doom 3 look like a walk in the park during daytime :')

[mirv]

I think raytracing would be good for the geometry section, there's definitely a lot to be gained from that. If you think about it, the only reason triangles are used are because it is easy for calculations - all you want in the end is a 2D image of depth values (and other things, like normal values, etc) which you can pass along to the pixel stage. There's no reason other paradigms can't be used - ones more compatible with physics too, as an extra benefit.

Of course this is still mostly speculation on my part - it would definitely be worth seeing a proof-of-concept, and profiling it to see what kinds of areas are the real bottlenecks.

[movieman]

I get 3-6fps with a raytracing benchmark with global illumination and depth of field and all that stuff, running on one core on my AMD Phenom X4 9950 at 640x480.

And I get 30fps even in reasonably recent games at 1280x800 on my Pentium-4 with a 7800GS card.

Let's start with the geometry. Truly round objects, beautiful refraction of water and water has been a problem with gaming thus far, but now it can look good with the right geometry.

And how many 'truly round objects' are you going to have in your game? Looking around me here I can't see a single 'truly round object' in this room.

Note, of course, that there's no fundamental problem with rasterisation of spheres rather than triangles, there's just little need for it. Nor is there any fundamental problem with rasterising other forms of smooth curves.

Now look at games such as Crysis and MMO's where you get a massive slowdown if you have too many trees and models of players in a town where you spawn.

And how is ray-tracing magically going to improve that? Ray-tracing requires comparing rays for every single pixel against every single piece of geometry that it might intersect. While you can use optimisations such as bounding boxes to rapidly eliminate geometry that the ray can't hit, there is nothing about ray-tracing which will magically make it handle complex geometry faster than rasterisation... generally quite the opposite as you have to search for the objects the ray interacts with rather than simply rendering the objects whose bounding boxes are visible on the screen.

[V!NCENT]

And I get 30fps even in reasonably recent games at 1280x800 on my Pentium-4 with a 7800GS card.
You're avoiding my point. I show you why ray tracing will be fast enough (TM) very soon ;)

And how many 'truly round objects' are you going to have in your game? Looking around me here I can't see a single 'truly round object' in this room.
Isn't seawater curved? Raytracing doesn't limit itself to rendering footballs... PS: you have never heared of NURBS

Note, of course, that there's no fundamental problem with rasterisation of spheres rather than triangles, there's just little need for it. Nor is there any fundamental problem with rasterising other forms of smooth curves.
There is: every added triangle takes up more processing power. As objects get more and more detailed with every graphic update/generation. And it is just plain ugly; who the hell has a square looking head? (for example)

And how is ray-tracing magically going to improve that?
Once you have enough computing power to render a square room in a desired resolution, the level of detail doesn't matter geometry-wise; it's all going to render at the same speed.

Ray-tracing requires comparing rays for every single pixel against every single piece of geometry that it might intersect.
No. I plan to achieve better image quality with less rays. You are either trolling or you have a very limited, or stupid, understanding of ray tracing in general.

While you can use optimisations such as bounding boxes to rapidly eliminate geometry that the ray can't hit, there is nothing about ray-tracing which will magically make it handle complex geometry faster than rasterisation...
Let's render 1 million teapots in ray tracing Vs traingle rendering, shall we?

generally quite the opposite as you have to search for the objects the ray interacts with rather than simply rendering the objects whose bounding boxes are visible on the screen.
You have to 'search' objects with just as much as triangle rendering by means of the Z-buffer as you do with rays.

I'm (well maybe not so) sorry, but you have statements that are full of shit.

[mirv]

I'll chime in and say that lucy (from the stanford scanning archive) is an incredibly detailed model that would likely render better with raytracing, assuming your data structures are ok. The reason is simple: once you get get to very small triangles in terms of screen space (pixel, or sub-pixel size) then its triangles start to lose some of their speed benefits.
Of course, there are LOD techniques that can get around this, but similar techniques can be used with ray tracing. The real catch here is if you added skeletal animation and wanted the model to move around - static data is easy, animated not so much, and matrix transformations on triangle vertices are quick and easy.

[yogi_berra]

I'm (well maybe not so) sorry, but you have statements that are full of shit.

John Carmack was interviewed by PC Perspective last year after Intel released a white paper on real-time raytracing, his thoughts:

John Carmack: I have my own personal hobby horse in this race and have some fairly firm opinions on the way things are going right now. I think that ray tracing in the classical sense, of analytically intersecting rays with conventionally defined geometry, whether they be triangle meshes or higher order primitives, I’m not really bullish on that taking over for primary rendering tasks which is essentially what Intel is pushing. There are large advantages to rasterization from a performance standpoint and many of the things that they argue as far as using efficient culling technologies to be able to avoid referencing a lot of geometry, those are really bogus arguments because you could do similar things with occlusion queries and conditional renders with rasterization. Head to head rasterization is just a vastly more efficient use of whatever transistors you have available.interview here (http://www.pcper.com/article.php?aid=532&type=expert&pid=1)

You should be careful about buying into marketing hype, especially from companies that are trying desperately to remain relevant in the graphics business, like Intel.

[movieman]

You're avoiding my point. I show you why ray tracing will be fast enough (TM) very soon ;)

Ray tracing has been going to be 'fast enough' for at least ten years too.

Isn't seawater curved?

Yes, but it's not a perfect sphere. In fact, it's generally a very irregular surface which is typically better suited to triangle modeling than curves.

PS: you have never heared of NURBS

Yes, I have.

There is: every added triangle takes up more processing power.

Added _detail_ takes more power in both ray-tracing and rasterisation. Again, there's no reason whatsoever why you can't rasterise curved surfaces instead of triangles... AFAIR Nviidia's first 3D chip did just that but no-one was interested because triangles were much better suited to games of that era.

Once you have enough computing power to render a square room in a desired resolution, the level of detail doesn't matter geometry-wise; it's all going to render at the same speed.

You seem to be implying that you believe you can ray-trace a room full of billions of objects in the same time as you need to ray-trace a simple cube?

No. I plan to achieve better image quality with less rays.

Given that good-looking ray-tracing typically requires multiple rays per pixel, how exactly do you intend to improve the image quality using less rays?

Let's render 1 million teapots in ray tracing Vs traingle rendering, shall we?

I'm sure 'Teapot Apocalypse' will be a multi-million selling game.

I'm (well maybe not so) sorry, but you have statements that are full of shit.

Yet I spent more than a decade working in the 3D graphics business before I decided I wanted a change. How about you?

[Ex-Cyber]

AFAIR Nviidia's first 3D chip did just that but no-one was interested because triangles were much better suited to games of that era.I think the difference is that it was quadrilateral-based rather than triangle-based, which would explain why some Sega Saturn games were ported to it (Saturn's "VDP1" sprite/polygon chip is quadrilateral-based). As for why triangle-based rendering won out, I think it's just that filling triangles is just a simpler problem to solve generally. Quadrilaterals can be concave, while triangles can't. This means that a quadrilateral can have a non-contiguous fill region for a given fill line orientation. Some quadrilateral-based rendering algorithms will do interesting things in this situation.

[V!NCENT]

John Carmack was interviewed by PC Perspective last year after Intel released a white paper on real-time raytracing, his thoughts:
Raytracing is abstract. John Carmack is a genious who wants to put out engines that you can use now, and not in 5 years. Of course he doesn't think ray tracing is around the corner...

You should be careful about buying into marketing hype, especially from companies that are trying desperately to remain relevant in the graphics business, like Intel.
I read Intel's research papers and I was not impressed at all. I don't bite into marketing ;)

Ray tracing has been going to be 'fast enough' for at least ten years too.
That was because people thought the algorythms would be improved, but they were not. Results gathered from the past are no guarantee for the future.

Yes, but it's not a perfect sphere. In fact, it's generally a very irregular surface which is typically better suited to triangle modeling than curves.
Yes, that irregular surface is calculated with voxels/dots/whatever and then smoothed out. This is done is CUDA fluid simulations. Guess what NURBS can do?

Added _detail_ takes more power in both ray-tracing and rasterisation. Again, there's no reason whatsoever why you can't rasterise curved surfaces instead of triangles... AFAIR Nviidia's first 3D chip did just that but no-one was interested because triangles were much better suited to games of that era.
That era. You nailed it yourself. Ofcourse more detail eats more performance, but geometry rendering doesn't.

You seem to be implying that you believe you can ray-trace a room full of billions of objects in the same time as you need to ray-trace a simple cube?
I am talking about rendering geometry in raytracing so yes.

Given that good-looking ray-tracing typically requires multiple rays per pixel, how exactly do you intend to improve the image quality using less rays?
The same way the human eye works; scanline rendering. No not horizontal ofcourse; think of scanlines that spawn from the center of the screen to the outer edges of the screen. Once you have the picture, then do some kind of texture filtering while you rasterise it to a preffered resolution. You will get a lot detail in the centre, or wherever the focus is and less on the outer edges. This also adresses dept-of-field, looks good on native high-res resolutions and eliminates a lot of compute power needs.

I'm sure 'Teapot Apocalypse' will be a multi-million selling game.
You don't get the point... How about a complete forest with 3D modelled grass?


Yet I spent more than a decade working in the 3D graphics business before I decided I wanted a change. How about you?
I have zero experience and I already kick more ass than enyone else.

[mirv]

You don't get the point... How about a complete forest with 3D modelled grass?


Actually that's something rasterisation has problems with - nice looking grass, and leaves (do note that I haven't played crysis). Most engines simply have a a few quads with alpha-blended textures on there, but you can still see that it's just rows of textured quads.
Only I'm not sure how raytracing will improve it much. Dunno, it's just something I'd like to see improvement on (I do have some ideas, but none have panned out properly so far).

[V!NCENT]

Actually that's something rasterisation has problems with - nice looking grass, and leaves (do note that I haven't played crysis). Most engines simply have a a few quads with alpha-blended textures on there, but you can still see that it's just rows of textured quads.
That's the point; Crysis uses two triangle-textured grass and it stresses even the current graphics offering to its limits.

Only I'm not sure how raytracing will improve it much. Dunno, it's just something I'd like to see improvement on (I do have some ideas, but none have panned out properly so far).
Ray tracing will eventually reach a point that it's faster than triangle rendering. Allthough the shadow rays really eat into the calculation power of the CPU :P

But whatever... in three years this can be mixed with OpenCL and it won't be a problem... ;)

[yogi_berra]

Ray tracing will eventually reach a point that it's faster than triangle rendering.

No, it won't. Re-read the Carmack quote I posted earlier in the context of this statement of yours.

[V!NCENT]

No, it won't. Re-read the Carmack quote I posted earlier in the context of this statement of yours.
First of all ray tracing scales 1 on 1 with more cores. The only, and then I mean the only advantage of rasterization right now is parralell execution. And that is the only advantage of todays graphics cards, because serial execution on these cards is slow as hell compared to that of a CPU. That said, CPU's will get more power than a graphics card over time by getting more cores (derivative of Moore's law today that Intel is pushing), but the cores will also get more efficient over time.

Rasterization is slower, way slower, with softpipe rendering on a CPU than raytracing on a CPU. So what are we even talking about?

And that's on general purpose HW. Just wait untill there will be dedicated ray tracing cards. It will kick the shit out of rasterizing graphics cards.

Carmack is a genious, but (and here comes the teapot refference I made earlyer) if I would make a NURBS model with smooth surfaces and render it with raytracing than in order to get a pixel-perfect rasterization equivilent (geometry here) than that would take so much triangles that it clearly shows that raytracing is indeed much, much, much faster.

[mirv]

Well I'll have to disagree with software ray-tracing faster than software rasterisation (otherwise original software renderers would have been ray traced). Graphics were of course much simpler then, but the pixel shader step is extremely quick, and something that's also highly parallel.
There's also the issue of throwing cores at a problem only does so much good - practical issues such as cache synchronisation when updating data structures will slow things down.

[yogi_berra]

Rasterization is slower, way slower, with softpipe rendering on a CPU than raytracing on a CPU. So what are we even talking about?

If this were truly the case, the kitchen in the Pixar film Ratatouille would have used raytracing for the numerous reflections instead of brickmapping. The brickmapped (rasterized) reflections dropped render times remarkably, Pixar published papers about it, do some research on your own, you'll be surprised what you may learn :cool:

You do, however, need to rethink your position, namely because it appears as if you are making the assumption that rasterization techniques will suddenly stop being efficient once the perfect storm of CPU and GPU cores is reached.

[V!NCENT]

Well I'll have to disagree with software ray-tracing faster than software rasterisation (otherwise original software renderers would have been ray traced).
Back in the days that graphics card started going 3D the foundation had alreeady been layed out and improved because crappy rasterization was just fast enough to just run. That's why you have rasterization cards today instead of dedicated raytracing graphics cards.

Graphics were of course much simpler then, but the pixel shader step is extremely quick, and something that's also highly parallel.
That is surely a nice addition :D

There's also the issue of throwing cores at a problem only does so much good - practical issues such as cache synchronisation when updating data structures will slow things down.
Parallelization is needed to have decent rendering speeds and te rendering only reads out the data and then puts it into the framebuffer and not a single synchronization is needed. That is the entire point ;)

If this were truly the case, the kitchen in the Pixar film Ratatouille would have used raytracing for the numerous reflections instead of brickmapping. The brickmapped (rasterized) reflections dropped render times remarkably, Pixar published papers about it, do some research on your own, you'll be surprised what you may learn :cool:
Then tell me why the FPS of Quake 3 over softpipe rendering is slower than a ray tracing benchmark? Do the calculations and see for yourself. And the research? ROFL. Even my grandmother could figure out that degrading image quality takes less computational costs.

You do, however, need to rethink your position, namely because it appears as if you are making the assumption that rasterization techniques will suddenly stop being efficient once the perfect storm of CPU and GPU cores is reached.
If you have read the entire thread that you would have known by now that Raytracing can get better graphics at less additional computational costs.

[yogi_berra]

If you have read the entire thread that you would have known by now that Raytracing can get better graphics at less additional computational costs.

No, however, reading the entire thread does tell me that you have no experience in graphics and rather than relying on firm data, you prefer to resort to playground tactics to silence people that disagree with you. :cool:

[V!NCENT]

No, however, reading the entire thread does tell me that you have no experience in graphics and rather than relying on firm data, [...]
Data = information = IT = information technology = programming
So uhh... what is your point? :S

[...] you prefer to resort to playground tactics to silence people that disagree with you. :cool:
Playground tactics? I have responded with constructive arguments to points and problems raised/that have been made and if I have been playing around these issues than when somebody asked to give constructive arguments isntead of just saying "You are wrong" than I have done that.

[Wingfeather]

VINCENT,

It is uncommon to come across someone who is so, errr... sure of himself, as to think they can singlehandedly best the efforts of an entire well-funded research community. I must say, in this day and age, it's not likely to happen. However, perhaps you have some solid insight; I don't work in computer graphics so I'm not qualified to comment. What I do know from my own community is that first-order logical arguments aren't going to convince anyone - you need something which works and can be measured.

Given the situation, I think you're likely to find there are hurdles blocking your approaches or which nullify any perceived advantages. Do be sure you have a solid foundation on which to base your work.

[V!NCENT]

VINCENT,

It is uncommon to come across someone who is so, errr... sure of himself, as to think they can singlehandedly best the efforts of an entire well-funded research community.
There have not been any serious efforts in realtime interactive raytracing, yet. Funds don't say anything: look at Microsoft. Nobody/no company has more money than Microsoft and yet Windows is the most sucking series of operating series ever made.

I must say, in this day and age, it's not likely to happen. However, perhaps you have some solid insight; I don't work in computer graphics so I'm not qualified to comment.
Everybody that is able to use his own brain is qualified to comment. The rest just quotes other people.

What I do know from my own community is that first-order logical arguments aren't going to convince anyone - you need something which works and can be measured.
A project is as good as the planning. Like I said before; I need to work this out to the most minute detail before I will even start to write a single line of code.

Given the situation, I think you're likely to find there are hurdles blocking your approaches or which nullify any perceived advantages. Do be sure you have a solid foundation on which to base your work.
That is my plan. Software is abstract and, well, it's just math and planning ;) Haiku is a fast and multithreaded OS so... It shouldn't be a problem. Read the link I posted a few posts back where I said "Yes, I will do this NASA style:" and see why it will be a viable and smart approach. The problems I will encounter will be during thge planning ;)

[mirv]

With synching, there's no issue with reading the data, as much as writing it. Changes will need to be made to the data structures to move objects around, otherwise you basically have a completely static environment. Having many cores sharing the same memory will introduce locking issues, cache misses, etc, that will slow things down.

[V!NCENT]

With synching, there's no issue with reading the data, as much as writing it. Changes will need to be made to the data structures to move objects around, otherwise you basically have a completely static environment. Having many cores sharing the same memory will introduce locking issues, cache misses, etc, that will slow things down.
This is indeed one of the problems I encountered earlyer on. The rendering will be done on static data that is read out from a simulation every time a frame has been rendered. Not a single piece of syncing will ever need to be done ;)

PS: The threads will lock in the favor of the simulation. The rendering is just a presentation of what happens.

[mirv]

Hmm, perhaps you're misunderstanding me - if you have shared data across multiple cores, you will have some synching as any changes that take place to your main data set will have to be updated across caches.
Of course this is a problem for any system, but it's already a situation that current multi-threaded engines must deal with for performance issues. Just pointing out that more cores will only go so far.

[V!NCENT]

Hmm, perhaps you're misunderstanding me - if you have shared data across multiple cores, you will have some synching as any changes that take place to your main data set will have to be updated across caches.
Of course this is a problem for any system, but it's already a situation that current multi-threaded engines must deal with for performance issues. Just pointing out that more cores will only go so far.
Ehm... okey let me explain it this way:

Image 1 in RAM:
Simulation with one or more threads and OpenCL kernels. (not yet figured out how that works exactly. This needs some thinking. Streaming from HDD/SDD possible.

Image 2 in RAM: copy of data that needs to be accessed for rendering. This data is only read out and not updated. Multiple cores are handeling the ray calculations.

Simulation (image 1) -> calculate the needed data -> copy image2 -> rendering without syncing -> go back to calculate needed data while copying to framebuffer
PS2: This will create some latency (xD) but computers get faster too and especially in a few years this won't be a problem at all.

Does this makes a little more sense? ;) Do you understand now why rendering get's to benifit from multiple cores and scales really well? :) PS: doubeling the amount of cores will cut the rendering time literally in half, not taking into account serially reading the RAM ofcourse :P

[mirv]

Oh yes, using a two-step approach works for most things out there, but even with a copy of the working data that's updated when things are written (this is one approach some people take), changes must be made. Sometimes you have to wait for those changes to be propagated - as I've mentioned this is already an issue - and throwing more cores at it will actually slow the system down as the memory copying becomes the bottleneck.
Of course this affects not only graphics, but also a.i, physics, etc. Reading isn't the issue - writing, however, is.

[V!NCENT]

Oh yes, using a two-step approach works for most things out there, but even with a copy of the working data that's updated when things are written (this is one approach some people take), changes must be made. Sometimes you have to wait for those changes to be propagated - as I've mentioned this is already an issue - and throwing more cores at it will actually slow the system down as the memory copying becomes the bottleneck.
Of course this affects not only graphics, but also a.i, physics, etc. Reading isn't the issue - writing, however, is.
Well there is a simple solution for this, but I want to avoid this at all costs. I could simply make the simulation 'not so simulated' by making it frame based. This is done in Doom 3 with the id Tech 3 engine; if you get more than 60FPS you will not really see it because the physics engine is limited at 60FPS. That is ofcourse not acceptable.

And on top of the thread problem there is another one just like it: netcode for multiplaying.

I think the thread that wil do the moving of objects must also copy at sort of the same time. This removes the problem almost entirely but not completely. There are some solutions in my head, but this will need some thinking...

Update: I think I have solved the problem entirely without doing framebased stuff and locking. Yes it's absolutely 100% totally epic, but I have to work it out first and I'll post it as soon as it's completed :D

[V!NCENT]

Fixed, finallly :rolleyes:

There is always more than one object in a scene to render. Rendering one object will have serial execution ofcourse, but the performance gain with multiple cores lies in rendering more than one object.

Thread locking is not an option (performance loss to the max) and sceduling threads isn't an option either (also performance loss). But what about locking object data instead?

Object data itself doesn't need to be altered. DMM just copies the objects, does some calculations and then fragmentates the copied data and defragmentates it back into multiple objects. The same sort of modifiying goes for animations too, but that's a different area. That said, I can easily split (not copy) the data into two segments: The object data itself and it's position.

The position (coördinates) data can be stored in arrays. Each non-static object position array wil be put in a que. For convieniance I will call the thread that modifies the coördinate data write_thread and call the copy thread simply copy_thread here.

The write_thread will serialy update the que from the bottom up and the copy_thread will serialy read out the que from the top to bottom. That way they will only 'collide' once per frame rendered on avarage and not constantly. The more non-static objects we have, the tinyer the performance penalty will be percentage-wise per the total amound of non-static objects.

There will be 2 bits reserved in each object position data array. Each of these two bits can hold a value of either a 1 or a 0.

For each to be modified array, the write thread will make the first bit hold a value of 1 and make the second bit hold a value of 0. The first bit holding a value of 1 indicates that the array is now going to be modified by the write_thread. If the array has been modified it then the write_thread will make the second bit hold a value of 1.

The copy_thread will read out each array and if the first bit holds a value of 0 then it will read out the array. After reading it out it will check the first bit again to make sure the write_thread wasn't modifying the array that the read-thread had just read out after the copy_thread had already read out the first bit. If the first bit still holds a value of 0 then the copy_thread will copy over the data it had just read out to the rendering buffer.

If the copy_thread is done reading out an array and finds that the first bit holds a value of 1 then it will check if the second bit holds a value of 1. If the second bit indeed holds a value of 1 then the copy_thread will make the first bit hold a value of 0 and start over the process of reading the array just like it would if it hadn't already read out the array. But... (see below)

If, after the copy_thread has read out an array, the copy_thread finds that the first bit holds a value of 1 but the second bit in the array holds a value of 0, then the copy_thread will jump to it's next to be read out array and starts the read process again. Once that read process is done and the copy_thread has read out the next array in the que it will jump back to the array that it had just skipped and start the read process from there again. After that has been done the copy_thread will skip the next array in the que, because it has allready read that one out.

But... what if there are not enough to be modified arrays and the copy_thread will constantly find itself to be blocked by the write_thread? I got a solution for that too: big, fat, muthafscking serialisation by means of thread locking. That isn't going to be a problem because the amount of FPS will not really differ with the added latency compared to data locking with a huge number of to be modified arrays. But switching dynamically between thread locking and data locking is another topic that can be solved easily...

Phew... what a bunch of text :)

EDIT: I squashed my first bug :)
PS: There's another inefficiency I can see... Will clear that up later, but you get the point...

[mirv]

I recommend you write some mock programs and run tests on them to see where bottlenecks lie. Reading and writing have different performances. Also, run comparison tests - you may find that the necessity of locking the "check bits" (it's quite likely that this will be required) all the time may well not be worth it.
Basically, make some mock ups before you try go too far with anything.

[V!NCENT]

I recommend you write some mock programs and run tests on them to see where bottlenecks lie. Reading and writing have different performances. Also, run comparison tests - you may find that the necessity of locking the "check bits" (it's quite likely that this will be required) all the time may well not be worth it.
Basically, make some mock ups before you try go too far with anything.
Yes :( In my first design I had two bits in arrays. The first one belonged to the write_thread and the second bit belonged to the copy_thread. and so If first bit = 0 then second bit = 1 and have them go past each other and come back later. But the problems with this was ofcourse: what if the first bit = 0 and then the write_thread reads out that the second bit = 0 and then after that they both go over the same array afterwards. That bug screwed up a large part of the performance gain...

Also: if this is going to be cross architecture and all, there is a second problem: RAM may be acting completely different with different types of RAM and acrhitecture. So it had come down to: I'm fscked; the design by itself needed to be waterproof :(

But still: letting the write_thread do the first part of the list and letting the copy_thread do the second half and then switch when they are done also sucks.

The third option is contstantly locking the copy_thread whenever the write_thread is modifying sucks the most. That is serialisation to the max + added latency.

Yes you are absolutely right with test cases. Maybe thread sceduling and syncing might be faster. Who knows? RAM technology sucks :') I am sinply missing the ability to lock data by design so I have to come up with an expensive software workaround by myself :(

[Svartalf]

Feel free to go spend 20 thousand bucks for a new desktop :D

If you're not gaming/compiling/massive number crunching, you can get a new NON-X86 desktop for a whoppin' $149: The Beagleboard (http://www.beagleboard.org) does it pretty well with an ARM Cortex-A8, which does as well as the eeePC does, but does it with vastly less juice.

[Svartalf]

No, it won't. Re-read the Carmack quote I posted earlier in the context of this statement of yours.

While John's a sharp cookie- he's not the final say on things like this.

He's got good observations, ones that should be listened to and counted into one's evaluation of things.

Unfortunately, one of the go-to guys on the subject, one that has worked for John in the past, worked with RAD on producing their Pixomatic library (Used as the software renderer for UT2k4 and reproduces a DX7 card completely in software...), and now Intel, one Michael Abrash, has a differing position and opinion on the subject.

I'm on the fence, the truth be known, on the subject myself. I know what John's saying there- and it's good and valid. But I also know Abrash is one of the brightest of the bright on the subject in question- and what he wrote is equally good and valid. There IS a threshold where it will be more useful to do software rasterization and ray trace for rendering a scene- and we may be right at that point in time or real close to it now.

[V!NCENT]

Unfortunately, one of the go-to guys on the subject, one that has worked for John in the past, worked with RAD on producing their Pixomatic library (Used as the software renderer for UT2k4 and reproduces a DX7 card completely in software...), and now Intel, one Michael Abrash, has a differing position and opinion on the subject.
I immediately fired up UT2k4 to check this out. I was hugely dissapointed by the image quality. Because he did not use texture filtering! The image quality get's resized every now and then but realtime texture filtering doesn't happen.

I was impressed though by the achievement overall... But nevertheless dissapointing... It's like: Okey we can handle the signals and draw something but don't expect the same quality that you get by far from a dedicated Direct3D 7.x card...

PS: What's up with the 800x600 resolution lock? I have a kickass AMD Phenom 9950 x4, and I am more than able to run the pixomatic rendering with hugely playable framerates but it sucks on my 22 inch widescreen.

[mirv]

ut2k4 is relatively old now, and the software renderer was intended for much older systems - I don't think they had the same performance and image quality expectations for it.

[V!NCENT]

ut2k4 is relatively old now, and the software renderer was intended for much older systems - I don't think they had the same performance and image quality expectations for it.
I was expacting the same texture filtering quality from the OpenGL rendered Quake 2 engine. It turned out to not have any texture filtering at all, although it is said that pixomatic can even run trilinair filtering... But the most important thing is that one can run UT2k4 with accaptable image quality without a graphics card. The only realy critisism I have is the 800x600 resolution lock.

But for everything else the pixomatic renderer kicks ass! ^^,

Are there any other games around that I can try out that use pixomatic 2 and 3?

PS: I mean version 3 only because that version is an implementation of a Direct3D 9.x card.