154 replies to this topic

[geon]

zavie said:

Just a little point. :-)
Ken Perlin has patented a hardware approach to his famous noise. So this could be another step toward real-time raytracing.

I'd see it as a step away from that.

[Axel]

Altair said:

Anyway, once we get those consumer class quantum computers in the market, raytracing problems are solved, but current 6 qubit test-lab quantum computers doesn't quite cut it yet

I don't think quantum computers are especially suited for raytracing. Do you know that only certain special algorithms work on them?

Or is there some theoretic work on quantum-raytracing-algorithms that I never heard of?

[Altair]

Axel said:

I don't think quantum computers are especially suited for raytracing. Do you know that only certain special algorithms work on them?

Or is there some theoretic work on quantum-raytracing-algorithms that I never heard of?

I was half-joking ;) Anyway, what I know is that quantum computers reduce the Big-Oh complexity of algorithms, so for example search of an element from random set of data can run in O(sqrt(n)) instead of O(n) of classical computers. The way this would help with raytracing is that you wouldn't need aux data structure (i.e. Kd-tree), but could just check the ray intersection against random set of polygons in O(sqrt(n)) time. Not quite O(1) time test yet, but at least a step towards the real solution :)

I don't claim to be expert on the subject, but at least it sounds an interesting area of research. They had some whacky problems with quantum computers, such that you can't duplicate data, but they figured out some weird solution to do this reliably by using probabilities or something (don't ask me the details ;)) Maybe that's why you think you can run only certain algorithms on quantum machine? There was a full-day course about quantum computing at siggraph, but I unfortunately didn't attend it for more than the introductory part. It's a bit difficult to justify for your employer how this would be useful for your next game ;)

Cheers, Altair

[theAntiELVIS]

Okay - this kind of thread always gets hijacked by the raytracer people who are desperate for anything that will free them from the endless wait for a render...

But everyone has missed what the REAL need is for graphics to progress, whether real-time or raytraced. What really is keeping computer graphics from looking as good as, say, a motion picture is monitor technology.

If you go outside on a clear night and look at the sky you will see the stars and the moon shining brighter than any monitor can reproduce. High luminance objects like stars, high-albedo planets, car headlights, Hell even christmas tree lights just can't be done on current monitors.

We need monitors that can reproduce the high luminance seen in reality. On current hardware such objects just go to a white washout far too soon.

-tAE-

[Altair]

theAntiELVIS said:

We need monitors that can reproduce the high luminance seen in reality. On current hardware such objects just go to a white washout far too soon.

Actually, there has been progress in this area, and HDR monitors were demoed at siggraph with still pictures & real-time 3D. Anyway, I didn't find the technology that convincing but that might be because of the limited and not that well authored demo material. The material that was demoed appeared to be even tailored to look bad on regular monitors to hype the technology but even then it didn't really add THAT much to the experience, IMHO. Anyway, when you get that type of quality increment you don't really realize that big of a difference at first, but when you get used to it, it's really painful to go back, so I guess it's the same deal with HDR monitors as well, just like it was when we transitioned from 8bit sound to 16bit :)

Cheers, Altair

[davepermen]

this is definitely the most reanimated thread ever on devmaster. we should finally close it, or whatever.. :D

hm altair, you should've stayed longer at the quantumpart at siggraph. definitely a cool thingy..

hm.. if an O(n) algorithm goes down to O(sqrt(n)), what will happen to an O(ln(n)) algorithm? well.. an O(sqrt(ln(n)) algorithm or something similar would definitely be cool :D

i for myself am now waiting for a nice lowlevel gpgpu interface for the new ati cards. if that one gets available, i'll have to think about writing a rendering backend for my distributed raytracer for it. would definitely boost up rendering times by some margin, i'd guess :D

[moe]

Quote

What really is keeping computer graphics from looking as good as, say, a motion picture is monitor technology.

It is true that better monitors would allow you to display what you have in a better way. Still it only allows you to display what you already have. I think the next big thing should do more than that. Is should give you the possibility to go further and bring up pictures witch could not be produced in realtime before. So the raytracing adepts do not really hijack the thread here but rather point out that raytracing brings you closer to reality.

[XORcist]

Hi Everyone,

Looks like this thread is gonna be closed. :sad: I never thought i would learn so much from it when I started this thread almost an year ago.
I have myself learnt 'A LOT' of new things from this thread. I want to thank all the people who have posted some cool things.

There were a lot of point-less 'post-count++' arguments. Its like one nice thought with a good-point, followed by 5 to 10 args. BIG Thanks to everyone for sharing your knowledge with us. Its not ATI, nVidia or EA that propel this industry. Its the community. I am a self taught game coder. I never attended a class. What ever I learned is what the community taught me.

I am pretty much convinced Real time ray tracing is the 'WAY TO GO'. I am no interest to further arguments on the above statement.

Argument is essential to any research area. Point-less arguments slow things down. There gotta be a balance. Its just that we always have a lot more issues coming up to think (or argue) about. Someone was arguing about how we can do inter-relations & render 10 reflective objects using 10 RenderTexture Cube maps.
10 Cube maps??? 60 RenderToTexture operations ???? :wallbash:

Mature argument?? Yeah sure...

Quote

Okay - this kind of thread always gets hijacked by the raytracer people who are desperate for anything that will free them from the endless wait for a render

Its not about Ray-tracer people or Rasterizer people. Its about Real-time people. Its all about reducing that endless wait period for a render. About getting close to reality at real-time rates.

Quote

We need monitors that can reproduce the high luminance seen in reality

Yeah those HDR monitors arent all that great. Higher range adds up to the realism factor. But, there are many other things. For now, we are faking it good pretty well.

Sweeny said that some years down the line, we would go video-like. We 'd have that kind of processing power. Monitors would be the bottle neck from then on.

For the next few years, we would be going towards getting the color (brightness, whatever.. ) of pixels right and go photo-real. Right now the gap is wide enough to keep us busy (and thread bloating :wallbash: ) for sometime. Then we would hit the limitations of resolution.

From then on its not about 'Photo-Realistic' but 'Eye-Realistic'. Its not easy to convince a human's sense of vision.

But, for now, we need to live with GPUs for a while. There is a lot to desire on GPU side.

I am not comfortable with the Stream based GPU architecture. Programmble shaders. We are inside a for-loop iterating over vertices & pixels. You can only write code inside the inner loop. Our existing rendering techniques can be simplified & improved significantly when dealing with render data as a set. not per-element.

Currently we are just hacking to overcome this problem. Render-To-Texture and more recently, Render to VertexBuffer ( WTF ). Current engine development is like stacking up more hacks over & over and making them work together.

Hacks = Code entropy + Art-Pipe entropy

In one of those GDC Videos, ATI's Render monkey chick was talking about something like

"Dynamic Image-Space Per-Pixel Displacement Mapping with Silhoutte Antialiasing via Parallax Occlusion Mapping."

Thats a SM 3.0 shader (nvidia only) and a single quad brought my 6800 Ultra to its knees (in a shader-visualizer. not a game ). All this for some shadowing on normal-mapped stuff (plastic-mapped). Gimme a more decent hack. ( And with a shorter name that i can remember ).

Most of those presentations are trying to push PRT. PRT does not interest me, for now. And those Ruby demos arent all that great either. Dawn's skin looks much better than that of Ruby.

Those caustic-mapping screens looked good. The numbers dont. I read their paper and I liked it a lot. Best shader based caustics (and also fastest) i've seen.:cool2: But, 30 FPS on a 7800 GTX (a few bunch of polys). May be for my next engine.

Rasterizer GPU development may hit fabrication limitations soon and they will go parallel. I wont be surprised if they tell us to code for 2D 'Cell' GPUs. And then 3D, Volume GPU matrices.

More flexible dynamic control-flow is desired ( especially pixel shader ). Lock-step execution of GPUs are a bit irritating. They said, its better to avoid checkered (high frequency) textures for good speed. I wont try telling it to our artists.

And ofcourse memory allocation on GPU. I am not keen on General Purpose stuff on GPUs. Physics hardware and such is coming anyway.

Currently I am researching Procedural-data generation. Natalya put a good paper on the topic ( ATI developer site )

Once again, so many thanks to all of you guys for sharing your thougts & also for the arguments.

Happy hackin people... :yes:

C ya people... Peace

[anubis]

Quote

Okay - this kind of thread always gets hijacked by the raytracer people who are desperate for anything that will free them from the endless wait for a render

Ok... I vowed not to respond to this thread anymore but there are a few words that need to be said. The topic ofthe thread clearly was : "The next BIg Thingy in RT-Graphics". Since RT-Ray Tracing has gained quite some momentum over the past few years IMO it's only fair to mention it. But as soon as you do a lot of people will jump in and say that it can thi, that and the other thing. But so what ? It handles huge static scenes quite gracefully and with a high degree of realism. In that respect it certainly is becoming more and more important to the industry.

I totally agree : Right now rt-tracing has no place in gaming, but at least looking at the title that was neither the intent of the question nor does it mean that it never will be able to handle dynamic scenes.

I can't speak for other people but I certainly didn't attack anybody for thinking that raster is the way to go. So if people try to shout me down (in the fashion of above quote), when I talk about something that I love to spent my time on and that is part of my work, I get agitated without a doubt. I'm sorry if that is distracting from the original topic (granted we still consider a thread on topic after a whole year aynway).

To conclude : I'd say that a lot of people who invest their time in current mainstream algorithms shouldn't be so smuck about what they can handle well. Ray tracing can score in areas that are difficult for other algorithms and, of course, has shortcomings in others. I don't see any need to pit these two worlds against each other.

PS : Rereading the first post I have to admit that it was more geared towards games, but as this raster vs trace discussion is popping up once in a while in different places I think my points are still valid.

[theAntiELVIS]

Uh - the line about ray-tracer people hijacking the thread was joke. Jeez, lighten-up you guys. I started ray-tracing on the old 486. Now THOSE were the days of "go away, have kids, put them through college, and when you come back maybe it will be done".

What I meant was, if you're raytracing, you got time on your hands - so why not make a forum post!

It was no slight on ray-tracing in general, although I COULD make comments on how some people turn their graphics technologies into a religious thing.

[juhnu]

Altair said:

Btw, you are dead wrong here. I don't know where you pulled that argument and what was the first 3D HW you ever saw, but I think it was Pyramid 3D by BitBoys (-97) and I was totally impressed of the capabilities of that chip at the time. I would argue that rasterizing HW ~10 years ago was more capable than raytracing HW today :rolleyes:

Sorry for the late reply, and sorry about resurrecting this thread:) I haven't had time lately to read these forums. Take this as my last reply for this thread. Thanks.

The first accelerator I saw with my own eyes was the Pyramid3D as well and it very well might be the time and the place were same too ;)

However I think there were some consumer affordable 3DLabs Glint based products before that. So what I had in mind was Glint, not Pyramid so I still don't think the first cards were that impressive feature-wise. Keep in mind that 10 years ago we were also 10 years younger and more easily impressed.

Anyway, It's a matter of taste so I don't think I'm "dead wrong" here ;)


Juhani

[davepermen]

where those cards capable of perpixellighting and shadows just the way doom3 looks? if not, then, no, i'd guess that hardware of back then was not as capable as the raytracing hardware of today.

[Altair]

juhnu said:

However I think there were some consumer affordable 3DLabs Glint based products before that. So what I had in mind was Glint, not Pyramid so I still don't think the first cards were that impressive feature-wise. Keep in mind that 10 years ago we were also 10 years younger and more easily impressed.

Glint and Pyramid 3D were developed around the same time, difference being that Pyramid 3D never shipped. If you just check the specs of the chip it was quite impressive for something developed 10 years ago. 10 years ago I was probably around the age of davepermen ;)

davepermen said:

where those cards capable of perpixellighting and shadows just the way doom3 looks? if not, then, no, i'd guess that hardware of back then was not as capable as the raytracing hardware of today.

Is raytracing HW today capable for per-pixel lighting like Doom3 looks today? Last time I checked, SaarCOR wasn't even capable of doing normal/bump mapping. On the other hand, Pyramid 3D supported bump mapping + stencil, so it seems you lost your bet right there.

Cheers, Altair

[davepermen]

every raytracer by default DOES per pixel lighting. if you know how they work, you know that it's actually easier to implement than vertexlighting.
and the rest is the shading part, and yes, the RPU2 provides shaders, so allow for anything (well.. at least a dot3.. :D)

doom3 graphics are about the default of any raytracer (if texturing is in, the bumpmapping is just a very small thing to add.. because everything except the dot3 is yet there).

and was the pyramid 3d capable of running doom3 graphics more or less smooth? with all the stencil shadows and that?

[Altair]

davepermen said:

every raytracer by default DOES per pixel lighting. if you know how they work, you know that it's actually easier to implement than vertexlighting.

You do realize I said "per-pixel lighting like Doom3", don't you? It means that it involves normal mapping, which I haven't seen any of the SaarCOR screens/videos featuring. Where can I find RPU2 specs and have they actually implemented the HW?

davepermen said:

and was the pyramid 3d capable of running doom3 graphics more or less smooth? with all the stencil shadows and that?

I'm sure it doesn't run Doom3 smooth if at all, but neither does SaarCOR so that argument is pretty much pointless ;) Anyway, it's just kind of sad that we have to be comparing SaarCOR against 10 year old prototype hardware.

Cheers, Altair

[davepermen]

available on the same page afai remember. and even if it's perpixellighting (and perpixelshadowing, a.k.a. about equal to stencil, but with more features) withOUT normalmapping, thats still more than a lot of gpu's where capable in doing for any useful scenes. sure, my gf2 was capable of faking some phong (but with horrible precicion), but trying to get it to handle perpixellighting, stencilshadows, and that in 2digit frames per second.. forget it.

this is doable on a saarcor, doesn't need to be an RPU2 for this. RPU2 adds shaders, thus, allows for doom3+ graphics.

[Altair]

I don't quite call a simple scene which consists of a table and 4 chairs running at ~20fps in low resolution quite Doom3 just yet ;) For sure even your gf2 was able to do better than that. Some Pyramid3D specs I found:
- Environment mapping
- Bump mapping
- Stencil operations
- Specular highlights
- 2-32 Mbytes of SDRAM, SGRAM or EDO DRAM supported
- Memory bandwidth up to 800 MBytes/sec with 64 bit bus
- 100 MHz operation
- 1 000 000 randomly rotated Gouraud shaded 25 pixel triangles per second
- 800 000 randomly rotated textured Gouraud shaded 25 pixel triangles per second
- Pixel fill rate 50 000 000 pixels per second

Cheers, Altair

[XORcist]

Hey altair, looks like u r back in business.

I get your point crystal clear and I am sure most others who read this thread also did. :worthy:

Lemme list down what i percieved from all your posts
- Ray-tracing hardware sucks.
- Rasterizer algos, techniques, and hardware rule the planet 10 years go -> now -> and forever
- Rasterization is the way of life.

If there is anything else, just tell us man. Post, counter-post, saga aint gonna stop if we go on this way.

But, one more thing i asked u guys in the first post is....

Quote

If u were to design a 3D-Engine that gives Unreal3 a run for it's money, what techniques would you incorporate (assuming you got the hardware powerful enough)

After unreal-3, not many engines have surfaced ( atleast announced ) except a few indie ones with nothing way better than that of ue3 features. Reality engine sold out. Project offset is kinda close ( their object-based motion-blur is one cool thing UE3 does not have). Unigine is cool but not much new . Serious engine 2 sucks.

Rendermonkey chick's parallax-occlusion mapping was actually, very impressive in ATI's Toyshop demo. especially the pavement thingy. But, ofcourse, its just an ' highly improved offset mapping' ( more displacement, occluision, shadows )

Btw, caustic mapping thing was cool though. :yes: something new, that we lacked for years.

More stuff from u guys ?? ( not just data-amplification thingies )

And whats with Shader model 4.0 & Dx10. Any ideas of new stuff possible. ?

BTW, worlds made out of diffuse , specular normal mapped stuff SUCK big time ( Doom3, Quake4 ) and so do simple shadow volumes. One guy titled it Quake4 - Plastic Arena.

[Altair]

All I can say is :wallbash:

[XORcist]

Does that mean you are gonna stop your stuff ?? If thats what you meant, then GREAT:yes: . No more posts from me dude. :surrender