Announcement

Collapse
No announcement yet.

HLSL Help!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    HLSL Help!

    Hi all,

    Long-time watcher, first time poster

    I'm a pretty proficient hlsl programmer, and I'm getting into the UDK now, drooling with anticipation of producing some good stuff. I've made custom Oren-Nayar shaders, Minnaerts, Cook-Torrance and the rest, and been consistently amazed and impressed by the work of many here, especially those like ambershee and IndependentSoul who push the limit of what this engine can do!

    So, of course, I want to try out some cool post effects as well, but I need a little help. A small thing, really.

    How can I access the buffers for, say, a custom SSAO or SSDO effect? I have the code written, tested it out in Composer, and I'm pleased, but I can't figure out exactly how to get buffer info out of the engine.

    Do I simply use the DestDepth (or equivalent) nodes in my loops, or can I declare them nakedly in the Custom node? All I need is a hint here! I'm really eager to get on with a good project I hope you will all like, but this has me hamstrung.

    Hoping for a bone

    Thanks

    #2
    AFAIK you can only use the SceneTexture and depth buffers. UDK doesn't give access to any 'normal' buffer for example
    try using nodes when possible (they are faster than the Custom node)

    Comment


      #3
      Thanks for the reply!

      Yeah, the custom node should only be used for certain limited functions; in my case, only things like loops that can't be coded with nodes. The main problem with it is lack of folding, which is completely understandable!

      However, you MUST be able to access normals in some form, since ambershee and IndependentSoul have both produced their own SSAO effects which require the use of normal lookups per pixel sample to operate. I'm guessing they used the CameraVector node or something like it to get a normal-per-pixel value, but I don't know how they achieved this... and they don't give much away in their threads I wonder if they or anyone else could just give a clue on that little nugget...?

      Thanks again!

      Comment


        #4
        There is one trick. Older versions of UDK gave you access to the actual shader files, where newer ones are compiled into binaries. You'd have to go backwards at least a year to obtain these.

        Comment


          #5
          And even then you don't know if they will work with newer UDK Versions, because all structural changes they might have been doing are now hidden inside the precompiled shader files.

          Comment


            #6
            Aha! Thanks so much, ambershee! That's exactly what I needed!

            Followup question; do the shaders still work in the new udk? I'm guessing so, but not taking anything for granted...

            Cheers!

            Comment


              #7
              Originally posted by rebb View Post
              And even then you don't know if they will work with newer UDK Versions, because all structural changes they might have been doing are now hidden inside the precompiled shader files.
              Possibly, but the shader code will give you the "UDK-speak" version of the buffer call, which is different from the standard HLSL gNormal/gDiffuse/gDepth call, which might then be called in a custom node. The engine then should run it, since the shader is compiled at runtime, and shouldn't care whether it's a pre-built shader or custom made. I hope that's the case, anyway, since it would be pretty sneaky to lock out selected pixel shader calls in the engine. Of course, it looks like Epic are hobbling the UDK right now (from our perspective, at least) but they probably have their reasons.

              The code access lockout and vertex shader lockout are understandable for different reasons, but this is a simple post process pixel shader, so shouldn't present any difficulty. I'll let everyone know if it works in a week or so (curse my busy schedule!)

              Comment


                #8
                Another quick thought before I go; it must work with the newer udk, since ambershee uses the later versions too

                Looks like a simple workflow; code and test in the older UDK, export as a .upk file and then pick it up in the new install.

                Comment


                  #9
                  Actually, I'm not sure if it will work properly with newer UDK versions - it will probably work, but since then a number of things may well have changed binary side. I often do not use the most up to date version of UDK.

                  Comment


                    #10
                    Originally posted by ambershee View Post
                    Actually, I'm not sure if it will work properly with newer UDK versions - it will probably work, but since then a number of things may well have changed binary side. I often do not use the most up to date version of UDK.
                    Oh, I see. Well I'll exercise cautious optimism, then, but unless sweeping changes have been made, I don't see how pixel shader access could be locked out at that level and still retain functionality for nodes that contain "hidden" access to the pixel and fragment shader code in a way that's useable by us mortals (UDK users).

                    BTW, was there any word on why they switched to binaries in the first place? The only two options I can think of are efficiency or to nobble attempts to use the shader system at a deep level...

                    Comment


                      #11
                      No idea. When you look in the material editor, you'll often find calls to functions that do not exist elsewhere in the code exposed to it. Those function definitions are inside the compiled shader files - along with a lot of variable definitions also not exposed in the material editor.

                      Comment


                        #12
                        Just looking at that now (March 2010 build). The code is exposed there, but there's little that should be specifically "locked out" to later builds. And as the Custom Node entry says, it allows access to functions not exposed by the nodes, so it should work, if I understand this correctly. That said, the only real test is doing, so here we go!

                        I'm going to start by just ripping the SSAO shader circa 2010 as a .upk and see if I can use it; if I can, then SSDO will work fine, since it uses the same buffer lookups. If not, well I may cry softly for a bit

                        Comment


                          #13
                          The catch is that in the newer revisions, there's an awful lot of new stuff in the compiled binary. I'm willing to bet you can break a lot of existing nodes by replacing the compiled binary shader file with a modified one. As for whether you can reference stuff you find in there in a custom node without exposing it, that's a good question - let me know how you get on!

                          Comment


                            #14
                            Sorry, my last post wasn't clear I'm not replacing the SSAO node in the new build with the old one; I'm making a custom node setup of SSAO using the call structure of the old one in the old build and opening it as a package in the new build to see if it works in the post process chain. Hopefully that won't break anything, since I'm not replacing anything.

                            I'll post results (if any!) When I get it done. First comes the laborious code-stepping.

                            Actually, first comes rebuilding my **** computer, whose HDD up and died on me this morning. Yay for smart phones!

                            Comment


                              #15
                              Originally posted by DifferenceEngine3D View Post
                              BTW, was there any word on why they switched to binaries in the first place? The only two options I can think of are efficiency or to nobble attempts to use the shader system at a deep level...
                              I made some inquiries on the matter here on the forums a few times, but none got an official reply. My guess is that Epic is trying to be more protective with their lower level shader code.

                              Comment

                              Working...
                              X