[Bf-committers] Possible Render Noise Filter?
Has anyone evaluated this paper? http://agl.unm.edu/rpf/ Seems like a potential addition to either cycles viewport rendering and/or a couple of compositor node. It takes as few as 8 samples per pixel and is comparable with many many times more for about 3 times the computation of 8spp. It preserves detail and edges well. Not sure what the additional memory use would be. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender IRC meeting minutes, sept 5 2010
> > > - Splash: Ton asks Durian team to pick a cool one, and not with sad > looking people this time! :) > Totally agree, the depressing splash weighed on my heart and made it really difficult to work for the second half of GSoC That said, I've gotten somewhat settled in here in Texas after moving so I'm ready to contribute to blender some more (for free woohoo!) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Using assert()?
I think one way to think of an assert is as extra documentation of assumptions that you do not want to check for because of efficiency or redundancy reasons. Like an extra check that goes beyond what the compiler can do for you at compile time. On Aug 16, 2010, at 10:33 PM, Torsten Rupp wrote: > Dear Jason, > > thanx for your message. > >> Asserts are not present in release code, so they should never >> contain code that has side effects. > > Yes, that is true. Asserts are only checks, thus never put something > in an assert with a side effect that is missing when the assert would > not be there which is usually the case for the non-debug version on > an application. > >> An assert should never be used for ordinary error conditions that >> need to be checked for delt with by the program. > > I agree, too. Asserts are not for error handling, but for checking if > the program still have a consistent state and is doing what was > intented to do. If something could go wrong in the normal program > behavior, e. g. open a file fail, this must be handled by some useful > code which does not simple stop the application (what an assert > always do). Though I think: > > - everything what could go wrong e. g. because of a user interaction, > must be handled by the program, even the user may misuse the program > totally. > > - everything which should never go wrong (the theory), but may go > wrong for some reason (the reality), should be checked by an assert > (the check of a precondition). This even become imho more important > if the failure could cause a disastrous result, e. g. a SigSegV, > which is usually hard to trace back. > >> Used properly I would almost say you do not need permission to add >> asserts. I normally add them all over the place. Unfortunately >> like you I was nervous about using them when it doesn't seem to be >> wide spread in Blender, so I refrained. > > Thanx for this clarification. I just wanted to make sure, what is the > intention. Thus I will add also asserts() now when this seems to be > helpful. > > Torsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [29073] branches/soc-2010-moguri: I rolled back the merge and merged correctly this time.
I immediately commit after I merge which gives me a version number close to what I need to use next time. It will be head+1 unless the repository is really busy :) But it may help to put the actual number in the comment so I'll do that too On May 29, 2010, at 8:52 PM, Dalai Felinto wrote: > Hi Mitchell, > for your own sake I recommend always put in the commit log the > revisions you are merging. > e.g. svn merge 8839: (use the number here instead of HEAD) > > Otherwise it may become hard to trace down merge problems later :) > > Cheers, > Dalai > > 2010/5/29 Mitchell Stokes : >> Revision: 29073 >> >> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=29073 >> Author: moguri >> Date: 2010-05-30 03:48:03 +0200 (Sun, 30 May 2010) >> >> Log Message: >> --- >> I rolled back the merge and merged correctly this time. (hopefully) >> >> Modified Paths: >> -- >>branches/soc-2010-moguri/CMake/macros.cmake >>branches/soc-2010-moguri/CMakeLists.txt >>branches/soc-2010-moguri/SConstruct >>branches/soc-2010-moguri/config/darwin-config.py >>branches/soc-2010-moguri/config/linux2-config.py >>branches/soc-2010-moguri/config/linuxcross-config.py >>branches/soc-2010-moguri/config/win32-mingw-config.py >>branches/soc-2010-moguri/config/win32-vc-config.py >>branches/soc-2010-moguri/config/win64-vc-config.py >>branches/soc-2010-moguri/intern/ghost/intern/GHOST_SystemCocoa.mm >>branches/soc-2010-moguri/release/scripts/io/export_fbx.py >>branches/soc-2010-moguri/release/scripts/io/import_anim_bvh.py >>branches/soc-2010-moguri/release/scripts/keyingsets/ >> keyingsets_utils.py >>branches/soc-2010-moguri/release/scripts/op/add_mesh_torus.py >>branches/soc-2010-moguri/release/scripts/op/object.py >>branches/soc-2010-moguri/release/scripts/op/uv.py >>branches/soc-2010-moguri/release/scripts/ui/properties_animviz.py >>branches/soc-2010-moguri/release/scripts/ui/properties_render.py >>branches/soc-2010-moguri/release/scripts/ui/space_view3d.py >>branches/soc-2010-moguri/source/blender/blenkernel/BKE_global.h >>branches/soc-2010-moguri/source/blender/blenkernel/BKE_multires.h >>branches/soc-2010-moguri/source/blender/blenkernel/CMakeLists.txt >>branches/soc-2010-moguri/source/blender/blenkernel/SConscript >>branches/soc-2010-moguri/source/blender/blenkernel/intern/Makefile >>branches/soc-2010-moguri/source/blender/blenkernel/intern/anim.c >>branches/soc-2010-moguri/source/blender/blenkernel/intern/ >> armature.c >>branches/soc-2010-moguri/source/blender/blenkernel/intern/image.c >>branches/soc-2010-moguri/source/blender/blenkernel/intern/ >> multires.c >>branches/soc-2010-moguri/source/blender/blenloader/intern/ >> readfile.c >>branches/soc-2010-moguri/source/blender/editors/CMakeLists.txt >>branches/soc-2010-moguri/source/blender/editors/animation/ >> anim_channels_edit.c >>branches/soc-2010-moguri/source/blender/editors/animation/ >> anim_filter.c >>branches/soc-2010-moguri/source/blender/editors/include/ >> ED_anim_api.h >>branches/soc-2010-moguri/source/blender/editors/interface/ >> interface_handlers.c >>branches/soc-2010-moguri/source/blender/editors/interface/ >> interface_regions.c >>branches/soc-2010-moguri/source/blender/editors/object/ >> object_intern.h >>branches/soc-2010-moguri/source/blender/editors/object/ >> object_modifier.c >>branches/soc-2010-moguri/source/blender/editors/object/ >> object_ops.c >>branches/soc-2010-moguri/source/blender/editors/render/ >> render_opengl.c >>branches/soc-2010-moguri/source/blender/editors/screen/ >> screen_ops.c >>branches/soc-2010-moguri/source/blender/editors/sound/sound_ops.c >>branches/soc-2010-moguri/source/blender/editors/space_action/ >> action_edit.c >>branches/soc-2010-moguri/source/blender/editors/space_action/ >> action_select.c >>branches/soc-2010-moguri/source/blender/editors/space_file/ >> Makefile >>branches/soc-2010-moguri/source/blender/editors/space_file/ >> SConscript >>branches/soc-2010-moguri/source/blender/editors/space_file/ >> writeimage.c >>branches/soc-2010-moguri/source/blender/editors/space_graph/ >> graph_buttons.c >>branches/soc-2010-moguri/source/blender/editors/space_graph/ >> graph_edit.c >>branches/soc-2010-moguri/source/blender/editors/space_graph/ >> graph_select.c >>branches/soc-2010-moguri/source/blender/editors/space_graph/ >> space_graph.c >>branches/soc-2010-moguri/source/blender/editors/space_image/ >> Makefile >>branches/soc-2010-moguri/source/blender/editors/space_image/ >> SConscript >>branches/soc-2010-moguri/source/blender/editors/space_image/ >> image_ops.c >>branches/soc-2010-moguri/source/blender/editors/space_logic/ >> logic_ops.c >>branches/soc-2010-moguri/source/blender/editors/space_logic/ >> logic_win
Re: [Bf-committers] a quick question
I'm anxious to integrate this into my branch. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I think the complaint was that as is pypy was all or nothing sandboxing. I was proposing writing a pypy hosted interpreter that had the specific features required. Too bad I have other fish to fry or I'd build a prototype On Apr 30, 2010, at 10:07 PM, Tom M wrote: > Jason, > > there is already a sandbox version of pypy. > > http://codespeak.net/pypy/dist/pypy/doc/sandbox.html > > > As regards web of trust and GPG, there is python GnuPG > > http://code.google.com/p/python-gnupg/ > > LetterRip > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
