I’m getting a lot 3D Delight errors when I use a Deep Shadow Map on a Distant Light (See screen shot). Does anyone know what is causing this and how to fix it? It’s also messing up the render in different ways as well. If the answer is posted somewhere, please feel free to post a link.
I could be wrong but it looks like you have an improper texture map ‘brickyard’ in that it doesn’t work as a displacement map for some reason. I would try finding that surface and disabling the texture in question temporarily to see if the error goes away. If it does, it would at least let you know where the problem is so you could figure out what you wanted to do to fix it.
Thanks for the replies. Yep, there is no problem when I switch from deep shadow to ray traced or if I use Uber. The texture is actually one that came with V5, Bree. I’ll fiddle with the displacement map and see what happens.
Arr there we have it Bree is either Human Surface Shader or UberSurface and therefore requires Raytarcing to be the most effective that is where the message is coming from.
Arr there we have it Bree is either Human Surface Shader or UberSurface and therefore requires Raytarcing to be the most effective that is where the message is coming from.
I don’t really agree with this Deep shadow maps have there place and can often be as effective as raytracing, I find the bug in DS with Deep shadow maps to be just that a bug, deep shadow maps should not produce error messages and the artifacts that they do. The work arounds are just that - a way of compensating for mistakes in the software.
If you have a high end machine raytracing is fine, if working on a lower end machine deep shadow maps are often more preferable.
So in my opinion don’t just ignore the error messages put in a bug report.
I have to agree with Scorpio64Dragon. There have been problems with the deep shadow maps for as long as I can remember, especially the artifacts. With DS 4.5, something else has changed (broken) with the shadow maps. The actual texture itself shouldn’t matter to a distant light with deep shadow map. Those designed for SSS would simply “look” better when you ray trace or Uber lights.
See pics below. This is the Bree texture. Ray trace does fine but I don’t understand why I get that error and why it renders the way it does when I switch to deep shadow map. It shouldn’t matter one way or another. Right?? Or not??
WOW.. it’s rendering the skin gold like that? Notice the one extended arm, the fingers are normal shaded tint and yet the arm supporting the dragon the hand is even more intensely shaded, like an orange color. ODD!
Arr there we have it Bree is either Human Surface Shader or UberSurface and therefore requires Raytarcing to be the most effective that is where the message is coming from.
I don’t really agree with this Deep shadow maps have there place and can often be as effective as raytracing, I find the bug in DS with Deep shadow maps to be just that a bug, deep shadow maps should not produce error messages and the artifacts that they do. The work arounds are just that - a way of compensating for mistakes in the software.
If you have a high end machine raytracing is fine, if working on a lower end machine deep shadow maps are often more preferable.
So in my opinion don’t just ignore the error messages put in a bug report.
What I am saying is that HSS or Uber Surface 1 and 2 will give better results when raytracing is used. I didn’t say you couldn’t use deep map shadows as the error message doesn’t interfer with the rendering process and does give resonable results. I never said I agree with it either. The error messgae btw has been around since DS3 which makes you wonder why we are still seeing it.
It’s an informational message spit out by 3Delight saying that particular item/texture is using 0% of it’s allocated displacement…in other words, it’s NOT being displaced, probably because Displacement is ‘on’ but no displacement map specified.
Here’s the 3Delight info on that specific message…
R2093 object ‘name’ (displacement ‘shader’, surface ‘shader’) used only usedbound% of its displacement bound
The displacement bound specified for the object is much larger than needed. Performance could be increased by reducing it.
Somewhere, I can’t find right now, there’s a list of what the severity levels mean…
The problems with deep shadow maps, in general, ARE NOT Studio problems, but long running and OLD 3Delight problems. The work arounds are from the movie studios/effects houses and 3Delight dev team itself. They are probably core problems in the base code/specification…
WOW.. it’s rendering the skin gold like that? Notice the one extended arm, the fingers are normal shaded tint and yet the arm supporting the dragon the hand is even more intensely shaded, like an orange color. ODD!
Very cute character!
Yes, and sometimes it’s just odd places or the whole body. Sometimes the whole body turns red like her right hand. Well unless anyone has anyone has any ideas about the deep shadow map, guess I’ll need to switch to ray tracing or use uber lights.
WOW.. it’s rendering the skin gold like that? Notice the one extended arm, the fingers are normal shaded tint and yet the arm supporting the dragon the hand is even more intensely shaded, like an orange color. ODD!
Very cute character!
Yes, and sometimes it’s just odd places or the whole body. Sometimes the whole body turns red like her right hand. Well unless anyone has anyone has any ideas about the deep shadow map, guess I’ll need to switch to ray tracing or use uber lights.
Thanks Wolf. That’s Mavka for Genesis by Smay.
There’s something else going on between those two renders than what the message is informing you about.
Just to be sure…the same lights are used for both renders, but the only difference is shadow type?
The various settings like SSS and ambient are the same…basically, there’s no other changes to the surface settings.
Things like bump/displacement/specularity maps are properly assigned…(like the limbs maps are actually on the limbs and not the torso maps)
Are you using progressive rendering?
Any actual rendering errors (severity level higher than 1) showing up in the log?
But h=yeah nothing to worry about.
