   Fragments in D3D10?
  I've just skimmed through the dx10 documents and can not find any information about compiling shader fragments and linking them together at runtime.My current project relies heavily on shader-linking, and so far, I've designed my project with d3d10 in mind, but if d3d10 lacks the capabilities of shader linking, i really need to consider some heavy restructural actions...Will there be any equivalence to d3d9's D3DXCreateFragmentLinker in d3d10?   
  As far as I know this not finally decided but Microsoft was never very happy with the fragment linker.  It looks like Ubershaders are the preferred way for D3D10. As the binary form of a D3D10 shader is much more complex (as example they are signed by the compiler and the runtime checks this) fragment linking would be more complex too.   ;  Last I heard, the fragment linker was going to at least be heavily changed/reworked if not dropped altogether. I don't know what the current thoughts (or state of any work-in-progress) are, but its safe to assume things are changing as far as this API component is concerned.If you have a specific use-case that D3D10 won't/can't handle then you might want to let Microsoft know about it. They might be able to let you know what they're working on, or if theres an intended work-around/alternative. I think the D3D10 beta is gone from Connect, but if you have access the microsoft.beta.d3d.misc newsgroup is a good place to post, possibly also email directx@microsoft.com and/or post in the official D3D10 forum.hthJack   ;Quote:Original post by Anonymous PosterI am personally pi**ed about MS not supporting DX10 on the XP platform. They could easily make it work on XP, they just *don't want to* (needing vista features *yeah right*).What exactly does this have to do with the topic again?Quote: It looks like Ubershaders are the preferred way for D3D10.Personally, I enjoy working with ubershaders.  They are simple in nature and work very well.  If you can keep your head straight through all of the pre-processor code, you should be good to go.   ;  But Übershaders are teh spwan of cthulhu!!11!oneUsing Übershaders - won't there be a pain in the rear end to write a generic shader implementation? Think of an exporter for your favourite game asset tool; like Maya or 3DS Max - You have just created your awesome cube and you want to render it using normalmapping and some kind of PRT. Using fragments, you could just simply link a normalmap shader and a PRT-shader in realtime, but Übershaders force you to write a specific NormalPRTShader...Not that I have the rights to complain - but Fragments were really convenient to use.  I sure hope Microsoft decides to keep, or at least rewrite the functionality of runtime shader-linking!;Quote:Original post by WixnerUsing fragments, you could just simply link a normalmap shader and a PRT-shader in realtime, but Übershaders force you to write a specific NormalPRTShader..Not quite.  All you have to do is add the necessary PRT code (assuming you already have the normal mapping stuff) into your ubershader and add the simple back-end stuff.  Then you can use that PRT functionality in combination with any other sections.It's quite like working with fragments, except that you are doing it at a lower level.  You stitch the fragments together yourself when you write the shader, then just include or drop out certain parts.   ;Quote:Original post by circlesoftIt's quite like working with fragments, except that you are doing it at a lower level.  You stitch the fragments together yourself when you write the shader, then just include or drop out certain parts.Hopefully first gen D3D10 hardware will handle this kind of shaders well.  But as this is a case of static branching it should work well. If not we still can emulate it with the CPU as on SM2 cards.;  Ahh.. It's like having gazillions of shader-functions in one (or several included) fx-files and then simply write 10 or 20 Techniques to implement the features you want? or perhaps this is made by code.. hmm...[source lang = "cpp"]void DisplacementMap() { ... }void NormalMap() { ... }void PRT() { ... }technique DisplacementNormalMapPRT{ pass p0 {  VertexShader = compile vs_3_0 DisplacementMap();  PixelShader = compile ps_2_0 NormapMap(); } pass p1 {   VertexShader = 0;   PixelShader = compile ps_3_0 PRT(); }};  You should have a look at the PS20_StaticBranching example in the RadeonSDK: http://www.ati.com/developer/radeonSDK.html   ;Quote:Original post by WixnerAhh.. It's like having gazillions of shader-functions in one (or several included) fx-files and then simply write 10 or 20 Techniques to implement the features you want? or perhaps this is made by code.. hmm...It's more along the lines of this:VS_OUTPUT UberVertexShader( VS_INPUT in ){    // Do stuff you would always do here    // Like transform by WVP matrix, ect#if !defined( NORMAL_MAP )    // Do all of the per-vertex lighting    // Note that NUM_LIGHTS is a back-end define as well    for( int i = 0; i < NUM_LIGHTS; i++ )    {   ...    }#endif#ifdef DIFFUSE_COLOR    // Do material diffuse color stuff#endif#ifdef AMBIENT_COLOR    // Do ambient color stuff#endif   ...}You can do the pixel shader in the same fashion.  Using defines like this simply allows you to say 'I want a shader with diffuse map, diffuse color, specular map, normal map, 2 dir lights, 1 point light, and ambient occlusion map'.   