Re: [Bf-committers] Proposal for Animation Actuators in BGE for Blender 2.50
Hi Aligorith/Joshua, * Why the need for armature and shapekey modes still? I can understand a potential reason for having the shapekey one, but why a separate one for bones? Does the GE really need such different settings there? Currently Armature/Shape Key actuators have the options: blendin, priority, continue F-Curve (old IPO) has Child + Force, Add, Local (those 3 only effective for dynamics objects. Do you think those settings are possible/compatible for all animation cases (bones, shapes and actions) ? It looks to me that parameters such as blendin and priority only make sense for actions of the same type, but them how to determine that? I think this is the only reason I see for keeping separate subtypes for animations. -- Dalai 2010/6/8 Joshua Leung aligor...@gmail.com: Hi, Some thoughts about this: * +1 for doing away with several different actuators. Having a single one is probably enough :) * Why the need for armature and shapekey modes still? I can understand a potential reason for having the shapekey one, but why a separate one for bones? Does the GE really need such different settings there? * Action Groups can be used for specific optimisations (i.e. only evaluating certain sets of F-Curves). However, remember to make these known well, since not everybody will use the default keyingsets and the grouping that those impose. Regards, Aligorith On Tue, Jun 8, 2010 at 3:26 PM, Dalai Felinto dfeli...@gmail.com wrote: Hi there, Campbell asked me to give some thought on how to adjust the animation actuators for the new animation system in Blender 2.50. I think it's a good opportunity to enhance the current system and I hope this is something Jörg can work in his GSOC project. Therefore this is my humble contribution: http://wiki.blender.org/index.php/User:Dfelinto/AnimationActuator2.50 I would love to hear feedback on that. (and if the wiki formatting is too bad well I can look at that later). Cheers, Dalai ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Fixes for sculpting on shape keys
Hi, Blender Community! I've been working under sculpting on shape keys (to fix troubles reported in http://projects.blender.org/tracker/?func=detailaid=22262group_id=9atid=498). I've wrote about problems, which were leading to such behaviour and attached patch here: https://projects.blender.org/tracker/?func=detailaid=22601group_id=9atid=127 It'll be very good if Brecht will look at this fix and tell his opinion. And i've got one more qyestion. It's about undo stuff. If i do such sequence: 1. create object with two keys (i.e. basis and key 1) 2. lock key 1 3. Enter sculpt mode 4. make several strokes 5. switch to basis 6. make one more stroke 7. try to undo this stroke After the last action shape from key 1 would be propagated to basis, which isn't good. So, question: which behaviour would be the most expected and maybe somebody have any ideas how this behaviour could be reached? -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] PyAPI breakage and possible solutions
Hello, sorry for the long mail, there is some stuff that came up in irc that I'd like we discuss here. Introduction = There has been some discussion in #blenderpython about what to do with broken scripts in bf-extensions svn: basically someone isn't comfortable including scripts in the category Broken. There's been some argument about the fact that people use Graphicall builds with scripts bundled in, and this has been my exact proposition when I first proposed bf-extensions workflow (tracker - svn contrib - svn trunk). I believe that having Graphicall distributing builds with embedded contrib scripts is cool because people can test and report (and BTW, Dingto added a Report Bug button to the addons panel so now it should be easy to have feedback from users). But, there is some feeling that for this same reason we should provide un-broken scripts. I don't think so. Graphicall is cool, but if it takes scripts from bf-extensions it depends on the work being done in bf-extensions, not the opposite. I don't think that we can maintain bf-extensions as it was a Release each given day :) It might happen that an API change breaks a scripts or two and Campbell already fixes scripts when he changes the API, but he confirms he usually doesn't check contrib so some script might slip, it happens. Also, script developers can disappear at any time, even if their script is in trunk. So if a script remains unmaintained for a long time we should remove it, if it stays there broken for a reasonable time (means days or a couple of weeks) IMO it can stay. It is also a good motivation to fix it. Meta-Androcto also talked about moving contrib scripts in Graphicall (which isn't very clear statement indeed) but I don't think this is desirable, especially if the development will happen outside of a public svn. I propose here 2 solutions for 2 problems: - how to solve broken scripts stuff - how to have contrib scripts in blender BROKEN SCRIPTS PROBLEM = Two usual cases: A) We enable the addon (we don't install it) To do this in the bl_addon_info dict we can add a status key that could be = 'WORKING' or 'BROKEN' Based on that, we do somthing similar to this mockup: http://www.pasteall.org/pic/show.php?id=4003 Like this, when we enable an addon it is evident it is broken. B) We install the script so that next times it is already enabled. If after a commit an installed script becomes broken, again we could use the status key in the bl_addon_info dict to: - disable the script (unregistering it?), and - alert the user with a popup If this approach is ok, we could even think about put this info in the startup panel, but it's not important now. CONTRIB SCRIPTS PROBLEM = Currently this folder https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/ is fetched into blender/release/scripts/addons. We can do the same for contrib: this folder https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/ could be fetched into a subfolder of blender/release/scripts/addons, like blender/release/scripts/addons/contrib This are source folders, not officially released folders. So if in Scons/CMake we could put a new variable like WITH_CONTRIB_INSTALL:BOOL = OFF (cmake) or WITH_CONTRIB_INSTALL = 'false' (scons) and this would mean that we DON'T copy scripts from blender/release/scripts/addons/contrib in the usual ./blender/scripts/addons or not If we know this and wanto to do it, we set up WITH_CONTRIB_INSTALL:BOOL = ON (cmake) or WITH_CONTRIB_INSTALL = 'true' (scons) to include contrib scripts into out build. Like this, one has to know what he's doing to enable contrib scripts, it cannot happen by default, and this applies also to Graphicall builds. = Suggestion are more than welcome! :) PS: we're not discussing py security issues here, please dont use this thread to start again discussing about sandboxing and blabla, thanks. Regards, Luca _ http://www.mindrones.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyAPI breakage and possible solutions
One important thing to consider is the needed ability to separate Blender release cycles and addons update cycles, we propose a third-party addon repository hosted at graphicall because of that reason. Script maintainers could push updates without the need for people to download a new blender version. This is specially important for people who do not use unofficial builds cheers Daniel Salazar www.3developer.com On Wed, Jun 16, 2010 at 8:02 AM, mindrones mindro...@gmail.com wrote: Hello, sorry for the long mail, there is some stuff that came up in irc that I'd like we discuss here. Introduction = There has been some discussion in #blenderpython about what to do with broken scripts in bf-extensions svn: basically someone isn't comfortable including scripts in the category Broken. There's been some argument about the fact that people use Graphicall builds with scripts bundled in, and this has been my exact proposition when I first proposed bf-extensions workflow (tracker - svn contrib - svn trunk). I believe that having Graphicall distributing builds with embedded contrib scripts is cool because people can test and report (and BTW, Dingto added a Report Bug button to the addons panel so now it should be easy to have feedback from users). But, there is some feeling that for this same reason we should provide un-broken scripts. I don't think so. Graphicall is cool, but if it takes scripts from bf-extensions it depends on the work being done in bf-extensions, not the opposite. I don't think that we can maintain bf-extensions as it was a Release each given day :) It might happen that an API change breaks a scripts or two and Campbell already fixes scripts when he changes the API, but he confirms he usually doesn't check contrib so some script might slip, it happens. Also, script developers can disappear at any time, even if their script is in trunk. So if a script remains unmaintained for a long time we should remove it, if it stays there broken for a reasonable time (means days or a couple of weeks) IMO it can stay. It is also a good motivation to fix it. Meta-Androcto also talked about moving contrib scripts in Graphicall (which isn't very clear statement indeed) but I don't think this is desirable, especially if the development will happen outside of a public svn. I propose here 2 solutions for 2 problems: - how to solve broken scripts stuff - how to have contrib scripts in blender BROKEN SCRIPTS PROBLEM = Two usual cases: A) We enable the addon (we don't install it) To do this in the bl_addon_info dict we can add a status key that could be = 'WORKING' or 'BROKEN' Based on that, we do somthing similar to this mockup: http://www.pasteall.org/pic/show.php?id=4003 Like this, when we enable an addon it is evident it is broken. B) We install the script so that next times it is already enabled. If after a commit an installed script becomes broken, again we could use the status key in the bl_addon_info dict to: - disable the script (unregistering it?), and - alert the user with a popup If this approach is ok, we could even think about put this info in the startup panel, but it's not important now. CONTRIB SCRIPTS PROBLEM = Currently this folder https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/ is fetched into blender/release/scripts/addons. We can do the same for contrib: this folder https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/ could be fetched into a subfolder of blender/release/scripts/addons, like blender/release/scripts/addons/contrib This are source folders, not officially released folders. So if in Scons/CMake we could put a new variable like WITH_CONTRIB_INSTALL:BOOL = OFF (cmake) or WITH_CONTRIB_INSTALL = 'false' (scons) and this would mean that we DON'T copy scripts from blender/release/scripts/addons/contrib in the usual ./blender/scripts/addons or not If we know this and wanto to do it, we set up WITH_CONTRIB_INSTALL:BOOL = ON (cmake) or WITH_CONTRIB_INSTALL = 'true' (scons) to include contrib scripts into out build. Like this, one has to know what he's doing to enable contrib scripts, it cannot happen by default, and this applies also to Graphicall builds. = Suggestion are more than welcome! :) PS: we're not discussing py security issues here, please dont use this thread to start again discussing about sandboxing and blabla, thanks. Regards, Luca _ http://www.mindrones.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyAPI breakage and possible solutions
Scripts that are bundled with Blender release must be working, correct? bf-extensions tracker having a broken category doesn't seem bad, since this is not release. script maintainers then have the responsibility of keeping their own scripts working. API breakage is a temporary problem; once blender reaches release status, I suspect Python api won't be changing for quite some time. I don't see why moving extensions to graphicall really changes anything. On Wed, 2010-06-16 at 08:10 -0600, Daniel Salazar - 3Developer.com wrote: One important thing to consider is the needed ability to separate Blender release cycles and addons update cycles, we propose a third-party addon repository hosted at graphicall because of that reason. Script maintainers could push updates without the need for people to download a new blender version. This is specially important for people who do not use unofficial builds cheers Daniel Salazar www.3developer.com On Wed, Jun 16, 2010 at 8:02 AM, mindrones mindro...@gmail.com wrote: Hello, sorry for the long mail, there is some stuff that came up in irc that I'd like we discuss here. Introduction = There has been some discussion in #blenderpython about what to do with broken scripts in bf-extensions svn: basically someone isn't comfortable including scripts in the category Broken. There's been some argument about the fact that people use Graphicall builds with scripts bundled in, and this has been my exact proposition when I first proposed bf-extensions workflow (tracker - svn contrib - svn trunk). I believe that having Graphicall distributing builds with embedded contrib scripts is cool because people can test and report (and BTW, Dingto added a Report Bug button to the addons panel so now it should be easy to have feedback from users). But, there is some feeling that for this same reason we should provide un-broken scripts. I don't think so. Graphicall is cool, but if it takes scripts from bf-extensions it depends on the work being done in bf-extensions, not the opposite. I don't think that we can maintain bf-extensions as it was a Release each given day :) It might happen that an API change breaks a scripts or two and Campbell already fixes scripts when he changes the API, but he confirms he usually doesn't check contrib so some script might slip, it happens. Also, script developers can disappear at any time, even if their script is in trunk. So if a script remains unmaintained for a long time we should remove it, if it stays there broken for a reasonable time (means days or a couple of weeks) IMO it can stay. It is also a good motivation to fix it. Meta-Androcto also talked about moving contrib scripts in Graphicall (which isn't very clear statement indeed) but I don't think this is desirable, especially if the development will happen outside of a public svn. I propose here 2 solutions for 2 problems: - how to solve broken scripts stuff - how to have contrib scripts in blender BROKEN SCRIPTS PROBLEM = Two usual cases: A) We enable the addon (we don't install it) To do this in the bl_addon_info dict we can add a status key that could be = 'WORKING' or 'BROKEN' Based on that, we do somthing similar to this mockup: http://www.pasteall.org/pic/show.php?id=4003 Like this, when we enable an addon it is evident it is broken. B) We install the script so that next times it is already enabled. If after a commit an installed script becomes broken, again we could use the status key in the bl_addon_info dict to: - disable the script (unregistering it?), and - alert the user with a popup If this approach is ok, we could even think about put this info in the startup panel, but it's not important now. CONTRIB SCRIPTS PROBLEM = Currently this folder https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/ is fetched into blender/release/scripts/addons. We can do the same for contrib: this folder https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/ could be fetched into a subfolder of blender/release/scripts/addons, like blender/release/scripts/addons/contrib This are source folders, not officially released folders. So if in Scons/CMake we could put a new variable like WITH_CONTRIB_INSTALL:BOOL = OFF (cmake) or WITH_CONTRIB_INSTALL = 'false' (scons) and this would mean that we DON'T copy scripts from blender/release/scripts/addons/contrib in the usual ./blender/scripts/addons or not If we know this and wanto to do it, we set up WITH_CONTRIB_INSTALL:BOOL = ON (cmake) or WITH_CONTRIB_INSTALL = 'true' (scons) to include contrib scripts into out build. Like this, one
Re: [Bf-committers] Normal perturbation paper
speaking of normals, another CG package has introduced a Vector Normal image type. The image is formed by baking a sculpted, high-res model (which started as a grid) to a 2D image. Each RGB value for a pixel is a normalized point in space and is used to displace the corresponding vertex in 3D space. This image is applied as a texture/modifier to a flat mesh. It looks like a normal image, depending on how it was sculpted, but it can contain bends and curves, not just a 1-axis displacement. Sliders allow you to control how big you want the ... extrusion... to be. The idea is that you can bake complicated stuff like ears, horns, plants, etc and get actual geometry out of a 2D image. --Roger ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyAPI breakage and possible solutions
I'm not really interested in mailing list discussion on this topic, We can agree addons for release must be stable. Further, the script module owners can come to some consensus on the matter. Which raises the topic... who are the module owner? :( no script reference except for UI: http://wiki.blender.org/index.php/User:DingTo/ModuleOwners-New From memory Brendon Murphy, Luca Bonavita and myself, Please correct me if I'm wrong! We can meet on IRC and decide if any changes are needed. On Wed, Jun 16, 2010 at 4:10 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: One important thing to consider is the needed ability to separate Blender release cycles and addons update cycles, we propose a third-party addon repository hosted at graphicall because of that reason. Script maintainers could push updates without the need for people to download a new blender version. This is specially important for people who do not use unofficial builds cheers Daniel Salazar www.3developer.com On Wed, Jun 16, 2010 at 8:02 AM, mindrones mindro...@gmail.com wrote: Hello, sorry for the long mail, there is some stuff that came up in irc that I'd like we discuss here. Introduction = There has been some discussion in #blenderpython about what to do with broken scripts in bf-extensions svn: basically someone isn't comfortable including scripts in the category Broken. There's been some argument about the fact that people use Graphicall builds with scripts bundled in, and this has been my exact proposition when I first proposed bf-extensions workflow (tracker - svn contrib - svn trunk). I believe that having Graphicall distributing builds with embedded contrib scripts is cool because people can test and report (and BTW, Dingto added a Report Bug button to the addons panel so now it should be easy to have feedback from users). But, there is some feeling that for this same reason we should provide un-broken scripts. I don't think so. Graphicall is cool, but if it takes scripts from bf-extensions it depends on the work being done in bf-extensions, not the opposite. I don't think that we can maintain bf-extensions as it was a Release each given day :) It might happen that an API change breaks a scripts or two and Campbell already fixes scripts when he changes the API, but he confirms he usually doesn't check contrib so some script might slip, it happens. Also, script developers can disappear at any time, even if their script is in trunk. So if a script remains unmaintained for a long time we should remove it, if it stays there broken for a reasonable time (means days or a couple of weeks) IMO it can stay. It is also a good motivation to fix it. Meta-Androcto also talked about moving contrib scripts in Graphicall (which isn't very clear statement indeed) but I don't think this is desirable, especially if the development will happen outside of a public svn. I propose here 2 solutions for 2 problems: - how to solve broken scripts stuff - how to have contrib scripts in blender BROKEN SCRIPTS PROBLEM = Two usual cases: A) We enable the addon (we don't install it) To do this in the bl_addon_info dict we can add a status key that could be = 'WORKING' or 'BROKEN' Based on that, we do somthing similar to this mockup: http://www.pasteall.org/pic/show.php?id=4003 Like this, when we enable an addon it is evident it is broken. B) We install the script so that next times it is already enabled. If after a commit an installed script becomes broken, again we could use the status key in the bl_addon_info dict to: - disable the script (unregistering it?), and - alert the user with a popup If this approach is ok, we could even think about put this info in the startup panel, but it's not important now. CONTRIB SCRIPTS PROBLEM = Currently this folder https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/ is fetched into blender/release/scripts/addons. We can do the same for contrib: this folder https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/ could be fetched into a subfolder of blender/release/scripts/addons, like blender/release/scripts/addons/contrib This are source folders, not officially released folders. So if in Scons/CMake we could put a new variable like WITH_CONTRIB_INSTALL:BOOL = OFF (cmake) or WITH_CONTRIB_INSTALL = 'false' (scons) and this would mean that we DON'T copy scripts from blender/release/scripts/addons/contrib in the usual ./blender/scripts/addons or not If we know this and wanto to do it, we set up WITH_CONTRIB_INSTALL:BOOL = ON (cmake) or WITH_CONTRIB_INSTALL = 'true' (scons) to include contrib scripts into out build. Like this, one has to know what he's doing to enable contrib scripts, it
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [29496] branches/render25: Render Branch: remove a few options
On Wed, Jun 16, 2010 at 11:12 AM, Brecht Van Lommel bre...@blender.org wrote: * Doubled Sided Lighting: just always do this, not much use in being able to turn this off, and it works only in the viewport anyway. Brecht - turning off double sided gives drastic viewport speedup - probably double? LetterRip ___ 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 [29496] branches/render25: Render Branch: remove a few options
You are right it's complicated to read the displayed normals, there was a patch a million years ago that faded out the normal drawing and gave a great sense of direction, maybe this can be added? (way to turn a conversation into a feature request) Daniel Salazar www.3developer.com On Wed, Jun 16, 2010 at 2:24 PM, GSR gsr@infernal-iceberg.com wrote: Hi, letter...@gmail.com (2010-06-16 at 1138.23 -0800): On Wed, Jun 16, 2010 at 11:12 AM, Brecht Van Lommel bre...@blender.org wrote: * Doubled Sided Lighting: just always do this, not much use in being able to turn this off, and it works only in the viewport anyway. Brecht - turning off double sided gives drastic viewport speedup - probably double? And does it not help when creating things where correct normal matters, like games or 3d printing? Yes, I know, there is show normals, but that can get messy. GSR ___ 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
