Just to re-iterate and to express my views on the subject.
Learning an API is trivial, what is important though is that you understand the fundamentals such as the pipeline and how everything ties in and some hardware knowledge. With this knowledge you can extend and use different API's and still be comfortable.
The reason I am saying this is the following...
When coding anything you need to understand what you are coding. Take for example a simple direct3d app. You know the rendering pipeline goes in the following order
Stage #1 -> Input Vertex data...
Stage #2 -> Transform and Lighting
Stage #3 -> Clipping/ Culling/ Rasterization
Stage #4 -> Pixel processing
Stage #5 -> Testing (Alpha, depth, stencil...)
Stage #6 -> Output to FrameBuffer
When you are comfortable with this knowledge and how each stage interacts with another you can easily understand that in the start of your app (excluding initializing the rendering device etc...) you need to store your data in a vertex buffer or a storage buffer. You then can using a vertex shader in the vertex processing stage do transform and lighting etc.
PS: It's always good to study the theory and then look at the implementation as it always works well when you understand what you want to do and when it comes to learning a new API you basically just bridge/extend your knowledge and plug in new parts of the pipeline like geometry shaders and input semantics...
I hope this helps.
Take care.
Re-Learn DX10?
Quote:Original post by remigiusAs a general concept, introducing new features never breaks backwards compatability - it's removing old features that does that.
However, I read that DX10 will completely break backward compatibility with DX9 (introducing the geometry shader and numerous other features)
Quote:Would anyone happen to have some good links on what is going to change with DX10 exactly, so I can read it firsthand? :)Seek out the Meltdown 2005 slides, or the PDC stuff. They contain a decent overview of what's changing.
In short summary: learning DX9 with a focus on the programmable pipeline (instead of the FFP) will put you in good stead for DX10. Names of functions will change, but the important stuff - the way the API gets used - will be familiar. (Learning an API shouldn't mean memorising the function names anyway).
Quote:Original post by superpig
As a general concept, introducing new features never breaks backwards compatability - it's removing old features that does that.
For good measure I'll submit that the accursed Java foreach loop almost did. In regard to platform changes, new features CAN render old code obsolete or disfunctional when the behaviour of statements/API calls changes, failing to replicate the old behaviour using the new features/approaches.
This might well be the case with the introduction of geometry shaders, as this fundamentally alters the pipeline. It shouldn't have to be breaking backward compatibilty, but it just might be. Just to expand your general concept :)
Quote:In short summary: learning DX9 with a focus on the programmable pipeline (instead of the FFP) will put you in good stead for DX10. Names of functions will change, but the important stuff - the way the API gets used - will be familiar.
I agree, but the current PP still is not as 'fleshed out' as the FFP. When doing some texture blending I can use the texture stages in the FFP without any additional effort, but with the PP I'll have to write a new shader from scratch (or am I missing something here?). It's inconvenient, but it's not my main problem with solely focussing on the PP.
The FFP serves as a layer of abstraction between the application and the graphics pipeline. Setting lights, fog or texture states on a device will perform some documented behaviour, which is easy to understand and predictable. When you're working directly with shaders, you don't know what's going on inside the shader until you take a look at it, which makes it harder to understand, predict and re-use than the FFP.
It may be a purist's discussion, but I feel this is a downside to the pure-PP approach. This might be where SAS compliant fx files come in, but information on this is a bit sketchy from what I've seen... Or maybe I didn't look in the right place and someone also has a link for that? :)
With regards to the push for use of the PP - in all fairness it's not a new concept. we've had 4 (5?) years of being able to use both FF and PP, and it was always a matter of time before it became the dominant feature.
For absolute beginners to graphics theory I can see why the FF might be useful - you can, within reason, get a long way without knowing much about the inner workings of graphics algorithms. However, this is probably a bad thing - knowing how something works can be quite important (at the very least, a useful skill) and hiding it all away can introduce other problems.
My favourite example of this is the texture cascade / fixed function texture blending. I *hate* that with a passion. It effectively masks a simple tree of possibilities and, when written down, isn't that complicated... but I find it ridiculously slow (development time, not runtime!) to work with. Hardware support for it is fairly good, but it's far from perfect - so you still have to be careful using any obscure components in your code. OTOH you can usually express exactly what you want very concisely, very clearly, using a pixel shader. You write it how you want to, in a way that makes more sense than setting 10-20 render states and leaving the implementation details hidden.
Strictly my opinion of course, but I completely disagree with this statement. I got pointed to this article yesterday, which shows a way in which to build lighting models from fundamental component functions. Using the effect interface you can then wrap it all up with a single technique name: OrenNayarWithBlinnPhongSpecular. You call a SetTechnique() in your code and you know what you're going to get. Strikes me as much more elegant than all the configuration and potential problems you can get via the render state system.
One thing to bare in mind though is that Microsoft are aware that a lot of people are fairly familiar with the FF method, and given the huge differences with D3D10 they're bound to include some stuff to help people migrate. It's simply not in their interest to kick everyone back to square-1 [smile]
You'll still be able to run applications compiled against previous versions of DirectX. Microsoft would be shooting themselves in the foot if they culled that much backwards compatability. Whilst it might not be the preferred route, developing for current 9.0c under WinXP should yield an executable that is compatable with current OS's as well as Vista. Could well be the best choice for some people.
Yeah, there's always a transition period. There's even DX9.L thats the Vista-specific version of DirectX9 to consider. As for the DX10 hardware - I'd expect some DX10 parts to be available at time of release, or very soon after it. New OS's tend to drive a new investment in hardware, so for money alone it's good for IHV's to have something ready for us to spend our money on [grin]
hth
Jack
For absolute beginners to graphics theory I can see why the FF might be useful - you can, within reason, get a long way without knowing much about the inner workings of graphics algorithms. However, this is probably a bad thing - knowing how something works can be quite important (at the very least, a useful skill) and hiding it all away can introduce other problems.
My favourite example of this is the texture cascade / fixed function texture blending. I *hate* that with a passion. It effectively masks a simple tree of possibilities and, when written down, isn't that complicated... but I find it ridiculously slow (development time, not runtime!) to work with. Hardware support for it is fairly good, but it's far from perfect - so you still have to be careful using any obscure components in your code. OTOH you can usually express exactly what you want very concisely, very clearly, using a pixel shader. You write it how you want to, in a way that makes more sense than setting 10-20 render states and leaving the implementation details hidden.
Quote:When you're working directly with shaders, you don't know what's going on inside the shader until you take a look at it, which makes it harder to understand, predict and re-use than the FFP.
Strictly my opinion of course, but I completely disagree with this statement. I got pointed to this article yesterday, which shows a way in which to build lighting models from fundamental component functions. Using the effect interface you can then wrap it all up with a single technique name: OrenNayarWithBlinnPhongSpecular. You call a SetTechnique() in your code and you know what you're going to get. Strikes me as much more elegant than all the configuration and potential problems you can get via the render state system.
One thing to bare in mind though is that Microsoft are aware that a lot of people are fairly familiar with the FF method, and given the huge differences with D3D10 they're bound to include some stuff to help people migrate. It's simply not in their interest to kick everyone back to square-1 [smile]
Quote:Since at least Vista will still ship with DX9, we can still use it, right?
You'll still be able to run applications compiled against previous versions of DirectX. Microsoft would be shooting themselves in the foot if they culled that much backwards compatability. Whilst it might not be the preferred route, developing for current 9.0c under WinXP should yield an executable that is compatable with current OS's as well as Vista. Could well be the best choice for some people.
Quote:ZMan also said in the article that no DX10 hardware exists yet, so I reckon it's gonna be 1 or 2 years before it gets really accepted and used, no?
Yeah, there's always a transition period. There's even DX9.L thats the Vista-specific version of DirectX9 to consider. As for the DX10 hardware - I'd expect some DX10 parts to be available at time of release, or very soon after it. New OS's tend to drive a new investment in hardware, so for money alone it's good for IHV's to have something ready for us to spend our money on [grin]
hth
Jack
It is in the interest of both Microsoft as well as the IHV's to have hardware available when a major product that makes extensive use of it is released. I would be surprised if there WASN'T hardware available when Vista launches.
As far as the FFP goes, I think it boils down to what your background is. If you have a graphics theory background, then shaders are much more understandable because you can just type in the math equations you already know. If your background is not in graphics, then the FFP masks away a lot of details that you would normally have to worry about. The downside to this is that the FFP then becomes a black-box, in which you don't really understand what's going on underneath.
For example, say you wanted to blend two textures together based on the alpha value of a material. To do this in a shader, you would just do:
vTextureColor0 * fMaterialAlpha + vTextureColor1*(1.0f-fMaterialAlpha)
This is easy to see conceptually. But doing this in using the FFP requires around 5 or 6 SetSamplerState calls with a ton of different parameters to select the appropriate texture, channel, blending mode, and alpha mode.
One of the reasons for the move to a programmable pipeline was that the moment you start to do anything even remotely complicated in FFP, you easily get mired down in a sea of renderstate settings that takes an expert to configure properly. Not only does the developer need to know the conceptual operation they want to do, but they also need to understand how to translate that into a ton of renderstate settings to get it working.
Seeing that DirectX was originally, and still is intended mainly for graphics professionals, it makes sense for Microsoft to let developers specify their rendering techniques in the way that is most natural to them: graphics theory. The DirectX docs are meant to show professional developers how to implement the graphics techniques they know from a theoretical point of view in the DirectX API. They aren't really meant to teach graphics programming to beginners, although there are some sections of the SDK docs that do cover a few of the basics.
neneboricua
As far as the FFP goes, I think it boils down to what your background is. If you have a graphics theory background, then shaders are much more understandable because you can just type in the math equations you already know. If your background is not in graphics, then the FFP masks away a lot of details that you would normally have to worry about. The downside to this is that the FFP then becomes a black-box, in which you don't really understand what's going on underneath.
For example, say you wanted to blend two textures together based on the alpha value of a material. To do this in a shader, you would just do:
vTextureColor0 * fMaterialAlpha + vTextureColor1*(1.0f-fMaterialAlpha)
This is easy to see conceptually. But doing this in using the FFP requires around 5 or 6 SetSamplerState calls with a ton of different parameters to select the appropriate texture, channel, blending mode, and alpha mode.
One of the reasons for the move to a programmable pipeline was that the moment you start to do anything even remotely complicated in FFP, you easily get mired down in a sea of renderstate settings that takes an expert to configure properly. Not only does the developer need to know the conceptual operation they want to do, but they also need to understand how to translate that into a ton of renderstate settings to get it working.
Seeing that DirectX was originally, and still is intended mainly for graphics professionals, it makes sense for Microsoft to let developers specify their rendering techniques in the way that is most natural to them: graphics theory. The DirectX docs are meant to show professional developers how to implement the graphics techniques they know from a theoretical point of view in the DirectX API. They aren't really meant to teach graphics programming to beginners, although there are some sections of the SDK docs that do cover a few of the basics.
neneboricua
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
