I am starting this conversation, purely because a bug that I have reported has been deemed not critical for the upcoming LTS release (not to mention previous LTS releases that also exhibit the same issue)
The bug in question is a significant issue when working cross-platform (especially renderfarms), as blender will produce inconsistant results compared to each other.
I want to understand how the triaging system works, and how the different levels are allocated.
There’s some confusion here because while the bug triagers are saying the issue is definitely not going to be fixed for 3.3.0, it can still be fixed for a 3.3.x LTS release.
Bugs like this will be looked at by the maintainers of the relevant module, they will decide case by case what to prioritize or consider critical. It seems you accidentally removed the Nodes & Physics module tag which would make the module not see this bug, though it can also take a while until the maintainers get to it regardless.
Its been another 2 months and havent seen any action going on at all. This has been a common theme on my bug reports aswell (some lasting many years). The others are not as critical as this one though, it is essentially a show-stopper for our workplace.
I know it only effects production workflows, but they are still important. There are now two LTS versions (3.3 and 2.93) that this effects.
I personally would have classed this as critical, however I am not in charge of triaging / making the changes. I am super surprised it wasnt picked up earlier. I guess most people stick to one platform rather than work on one, render on another.
In any case, what is the process of getting this fixed and into a LTS releases? there was a post recently from Ton saying that LTS fixes should be monthly.
Personally, I don’t see any error here. Yes, different systems have different noise hash implementations. It happens. To fix it, you probably have to change how the whole program creates noise, just to unify it at the level of the program, and not the OS (but this is just a vision of a non-specialist from the outside). This is if we talk about priority (again, my opinion).
And at the same time, the last month there was a blender conference. The work process basically stopped for 1 week.
To fix it, you probably have to change how the whole program creates noise, just to unify it at the level of the program, and not the OS (but this is just a vision of a non-specialist from the outside). This is if we talk about priority (again, my opinion).
Um, yes and no. Have a look at cycles, it creates noise consistantly across OS’s. Not to mention this was NOT an issue with 2.79
Having consistancy is key, especially trying to push the professional area, as artists are working on windows machines (for photoshop), seeing trees generate (as they are on hair) differently to how it renders on the render nodes, which are linux machines. It could mean the difference between having a nicely framed shot, and a shot which has the camera going through a tree.
I sortof looked into it a bit. And I don’t really understand why it’s different. As far as I can tell the particle system just uses the random functions from BLI_rand.h, which in turn use the rng from BLI_rand.hh. And I don’t see anything platform specific in there.
To really know what’s going on is quite a complicated bug hunt which needs a build environment set up for both linux and mac/windows. As I don’t really have much experience with windows I can’t really do that. On top of that the particle system is being phased out so it’s not the most rewarding piece of code to spend huge amounts of time on (for a volunteer developer like me, at least).
And while I agree with you that it should be consistent across platforms, apparently it’s not a huge problem in the wild as (I think) yours is the only complaint about this that’s been received.
If I can find some time later this week I’ll try to go over the code a bit more to see if I can spot something platform-dependent, but don’t get your hopes up!