am i missing something here? there is an unbiased toggle in the render settings, but disabling it does not restore any step-size options.
its fine to offer an unbiased option if quality matters more than speed, but it feels wrong to unilaterally say “only quality matters and speed doesn’t” when there are a wide variety of project needs, and volumes are already notoriously slow, and this ‘tradoff’ can sometimes lead to a doubling of render-times in their own examples. i quite frequently made use of step size to optimize renders where larger step sizes provided massive speed ups and the visual tradoffs felt non-existant.
i’m sure you can cherry pick cases in either direction, but ultimately taking away an artist’s ability to decide for themselves is a loss in my books.
On a serious note (not directed to anything particular posted here), complaining during development stages is often positive feedback as long as the complaints are well founded.
Yeah, but how likely is it that the devs will actually leave something that doubles render times without any options to adjust it?.. I have more faith in them than that. Unless of course the previous functionality had some really huge issues.
I was not referring to this particular case, just about all rendering parameters have options to sacrifice quality for speed and volumes in particular need them.
I have had cases where lowering the step rate actually gave me better results, more visually pleasing.
I would not go that far but there are (and could be more) things like Optix that are only for Nvidia cards. Blender should make use of the technology that cards offer.
Also looking at AI, AMD currently is close behind Nvidia. It’s always been stupid to run behind only one technology. I remember people not giving GPU a chance and rather stay in CPU… now things are different, or?
i will contend that sometimes a little bit of pushback on developers is useful in making people aware of oversights.
case in point, at some point in the 4.x series, they made a change where if you tab toggled the graph editor from the timeline editor, it would permanently exit you from the timeline view and force you into dope sheet when you tabbed back out. this was both disorienting from a user standpoint, and lost some functionality (being able to make fcurve adjustments to your keys in that view, while keeping all your timeline controls, etc). the initial response from the developer triaging the report was somewhat dismissive before there was a bit of pushback from other users, as well as other developers agreeing that it did seem confusing, and they were able to revert the old behaviour.
long story short, a developer is not a god (i say this as someone who has programmed things and gotten user feedback myself), and moreover, staying silent and “trusting” them isn’t always right either. i saw in the bug report thread the one developer telling users “if you actually cared that much about this bug you would have reported it sooner” as a justification for not fixing the behaviour.
I have definitely seen that responsiveness for UI bugs and smaller things like that. The place where it becomes less helpful is large structural changes or things that require a lot of work to change.
The devs should make this button do something slightly different is a little easier than the devs should make shader compilation faster, you know?
of course i’m not advocating that any random user whim should be accommodated haha.
and in this particular case, advocating for the benefits of a custom volume sampling step size, given that it has been a longstanding option that has concrete benefits, feels fairly reasonable?
this would be like saying “we removed user configurable light bounces since anything less than the maximum is less accurate” ignoring the optimization and stylization opportunities than it provides.
i only say push back because the original developer took the bug report, said it wasn’t important and closed it, before people did persist a little more and they capitulated.
definitely not advocating for bickering with developers or anything, just that sometimes they can be a little too eager to dismiss a legitimate concern!
Well, maybe run some test with the new algorithm in your existing scenes and provide real world examples with numbers to the developers as arguments.
In general they keep many options so if they don’t there is probably a good reason for it. That’s why we have various sky texture algorithm, as well as SSS, or boolean…
my point is that there is room for discussion on both sides. so no i’m not expecting immediate capitulation, but also i’d hope they’d listen to reasonable arguments in favour of something.
perhaps i will run a test, although its somewhat redundant since in the developer’s own examples it can run over twice as slow on gpu, which is kinda the default for rendering these days.
i could not tell you the difference between the two output images except that on gpu the newer approach took 11s while the older approach took less than 5s. extrapolating those results from a 512px image to a hd or 4k frame, multiplied over the course of an animation, that is a lot of extra time for an unclear benefit.
edit: someone has already filed a bug report reinforcing my concerns, where they observe a real world 30x slow down by removing the ability to optimize and sole-ly favouring accuracy. https://projects.blender.org/blender/blender/issues/144706
Yes ! From what I read in the PR , Brecht asks for test files so they can see if the current algorithm is fixable or if they need to make things differently…
So it’s probably worth testing on your own files especially if you can share the volume part. It doesn’t seems they are settled on the mater anyway, so it’s the best time to participate to the discussions.
However, you talk about “immediate capitulation” : it’s not a battle, we are all on the same side here. Devs won’t do something that would make blender worse unless there is a really good reason for that.
If you’re concerned provide good examples, show a constructive attitude in devtalk and it’s very likely that devs will listen and provide answers to your concern. It’s great to bring awareness here, but it’s likely to have a very limited impact on blender.
This isn’t an artifact about the previous method, by the way, this is about how volumes handle mesh unions (when they’re not a single object) and instances. I reported on this a while back, and Weizhen had fixed the behavior, but it didn’t merge because it slowed down performance and null scattering render was expected to fix that. Currently it’s still being reviewed because there are still precision issues due to self-intersection.
