154 replies to this topic

[Goz]

Altair said:

Of course. Like I said, once we got quantum computers, it's irrelevant which algo we choose ;)

hehe .. but .. what's so complicated about modifying a structure like an octtree? Dynamically rearranging it is fairly simple as are things like CSG ... Its not particularly slow either. Undoubtedly there are better algorithms out there ...

Quote

Sure, but at that point you need already the programmable shader architecture which takes about the same resources as current GPUs alone. On top of that you would need the resources for raytracing. Or are you telling me that raytracing logic is somewhat simplier than rasterization logic? I don't think so.

In certain circumstances yes but, admittedly, in the majority of cases no... However the firther we push rasterisation logic the more bits and pieces will be borrowed from things such as RT (and other schemes) to provide the necessary results. How does cube mapping work again?

Quote

I don't think you can execute different shaders on different quad pipes simultaneously, because investing transistors for that would be pretty useless considering how current games utilize GPUs. Anyway, yeah, your info is outdated, because I don't think rasterizing multiple triangles simultaneously has been possible before nv4x. It's only matter of investing transistors on logic that gives you the biggest bang for the buck anyway. That's how NVidia/ATI work, i.e. they take existing games and use them to guide where transistors would have most impacts on the performance. Again, here is a link.

Ta for that ...interesting article. Still not sure where you get your 4 pixels from 4 different triangles from, though .... that part of the article is a little confusing.

"Article" said:

On triangle-borders, the GPU still works with full quads, even if only one pixel is part of the triangle to be computed. In this example, three pipes won't do any work

Is that referring to the NV40 or previous designs?

Quote

I don't think computing ray-triangle intersection is expensive, but quite contrary, it's pretty fast actually. What's expensive is to find the closest triangle to use for intersection computations and that's where raytracing is inherently slow algorithm. Sure you can utilize coherency to a degree, but it wont solve the inherent flaw in the algorithm.

Gonna have to do a bit of research on this but i am sure there are scene traversal systems that work in linear time. Its a simple process to iterate an octtree to find the nearest tri along a ray path, for example (and there are undoubtedly far more efficient methods of doing this). I don't see how this is so expensive ...

Not to mention the fact that if you are doing this sort of thing you already have a perfect database setup for things like collision detection and such like :)

Quote

Yes, I have heard it, i.e. you rasterize the first-hit rays and continue with raytracing afterwards. The problem is though that then you have double logic for rendering (not necessarely bad idea if they complement each other) and that raytracing would require the whole scene capturing. Also there is many other issues with raytracing which I have brought up, so I'm not quite sure the hybrid solution would be good idea in practice.

Well, tbh, this could go on forever (must remember not to get involved in this sort of discussion 2 weeks before beta :lol:). So i'm going to end with ... I disagree. As yet you have not managed to convince me so shall we agree to disagree on this? Afterall the only REAL way to tell is to re-visit this subject in 10 years time. You up for it? :D

Edit: Should add to that last bit that i don't reckon im gonna convince you either ...

[davepermen]

just to inform, i'll be out of this discussion for a while. gets me too stressy all the time :D

i just prefer to have a full solution, and then step back and take what you need to get an optimal solution for your needs. and not a weak solution and i have to add and tweak and change and fake around till it gets at least close to what i want.. and nowhere near close to what i could have in the full solution.

i just wished, years ago, there would have never been the invention of the hw rastericer.. without that, raytracing would have stayed competitive in realtime tasks. but capitalism took over, and pushed one into heaven, and the rest back beyond earth.. and now it's very hard to catch up again.

but anyone stating he would prefer fakes and tweaks over a simple, working, full solution, lies.. at least if he programs by heart.


oh, and altair, the important thing about swshader is just it's speed. it's about the fastest dx9 sw implementation possible. and you can compare it by highest end cpu's of today with highest end gpu's.. and then, you look at what realtime raytracing is possible on highest-end cpu's (quite something possible actually), and scale that by the same amount.

then you got where we, more or less, would be, if rastericing would not have taken over gaming and marketing world due it's cheaper starting requirements.

[Goz]

davepermen said:

just to inform, i'll be out of this discussion for a while. gets me too stressy all the time :D

Wuss :tongue: hehehehe

[Altair]

Goz said:

hehe .. but .. what's so complicated about modifying a structure like an octtree?

Not really complicated but expensive. Think what it takes to rebuilt octree for an object of let say 10k polys. In object level it makes more sense. Or did you think of getting away of having an object space SDS and testing each ray against all object triangles? Didn't think so ;)

Goz said:

How does cube mapping work again?

There is no raytracing involved in cube mapping if that's what you are implying.

Goz said:

Ta for that ...interesting article. Still not sure where you get your 4 pixels from 4 different triangles from, though .... that part of the article is a little confusing.

Yeah, that was wrong article. I edited my previous post earlier.

Goz said:

"Article" said:

On triangle-borders, the GPU still works with full quads, even if only one pixel is part of the triangle to be computed. In this example, three pipes won't do any work

Is that referring to the NV40 or previous designs?

That's the nv40 architecture. It seems you are confusing pixel pipes and quad pipes. Even when at triangle border other 3 pixel pipes for a quad don't do work, other 3 quad pipes do work.

Goz said:

Gonna have to do a bit of research on this but i am sure there are scene traversal systems that work in linear time. Its a simple process to iterate an octtree to find the nearest tri along a ray path, for example (and there are undoubtedly far more efficient methods of doing this). I don't see how this is so expensive ...

If you compare the process of finding ray intersection with a triangle from both memory access/coherency and performance POV to simply rasterizing triangle you'll realize what I mean.

Goz said:

Not to mention the fact that if you are doing this sort of thing you already have a perfect database setup for things like collision detection and such like :)

You'll have that structure with hierarchical z-buffer visibility without raytracing anyway.

Goz said:

Well, tbh, this could go on forever (must remember not to get involved in this sort of discussion 2 weeks before beta :lol:). So i'm going to end with ... I disagree. As yet you have not managed to convince me so shall we agree to disagree on this? Afterall the only REAL way to tell is to re-visit this subject in 10 years time. You up for it? :D

Man, you are in no hurry with whole two weeks for beta ;) Anyway, I hope I have atleast convinced some other people who happens to read the thread and have a clue that raytracing has no future *throws fuel to the fire* :tongue:

[Goz]

davepermen said:

i just prefer to have a full solution, and then step back and take what you need to get an optimal solution for your needs. and not a weak solution and i have to add and tweak and change and fake around till it gets at least close to what i want.. and nowhere near close to what i could have in the full solution.

Sorry .. this comment bothers me. What is so "full" a solution about raytracing? How do you model a truly diffuse surface without firing an infinite amount of rays for every surface intersection?

Ray tracing is no perfect solution ...

[Goz]

Altair said:

Not really complicated but expensive. Think what it takes to rebuilt octree for an object of let say 10k polys. In object level it makes more sense. Or did you think of getting away of having an object space SDS and testing each ray against all object triangles? Didn't think so ;)

Sure its expensive to rebuild a whole octtree ... thats why you take advantage of frame to frame coherency.

Quote

There is no raytracing involved in cube mapping if that's what you are implying.

No thats true ... but the idea behind it is much the same. Trace a beam/ray/normal into the cube map. Admittedly thanks to the wonders of people with more of a brain than me this is a HEAVILY optimised solution that requires no beam to actually be traced :)

Quote

Yeah, that was wrong article. I edited my previous post earlier.

Kinda like the old Pixel Planes system ...

Quote

That's the nv40 architecture. It seems you are confusing pixel pipes and quad pipes. Even when at triangle border other 3 pixel pipes for a quad don't do work, other 3 quad pipes do work.

Indeed i was ...

Quote

If you compare the process of finding ray intersection with a triangle from both memory access/coherency and performance POV to simply rasterizing triangle you'll realize what I mean.

Thats actually a good point. Mind there are always ways to improve cache coherency ... Work on the PS2 you'll see what i mean :lol:

Quote

You'll have that structure with hierarchical z-buffer visibility without raytracing anyway.

If you can access it ... the hierarchical Z is kept on the graphics card ... Mind lets hope they allow us to get shit from the card quickly ...

Quote

Man, you are in no hurry with whole two weeks for beta ;) Anyway, I hope I have atleast convinced some other people who happens to read the thread and have a clue that raytracing has no future *throws fuel to the fire* :tongue:

hahahaha :tongue: While i do appreciate your points i think you are being entirely too dismissive of Ray tracing ... Many solutions are far more elegant and, indeed, simpler when using raytracing (bulletholes in walls, for example)...

[Altair]

Goz said:

Sure its expensive to rebuild a whole octtree ... thats why you take advantage of frame to frame coherency.

If you have flexibility of current vertex shaders, you can't gain from temporal coherency. That's why I said that you should pose some reasonable limitations to objects (i.e. assume that objects are always within their bounding volumes) in order to gain from temporal coherency when updating world space SDS, but as I see it, you can't pose those limitations to object space SDS, or it would atleast be extremely difficult (i.e. defeat the purpose of trying to gain from the coherency) and very limiting.

Goz said:

Thats actually a good point. Mind there are always ways to improve cache coherency ... Work on the PS2 you'll see what i mean :lol:

I have actually worked on PS2 and GC in the past, so yeah, I see what you mean :D Having coherent memory accesses has always been very important from performance POV regardless of architecture and the importancy has nothing but increased since caches were first introduced. And now even with GPUs all kind of coherency is extremely important and GPU manufacturers take all the measures to increase it (swizzled/compressed textures/render targets, mipmaps, etc.)

Goz said:

Quote

You'll have that structure with hierarchical z-buffer visibility without raytracing anyway.

If you can access it ... the hierarchical Z is kept on the graphics card ... Mind lets hope they allow us to get shit from the card quickly ...

That's what PCI Express is for ;)

Goz said:

hahahaha :tongue: While i do appreciate your points i think you are being entirely too dismissive of Ray tracing ... Many solutions are far more elegant and, indeed, simpler when using raytracing (bulletholes in walls, for example)...

Sure, there are alot of utilizations (other than rendering) for raytracing, and we use raytracing quite a bit in our game (for instance for bullet holes you mention) because it's very intuitive and simple. But even for those cases it's not very cheap and has fair amount of problems alone. I may appear more dismissive to raytracing than I am though, but that's kind of nature of a debate :happy:

[Goz]

Quote

That's what PCI Express is for ;)

Forgive me if wrong here (spent too much time recently on X-Box and PS2 to pay much attention to the PC happenings) but as i understand it the only real difference between PCIx and AGP (ignoring the bandwidth) is that PCIx is full duplex where AGP was half. There was no AGP spec reason why a card can't download from the card as fast as it can upload ...

Am i right on that?

If i am i can see whats gonna happen with PCIx :rolleyes:

[Altair]

Goz said:

Quote

That's what PCI Express is for ;)

Forgive me if wrong here (spent too much time recently on X-Box and PS2 to pay much attention to the PC happenings) but as i understand it the only real difference between PCIx and AGP (ignoring the bandwidth) is that PCIx is full duplex where AGP was half. There was no AGP spec reason why a card can't download from the card as fast as it can upload ...

Am i right on that?

If i am i can see whats gonna happen with PCIx :rolleyes:

PCI-X != PCI Express. PCI Express (x16) delivers ~4GB/s transfer rate simultaneously to both directions, while AGP8x does ~2GB/s to single direction. I don't know much about the details, but it's supposed to be very cost efficient solution, currently delivers ~10x more data / pin than AGP4x (expected to increase up to ~4x / pin with advanced silicon technology), has dedicated line / device thus doesn't cause transfer bottlenecks to SLI graphics cards, etc.

[davepermen]

theoretically agp readback could be quite faster (and is on some highend cards), but yes, they always 'forgot' to add that feature.

now, that pcie doesn't bring more performance (as agp8x is more than enough in one direction anyways for now), they now need some reason to hype pcie => they now try to hype it's readback speed.

marketing, all marketing :D but no, pcie is much faster in readback.. still, agp by itself could be much faster, too.. :D

i know of at least one who will profit from pcie by much.. and it's one of the most impressive gpu works done..

[Michael]

davepermen said:

theoretically agp readback could be quite faster (and is on some highend cards), but yes, they always 'forgot' to add that feature.

now, that pcie doesn't bring more performance (as agp8x is more than enough in one direction anyways for now), they now need some reason to hype pcie => they now try to hype it's readback speed.

marketing, all marketing :D but no, pcie is much faster in readback.. still, agp by itself could be much faster, too.. :D

"Yes, you're right, but theoretically I could be right as well, it's just that I'm not." ;)

[pat_mathis]

It's most likely dumb to step between two dogs going at it, especialy as a booter to the site. But, I don't feel lighting alone is what it takes to make a game feel real. I would much like to see a smarter colision system. Slid along walls, brush up on things, and actually see persons grasp objects with the skin giving way to the object. I guess that's not really relative to the video card aspects of things though, huh? :blush:

:D Well then while I'm at it then what about sound cards getting things like dragon speak and reading programs intergrated into it.

Then you could really get into character by making a costom voice. No more 12 year old kid's voice cutting into my counter strike games. :lol: -YEAH :lol:

And maybe then you could get some really complex infocom program on the computer! Imagine that for mmorpg's! You would have to act out as your character! Then of course there's this:

"Hey Computer!" (from other room)
"Yes, Man?"
"Play my 'Punk n Ska' mix"
"Sure thing, boss!"
-Music Plays
"Hi" (from your little sister)
-Robot Mother F#@ker, by green jelly stops. Dashboard starts.

how cool would that be?!

you could even get it to rejester tone.

[Goz]

pat_mathis said:

I would much like to see a smarter colision system. Slid along walls, brush up on things, and actually see persons grasp objects with the skin giving way to the object.

Hey man! You trying to steal my Quantum Physics engine idea? :lol:

[davepermen]

i've played a bit hl2 yesterday (a quarter of an hour, or so..), and.. well.. the physics do, for me, first time feel quite real. we can go much further, of course, but it's at least a step.

oh, and, yes, there's much more in the whole "good illusion" thing than lighting. it's just, i'm fighting for raytracing because 'it works'. it can be more or less converge to a general full solution to all such problems => programers won't have to work that much for it anymore, and can dive more into the artistic part of it (implementing good tools for complex shader generation for artists, etc..).

most important: realistic animation. that both involves physics, and great art. so far, hl2 impresses me, there, too. zelda did as well. realistic movement of characters, they actually do steps to walk, and not just "swing their legs" like in quite some shooters. the animations have to be fluid, and behave rather logical. physics as well (they are just automatic animations, so the same rules apply).

next important: constistency. the whole world, the individual grass blade. all need some detail, and all the same 'some'. the world has to look like it's one piece, not like uhm.. a bsp with some skinned characters in it. it should give the feeling of being touchable. has to do very much with the animation of above, but as well much more with the artists work (like characters wear stuff that exists in the world, too.. say some gold-medaillon gets the same shader as the goldnuggets you can find..)

third: realistm: not important if you want cartoon shading, or the most realistic reallife simulation. graphics have to look logical, to not stress the eye in any form. to have a good backend there, a graphical api should exist, that provides a simple interface to full customisable global illumination, theoretically. you can still disable what you don't want, but it would be the right "base" to work with.

and thats why i fight for hw raytracing. it would give this possibility. with doom3 graphics sort of the lowest a raytracer hw does by default, it would be quite a nice "start" to evolve to realistic graphics :D


i'm quite aware that graphics are not everything. but they are an important part. they should as accurate as possible represent what the artists and designers imagined. just like it is for movies today.. be it nemo, shrek, the incredibles, ice age, or what ever. there, artists don't have to care (much) about technique at all. the result is a consistent, realistic, believable world.

this is even true in some old games. graphics don't have to be top notch, to be believable. but the whole mix of the 3 points above should find a good combination. thats what counts.

of course, ai and sound have the same criteria :D

[PsiProvider]

Ok, back to Raytracing vs. Rasterization ...
Altair can you tell me why saarcor as a rtrt-chip does perform so incredibly well with that limited resources in contrast to rasterization hardware ?
- 90Mhz Clock Speed (Rasterization Hardware is at 500Mht, right ???)
- 64 MB Ram (Rasterization Hardware has > 128MB)
- it's good old SD-Ram not DDR
- it's implemented in a FPGA, it's not even "real hardware" => it's still some kind of simulation
- btw it's a PCI-bus FPGA-Card they use ^^

Now look at the performance :
"This small prototype with only one rendering pipeline achieves already realtime frame rates of 15 to 60 fps in 512x384 and 32 bit colour depth and between 5 to 15 fps at 1024x768 in our benchmark scenes as presented on this page. Thus the prototype with on 90 MHz already achieves the performance of the highly optimized OpenRT software ray tracer on a (virtual) Pentium-4 with 8 to 12 GHz!"

And they didn't use trivial scenes but levels from quake3 and ut2003 :
- Quake3-p: 52,790 triangles, 17 objects
- UT2003-Shooter Game "Rabbit": 53,722 triangles, 3 objects
- SunCor: 187,145,136 triangles, 5622 objects (ok fps drop, but still a lot less than on rasterization hw)

So now look at the rasterization hardware with those specs : I suppose we'd been at the pre-riva tnt2-level, right (90 Mhz, ok Ram was less than 32mb, so 64mb would've been huge)?

Doesn't that prove that Raytracing Hardware is AT LEAST as fast/good as Rasterization Hardware.

By the way you mentioned the shading problem of saarcor, did you ? Well, look at the pictures at http://www.saarcor.de/ ... maybe there are no "wow-they-are-so-cool" effects comparable to Pixel Shader effects but compare those pics to saarcor's rasterization-eqivalent (seen from the hardware side) - a voodoo 2 card :
Ok, you have bilinear filtered textures, but the realtime shadow would be a problem (hey I mean GPU supported !) , also that huge amount of triangles. I think the quality of the sample pics is quite promissing, so don't forget : saarcor is the first real usable implenention not even in "real hardware". Think about what would be possible if you'd use the same amount of transistors like a GF6 ^_^ and use them for the shading pipeline if you want ....^

Well I really don't wan't to argue about the theoretical possibilities and algorithms concerning raytracing/rasterization because I think only the results count in the end. And comparing the raw output (the image quality) I think the saarcor wins even against a Riva TNT (which had better hardware specs).

[Altair]

PsiProvider,

I don't have time to repeat everything that was said in this thread, so read it throughfully, try to understand and we can discuss more.

[PsiProvider]

Well Altair seams like you missed my point :
The only things you mentioned here in this forum are comparisons of algorithms - rather boring stuff. Concerning the image quality I don't care what algorithm was used as long as it runs at "realtime" (> 15fps). It seems like you're completely ignoring the fact that there is a working realtime raytracing "chip". And its output is IMHO absolutely comparable to the high end grafic cards today (GF6, Radeon X800). So why can't you simply accept the fact that a 90mhz rtrt-chip produces comparable output to a 500Mhz Rasterizer ? I do NOT say that some algorithm is better than another - that would be very stupid, because it always depends on the use and the exact context you want to use the algorithm in.
By the way I'm not a newbie concerning raytracing : I've written a working realtime raytracer for school so I know the biggest problem in raytracing : to find out which primitive is hit by a ray without testing them all against the ray. But saarcor's solution seems to work : otherwise they wouldn't have "realtime"-framerates at 1024x768.)
Ok, so what's your problem in one sentence ?
To be fair I'll put my argument in one sentence, too (so you don't have to spend too much of your precious time on my posting):
I prefer the Realtime Raytracing Chip towards rasterization hardware because of comparable image quality (often better IMHO) at comparable speed at MUCH lower hardware costs.

[Altair]

PsiProvider said:

And its output is IMHO absolutely comparable to the high end grafic cards today (GF6, Radeon X800).

Ok, I guess there is nothing to discuss about then :rolleyes: Since there is no raytracing HW that's scaled up to GF6 level, you have to talk about it in algorithm level and use that as argumentation for what kind of problems there potentially is, regardless how boring it is. IMHO, SaarCOR chip has come nowhere near the rendering quality of latest GPUs and I don't think investing the transistors of nv40 to raytracing would get you there either.

[Malkiah]

I would say, a particle physics system, say it rains(particle system kicks in) then mud,(physics engine kicks in, deforms the mesh). I dont know, just an idea.

[davepermen]

altair, what does saarcor miss in terms of rendering quality?