Twice you ignored me when I said a bug was found that potentially effects any 3D game with a day and night cycle. I question your and Unitys priorities since it feels like the goal is too much about having positive things to talk about rather than focusing on what makes good software.
As in, focusing on a new performance upgrade so the next social post can say something like “We improved shadows performance by 30% in URP, go switch now!” rather than investigating a bug that has serious implications on your core tech.
Previously you recommended a bug report, well I did that Three Years Ago and had it confirmed by QA (eventually) with the resolution of “This issue requires a larger change and will be investigated separately.”.
Flickering shadows is something you should be taking very seriously, why are you not?
I am not intentionally ignoring any issues mentoned in this thread. There are quite a few issues mentioned here in this single thread, and I am not individually capable of answering all of these questions or solving all of these issues. I have asked the URP team to directly respond to this thread. Most of the people who respond to posts in the forums are the people in Unity who care the most about the problems you are facing, so please don’t question their individual priorities, as most of the people commenting in the forums do not control the roadmaps.
I don’t actually own this area, so I do not control the prioritization around almost all of these issues, and I have been mainly supporting this thread because of my personal opinion of the importance of high quality and stable shadows. I joined Unity a year and a half ago, and my team specifically own the mesh API and also the culling area, so the questions that I seem to selectively answer are generally the ones that are specific to my team, but in this thread, I have gone beyond my area of technical ownership to support as many people here as possible, and I have been having extended discussions in DM with as many people as I can personally manage, but the problems in the technical area of shadow mapping are numerous, and this isn’t sepcific to only Unity, and these problems vary wildly between scene configurations. Industry research in the area of shadow mapping has signficantly reduced over the past few years, which doesn’t help either. My team has inherited a lot of responsilbility, but we also cannot solve all of the problems ourselves. We are currently heavily focused on improving the skinned mesh renderer API and also developing a (fully conservative and fully dynamic) occlusion replacement for Umbra, which is a massive effort and extremely critical task, which is my team’s primary focus, and that work is mostly unrelated to this thread.
The conservative enclosing sphere is not primarily a performance optimization. It is a critical core foundational problem with our frustum culling, and in my personal opinion, it is the most critical. The problem was actually reported as a bug due to the erroneous culling of shadow casters. It also fixes issues with shadow fade, and many other crital problems that I mentioned in my previous posts, and also happens to potentially improve performance as well. These spheres are actually used to stabalize shadows from camera view transformations as the shadow maps are relative to world space and invariant to camera translation and rotation (though it is still sensitive to field of view changes and other things). If you are interested in understanding one of the other problems with regards to shadow flickering, there is an old relevant publication in Shader X7 in the chapter on “Stable Cascaded Shadow Maps”.
With regards to the issue that you individually reported. There was quite a bit of effort put into the problem analysis internally, but it was converted to feature request, as it is an edge case for a very complicated problem, and we receive a very large number of feature requests for incredibly specific problems. I personally cannot comment on the prioritization of that issue as it is outside the scope of work for my specific team, but I have asked others to follow up in this thread.
Yes but you directly asked me for more information and did nothing with it at the time (so far as I know) until I called you up like this. That is when it feels like ignoring.
I do this because frankly Unity has been dropping the ball lately at an impressively consistent scale and I feel its fair to say a lot of users are sick of it. In this case I think it was fair to originally question your priorities since as you say you chose to respond to the area your team is handling. This means your first reaction was to ignore a bug because it was not in your working area but instead you made a large post talking about other things.
If instead you had simply said something like “ah sorry not my department, try reaching out to person X” then I wouldn’t be questioning anything and would have taken the conversation elsewhere.
By not doing that, I think its fair to question your priorities. Especially since it has nothing to do with Unity’s roadmaps and internal process but how you choose to handle the information presented to you on the forums.
Reading your assessment of this all sounds sensible. My summary of it being only for performance was as an example rather than me knowing anything about the feature. I did this because I admit I skimmed what was being said partially because I was annoyed but mainly because when I see SRP I switch off because of reasons stated in my other posts.
Wow. Now this Really makes me question Unity’s priorities and working practises!! I really don’t see how wanting stable shadows in an open world game can be viewed as feature request and not a bug or fundamental flaw with real time shadowing. The only situation that makes sense is if Unity’s official view is that day and night cycles are not supported, which is madness for a 3D games engine.
Anyway I’m getting side tracked and as you say that is out of the scope of your team. I do greatly appreciate you looking into it now since from my perspective it feels like this issue could have huge implications but has still been pushed to a side. I’ve yet to hear good reasons as to why this is edge case and I’m looking forward to hearing more about it.
I think from this point it’s fair that any communications you make are accompanied by a bug report as you’re still wilfully ignoring staff going out of their way to help. They don’t have to. It’s not their job.
Honestly there’s a line between being irate at unity and irate at staff. Your tone is irate at staff which has made me lean in. I hope it’s just frustration talking though. If you were able to make a thread about your issues perhaps workarounds exist for them?
But I do have a bug report, that is what started all of this and what I am trying to talk about. It was even acknowledged as a “very complicated problem”. Complicated issues require discussion to resolve them.
It was also described as edge case. Edge cases require discussion to determine just how edge case it truly is.
I don’t see how I am. I feel a member of Unitys staff acted unprofessionally and so I told him that. Am I not allowed to criticise someone simply because they are employed by Unity?
Anyone’s job that involves creating anything requires you to gather feedback on your product. It might not directly say in their contracts that Unity staff must spend X time on the forums but they are clearly encouraged in some form to interact with us here or they would never do it.
I feel I had a valid reason to raise criticisms here and I don’t appreciate your attitude that I should effectively shut up and be grateful simply because others have to pay for support. I took time out of my day to help Unity improve their product by submitting a bug report, should I tell them to be grateful that I didn’t charge them for my time?
My post was absolutely directed at staff, but I feel I had a valid reason. I was specifically asked for more information and then ignored. I find that rude and the only way I can direct that is personally.
Like I said, if the response was along the lines of that is not my department, I would have asked for who else I could chase and left it at that (whilst starting again with whoever was recommended).
The whole point about this is that the process is a black box. It started with me making that bug report and having to really fight for it to be taken seriously. It was instantly dismissed because I found it in BIRP, and then then it was shelved.
If its a bigger issue, I’ve said from the start that I fully accept that. The problem is I have no idea how big of an issue it is. I don’t know if it will ever be solved. All I know is this started because shadows in my game where flickering horribly at a distance. I spent a lot of time tracking it down and found I could recreate in a simple scenario of just 2 cubes and a spinning directional light.
To me, this seems like a Very fundamental issue that could affect any open world game with a day and night cycle. But whenever I try to talk about it, it gets ignored. I don’t know how big of an issue this is because no one seems to want to talk about it. Even in Nigels reply, all I know from it is that it was investigated and deemed complex but edge case. I don’t even know why its considered edge case, I don’t know why its deemed complex.
All I truly know is that in an extremely simple scenario, Unity doesn’t behave as expected and no one seems able to tell me why.
However my main frustration here is around the process. If after that investigation someone updated the bug to show what was learned, and why it was shelved then I can at least have an understanding of what is going on and accept that I might need either horrible hacks or custom systems to over come this.
Maybe that simple scenario I found has nothing to do with the flickering shadows I see but I have no way to know until I get more information on that bug report.
Just so people don’t think I’m making this up, the bug is still present in Unity 2021:
This is the code I used, happens with both quaternions and traditional axis angle rotations:
public new Transform transform;
public float speed = 3;
public Vector3 axis = new Vector3(1, 0, 0);
public bool useEular;
public Vector3 eular = new Vector3(3, 0, 0);
void Start()
{
transform.rotation = Quaternion.Euler(85, 270, 0);
}
void Update()
{
if (useEular)
transform.Rotate(eular * Time.deltaTime);
else
transform.Rotate(axis, speed * Time.deltaTime);
}
What you are seeing is me hitting next frame. The first time I press it the shadow gets longer to the left, this is wrong. Then I hit next frame and it gets shorter, this is correct.
By hitting next frame a few times you can see the shadow getting shorter, shorter, longer(wrong). It should be consistently getting shorter and never getting longer (until the angle flips to the other side of course).
I have no idea what implications this has. All I know is that there is a high chance it is causing issues in my game where the light is at a very steep angle for a sunset/sunrise and shadows appear to jump back and forth.
In the original bug report I found a way to show this really prominently but I didn’t take the time today to try to do that.
Here is a more ‘real world’ example of the bug that I came across today that was particularly bad. I really don’t understand how this is deemed as a feature request and not as a critical bug:
