#### Archived

This topic is now archived and is closed to further replies.

# Ray Tracing in the future?

This topic is 5029 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

In the coming years, say 5 to 10 years, will ray tracing become the prominent rendering method as opposed to polygonal rendering? With CPU speeds taking leaps and bounds, could it be in the next couple of years? Or will hardware based GPU polygonal rendering continue to be the main rendering method? I am doing a speech on Ray Tracing in the next coming weeks, and if it will become wide spread. Im just wondering what the experts think about this. What is the future of ray tracing?

##### Share on other sites
yes. it will.

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

##### Share on other sites
Speaking as one who is very qualified to comment on such matters, yes, raytracing will be the graphics rendering method of the future - specifically, realtime photon mapping.

There have been a lot of discussions about this topic here on GDnet; some of the better ones can be found here and here. There''s also a bit on radiosity here, which includes a sometimes less-than-civil debate on how raytracing is better than radiosity.

Enjoy

##### Share on other sites
Take a look at the Realstorm Raytracer. It''s a realtime-raytracer demo. Just take a look at the site, and try out their demo.

My machine (XP2800+,1GB-DDR333) gets an average of 2.8 fps at a resolution of 640x360. Not quite usable for games or other applications just yet. Even more so, if you take into account that most games also need things like physics and ai, which require their share of cpu power.

Then take a look at one of nvidia''s current demos like Last Chance Gas. If you don''t own a GF-FX take a look at the video they provide.

My idea is that cards like the Radeon or GeForce will slowly adobt more and more features only found in raytracers a few years before, increasing the visual realism to a level where you can''t distinguish between raytracing and realtime rendering.

Also, why should you let all the processing power included in such cards go to waste and return to cpu-only dependand raytracers? I don''t think processor speed will take such a leap that it can do the same demo in 1024x768 @ >100 fps in the near future. And even if, GPUs will have developed too, providing visual results close to that of a raytracer and freeing up cpu cycles that can go towards more realistic physics for example.

##### Share on other sites
Don''t get too excited just yet, though. I''m pretty sure the hybrid approach will remain far more usable than plain raytracing for quite a while.

- JQ

##### Share on other sites
quote:
Original post by Wildfire
Also, why should you let all the processing power included in such cards go to waste and return to cpu-only dependand raytracers? I don't think processor speed will take such a leap that it can do the same demo in 1024x768 @ >100 fps in the near future.

*hint* Hardware raytracing */hint*

SaarCOR

I dunno how long it will take, but I'm pretty sure HW raytracers will surpass rasterisers at some point

[edited by - Eternal on November 17, 2003 4:43:18 AM]

[edited by - Eternal on November 17, 2003 4:44:12 AM]

##### Share on other sites
quote:
Original post by Eternal
*hint* Hardware raytracing */hint*

That's what I was actually trying to get at with the paragraph above that

quote:

My idea is that cards like the Radeon or GeForce will slowly adobt more and more features only found in raytracers a few years before, increasing the visual realism to a level where you can't distinguish between raytracing and realtime rendering.

Of course, I'll take a while before you see that Or maybe not I just doubt that we'll go back to single cpu solutions as opposed to cpu/gpu solutions very soon. I think neither Ati nor nVidia want to go out of bussiness and thus will keep improving their cards, in whatever direction will give better visual results then any software raytracer can do in realtime at the same framerate and resolution.

//edit: My messing is spelled up. Me tired. %|

// edit2: I forgot to mention: The above benchmark results are with radiosity and depth of field disabled. I never had the patience to run the demo with that because it slows down things at least by a factor of 10.

[edited by - Wildfire on November 17, 2003 5:09:45 AM]

##### Share on other sites
Id say about 5 years after the likes of Pixar and PDI stop using rasterization as their primary method of rendering seems a reasonable guess (so 5-10 sounds about right).

Wether it will be done on CPUs or GPUs depends on where the market for PCs is going. CPUs designed primarily to run legacy code are lame ducks compared to more parallel designs such as GPUs (even with huge process and R&D advantages). If the mainstream CPUs start being designed primarily for parallel processing and for legacy processing second then maybe the GPU tasks can be reintegrated with the CPU.

Sony is moving their console in that direction with Cell, but PCs are not at the moment.

##### Share on other sites
I won''t be surprised if raytracing becomes the way of realtime graphics in the future.

I remember Yu Suzuki wanting to use raytracing to fully experience Shenmue on the Dreamcast. But as he said, at that time, this was not possible. But i doubt it will replace rasterization in the next 5-10 years.

##### Share on other sites
WildFire: you should get much bether results actually, i think.

WildFire: the nvidia demo is just a plain hack. there is nothing real usable about it. i hope you know that. (guess why the file is that big..)

PinkyAndThaBrain: rasterization stopped to be the single way to render for Pixar and friends yet quite a while ago. Ice Age was the first full-raytraced movie.

WildFire/Pinky and all others: RealStorm performs very bad on pentiums, as its really not written for it. so we can''t see if hyperthreading could help. but if you read about the future of cpu''s, you know that amd''s next plans, k9, are planned to be in 2-3 years. the main difference to now will ONLY be that those k9 are just like k8 (athlon64, opteron), but several of them in one chip. up to 32 they plan. similar to hyperthreading, but more split => more behaving like real 32 parallel cpu''s.

intel plans the same. hyperthreading gets extended to "real dual cpu in a chip". and it gets extended to 4, 8, ... cpu''s in a chip. this is all plans of the next some years..

and realstorm normally performs much bether than what WildFire reports actually. you sound more like a 2000+ system. i''m still waiting for the first 3200+ a64 results.

with those next gen cpu''s, wich are planned over the next years, i think yes, in 5 years, raytracing is very simple doable on cpu''s.

oh. and i''m very against supporting todays hw to evolve more. reasoning is simple: they split more and more completely away from being part of your system. think about it. they have their own memory, their own chips, their own datamanagement. and they have a very fast lan-like connection to the system (or merely adsl), called agp. this system is VERY inefficient. just think how powerful your gpu could be if you could plug it into the second slot of a dual opteron mainboard. direct memory access to the system, direct talking with the cpu, etc. full memory bandwith all the time. no need to TRANSFER memory at all.

it would perform much bether.

thats why i''m more for a multiprocessor system, and the gpu just as another processor, optimized for stream-tasks.

there are cases where IGP beats even todays leader gpu''s. and that is, when they have to share and co-work with the cpu.

the hw gpu design limits. not only because it rasterices. but, too, because it does. of course.

raytracing is way to go. and it will not happen on gpu''s. just because they are too proprietary anyways.

thats my guess.

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

##### Share on other sites
I guess this post proofs the fact that near future is over-estimated, whereas far future is under-estimated.

It seems though, that the future of computer graphics is actually Monte-Carlo estimated.

- Mikko Kauppila

PS: Hey, where are my favorite "there''s always the first-ray optimization!" posts?

##### Share on other sites
quote:

Wildfire: you should get much bether results actually, i think.

Well, I don''t I don''t know if you''ve seen the new Realstorm Bench 2004 yet, but the scenes are pretty complex.

Here''s a comparison of my system and a P4 done with the result browser realstorm 2003 (the old one) provides:

resolution       320x180x32shadows          yesreflections      yesanti aliasing    novolume lights    nodepth of field   noSystem           Athlon XP                P4Frequency        2088 MHz                 2803 MhzRating           2800+                    N/AMMX              Yes                      YesAMD MMX Ext      Yes                      NoSIMD             Yes                      YesSIMD2            No                       Yes3D Now           Yes                      No3D Now Ext       Yes                      NoRam              1024 MB                  512 MBAverage FPS      44.82                    33.74Min              20                       14.08Max              166.67                   125

So, I don''t think my system is performing that badly. Plus I think that''s a pretty good confirmation that AMD''s rating is pretty much valid.

quote:

Wildfire: the nvidia demo is just a plain hack. there is nothing real usable about it. i hope you know that. (guess why the file is that big..)

No, I didn''t know that. I''ve only seen their video so far, since I don''t own a GF-FX and can''t watch the demo.
I always wondered why nVidia''s demos (all of them) are usually >50 MB in size though. I don''t see any excessive use of high-res textures and the like that justify the size.

quote:

and realstorm normally performs much bether than what Wildfire reports actually. You sound more like a 2000+ system. i''m still waiting for the first 3200+ a64 results.

Well, it doesn''t. And my system is a 2800+ (2.08 GHz). At least this is what my bios and windows xp tell me. Maybe the above results from RS-2003 are more to your liking.

##### Share on other sites
just disable softshadows. adrian told me you use them, i must''ve missed that. they are inherently slow currently, they''re working on that.

softshadows are in there merely to prove they are doable. they are by NO means done fast.

with standard settings, first test 2004, you should get very smooth fps.

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

##### Share on other sites
Ice-Age wasnt from Pixar or PDI though

If you want to do things stupidly you can slow anything down. When you work to get the best IQ out of your sytem you wont be reading back memory. System memory isnt all that much faster as AGP to begin with ... you cannot make extensible memory as fast as hardwired stuff (and you cant make hardwired memory as fast as embedded stuff for that matter).

Desktop CPUs designed for legacy software are fundamentally suboptimal for media-applications and games. As long as you keep one in the system and dont evolve it, all it will be is expensive dead weight in the end.

You can stuff 8 P4s or Opterons on a die, but on the same die you can put 10 times more area efficient cores with far higher peak performance (and with the kind of code we are interested in that advantage wont be lost in sustained performance either). Most of the hardware in a desktop processor goes into speeding up legacy serial code. They might have realised that diminishing returns have set in and combine a couple on a die, but that does not erase the fact that they use huge cores designed for serial code.

The DX-Next slides from meltdown mention an integer programming model for shaders and general I/O (ie. not just textures and 2D buffers anymore). With that the GPU is getting very close to being able to take up more than just the rendering tasks away from the CPU.

##### Share on other sites
its taking them away, much too far away. thats my point actually. dx next sucks imho. they should start thinking about getting gpu and cpu to work more closely together, than to split them completely. that only means doubling of data. and doing work on the suboptimal system.

but i know that you won''t agree with me and i won''t agree with you pinky. we never got that near to each other anyways. not that your points aren''t true. i never implied that. but i don''t think they are good, and definitely not a good future.

the current way to do graphics on pc''s IS suboptimal. VERY suboptimal. just code at least once for a console system, and you know it. there, graphics and cpu''s are a team. they work together. on pc''s, they are fighting against eachother. when ever you need them to work together, you realise how slow they share their work. much too slow for any real advantages. the only way around this is to make the gpu do everything. but then, why do we need a cpu again? just put your hd and os onto the gpu and you''re done.

i prefer to start at the cpu system and make it evolve to get more simd and espencially mimd tasks done. this brings much more. more speed for physics, for audio processing, and much more. huge scene interpretation analises for ai, etc. a gpu can NEVER do that. a cpu can.

but its a worthless discussions, as we don''t design the future. big marketings do. and they push rastericing till the end. and then they will start hyping raytracing..

they never care about what is a good way. they only care about what way they can make big money. else, rastericing would''ve never been pushed that long that strong.

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

##### Share on other sites
oh, and just to have said it: we''re getting OFFTOPIC.

raytracing/rastericing has not much to do with how hw evolves. because good hw can do both. (with hw == cpu + gpu, no mather who does what:D).

oh, and, ApochPiQ, anything new yet? or do we still have to wait till december?:D

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

##### Share on other sites
quote:
Original post by davepermen
oh, and, ApochPiQ, anything new yet? or do we still have to wait till december?:D

December 23 is the official public announcement date. In fact I''m about to go start working on "it" in a few minutes

Unfortunately I must be forced to disagree with your analysis on GPUs vs. CPUs. I think the real problem is that people see fast GPUs and think "why not make the GPU do everything, since its faster?" This is a bit of a mistake because a GPU is, after all, a dedicated graphics unit. I doubt it would perform anywhere near as well doing, say, MP3 decoding, or running Windows software. The fact is, GPUs are gaining power in order to become better at graphics, not to become better at doing system functions. I think that for the visible future, for better or worse, the CPU/GPU decoupling is here to stay. As long as specialized applications can benefit from dedicated hardware, we will see decoupling. Only once a single integrated chip can handle all kinds of functions equally well will we finally get away from the CPU/xPU model and get into something more interesting.

Its also worth noting that, regardless of CPU architecture, you can accelerate raytracing far more effectively in dedicated hardware. CPUs will have to undergo a lot more changes than hyperthreading/K9 in order to catch up.

##### Share on other sites
i don''t say dedicated hw is not bether suited for its dedicated task. but i say a coprocessor unit would fit our needs much bether. fpu was a dedicated hw long ago, too!

just think of it. buy a dual opteron mainboard, and now, instead of two opterons, you could put in one opteron and one dedicated nv30opt or r300opt. you could directly excecute pixelshader code on it, and all directly with the system memory.

there would be no cpu <-----------------------> gpu like today. you could do just what you want on the hw you want.

and i think, by supporting software rendering more, we can motivate hw to possibly think about coprocessors again. an spu secondary processor could help very much. and with the memory-management layout of the amd64 systems, they could work very closely with the rest of the system.

i just don''t think that split we do today, and we do even more and more, is good. gpu''s get more general purpose systems today. they have their ram, their management, and their near-to-os-capable chip on it. and still, sharing the information is terrribly slow.

i don''t say anything against specialiced hw. i only say something about the way we split it more and more from the rest of the system today. THAT is wrong. and THAT could be the reason software rendering could actually start to catch up with multiple parallel processors sooner as the gpu-vendors like to think.

just think of the software solution of openrt. they run today realtime on nice res on multpc-systems of 5-8 p4. connected over ethernet. if they could get a board with say 8 opterons at 2gig, or more (2.2 is anounced?), that will definitely help them to solve the current connection-latency and bandwith issues, to gain even more speed. on such a system, realtime raytracing completely in software is no problem. such systems are today available as highend. they will be, one day, available as homepc. the question is just, when. in 5 years for sure.

but actually, thats not the topic:D oh damn.. who cares?:D

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

##### Share on other sites
The point is that the desktop processors are suboptimal for every part of the workload which is computationally significant. They are relics, they will either evolve or be ignored ... sharing a workload always has overhead, unless the CPU becomes more efficient the overhead simply wont be worth it. DX-Next isnt about splitting them up, it is about cutting the CPU off.

Consoles are not extensible ... that allows them to get more bandwith between components, and allows developers to use a static work distribution with tightly intercoupled timing between components since there are no performance variations for each and every component. As such they are less reliant on a strictly one way rendering pipeline.

That kind of programming just doesnt translate to a system where all communication has to cross connectors and every component can have wildly varying performance.

MP3 decoding and running windows software are not computationally significant tasks compared to the amount of computations which will be dedicated to rendering on next gen hardware ... rendering, physics+collision detection and perhaps AI is what hardware should be designed for (and I think DX-Next is bringing GPUs closer to that goal, much closer than present CPUs). Other tasks I dont care about, if they run a little slower so be it ... they are insignificant.

[edited by - PinkyAndThaBrain on November 17, 2003 9:10:03 AM]

##### Share on other sites
Realistically speaking: even if one has a raytracing solution that can shoot millions of rays per second, that''s still not enough, because you need to handle all the additional logic (sampling, exposure, brdfs, path tracing, bidirectional tracing, photon mapping, metropolis light transport, whatever!) in software, perhaps via a shader running on the RPU (ray processing unit).

Although the bottleneck would be removed, even the additional logic part is overly expensive for today''s CPUs, to be done per pixel that is.

So in the end, raytracing would still not be interactive if it were implemented on hardware. Hardware just doesn''t sell within consumer circles unless it gives realtime results on reasonable scenes, period.

- Mikko Kauppila

##### Share on other sites
uutee.. you''re only partially right. you know the link of above, openrt.de? you know saarcor? realstorm?

they prove you partially wrong. of course, a full 100% solution for anything cannot be done realtime yet. but rastericers of today provide a lot more stuff than rastericers of the beginning, too. this would be normal evolution of a raytracer hw or sw, to provide more features, and provide them fast.

i would like to see dedicated hw. i would prefer to see it as a secondary pu. so it could get part of the whole system.

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

##### Share on other sites
uutee -- I''ve got a lot of [invested] money that says you are wrong

What you''re forgetting is parallelism. First-hit is, of course, only one part of the issue; but lighting can be done very very fast - i.e. almost negligible cost (not including recursive rays) - when one is not doing photon mapping. Say we have a pipeline for a simple Phong-style BRDF; we just evaluate each component of the BRDF in a separate subpipe, and for multiple light sources we can have multiple lighting pipes. So we might be able to shade a point with 20 light sources for the cost of computing the [local] diffuse lighting for one light source on that same point on a CPU.

I highly doubt photon mapping will be in the first raytracing hardware, simply because one has to get working raytracing first, and then add GI. But once it has been established that raytracing can be nicely accelerated in HW, we''ll see photon mapping.

With regards to hardware - I like the idea of nongeneric processors going into a processor slot, but that will take some radical changes to system architecture. Still, something to be watching for, as it would really improve performance over the whole AGP bus conundrum.

##### Share on other sites
quote:
Original post by ApochPiQ
With regards to hardware - I like the idea of nongeneric processors going into a processor slot, but that will take some radical changes to system architecture. Still, something to be watching for, as it would really improve performance over the whole AGP bus conundrum.

yeah. it would "just" have to be sort of a vs3/ps3 style simd/mimd spu, that fits the communication specs of the athlon64 :D

"just"

... :D

it would be THE greatest thing for graphics. say 8 parallel pipelines there in, capable of doing vs/ps3.0 style work.. at 1gig clocked.. that would be enough to accelerate raytracing, or rastericing, enough to perform very well.. i guess.. i''ve done the theoretical math once, but it was a while.. :D

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

##### Share on other sites
Things are not getting better for rasterization. What we have right now is hacked dynamic lighting that runs at unusable frame rates with a single light source. Some other things, like refraction, are never simulated. In a rasterizer, in order to get reflections, you have to render the scene upside down and use a "stencil buffer"... Shadows often make use of the stencil buffer too... You have to order surfaces in order to draw the alpha surfaces last... This all makes no sense. Not to mention that rasterizers are *still* and probably forever will be limited to polygons.The problem is that rasterizers are way too much work, they are totally hacked and you have to perform too many things at once.

Raytracing is much more flexible, and it can be implemented in the hardware too. You can easily render all geometry that can be described by mathematical equations, you can render voxels fast... You automatically have your lighting and shadows without re-drawing your scene, its very easy to have texture shaders and apply other well known techniques such as normal maps. Also, with a raytracer, you can pass static geometry ONCE, have the renderer build its own data structure out of it and never have to send it again...

Its sickening to see how companies just keep adding bloated features to their cards all over the place (truform anyone?). Modern videocards are just growing more and more monolithic.
I believe the near-future is in hardware raytracing... Raytracing requires parallelism to be fast, but it does not require as much memory access as rasterization, current hardware optimizations could benefit to it. Also, having hardware raytracing cards and not having to pass polygons all over every frames, it could be possible to have raytracing videocards on the next generation of the PCI bus, just like the sound and network cards... Not anymore requiring a dedicated port... Not anymore being limited to one AGP card.

Software raytracing has many advantages, it would be very nice just being able to download the latest release of directx and be able to see all the new effects rendered fast without having to buy a card that costs twice the price of the fastest processor on the market... It would be nice having people making their own software renderers which provide original looking effects.

The truth is... For software raytracing to take place and compete with hardware, we would need either:

A) Processors to become at least 1000 times faster than they actually are withing the next 5 years.
B) Processors to integrate features such as vector processing... In other words, we would need processors to integrate features we usually see in a video card.

Looking for a serious game project?
www.xgameproject.com

[edited by - Max_Payne on November 17, 2003 3:44:59 PM]

##### Share on other sites
A) 1000 times faster than what we have in 5 years? no.. 10 to 100 times of what we have TODAY at MAX. see openrt and realstorm. a combination of that can run at great fps at say 800x600 with a 10 faster than today hw. this will be available in 5 years, i guess..

B) as this is requrested by very much high end users, this is a main target for high end cpu''s. and, as we know, amd only creates ONE sort of cpu''s. and intel normally shares the features over all their cpu''s, too.. with more hyperthreads, we essencially get MIMD. wich is great for exactly that.

one of openrt''s limits today is the bandwith of the 100mb ethernet. they can''t get more than 25fps on 640x480 TRANSFERED (numbers may be wrong from brain). so no mather how they speedup, they can''t get faster due the network. i guess they move to 1gb ethernet as next, and a set of say 2.8gig ht p4 800mhz fsb.. and THEN they will get quite some boost again. i think 4 such pc''s will be enough for adequate realtime raytracing. and _then_, they could still use the additional cheat-features of realstorm, to cut down the workload by much..

and we still have the gpu of today free for our usage:D wich can do 91million ray-sphere intersections per second:D in an
ARBfp1.0..

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