[Bf-taskforce25] Blender spring cleaning

[Nathan Vegdahl]

Ah, that makes sense.

However, it's still confusing to the user, because it's completely
hidden.  "Stamp" doesn't bring to mind metadata.  Perhaps they could
be made two separate and independent options, "Stamp" and "Metadata"?

As it stands right now it's a completely hidden behavior, and makes
the interface confusing.

--Nathan V

On Fri, May 29, 2009 at 4:26 PM, Michael Fox <mfoxdogg at gmail.com> wrote:
> stamp without the render stamp option puts the info in the metadata of
> the image
>
> On Fri, 2009-05-29 at 16:13 -0700, Nathan Vegdahl wrote:
>> Would it be possible to remove the "Render Stamp" option?  Unless I'm
>> missing something, it appears to be 100% redundant with the "Stamp"
>> option.
>> We could just make "Stamp" toggle stamps altogether.
>>
>> --Nathan V
>>
>> On Wed, May 20, 2009 at 8:35 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> > After talking with Joe on IRC he pointed me to this paper:
>> >   http://www.vis.uni-stuttgart.de/~weiskopf/publications/eg03short.pdf
>> >
>> >   Indeed halfway shadow buffers do have artifacts that normal buffers
>> > don't, namely self-unshadowing in some scenes with concave objects or
>> > surfaces that aren't closed such as planes.
>> >
>> >   So I retract my proposal (with apologies to Joe) to remove normal
>> > shadow buffers.
>> >
>> >   But I do think that halfway buffers (with a very small bias) should
>> > be made the default.  They generally "just work", unlike normal shadow
>> > buffers which usually require a fair amount of tweaking on a
>> > case-by-case basis to get rid of artifacts.
>> >
>> >   I also like Joe's idea of making the halfway buffers a checkbox on
>> > normal shadow buffers.  They are so closely related to each other that
>> > it seems odd for them to each have a separate menu item.  Then we can
>> > just make the checkbox on by default.
>> >
>> > --Nathan V
>> >
>> > On Sat, May 16, 2009 at 4:29 AM, joe <joeedh at gmail.com> wrote:
>> >> 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
>> >>>
>> >> _______________________________________________
>> >> 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
> --
> Michael Fox
> Developer and user of Blender3d
> www.blender.org
> http://mfoxdogg.googlepages.com
>
> mfoxdogg at gmail.com
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>