[Bf-taskforce25] Blender spring cleaning

[Michael Fox]

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