[Bf-taskforce25] Blender spring cleaning

[joe]

Perhaps it could become a little checkbutton ("Use Midpoint") that
people can disable if they ever get the bad use cases.  It could be
kept amongst whatever other "advanced" options we end up with :)  I
think removing the option to ever use normal buffers would be a
mistake, though.

Joe

On Fri, May 15, 2009 at 9:26 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>>> It's not always better; there are issues on 90 degree corners.
>>>
>>>   I've been messing around for a while now trying to reproduce what
>>> you're talking about.  I'm not having any luck, and I've never seen
>>> any issues with corners before.  Could you send an example scene?
>>
>> Ah not really, I think I've seen it once or twice, but that's it.  Not
>> sure how to reproduce it either, heh.
>
> If that's the case then I would hazard a guess that it's either a bug,
> or user error (too low or too high bias).
> After drawing out some diagrams I'm still finding that halfway shadow
> buffers always perform better.  In cases where halfway shadow buffers
> have artifacts, normal shadow buffers have the same artifact but
> worse.  And with halfway shadow buffers much less bias is necessary to
> fix the artifact.
>
> --Nathan V
>
> On Fri, May 15, 2009 at 3:27 PM, joe <joeedh at gmail.com> wrote:
>> On Fri, May 15, 2009 at 1:16 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>>>>      - Can we kill classic shadow buffers?  Classic-halfway is
>>>>> universally superior as far as I know, and it doesn't seem to have any
>>>>> noteworthy performance/memory penalties.
>>>>
>>>> It's not always better; there are issues on 90 degree corners.
>>>
>>>   I've been messing around for a while now trying to reproduce what
>>> you're talking about.  I'm not having any luck, and I've never seen
>>> any issues with corners before.  Could you send an example scene?
>>
>> Ah not really, I think I've seen it once or twice, but that's it.  Not
>> sure how to reproduce it either, heh.
>>
>>>
>>>> True oversampling is better, I think.  Certainly easier then messing
>>>> with resolution/softness settings.
>>>
>>>   To be fair, true oversampling should be done via DSM.  This was
>>> just a hack to get around the lack of DSM at the time, because we
>>> needed it for BBB.  I'd much rather kill this in favor of your DSM
>>> work (granted it's on the slow side, but it can be optimized over
>>> time).  In the mean time, larger buffer res + softness can do this in
>>> productions that need it.
>>
>> DSM isn't always worth it though, it really is quite a bit slower.
>> During BBB I tried very hard to get it working in time, but after a
>> certain point it became clear that it was just too slow for you guys,
>> so I eventually gave up on that goal.
>>
>>>
>>>>> - B-bone Rest: kill this!  It's an evil behavior kept only for
>>>>> backwards compatability with older files!  DIE!!!!
>>>>
>>>> As someone with such a rig, I would be sad to see it go. On the other
>>>> hand, I'm sure my rig will need a fair amount of updating for 2.5
>>>> anyway, so probably the least of my worres. :)
>>>
>>>   I imagine several people out there have rigs like this.  But it's
>>> no longer the default behavior anyway, and for good reason: it's a
>>> buggy behavior.
>>>   Best to get rid of it in 2.5, I think, leaving only the sane behavior.
>>
>> Yeah I agree.
>>
>> Joe
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>