Oh, and none of the shots you posted look anything like Crysis in game. Especially the characters look out of place. I'm guessing they're pre release renders. (Raytraced!:P)
How about this one? The torso of the guy in the middle of the shot casts a shadow onto his left leg. No you don't get shadows in every nook and cranny with shadow maps due to aliasing (you need to bump the map resolution a lot to remove that), but you don't need that to get fairly decent results.
Crysis also has screen space ambient occlusion (oh noes! more fudging) which makes up for a lot of the details lacking in the shadow maps. The over all effect is in my opinion much better than the pixel perfect ray traced shadows in the Nvidia demo. That looks about the same as the stencil shadows you saw in Doom3. Horrible stuff.
I don't think that means what you think it means.
Yeah, my terminology may be off. What I meant was shadow mapping that works uniformly across the entire scene, of which perspective shadow maps are one kind.
Shadow maps ARE a form of projected shadows.
Again, my terminology is probably off. I was thinking of per object projected shadows which project a shadow from the object onto the ground, but nothing else.
Now the leaves in Crysis do cast shadows since in those cases missing shadows would be immediately noticeable.:) And you would do the same kinds of optimizations in a ray traced engine if you wanted it to run real time. Barely noticeable details like grass shadows are fair game when optimizing for performance, and culling all that geometry before tracing would probably help (though maybe not as much as in a rasterized engine).
There's always going to be trade-offs like that in real time graphics, ray traced or rasterized. It's all about fudging it just enough that you can get away with it, you just have to fudge different things depending on the technique. Dynamic geometry is for instance a real pain in the neck in ray tracing since you have to rebuild (parts of) your acceleration structure every time something moves. This overhead can get quite significant in a dynamic game world.
Again, look at Crysis. Every leaf of grass casts a shadow.
Grr, no that's wrong. They only receive shadows. There's nothing technically preventing them from casting shadows though. It's probably disabled for performance reasons.
As an example, a field of grass would need a shadow map for every blade
No, no, no. You have one shadow map per light source in most implementations (or a cube map for a point light. Depends on the algorithm used). You render the scene (depth only) from the light's viewpoint into this texture, thus finding the world space coordinate of the front most geometry (the shadow casters). Then, when you render from the camera viewpoint you look up each pixel's world space coordinate in this texture to determine if it's behind a shadow caster or not. If it is, do nothing, else calculate light contribution for the pixel.
Again, look at Crysis. Every leaf of grass casts a shadow.
When a soldier moves his leg far forward during a sneaky walk, you don't see a shadow of his weapon and arm cover his leg. That is realistic internal shadows. Placing shadows on obvious overhangs is just more beating the player over the head with depth perspective.
But you do see that.:) Crysis has completely uniform shadow mapping. Everything casts shadows on everything (unless it's been specifically disabled by the artist). All light sources are completely dynamic as well, so you can take any one of them and move it about and the shadows will update accordingly. This is exactly the same as ray traced shadows, the only difference is quality and power requirement. I have a feeling you may be thinking of projected shadows which do indeed have a few of those attributes (they suck).
It shows what can be done given (relatively speaking) unlimited time. Unfortunately that has no bearing on what is feasible in real time, as the Nvidia demo handily demonstrates.
you really meant they can, it just doesn't look very good?
Meh, going back to your original post I seem to have misinterpreted your statement the first time around. That was in fact all you said. My apologies. My point still stands though. For the quality, shadow maps are more efficient, hence yield more realistic results in real time.
It's not disabled. Look at the upper right corner of the ship, just to the left of the right wing. You will see a minor shadow cast by the ship onto the ship. Look at the superstructure to the left. The overhang is casting a shadow onto the lower part of the tower.
Both look like crap.
Ah, so when you said game engines can't do it, you really meant they can, it just doesn't look very good?
Well, that is purely down to shadow map resolution and power limitations in the filtering of them. You'd hit the similar limitations using ray traced shadows if you try to do them in real time. Which is why Nvidia has used a single light source trace in their demo. Add more and it doesn't run fast enough. Do the shadows in Toy story look bad for example? They are shadow maps too.
But either way, if you honestly think the shadows in the Nvidia demo looks closer to real shadows (not necessarily more accurate) than the ones in Crysis, I'll leave you to it. I strongly disagree though.
I think the fact that it looks fine to you is more or less where the problem lies:)
Okay then, please humour me. Which general area of the picture should I be looking at? There's a lot of shed.
The only way to really tell is to take the exact same scene and lighting model, run both algorithms, then compare the results side by side, and in those comparisions, ray tracing wins hands down, at the expense of a vast increase in computing resources used.
Whoo there. That depends highly on the scene in question now doesn't it? If you're talking about the ray tracer's dream of the reflecting ball on checkerboard, then yes, obviously. But if you take a normal real life scene, the result is far less clear cut.
I also don't see why you need to impose the "same lighting algorithm" requirement. That will automatically bias towards one or the other technique. What matters is the resulting image quality (and to some extent the work needed to make it happen), not how it's achieved.
Heck, you don't even have to get that complex. The car casts shadows upon itself. Which already makes it look more realistic on a closeup than anything an existing game engine can do.
Bullshit. Crysis has self shadowing, just like any other moderately recent game. The screenshot you posted is in one of the lower quality modes in which it may be disabled.
Crysis also has shadows from a number of light sources simultaneously, but the number is limited (4 IIRC) for performance/quality reasons. I suggest you look up what shadow mapping actually is before you spout off nonsense.
Rasterization has moved forward since Quake 3 you know.
The same scene using shadow maps would look more or less the same, but in addition you would have compute power left to actually make the shadow fuzzy like it is in real life. The hard shadows you get in ray tracing without sufficient light traces look anything but realistic. Especially in outdoor scenes.
I'm not sure I understand what you mean about the Crysis pic though. Looks fine to me?
I'm not "opposed to raytracing". I'm opposed to the commonly held belief that raytracing automatically equals realistic graphics and that it somehow scales better than rasterization. It may if you completely ignore acceleration structures, but if you do that both ray-tracing and rasterization will run at non-realtime framerates for any moderately complex scene.
What matters is what gives the best result using the available computing power. Right now that is rasterization, and it will stay that way until the hardware is fast enough to make the extra work usually involved in making rasterization work not worth the effort in terms of quality.
The reason ray traced images often look very realistic isn't because they're ray traced, but rather because they are done offline and as such can take ages to do the calculations required for a realistic lighting model. What can be done given enough time doesn't matter. What is efficient enough to be feasible real time is.
Raytracing may be "closer to simulation", but that's completely irrelevant when the performance isn't there for the quality of the output. Can you honestly tell me you think the shadows in Nvidia's demo look better than the ones in, say, Crysis?
Sure you can. A human instinctively knows when something looks "right" or "wrong".
Yes, and amusingly reflection and refraction (two of the main benefits of ray tracing) are a couple of things that humans generally can't tell if are being fudged. As long as it's in the ballpark it's enough to fool the human eye. Pixel perfection is way beyond what's required.
And one of the reasons why rasterization is capped is due to lighting problems.
What does that mean? Capped?
Lighting technology has improved significantly in the last decade, but still not sufficiently to compete with raytracing. Raytraced lighting will look more natural to an untrained viewer.
Why? Details please. What exactly is more realistic about tracing each pixel through the geometry than drawing the geometry directly in the appropriate pixels? The underlying lighting calculations are the same either way, meaning they will both look the same, so the only real concern is speed for any given scene.
So if we look at speed ray tracing only has a real benefit in reflection and refraction, but that's not really a winning argument because, as I said, people can't really tell if it's 100% accurate anyway. I sure can't. Ray tracing can also do accurate soft shadows relatively easily, but the ray count required makes that completely unrealistic in real time for the foreseeable future. Shadow maps will be faster either way, and look 99% as good.
Ray tracing is simple to implement, but so is cracking a password using brute force. That doesn't make it the best solution.
They are gorgeous? Really? I think they look distinctly average. The lighting calculations look very simplistic. Yes, the shadows and reflections may be pixel perfect, but that just doesn't matter that much. You usually can't tell they are anyway. The same scene rasterized with a simple cube map for the car's reflection and some proper shadow maps would look much better. Not to mention run faster.
And "graphical quality becomes a matter of raw horsepower"? This unlike in rasterization then?
And how efficient is transferring the electricity across the grid to your house so you can charge your batteries? Furthermore, you obviously wouldn't generate the hydrogen yourself at home, but rather get it at some filling station like today (unlike with batteries which would be difficult to refill within a minute at a "recharging station").
You lose a lot of power in the hydrogen generation, that's true, but batteries and power lines aren't especially efficient either. I'm not sure which one would best/most practical though.
I'm basing this on the quality OGL drivers have had up until this date (they are a horrible, inconsistent mess), and that driver quality was one of the stated benefits of the original (and dropped) GL3 attempt. If the big three haven't gotten it right in the 16 years since OpenGL was first released, I don't see how an even more complex standard is going to be any easier for them.
It's certainly a step in the right direction. Having to bind resources in order to change them is one of the major annoyances in OGL.
It still feels somewhat halfway there considering how nice Longs Peak was looking though (immutable state objects), but reading Barthold Lichtenbelt's "explaination" on the OGL discussion boards they found a few problems with that approach. Maybe this way is better after all.
I think I need to give all this a few days to sink in before I can look at it rationally. So disappointed.:)
All two levels, including the deprecated and non-deprecated level...
Two levels, for now. There will be more in the future as more stuff gets deprecated if I'm reading it right.
And the forward compatible API is nowhere near as clean as the one promised a year ago. The fact that it may be layered on top of a cleaner API inside the driver doesn't really help me.
Will the IHVs (or Tungsten for Gallium) develop separate state trackers (or whatever it is they're doing internally) for each deprecation level though? Sound like an awful lot of duplicate work for what is essentially the same API. And if they're not, well that's where I get worried. The famed OpenGL rewrite over at ATI wasn't exactly painless (and lots of apps are still broken), and if they have to do all this refactoring underneath the API yet again I don't look forward to the fallout.
Their code will require a huge architectural rewrite no matter what the API looks like. Hardware just doesn't work like these programs are using the APIs anymore, and hasn't for a long time. Keeping this legacy stuff around in the new API won't change that. It'll still be a complete mismatch with the hardware.
If they want to take advantage of GL3 (either the promised or the delivered version) they will have to rewrite large parts of their code, so why not just drop all this backwards compatibility nonsense and make GL3 actually good, while still keeping GL2 around for legacy? With the original plan for interoperability between the two they could still switch to GL3 one piece at the time while they rewrote their codebase to modern standards. This would have been much simpler for everyone involved. These companies included.
The problem here isn't the actual implementation of the old fixed function pipeline. That has been emulated with shaders for yonks already.
The problem lies in the state machine at the core of OpenGL. This will have to be there no matter what "deprecation level" you're running at and I can't imagine the IHVs will implement a standalone version of that for each of these levels. The result is that every feature will impact others since they interact with the same core system, enabled or not. IHVs will have to hack up their currently stable code to add OGL "3" support, and they will break things in the process.
What really breaks my heart is that OGL2 could "easily" be layered on top of the original GL3 they proposed. That way they could take care of backwards compatibility while still providing lean and mean drivers for the rest of us. The other way around isn't nearly as easy though (if at all possible), and will do jack squat for driver simplicity.
Sure, but that does nothing to help driver development. They still need to support all the deprecated features if the application requests them (most likely for a very long time to come as well), and driver quality is one of the major problems with OGL right now.
The "old" GL3 was also supposed to include interoperability with GL2 mind. But it would not do it by layering yet more stuff on top of the old, which I can't imagine will do driver quality any favours.
Slashdot Mirror
Oh, and none of the shots you posted look anything like Crysis in game. Especially the characters look out of place. I'm guessing they're pre release renders. (Raytraced! :P)
How about this one? The torso of the guy in the middle of the shot casts a shadow onto his left leg. No you don't get shadows in every nook and cranny with shadow maps due to aliasing (you need to bump the map resolution a lot to remove that), but you don't need that to get fairly decent results.
Crysis also has screen space ambient occlusion (oh noes! more fudging) which makes up for a lot of the details lacking in the shadow maps. The over all effect is in my opinion much better than the pixel perfect ray traced shadows in the Nvidia demo. That looks about the same as the stencil shadows you saw in Doom3. Horrible stuff.
Yeah, my terminology may be off. What I meant was shadow mapping that works uniformly across the entire scene, of which perspective shadow maps are one kind.
Again, my terminology is probably off. I was thinking of per object projected shadows which project a shadow from the object onto the ground, but nothing else.
Now the leaves in Crysis do cast shadows since in those cases missing shadows would be immediately noticeable. :) And you would do the same kinds of optimizations in a ray traced engine if you wanted it to run real time. Barely noticeable details like grass shadows are fair game when optimizing for performance, and culling all that geometry before tracing would probably help (though maybe not as much as in a rasterized engine).
There's always going to be trade-offs like that in real time graphics, ray traced or rasterized. It's all about fudging it just enough that you can get away with it, you just have to fudge different things depending on the technique. Dynamic geometry is for instance a real pain in the neck in ray tracing since you have to rebuild (parts of) your acceleration structure every time something moves. This overhead can get quite significant in a dynamic game world.
Grr, no that's wrong. They only receive shadows. There's nothing technically preventing them from casting shadows though. It's probably disabled for performance reasons.
No, no, no. You have one shadow map per light source in most implementations (or a cube map for a point light. Depends on the algorithm used). You render the scene (depth only) from the light's viewpoint into this texture, thus finding the world space coordinate of the front most geometry (the shadow casters). Then, when you render from the camera viewpoint you look up each pixel's world space coordinate in this texture to determine if it's behind a shadow caster or not. If it is, do nothing, else calculate light contribution for the pixel.
Again, look at Crysis. Every leaf of grass casts a shadow.
But you do see that. :) Crysis has completely uniform shadow mapping. Everything casts shadows on everything (unless it's been specifically disabled by the artist). All light sources are completely dynamic as well, so you can take any one of them and move it about and the shadows will update accordingly. This is exactly the same as ray traced shadows, the only difference is quality and power requirement. I have a feeling you may be thinking of projected shadows which do indeed have a few of those attributes (they suck).
It shows what can be done given (relatively speaking) unlimited time. Unfortunately that has no bearing on what is feasible in real time, as the Nvidia demo handily demonstrates.
Meh, going back to your original post I seem to have misinterpreted your statement the first time around. That was in fact all you said. My apologies. My point still stands though. For the quality, shadow maps are more efficient, hence yield more realistic results in real time.
Ah, so when you said game engines can't do it, you really meant they can, it just doesn't look very good?
Well, that is purely down to shadow map resolution and power limitations in the filtering of them. You'd hit the similar limitations using ray traced shadows if you try to do them in real time. Which is why Nvidia has used a single light source trace in their demo. Add more and it doesn't run fast enough. Do the shadows in Toy story look bad for example? They are shadow maps too.
But either way, if you honestly think the shadows in the Nvidia demo looks closer to real shadows (not necessarily more accurate) than the ones in Crysis, I'll leave you to it. I strongly disagree though.
Okay then, please humour me. Which general area of the picture should I be looking at? There's a lot of shed.
Whoo there. That depends highly on the scene in question now doesn't it? If you're talking about the ray tracer's dream of the reflecting ball on checkerboard, then yes, obviously. But if you take a normal real life scene, the result is far less clear cut.
I also don't see why you need to impose the "same lighting algorithm" requirement. That will automatically bias towards one or the other technique. What matters is the resulting image quality (and to some extent the work needed to make it happen), not how it's achieved.
Bullshit. Crysis has self shadowing, just like any other moderately recent game. The screenshot you posted is in one of the lower quality modes in which it may be disabled.
Crysis also has shadows from a number of light sources simultaneously, but the number is limited (4 IIRC) for performance/quality reasons. I suggest you look up what shadow mapping actually is before you spout off nonsense.
Rasterization has moved forward since Quake 3 you know.
The same scene using shadow maps would look more or less the same, but in addition you would have compute power left to actually make the shadow fuzzy like it is in real life. The hard shadows you get in ray tracing without sufficient light traces look anything but realistic. Especially in outdoor scenes.
I'm not sure I understand what you mean about the Crysis pic though. Looks fine to me?
I'm not "opposed to raytracing". I'm opposed to the commonly held belief that raytracing automatically equals realistic graphics and that it somehow scales better than rasterization. It may if you completely ignore acceleration structures, but if you do that both ray-tracing and rasterization will run at non-realtime framerates for any moderately complex scene.
What matters is what gives the best result using the available computing power. Right now that is rasterization, and it will stay that way until the hardware is fast enough to make the extra work usually involved in making rasterization work not worth the effort in terms of quality.
The reason ray traced images often look very realistic isn't because they're ray traced, but rather because they are done offline and as such can take ages to do the calculations required for a realistic lighting model. What can be done given enough time doesn't matter. What is efficient enough to be feasible real time is.
Raytracing may be "closer to simulation", but that's completely irrelevant when the performance isn't there for the quality of the output. Can you honestly tell me you think the shadows in Nvidia's demo look better than the ones in, say, Crysis?
Yes, and amusingly reflection and refraction (two of the main benefits of ray tracing) are a couple of things that humans generally can't tell if are being fudged. As long as it's in the ballpark it's enough to fool the human eye. Pixel perfection is way beyond what's required.
What does that mean? Capped?
Why? Details please. What exactly is more realistic about tracing each pixel through the geometry than drawing the geometry directly in the appropriate pixels? The underlying lighting calculations are the same either way, meaning they will both look the same, so the only real concern is speed for any given scene.
So if we look at speed ray tracing only has a real benefit in reflection and refraction, but that's not really a winning argument because, as I said, people can't really tell if it's 100% accurate anyway. I sure can't. Ray tracing can also do accurate soft shadows relatively easily, but the ray count required makes that completely unrealistic in real time for the foreseeable future. Shadow maps will be faster either way, and look 99% as good.
Ray tracing is simple to implement, but so is cracking a password using brute force. That doesn't make it the best solution.
They are gorgeous? Really? I think they look distinctly average. The lighting calculations look very simplistic. Yes, the shadows and reflections may be pixel perfect, but that just doesn't matter that much. You usually can't tell they are anyway. The same scene rasterized with a simple cube map for the car's reflection and some proper shadow maps would look much better. Not to mention run faster.
And "graphical quality becomes a matter of raw horsepower"? This unlike in rasterization then?
And how efficient is transferring the electricity across the grid to your house so you can charge your batteries? Furthermore, you obviously wouldn't generate the hydrogen yourself at home, but rather get it at some filling station like today (unlike with batteries which would be difficult to refill within a minute at a "recharging station").
You lose a lot of power in the hydrogen generation, that's true, but batteries and power lines aren't especially efficient either. I'm not sure which one would best/most practical though.
You can make Hydrogen using any source of electricity. Same difference.
I'm basing this on the quality OGL drivers have had up until this date (they are a horrible, inconsistent mess), and that driver quality was one of the stated benefits of the original (and dropped) GL3 attempt. If the big three haven't gotten it right in the 16 years since OpenGL was first released, I don't see how an even more complex standard is going to be any easier for them.
It's certainly a step in the right direction. Having to bind resources in order to change them is one of the major annoyances in OGL.
It still feels somewhat halfway there considering how nice Longs Peak was looking though (immutable state objects), but reading Barthold Lichtenbelt's "explaination" on the OGL discussion boards they found a few problems with that approach. Maybe this way is better after all.
I think I need to give all this a few days to sink in before I can look at it rationally. So disappointed. :)
Two levels, for now. There will be more in the future as more stuff gets deprecated if I'm reading it right.
And the forward compatible API is nowhere near as clean as the one promised a year ago. The fact that it may be layered on top of a cleaner API inside the driver doesn't really help me.
Will the IHVs (or Tungsten for Gallium) develop separate state trackers (or whatever it is they're doing internally) for each deprecation level though? Sound like an awful lot of duplicate work for what is essentially the same API. And if they're not, well that's where I get worried. The famed OpenGL rewrite over at ATI wasn't exactly painless (and lots of apps are still broken), and if they have to do all this refactoring underneath the API yet again I don't look forward to the fallout.
Their code will require a huge architectural rewrite no matter what the API looks like. Hardware just doesn't work like these programs are using the APIs anymore, and hasn't for a long time. Keeping this legacy stuff around in the new API won't change that. It'll still be a complete mismatch with the hardware.
If they want to take advantage of GL3 (either the promised or the delivered version) they will have to rewrite large parts of their code, so why not just drop all this backwards compatibility nonsense and make GL3 actually good, while still keeping GL2 around for legacy? With the original plan for interoperability between the two they could still switch to GL3 one piece at the time while they rewrote their codebase to modern standards. This would have been much simpler for everyone involved. These companies included.
The problem here isn't the actual implementation of the old fixed function pipeline. That has been emulated with shaders for yonks already.
The problem lies in the state machine at the core of OpenGL. This will have to be there no matter what "deprecation level" you're running at and I can't imagine the IHVs will implement a standalone version of that for each of these levels. The result is that every feature will impact others since they interact with the same core system, enabled or not. IHVs will have to hack up their currently stable code to add OGL "3" support, and they will break things in the process.
What really breaks my heart is that OGL2 could "easily" be layered on top of the original GL3 they proposed. That way they could take care of backwards compatibility while still providing lean and mean drivers for the rest of us. The other way around isn't nearly as easy though (if at all possible), and will do jack squat for driver simplicity.
Sure, but that does nothing to help driver development. They still need to support all the deprecated features if the application requests them (most likely for a very long time to come as well), and driver quality is one of the major problems with OGL right now.
The "old" GL3 was also supposed to include interoperability with GL2 mind. But it would not do it by layering yet more stuff on top of the old, which I can't imagine will do driver quality any favours.