DirectX9 vs DirectX10 *again*
- Thread starter alexsok
- Start date
Dave Glue said:
Whoa, easy.
What i'm getting at is that it looks like something easily doable on todays dx9 based hardware...like Far Cry : Instincts water...mere image trickery can result in some pretty nifty visuals, and I seriously doubt we're going to NEED a dx10 card to get that kind of water. Unless it's geometric water with proper waveform physics bouncing it around and lapping against boatsides and beaches...I see no reason why it couldn't be done on anything today...specially with (debatable) AGEIA's PhysX PPU.
I...M...O.
A couple of things...
Technology development isn't inevitable. It's piecemeal, it's progressional, it's historical, and it's driven commercially through competition. And, for it to make much sense at all commercially, it's got to be backwards compatible to a degree that makes it practical.
Part of the commercial allure that creates the wealth necessary to drive the technological engine is the concept of "new and improved." I see nothing wrong with this approach at all, only provided that what is new is, in fact, new and improved in reality.
I get the sense in reading some of these posts that people are unhappy because "the ultimate" in technology isn't ever presented to them conveniently. Yes, it would be great if tomorrow I could go out and buy the Ultimate CPU or the Ultimate GPU in that either was so incredibly well designed that it could never be eclisped by latter products. To a certain extent I can understand the reluctance of people to respond ecstatically whenever a new & improved version of the D3d API comes along, in tandem with newer and better products designed to support it. But, this kind of thing is the nature of the beast, imo. Progress is the wheel on which technology turns, and incremental progress is the *only* way the wheel can turn. The important thing, I think, is that progress doesn't start moving in reverse. DX10 is but a small, but significant, step in the right direction. It is not nirvana. Indeed, were technology to ever reach such a plateau then forward progress would stop and that's what is to be avoided.
Technology development isn't inevitable. It's piecemeal, it's progressional, it's historical, and it's driven commercially through competition. And, for it to make much sense at all commercially, it's got to be backwards compatible to a degree that makes it practical.
Part of the commercial allure that creates the wealth necessary to drive the technological engine is the concept of "new and improved." I see nothing wrong with this approach at all, only provided that what is new is, in fact, new and improved in reality.
I get the sense in reading some of these posts that people are unhappy because "the ultimate" in technology isn't ever presented to them conveniently. Yes, it would be great if tomorrow I could go out and buy the Ultimate CPU or the Ultimate GPU in that either was so incredibly well designed that it could never be eclisped by latter products. To a certain extent I can understand the reluctance of people to respond ecstatically whenever a new & improved version of the D3d API comes along, in tandem with newer and better products designed to support it. But, this kind of thing is the nature of the beast, imo. Progress is the wheel on which technology turns, and incremental progress is the *only* way the wheel can turn. The important thing, I think, is that progress doesn't start moving in reverse. DX10 is but a small, but significant, step in the right direction. It is not nirvana. Indeed, were technology to ever reach such a plateau then forward progress would stop and that's what is to be avoided.
Dave Glue said:
You rock WaltC!
No way. Not only would such a technique be horribly expensive in hardware (anything involved in modifying the z-buffer in the pixel shader is going to be expensive), but it wouldn't give any tangible benefit in this scenario (which would be adding the illusion of curvature to the edges of an object: in a flight sim, you'll never see the edges of waves on water).DudeMiester said:
Now, as for the reflections, it's obvious that the bump mapping wasn't taken into account when calculating the reflections. This choice could have been just a stupid move by the developers, or it could be because they didn't want to worry about aliasing, or it could be because it would thrash the texture cache.
Anyway, I doubt there's anything in that "DX10" shot that couldn't be done well on SM3-level hardware.
DudeMiester
Regular
It's not just for edges, it's also for proper parallax within the surface. Moreover, maybe they don't modify Z. They just assume the hull will be close enough, so you don't really notice anything unusual. Like the whole water surface could be flat, and everything you see is virtual geometry.
It's not just a maybe. There's no way in hell they're modifying the z-buffer, not if they're paying any attention at all to pixel shader performance. But yes, there are some methods of parallax mapping that are better than others. I don't think we can say that any of those have been used here, though. There's not a lot of contrast or regularity to really bring out the problems of even basic bump mapping.
The thing that makes it look great isn't the bump mapping: it's what is being bump mapped. They've done a really good job at generating some good textures for the water there. What I'm wondering is if they're static textures, or procedural.
The thing that makes it look great isn't the bump mapping: it's what is being bump mapped. They've done a really good job at generating some good textures for the water there. What I'm wondering is if they're static textures, or procedural.
I've never really expected tons of really expected D3D 10 (or DirectX 10 or whatever its going by these days) to be able to provide us with tons of things DirectX 9 couldnt do. Instead I've thought Dx10 as being much more efficent and allowing the programmers and artist to provide with more expressive details why not bringing performance down into unusable levels.
I believe this is the point JHoxley is trying to make, but it seems no one is reading his posts in this thread and he is by far the person I've seen post the most useful information about Dx10.
I believe this is the point JHoxley is trying to make, but it seems no one is reading his posts in this thread and he is by far the person I've seen post the most useful information about Dx10.
Could they have chosen a worse "D3D9" water effect to compare? Here's a much better one: http://multimedialab.elis.ugent.be/h2ocean/ShowPicture.asp?ShowPic=Screens/screen70.png
Which was done back in 2004. Runs smoothly on my X850. You can download the demo here: http://multimedialab.elis.ugent.be/h2ocean/
This exagerated comparison reminds me of a similar incident a certain IHV caused when one of their presentations was leaked.
Which was done back in 2004. Runs smoothly on my X850. You can download the demo here: http://multimedialab.elis.ugent.be/h2ocean/
This exagerated comparison reminds me of a similar incident a certain IHV caused when one of their presentations was leaked.
What does that have to do with the fact that it's a screenshot from a full game, and not a demo?Mordenkainen said:
When we have Nalu/Ruby-looking characters and environments in a full game it will be a watershed event - the fact they existed in demos years beforehand will mean nothing. As mentioned several times, it's about enabling certain effects within a performance envelope. You can pick up many demos from almost every GPU manufacturer that look better than games now - getting those kind of graphics into a full game where there are far greater demands on the hardware overall is something different.
Last edited by a moderator:
This is only true in restricted circumstances... The hardware is far more flexible than a simple, depth mod in pixel shader = slow. In some cases its can be fairly cheap (possible even free?).Chalnoth said:
Whether this is expressable in any PC API is the problem I expect, but from a hardware POV, modifing depth CAN be okay if you know how to use it.
It doesn't seem like an easy thing to me. The z-test units and the pixel shader are decoupled specifically for the purpose of optimization (with long pixel shaders, you don't want to execute pixels that are occluded). Any modification of z-buffer data from the pixel shader messes with this decoupling.
I'm sure that current hardware has optimized for the case of cancelling writes to the z-buffer, for the purpose of alpha tests, but that's about it.
I'm sure that current hardware has optimized for the case of cancelling writes to the z-buffer, for the purpose of alpha tests, but that's about it.
Then NVIDIA (don't know about ATI) should prehaps revisit there optimisation docs, there hardware CAN and DOES optimise z modifications... Its possible that no current PC API exposes the nessecary states to enable these optimisations, so its simplier to just say don't do it...Chalnoth said:
As an example to prove that it is possible to do z-cull optimistion even with modification consider this - if you modify the z but also have a commitment to always modify it in a consistant direction away from the triangle plane then because of this commitment, the original triangle plane can be considered a conservative estimate of the depth (it will be nearest value output by the pixel shader...) and so you can enable nearest z-cull.
Yeah, I guess that makes sense. But does even DX10 support the required state flag?
P.S. This doesn't actually change the fact that it would make zero sense to do z-buffer modification for the application in question: bump mapping on water in a flight sim. You'd never be low enough to the water to see the difference.
P.S. This doesn't actually change the fact that it would make zero sense to do z-buffer modification for the application in question: bump mapping on water in a flight sim. You'd never be low enough to the water to see the difference.
