Applying Post Process Effects to Canvas
Hi all!
I'm in the early stages of planning something new which is going to use UnrealScript rather heavily; my problem is that the result of the script is going to be an image (specifically a camera-view image with some effect applied). Think of it as a complex UnrealScript-based post effect, if you like. My problem is then getting that image to the screen.
If I specify it as an image for Post Processing (basically like a stand-in SceneTexture Expression), how do I get it to a texture file that updates per-tick? Or, alternatively, if I use the Canvas class, how do I ensure that the image is post-processed with the rest of the image?
I can go into more detail if this isn't enough, but, really, I'm just in the pseudo-coding stage right now, and I want to know if what I'm planning is possible, or if I should just quit right now
Thanks!
I'm in the early stages of planning something new which is going to use UnrealScript rather heavily; my problem is that the result of the script is going to be an image (specifically a camera-view image with some effect applied). Think of it as a complex UnrealScript-based post effect, if you like. My problem is then getting that image to the screen.
If I specify it as an image for Post Processing (basically like a stand-in SceneTexture Expression), how do I get it to a texture file that updates per-tick? Or, alternatively, if I use the Canvas class, how do I ensure that the image is post-processed with the rest of the image?
I can go into more detail if this isn't enough, but, really, I'm just in the pseudo-coding stage right now, and I want to know if what I'm planning is possible, or if I should just quit right now
Thanks!
Replies
If you want a post-process effect, using the post-process chain is what you need.
Otherwise you can play with HUD/Scaleform.
I have already tested some stuffs for changing a material while playing, it's very easy and it's the same logic for a post-process material. Keep in mind that you need an instanced material !
http://www.froyok.fr/blog/2011-06-code-exil-change-material-ingame
http://udn.epicgames.com/Three/DevelopmentKitGemsHUDDistortion.html
Let me explain in a little more detail, assuming that my plan actually works!
I am looking to implement a realtime GI system using a combination of UnrealScript and DLLBind. The script essentially "packages" the level (or volume) as a sparse octree, which is then passed via dllbind to my "renderer", written in C++ (which actually works! Yay!) which returns an image (ie, the global illumination).
I can pass the image back to UnrealScript no problem, but if I assign it to Canvas I don't know how to apply post effects to it, which it needs, since I have DOF, motion blur and color correction passes on top. AFAIK, the Canvas class acts as a screen overlay after the effects chain, and if I try to implement the DOF and other effects in UScript, it'll be sdlow as hell and probably won't match up.
So my qquestion is, is there a method for applying post effects to the Canvas object, or, alternatively, a way of passing an image from UScript to a material for post processing?
Thanks!
Unfortunately, no way. The first problem is that what you want achieve is not the classic way of how the UDK work, from that, we don't have access to the render directly, we are dependent of the material's nodes for applying special effects.
You also need to write your rendered GI image somewhere for applying it in the material, but packages can't be edited during the game (and after when they are cooked).
The only way to achieve your idea require an access to the render of the UDK (for passing directly a memory image to the render) and by the way it require an access to the full source code (which we don't have with the UDK).
Maybe there is an alternative (by HLSL ?) but I'm not sure at all.
I did already achieve a basic screen-space GI effect by combining SSDO, screen space indirect illumination and screen-spece color bleeding effects as post passes, but I wasn't really satisfied with the result, which I why I started to kluge this together. Hummm... It's a shame, since I really like UDK.
I may have to look at CryEngine, then... See if I can rip out the light propagation volumes and replace it with my GI effect (which is really really efficient...) and add in a few other pieces of HLSL to replicate things that UDK does so well. And see if I can get APEX woring in it. WHich is a bugger, to say the least...
Cheers!
Continues: Compared to the normal posts and issues dealt with on this forum.
There's practically a running gag of "there aren't coders on polycount" even when people post "Hey I'm a coder!"
I'm going to push on with the idea for now, since the idea really works well. UScript does a great job of rapid assembly of the SVOs, and the cone-tracer is lightning fast since I got it optimized. I'm not willing to give up ecause of such a simple issue, and if nothing else I'll find a workaround!
In UDK there is support for Scripted Textures (textures created at runtime by UnrealScript (documentation HERE)
So basically, I run the UScript in the volume to populate the SVO, pass the array to the cone-tracer via DLLBind and receive a bitstream array in return (i.e. an image!) UScript then renders the image from the bitstream (trivial task) and paints it to the scripted texture, which is then called in the post chain at root, to which is then applied motion blur, DoF, color correction and anything else I can think of!
While UScript is slow compared to native C++, it is fast enough for the relatively quick task of constructing SVOs. I decided to go with DLLBind, since C++ is faster, but also to enble me to use hardware rather than software for the cone tracer, and specify a single target graphics card to run it on, thus freeing the system from having to distribute the task across my rig.
Unfortunately, this means the approach is only suitable for my computer at the minute, but with some work I can probably make it more generic...
Keeping my fingers crossed this will work now.
Feel free to come back and show us your results !
Right n ow I'm just starting with the UScript; there's a long way to go. I have SVO-constructor C++, and porting it to Unreal is not as easy as it might appear, since the class structure, while similar, is not identical. I'll report back on any issues I have.
The cone-tracer has already been written in C++ as an exe, so recoding to DLL shouldn't be hard at all (although there might be some malloc and i/o issues to correct). I've also already flow-charted the bitstream demuxer for the image rendering at the end... Again, nothing bleeding-edge in terms of coding here, but I think it may be a little more difficult to get the tick update to sync up... hrrmmmm....
Well, enough technobabble... hopefully I'll have something in the coming weeks...