UDK - Shadows - Dynamic, Vertex and Self
polycounter lvl 12
Heya peeps,
I'm having some issues with UDK's shadows, and here is the issue (if anyone is kind enough to help me with their every lasting love of being a good Samaritan - pun intended).
I'm trying to display a single, low performance, cheap model in my simple scene, but UDK doesn't seem to want to budge in giving me good looking shadows.
What I mean by this is the following:
1- Dynamic Shadows: I don't know why, but UDK doesn't want to cast ANY type of Dynamic shadows, regardless of light-type of channels I enabled.
HOWEVER, I do SEE my Dynamic shadows, ONLY when I select the light source. Again, I'm trying to make a demo piece in which I would like to preview on how my dynamic lights will look, but can't seem to get them to work in the viewport.
I also tried baking light-maps, hoping UDK was 'wake' up to my issue, but nothing happened.
So yeah, first issue, Dynamic lights don't seem to work UNLESS I select them and as soon as I deselect them they vanish.
Please don't tell me I need to 'compile' my level and preview it as a game since I'm pretty sure the old versions of UDK didn't have this new 'default' issue. And yes, I did try a compile and bake, still same issues persists.
===============
2- Self Shadowing: I was reading up on UDN on how UDK doesn't support Self-shadowing for Translucent materials, OK, fine by me I said.
However, the current self-shadow in UDK on Opaque materials ;ooks pretty horrible, as in Hatching horrible, I can't say on how it looks blotchy and jaggy, I was wondering apart from a standard Lambert term in shader, is there any other way to solve self shadows?
Extra reason explained below;
========================
2- Related to above: Many pieces of my model have 'round' surfaces for a lack of better terms, however, UDK seems to not only break my dynamic shadows (at least the one in my material editor preview), but is reverting to Vertex shadow's for my Dynamic models (same like it's doing to my self shadow).
Many of my shaders are, again, not Lambert, they're half-lambert setup, so they really do rely on the shadows to look good to compensate for certain issue, but as I said, UDK doesn't seem to want me too give decent looking shadows which are dynamic in the first place.
I tried setting up my INI files to force them to access and buffer 4K dynamic shadows a la Skyrim style, but it still seems to limiting itself to 1K at most. I know this because it's literally creating tears ON the polygon faces VS. shadows jags and tear via standard lighting.
Please don't link me to the UDN documentation since I read them inside out over and over again, and they don't give any solutions to any of my issues that I'm facing, especially as to why UDK doesn't want to even give me a HINT of dynamic shadows anywhere.
Cheers and thanks in advance.
I'm having some issues with UDK's shadows, and here is the issue (if anyone is kind enough to help me with their every lasting love of being a good Samaritan - pun intended).
I'm trying to display a single, low performance, cheap model in my simple scene, but UDK doesn't seem to want to budge in giving me good looking shadows.
What I mean by this is the following:
1- Dynamic Shadows: I don't know why, but UDK doesn't want to cast ANY type of Dynamic shadows, regardless of light-type of channels I enabled.
HOWEVER, I do SEE my Dynamic shadows, ONLY when I select the light source. Again, I'm trying to make a demo piece in which I would like to preview on how my dynamic lights will look, but can't seem to get them to work in the viewport.
I also tried baking light-maps, hoping UDK was 'wake' up to my issue, but nothing happened.
So yeah, first issue, Dynamic lights don't seem to work UNLESS I select them and as soon as I deselect them they vanish.
Please don't tell me I need to 'compile' my level and preview it as a game since I'm pretty sure the old versions of UDK didn't have this new 'default' issue. And yes, I did try a compile and bake, still same issues persists.
===============
2- Self Shadowing: I was reading up on UDN on how UDK doesn't support Self-shadowing for Translucent materials, OK, fine by me I said.
However, the current self-shadow in UDK on Opaque materials ;ooks pretty horrible, as in Hatching horrible, I can't say on how it looks blotchy and jaggy, I was wondering apart from a standard Lambert term in shader, is there any other way to solve self shadows?
Extra reason explained below;
========================
2- Related to above: Many pieces of my model have 'round' surfaces for a lack of better terms, however, UDK seems to not only break my dynamic shadows (at least the one in my material editor preview), but is reverting to Vertex shadow's for my Dynamic models (same like it's doing to my self shadow).
Many of my shaders are, again, not Lambert, they're half-lambert setup, so they really do rely on the shadows to look good to compensate for certain issue, but as I said, UDK doesn't seem to want me too give decent looking shadows which are dynamic in the first place.
I tried setting up my INI files to force them to access and buffer 4K dynamic shadows a la Skyrim style, but it still seems to limiting itself to 1K at most. I know this because it's literally creating tears ON the polygon faces VS. shadows jags and tear via standard lighting.
Please don't link me to the UDN documentation since I read them inside out over and over again, and they don't give any solutions to any of my issues that I'm facing, especially as to why UDK doesn't want to even give me a HINT of dynamic shadows anywhere.
Cheers and thanks in advance.
Replies
:poly142:
So, DominantDirectionalLight Doesn't cut it? Your using an old build of UDK correct? They should still show Per-object dynamic shadows on non StaticMeshs. IDK, Maybe your on a lower quality level? Dynamic shadows work fine for me.
As for the hatching, that has to do with the shadow biasing IIRC.
But yep, I pretty much did everything, from boosting the Bias to low figures to increase shadow strands, but no dice, it's almost as if UDK only wants to use 1K dynamic scale. Kinda like a recent bug that ZB had, where if you increase the shadow ray count, it keeps it's locked at 1K and doesn't go to 2/3/4K values.
I did the change via INI FTW.
I'm using the latest version of UDK, and pre-latest version I have used is December.
Also, Dynamic Shadows work, ONLY in the Material Editor (albeit pretty horrible looking) OR when I put up a light source in my scene and have it selected. If I deselect my light source, it stops casting dynamic shadow instantly, which doesn't make sense.
I also did check my mesh channel for Dynamic Shadow casting, etc, but no dice.
Forgot to mention, does it matter if my mesh is static or skeletal, and should shadows change based upon this? I pretty much made sure both of them have the same options enabled, not sure if it counts.
Not sure if I correctly understood your problem, and I'm aware that you've mentioned compiling in your post, but I'm assuming that you are refering to baking static lighting.
Did you try opening the World Properties menu, going to the Lightmass tab and enabling the "Force no precomputed lighting" option? You will need to rebuild the lighting afterwards to see the dynamic lights in the editor. Also, once you edit your scene the quality of your shadows will degrade and you will have to rebake the lights again. Unlike baking lightmaps however, this takes only a second.
As far as I'm aware this will work only with Directional Dominant lights. I've been using it mostly for outdoor scenes so I can't really say how it fares with Point lights. You can also use a mixed setup. And have both the static and dynamic lighting at the same time. You will need to bake lightmaps the normal way, then select your dominant directional light and set the "Whole Scene Dynamic Shadows" to your desired value in Unreal units. Something like 512 or 1024 should do the job. This will give you static lighting from far away and dynamic shadows up close. You can change the quality of the dynamic shadows by editing the other values in Cascaded Shadow Maps tab.
Speaking of lighting channels, I could never get that to work either. Isn't this a legacy feature or something?
Regarding the Ini files, sometimes UDK reverts them back to their default settings. On a few occasions I had to set the ini files to "read only" after editing them to keep my settings.
edit:
Hah, Jordan is here. You should listen to him. I'm just saying what works for me, I can't say whether it's the proper way to do these things.
I tried all the light types, here is what they look like with all types of converted models, here is a example of happens in the basic default scene:
After some fiddling around, by PURE luck, I got this, but with some oddity:
Same setup by the way as prior by the way.
If I spawn/clone my light sources, it seems to be negating my shadows (pending on which light is closer to the model).
So this kinda means if I have two filler lights and one to cast shadow, my shadow light must be CLOSER to my model for it to cast the shadow, since the filler lights being closer will override it and negate my shadow cast.
Can it be confirmed if this is the case? I looked up on UDN again and can't find any mention of a the closer light negating my shadow (while the mesh recives the light riddance correctly). I don't require more then one shadow for my per object in my reel, but this this seems like an odd setup for shadows, can't find info for it on UDN.
Case solved? Not really, since even if I force "Don't cast shadows" for my filler lights, it will still negate my shadows, any help in that regard? It seems odd that I can't have one light be my 'shadow' light and two as filler without each one negating each other in the same scene somehow....
============
Hey TeaAndCigarettes,
Thanks, that was part of the issue previously mentioned, that's one less problem to deal with later on.
As for the Channels, no idea, if indeed, it is legacy, I didn't read anything about it being as such.
INI files, I lock them all the time and a default backup just incase, so unless UDK somehow is able to unlock Read Only, I would say they 'should' be fine...should...
The dynamic shadows seem to work "fine" when I give my rig a mesh (so that it's a 'skeletal' mesh and not a 'static' mesh). However, the value of "fine" decreases rapidly as distance to the object increases, when using translucency or 'custom lighting' which is non-zero for angles past 90 degrees (i.e. normal dot light < 0 ). Lighting models other than 'custom' naturally go to zero when the dot product goes to zero. The upshot is that self-shadowing doesn't appear to work on not-perfectly-opaque materials - from a distance, anyway. Opaque materials aren't self-shadowed from a distance either, but it's less noticeable. Very frustrating :poly127:
(This is for in-game use, BTW)
Here's what happens:
Ah, OK, understood, will try and report back.
EDIT: OK, maybe I'm dumb, but I still don't see where I need to disable for said effect.
Complimentary video by Problem and Co.
http://www.youtube.com/watch?v=t37CXFLLc4I
The shadows look low-rez, but that's not an issue since I don't have a physical material setup, so that can be fixed pretty easily, however, the lights still negate each other pending on distance.
Also, it seems like the model had a rim-light effect on it, so the actual fill light wasn't affecting it, oops, my bad.
Anyhow, as you can see, I tired disabling and enabling pretty much everything in both light and mesh option for shadows, issue still persists.
====
Yep, I know, it isn't too bad if you make a custom AO map for a Custom solution and stick it in your Diffuse light slot, faking shadows, it works pretty well actually and you don't have to worry about half of this stuff, especially if you set it as a standard Lambert term.
Extra texture and instruction space, but should serve well.
Also, I disabled Precomputed Shadows and Light Environment Component, just as you said.
Honestly, I'm baffled, I know I can trust both you and UDN, but as to why my shadows refuse to work is beyond me.
Thanks anyways I guess, still didn't work, so I'll try the latest version of UDK on another PC and see what's up.
EDIT: OK, I swear, I just started up my scene and my lights turned into black icons and not green like they were before.
Also, I went into my nVidia drivers, and reset everything back to default, and disabled any fancy 'effects' like AO which I had activated.
Seems like the shadows and lights are working correctly now, no idea what I did, but if anyone has issue, just restart UDK and default your driver profiles is the best thing I can think of at this point.
Cheers and thanks guys, much appreciated for the 'stay-in' on the issue.
Quite a few things going on here (SSS, 'physical' lookup-based specular, rim light, AO and translucency mapping), but it comes in at about 120 instructions and 5 texture lookups (3 on greyscale, one colour, one normal), including a 'physical specular' rho value lookup texture.
Note in particular the translucent ears in the top photo - that was what I needed the shadow falloff for, otherwise the ears (and nose) light up from behind at a distance :poly141:.
Pretty pleased with it, for an in-game-complexity shader, but any suggestions welcome.
Credits:
- head model - http://www.ir-ltd.net/infinite-3d-head-scan-released
- SSS and specular based on the DT3D skin shader, but without the patented (and somewhat dodgy) use of half a dozen normal maps.
If you want I can post up the INI files and you can take a look? Although it might blow up someone's PC.
Also, the Rho lookup, is it Gaussian or Beckmann based texture, and what Specular did you go with? I tried a Kelemen Kalos, but found it too confusing for user based input, so went with a lite Cook-Torrance instead and some Strauss.
And how many layers do you use for the SSS from D3TD? The D3TD SSS shader for UDK is nothing more then a Diffuse Power based Lambert setup, glorified with a complex Blended Normal using blurring Normal maps approach, so I cut out the fat by making it directly Normal Blended with 3 values instead of 2 and much easier to control the color values (especially if you don't want 'red' scatter only).
Also, thanks for the link of the Head, gonna get me a nice head to test stuff with, cheers!
The specular I'm using right now is just the precomputed Beckmann implementation pulled straight from the DT3D material (same as an nVidia GPU gem, I notice, so I guess the credit goes there) but the full effect is lost as I haven't really played with the specular yet - the specular map is currently set to 50% grey. I do like the look of the Cook-Torrance though, to my eye it 'flattens out' the reflectance value more realistically at shallower angles. Something to play with more...
For the SSS, I'm using the 6 layer model, but biasing the dot product from a single normal map instead of using blending - I'm not planning on highly detailed normal maps (this is intended for in-game, and it's a solo project so art time is at a premium), and this works quite nicely in softening the shadow edge in relatively smooth areas, and handles a small amount of normal detail (if I start using a highly detailed normal, I'll probably just use a blurred version for the SSS term). Say dotNL = dot( lightVector, normal ), the layers each use dotNLBiased = clamp( a*dotNL - a + 1 ), with a different value of a per layer - mostly a > 1, but a couple of the redder terms have a < 1. Basically just normal-bending after the fact. BTW, have you tried using tex2DBias() for the blurring? Looks like it has potential for this kind of thing in a real-time context...
A lot of what I'm doing at the moment is focussed on keeping the art pipeline as tight as possible - makehuman for base meshes, some minimal manual modelling & colour painting on top of that. AO and translucency maps baked using standard techniques. The more I can bake instead of paint, the more characters I can create. I'm going to see if I can have a standard UV map for faces so I can compose a dozen or so 'basis function' specular maps (e.g. with different variations focussing on lips, nose, forehead etc.) that I can just dump into layers in GIMP and tweak the opacity sliders to create a wide range of variations.
The reason I like the high-res head scan is that I can play with the shader without my mediocre modelling skills distracting from the problem ;o)