[Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous

Simon Repp simon at fdpl.foundation
Thu Nov 13 00:22:47 CET 2014


Dear Renderistas,

I only recently found out that progressive refinement in Cycles
rendering (which the corresponding checkbox's tooltip describes to be
"somewhat slower" than bucket rendering) in fact can impose performance
penalties of over 100% (aka the same amount of samples takes more than
twice as long to render).

Now I don't know if this is just a personal flawed interpretation of the
english language on my part, but when reading "somewhat slower" I didn't
realize what I was really in for, and in retrospect I'd rather not
reconstruct how many days my poor laptop spent in excess to render some
projects I did in the past.

I'd hereby like to propose a change of this tooltip to something less
ambiguous, lest anyone else falls into that same trap that I have - My
proposal for this would be to include actual figures describing the
possible speed penalty that progressive refinement can impose, that is,
something along the lines of "renders [a]% to [b]% slower depending on
the scene", where figures [a] and [b] are ideally derived from real
world data we gather (or already have?) about how much speed penalty
progressive refinement can impose in different scenes. Alternatively,
only stating "up to [x]% slower" would work as well I guess, as the main
point is to make people aware that it _can_ possibly affect render times
_significantly_.

If the proposal to include figures is not agreeable for some reason, I
would at least ask for a more indicative wording than "somewhat slower",
which even after consulting multiple dictionaries I'm not sure if there
is an official interpretation for. (One dictionary suggests "quite" as a
synoym, another "slightly" ...) I'd still prefer the figures though, no
one looks up terms in the dictionary while using Blender and I am
probably not the worst offender at massacring and misunderstanding the
english language in the Blender community, and it doesn't get less
ambiguous than numbers anyway, so I say we use them here? :)

Best,
Simon


More information about the Bf-committers mailing list