Take a look at short attached video. On video just simple PDO in profiled metal material. Everything what go in depth are shaded by mesh shadow. Shadow casting work like it have no ideas about any PDO and object mesh cast shadows on to it self parts because now they are virtually offset behinde actual mesh plane… Is there any known way to avoid this issue and make material/light/any cast self shadow with taking in to account fact that material use PDO?
In main work I still working with UE4.19 because of our product/client specific reasons. So I always thinking this is just old 4.19 issue and it already fixed in new versions. But right now I working on my home projects with new 4.26 (few years between 2.19 and 4.26) and this issue is still here, it look and work same way. Does no one but me see something go wrong here?
Any comments from EPIC staff about this issue, is it known issue, any plans to fix it, etc.?
It’s PDO pushing the pixel behind the shadow buffer. Tessellation has the same issue.
With Tessellation this can be remedied by keeping your displacement in the positive value range (so that it is always pushing OUT of the surface) but I couldn’t manage to figure this out with PDO, I assume PDO only offsets inward.
Just keep low enough = just don’t use PDO caus such “low enouh” has almoust no sense… Thing should not work in this way. We have some feature and this feature work as if it broken. We need this feature to have some special solution IMO to make it look as expected. PDO is old as world thing.
I will refresh this topic until get some answers from EPIC devs. Don’t like such cases when something broken and no one care, just like nothing happened.
"Something we unable to address yet (YET!!!). Because PDO is a new feature (time ago it really was a “new feature”) and what needs to happen is to be PDO render during main dynamic shadow pass and apperently it’s a not trivial thing but lot of people asking for it… "
Jan 8, 2016
2016 Carl !!! Today almost 2021… Too much not trivial I guess. Real time ray tracing already here we couldn’t even imagine in 2016. But this thing still same.
All your comment has no sense. No any perfect sense in using not completed feature in broken way just for a bit so it is not so noticable that is it is broken but it should be the only way to use this feature. Thank you for attention but I not looking for such advices. Because of people like u it stay all this years same not completed and no one care…
These issues in the engine are difficult to comprehend for artists and developers. There could be a better, more practical solution often times when it’s suggested to do something that is problematic yet would only partly solve a problem or would be limiting to the result of the project. OP is making a case for hearing multiple different approaches to the issue, so it would be helpful if suggestions weren’t exclusive to ‘that’s only how it works, can/should be…etc’ because it’s quite probable that the devs will get ideas from any other suggestions and/or merited discussion of the PDO issue.
@IIIFGIII
There’s two nodes that are for PDO effects called ddx and ddy, and are used in a few different bump mapping functions without using tangent space. I don’t know if it applies to the PDO you’re doing, but there might be useful information on the following page: Bump Mapping w/o Tangent Space | Unreal Engine Documentation.
IMO such point is not relevant. Most of users, most of cases - see issue, try to google solution, if can’t find solution enable mode “not my business/I need to do my work, I have no tme to waste on forums”. As well as me - I saw it broken, I said my self “they will fix it somewhere in the future”. Speaking of my personal case - I still working on main work with 4.19 because of reasons related to my clients. So I not really follow all new changes (only some really major things) in new releases and I thought that this issue already fixed nowadays.
Why others do not sitting here and asking for doing something with this issue - maybe because after few days I still don’t see here reply like "** I am developer from EPIC staff, let’s talk about this issue, etc.** ". As I guess no one who reply here at this moment not in touch with UE development (correct me if I wrong).** People usually busy in their businesses and have no time to sit on forums and wait for miracles.**
If this guy in video from 2016 said true - there is way to make it work properly with dynamic lighting. But I see here no comments from real developers. Do any one from render engine development team check this forum thread at least once in a week?
Thank u for reply, but I not sure if bump mapping have anything to this.
Goal of using PDO - to make flat planes with profiled metal material (relief IRL) look more realistic. Make it as mesh cumbersome but possible solution. Btw point of topic is not about how to make it, but in general about issues related to using PDO for such cases in dynamic lightting scenes.
It is only broken according to your perceptive judgment.
Technically, it is working exactly as it should. If you think otherwise, it is only due to you not having deeper insight into the issue.
Likely, because majority understands that this isn’t an issue, as well as having understanding what needs to be sacrificed to make changes to overcome the limitations. Multiply that by percentage of people, who are actually affected and again multiply by a fraction of affected people, that are not flexible enough to deal with limitation on their own and it is very likely that you end up being the only one. Besides, you are on average 3 years behind, as the topic was discussed all over the forum and other resources.
I personally think that this thread is not worthy of staff’s attention. Because it would likely boil down to familiarizing you with technical details of why this issue exists. And once you are aware of them details, you will instantly realize the reason why nothing was ever done. But with due diligence, you do not need someone from Epic to explain it to you. Shadow mapping is far from cutting edge of technology and there is sufficient material on it on the plains of internet.
Out of luck, bruh. Only random hobbyists.
Real developers, likely, don’t have time to educate everyone individually, especially ones with dismissive attitude.
You never know, but very likely that yes.
There certainly is. But it is on you to implement. And with your current attitude, you are not getting much further with it.
It is not targeted at you, but rather others, who might read the thread and get wrong impression that there is an issue while there is none.
Not on me. Development of UE is not my work, I not geting money from selling UE… If possible solution exist, but after so many years not implemented - feature is “not completed”. Maybe it can be completed to make it work with dynamic shadows properly. But it is question to EPIC devs (not to you) and I still waiting for their reply.
I not looking here for you teaching me with your argumets why (on your point of view) this is not an issue. If this is not an issue for you - why youspend here so much time to arguing something? What’s wrong with you man?
When your mesh low enough that will hardly cast shadow on other objects,you can switch on"self shadow only " in actor detail.In that case,mesh can still recive right shadow with no self shadow issue.
This thread was a miserable read with no knowledge anywhere to be found. Considering how common this issue is, I wanted to add some information for anyone else who found this and felt disappointment and second-hand condescension.
PDO has some unfortunate lighting issues… The original poster was searching for a way to enhance their geometry through offsetting the pixels in parallel with some parallax effects. Now with nanite, I would suggest using a higher detail model and bypassing this issue.
However, PDO still has some valuable uses, like blending meshes with terrain (or terrain with meshes, depending on which material you want to use the PDO).
Your best option is enabling distance fields in the settings, and on the desired mesh, and using the DistanceToNearestSurface function.
I’ve noticed that it seems best to not over extend the mask, and it actually improves the outcome for it to vary in depth between that 0 to 1 range.
This is not quite as precise as it would be without distance fields and you’ll notice it doesn’t always blend well. That requires some level adjustments to get a decent outcome.
If anyone has found a better method, feel free to share.
