[Bf-committers] Antw.: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41909] trunk/blender/source/blender/ modifiers/intern: Default cache file paths for ocean and fluidsim modifiers are now "< t
Agree here. This makes sense.
Sent from my mobile device
- Reply message -
Von: "PabloVazquez.org"
An:
Betreff: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender
[41909] trunk/blender/source/blender/ modifiers/intern: Default cache file
paths for ocean and fluidsim modifiers are now "< temp folder>/ocean_cache/"
and "/fluid_cache/" when the file i
Datum: So., Nov. 20, 2011 21:59
As we usually have folders for textures/references/tests and so on inside
our .blend's folder, I'd rather have these folders starting with "cache_"
instead of the sim name, like:
cache_fluid
cache_ocean
cache_futuresimulations
So when listing our .blend's folder alphabetically they are nicely listed
together, easier for the eye.
Perhaps a bit silly, but reduces the noise when having many caches and
extra folders.
--
Pablo Vazquez
CG Artist
Blender Foundation Certified Trainer
E-mail: cont...@pablovazquez.org
Website: http://www.pablovazquez.org
On Wed, Nov 16, 2011 at 09:43, Lukas Toenne wrote:
> Revision: 41909
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41909
> Author: lukastoenne
> Date: 2011-11-16 12:43:12 + (Wed, 16 Nov 2011)
> Log Message:
> ---
> Default cache file paths for ocean and fluidsim modifiers are now " folder>/ocean_cache/" and "/fluid_cache/" when the file is not
> saved yet at the time the modifiers are created.
>
> If it has been saved, the file paths are relative to the .blend:
> "//ocean_cache/" and "//fluid_cache/".
>
> This should at least partially fix bug #29273. Particle external point
> caches are not changed.
>
>
> http://projects.blender.org/tracker/?func=detail&atid=498&aid=29273&group_id=9
>
> Modified Paths:
> --
>trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
>trunk/blender/source/blender/modifiers/intern/MOD_ocean.c
>
> Modified: trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
> ===
> --- trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
> 2011-11-16 12:38:40 UTC (rev 41908)
> +++ trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
> 2011-11-16 12:43:12 UTC (rev 41909)
> @@ -69,6 +69,7 @@
>if(fluidmd)
>{
>FluidsimSettings *fss =
> MEM_callocN(sizeof(FluidsimSettings), "fluidsimsettings");
> + int surfdataPathMax = FILE_MAX;
>
>fluidmd->fss = fss;
>
> @@ -104,7 +105,22 @@
>
>/* elubie: changed this to default to the same dir as the
> render output
>to prevent saving to C:\ on Windows */
> - BLI_strncpy(fss->surfdataPath, BLI_temporary_dir(),
> FILE_MAX);
> + if (G.relbase_valid) { /* is the .blend saved? */
> + /* subfolder next to saved file */
> + BLI_strncpy(fss->surfdataPath, "//fluid_cache",
> surfdataPathMax);
> + BLI_add_slash(fss->surfdataPath);
> + }
> + else {
> + /* subfolder in temp. directory */
> + BLI_strncpy(fss->surfdataPath,
> BLI_temporary_dir(), surfdataPathMax);
> + surfdataPathMax -= strlen(fss->surfdataPath);
> + if (surfdataPathMax > 1) {
> +
> BLI_strncpy(fss->surfdataPath+strlen(fss->surfdataPath), "fluid_cache",
> surfdataPathMax);
> + surfdataPathMax -= strlen("fluid_cache");
> + if (surfdataPathMax > 1)
> + BLI_add_slash(fss->surfdataPath);
> + }
> + }
>
>// first init of bounding box
>// no bounding box needed
>
> Modified: trunk/blender/source/blender/modifiers/intern/MOD_ocean.c
> ===
> --- trunk/blender/source/blender/modifiers/intern/MOD_ocean.c 2011-11-16
> 12:38:40 UTC (rev 41908)
> +++ trunk/blender/source/blender/modifiers/intern/MOD_ocean.c 2011-11-16
> 12:43:12 UTC (rev 41909)
> @@ -34,10 +34,12 @@
> #include "DNA_scene_types.h"
>
> #include "BKE_cdderivedmesh.h"
> +#include "BKE_global.h"
> #include "BKE_modifier.h"
> #include "BKE_ocean.h"
> #include "BKE_utildefines.h"
>
> +#include "BLI_blenlib.h"
> #include "BLI_math.h"
> #include "BLI_math_inline.h"
> #include "BLI_utildefines.h"
> @@ -95,6 +97,7 @@
> {
> #ifdef WITH_OCEANSIM
>OceanModifierData *omd = (OceanModifierData*) md;
> + int cachepathmax = sizeof(omd->cachepath);
>
>omd->resolution = 7;
>omd->spatial_size = 50;
> @@ -122,7 +125,22 @@
>omd->repeat_x = 1;
>omd->repeat_y = 1;
>
> - BLI_strncpy(omd->cachepath, "//ocean_cache",
> sizeof(omd->cachepath));
> + if (G.relbase_valid) { /* is the .blend saved? */
> + /* s
Re: [Bf-committers] Antw.: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41909] trunk/blender/source/blender/ modifiers/intern: Default cache file paths for ocean and fluidsim modifiers are now "
+1, though would change: cache_futuresimulations --> cache_fluidsim
On Tue, Nov 22, 2011 at 1:05 AM, Thomas Dinges wrote:
> Agree here. This makes sense.
>
> Sent from my mobile device
>
> - Reply message -
> Von: "PabloVazquez.org"
> An:
> Betreff: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender
> [41909] trunk/blender/source/blender/ modifiers/intern: Default cache file
> paths for ocean and fluidsim modifiers are now "< temp folder>/ocean_cache/"
> and "/fluid_cache/" when the file i
> Datum: So., Nov. 20, 2011 21:59
>
>
>
>
> As we usually have folders for textures/references/tests and so on inside
> our .blend's folder, I'd rather have these folders starting with "cache_"
> instead of the sim name, like:
>
> cache_fluid
> cache_ocean
> cache_futuresimulations
>
> So when listing our .blend's folder alphabetically they are nicely listed
> together, easier for the eye.
>
> Perhaps a bit silly, but reduces the noise when having many caches and
> extra folders.
>
>
> --
> Pablo Vazquez
> CG Artist
> Blender Foundation Certified Trainer
> E-mail: cont...@pablovazquez.org
> Website: http://www.pablovazquez.org
>
>
> On Wed, Nov 16, 2011 at 09:43, Lukas Toenne
> wrote:
>
>> Revision: 41909
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41909
>> Author: lukastoenne
>> Date: 2011-11-16 12:43:12 + (Wed, 16 Nov 2011)
>> Log Message:
>> ---
>> Default cache file paths for ocean and fluidsim modifiers are now "> folder>/ocean_cache/" and "/fluid_cache/" when the file is not
>> saved yet at the time the modifiers are created.
>>
>> If it has been saved, the file paths are relative to the .blend:
>> "//ocean_cache/" and "//fluid_cache/".
>>
>> This should at least partially fix bug #29273. Particle external point
>> caches are not changed.
>>
>>
>> http://projects.blender.org/tracker/?func=detail&atid=498&aid=29273&group_id=9
>>
>> Modified Paths:
>> --
>> trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
>> trunk/blender/source/blender/modifiers/intern/MOD_ocean.c
>>
>> Modified: trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
>> ===
>> --- trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
>> 2011-11-16 12:38:40 UTC (rev 41908)
>> +++ trunk/blender/source/blender/modifiers/intern/MOD_fluidsim_util.c
>> 2011-11-16 12:43:12 UTC (rev 41909)
>> @@ -69,6 +69,7 @@
>> if(fluidmd)
>> {
>> FluidsimSettings *fss =
>> MEM_callocN(sizeof(FluidsimSettings), "fluidsimsettings");
>> + int surfdataPathMax = FILE_MAX;
>>
>> fluidmd->fss = fss;
>>
>> @@ -104,7 +105,22 @@
>>
>> /* elubie: changed this to default to the same dir as the
>> render output
>> to prevent saving to C:\ on Windows */
>> - BLI_strncpy(fss->surfdataPath, BLI_temporary_dir(),
>> FILE_MAX);
>> + if (G.relbase_valid) { /* is the .blend saved? */
>> + /* subfolder next to saved file */
>> + BLI_strncpy(fss->surfdataPath, "//fluid_cache",
>> surfdataPathMax);
>> + BLI_add_slash(fss->surfdataPath);
>> + }
>> + else {
>> + /* subfolder in temp. directory */
>> + BLI_strncpy(fss->surfdataPath,
>> BLI_temporary_dir(), surfdataPathMax);
>> + surfdataPathMax -= strlen(fss->surfdataPath);
>> + if (surfdataPathMax > 1) {
>> +
>> BLI_strncpy(fss->surfdataPath+strlen(fss->surfdataPath), "fluid_cache",
>> surfdataPathMax);
>> + surfdataPathMax -= strlen("fluid_cache");
>> + if (surfdataPathMax > 1)
>> + BLI_add_slash(fss->surfdataPath);
>> + }
>> + }
>>
>> // first init of bounding box
>> // no bounding box needed
>>
>> Modified: trunk/blender/source/blender/modifiers/intern/MOD_ocean.c
>> ===
>> --- trunk/blender/source/blender/modifiers/intern/MOD_ocean.c 2011-11-16
>> 12:38:40 UTC (rev 41908)
>> +++ trunk/blender/source/blender/modifiers/intern/MOD_ocean.c 2011-11-16
>> 12:43:12 UTC (rev 41909)
>> @@ -34,10 +34,12 @@
>> #include "DNA_scene_types.h"
>>
>> #include "BKE_cdderivedmesh.h"
>> +#include "BKE_global.h"
>> #include "BKE_modifier.h"
>> #include "BKE_ocean.h"
>> #include "BKE_utildefines.h"
>>
>> +#include "BLI_blenlib.h"
>> #include "BLI_math.h"
>> #include "BLI_math_inline.h"
>> #include "BLI_utildefines.h"
>> @@ -95,6 +97,7 @@
>> {
>> #ifdef WITH_OCEANSIM
>> OceanModifierData *omd = (OceanModifierData*) md;
>> + int cachepathmax = sizeof(omd->cachepath);
>>
>> omd->resolution
Re: [Bf-committers] Collada and Custom Properties export
I have created a patch that adds this functionality, please someone review if possible: http://projects.blender.org/tracker/index.php?func=detail&aid=29357&group_id=9&atid=127 Thanks On Mon, Nov 14, 2011 at 5:48 PM, Micael wrote: > Hello > > Dear Nathan, first of all, thanks for all your work :) > > According to > http://www.blender.org/forum/viewtopic.php?t=18145&sid=f92f437b3a4ad3aa31e1342e460f83f3 > it > seems it's on your mind to implement custom properties export code on the > Collada plugin. > > I am currently about to begin a project that would *greatly* benefit from > this feature (so I could use Blender as a level editor for graphics, > physics and so on). > I would like to know if this will be implemented in the very near future > or not. I have experience and feel confortable enough with C++ that I think > I could help implement this support if someone gives me a little guidance > on where to look (something more than the "collada" folder). > > Thanks. > > -- > Micael Dias > -- Micael Dias ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] 2.6 section in Wiki not (yet) fully set up ?
Hi. I just wanted to start documenting some changes on the User interface for Blender 2.6. But most pages are only available for 2.5 and they all are marked with "Do not modify page". Is it planned to copy the 2.5 documentation into the 2.6 section ? Or are we supposed to create the pages as we update them for 2.6 ? How shall i proceed now ? I could not find any documentation for how to migrate an existing page to a new release. -gaia- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 section in Wiki not (yet) fully set up ?
Hello, please join http://lists.blender.org/mailman/listinfo/bf-docboard mailing list or #blenderwiki channel to discuss about documentation. Francesco On 21 November 2011 19:51, Gaia Clary wrote: > Hi. > > I just wanted to start documenting some changes on the User interface > for Blender 2.6. But most pages are only available for 2.5 and they all > are marked with "Do not modify page". Is it planned to copy the 2.5 > documentation into the 2.6 section ? Or are we supposed to create the > pages as we update them for 2.6 ? > > How shall i proceed now ? I could not find any documentation for how to > migrate an existing page to a new release. > > -gaia- > ___ > 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
Re: [Bf-committers] color wheels screwed again
ok so it does work with the continuous grab. Is that normal ?! doesn't change anything for the issue of the two color wheels displaying different value. My guess would be one is showing a gamma corrected value and not the other one :p 2011/11/21 Campbell Barton > On Mon, Nov 21, 2011 at 10:43 AM, François T. > wrote: > > http://www.pasteall.org/pic/21161 > > > > At least on the color balance node the color wheel doesn't match which > > makes the one in the Node itself un-useable (before you ask its same deal > > with or w/o CM) > > > > While I'm at it, on my Mac the precise mode on any color wheel does not > > work anymore (can't remember if its supposed to be shift or ctrl, but I > > tried any combination nothing work). > > > > > > cheers, > > > > F. > > Try enable continuous grab in the input user preferences. > > > > -- > > > > François Tarlier > > www.francois-tarlier.com > > www.linkedin.com/in/francoistarlier > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Color wheel proposal
Yet another one :/ I have been trying to do lots of grading lately in Blender, and lost half of my hairs, so here is my proposal to make it (yes IMO, I know) more confortable *1 - where ever I click on the color wheel (CW), the mouse jump to cw cursor * right now its the other way around. While I understand it makes it easier to quickly change to a total different color, it makes it almost impossible to fine tune the current color. *2 - precise mode by default *(perhaps with a logarithmic curve on the mouse ?) This might be just a color grading thing, but again I find myself more looking for the color I'd like surrounding the current one, rather than totally jumping to a total different one. So pressing the shift key is a bit annoying *3 - When releasing the cw cursor the mouse jump to it* Yet I believe that would be solved by its own if the first step was done. But just to notice how annoying this behave right now. Especially since you have to release the cw cursor to see the new values being updated in the viewer. you would find yourself to click drag release, click drag release, click drag release. But since the mouse doesn't move to the new location, you keep going back to the previous color (gr). So you have to think about moving the mouse as close as possible to the cw cursor which makes fine tuning IMPOSSIBLE. 4 - *having a Hue saturation wheel when in HSV mode* (not a big deal, just makes it easier to see what you are doing a makes more sense IMO) - Making everybody happy - click far from the cw cursor makes it jump to the mouse position - click close to the cw cursor makes the mouse jump (snap) to it - when releasing the cw cursor the mouse postion gets the cw cursor (that with the two above makes click-drag-release not so painful) - (mode selfish ON) pressing shift turn off the precise mode ? 8-) cheers, F. -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ 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 [42041] trunk/blender: move image settings into their own structure so the interface can be shared where image saving settings are
Hi Campbell, nice refactor, still the new UI looks horrible imo, especially in the Render Output panel. Another thing are function names. " BKE_imtype_is_zbuf_ok" should be better something like " BKE_imtype_use_zbuf", as the functions are there to check if the image format supports these things. "is_zbuf_ok" is rather confusing. Just my 2 cents. Regards, Thomas Am 21.11.2011 21:20, schrieb Campbell Barton: > Revision: 42041 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=42041 > Author: campbellbarton > Date: 2011-11-21 20:19:58 + (Mon, 21 Nov 2011) > Log Message: > --- > move image settings into their own structure so the interface can be shared > where image saving settings are needed. > currently file out node and render output share this struct& UI. > -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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 [42041] trunk/blender: move image settings into their own structure so the interface can be shared where image saving settings are
Another issue: AVI JPEG now misses it's Quality slider in the Render Output panel. Am 21.11.2011 22:30, schrieb Thomas Dinges: > Hi Campbell, > nice refactor, still the new UI looks horrible imo, especially in the > Render Output panel. > > Another thing are function names. " BKE_imtype_is_zbuf_ok" should be > better something like " BKE_imtype_use_zbuf", as the functions are there > to check if the image format supports these things. "is_zbuf_ok" is > rather confusing. > > Just my 2 cents. > > Regards, > Thomas > > Am 21.11.2011 21:20, schrieb Campbell Barton: >> Revision: 42041 >> >> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=42041 >> Author: campbellbarton >> Date: 2011-11-21 20:19:58 + (Mon, 21 Nov 2011) >> Log Message: >> --- >> move image settings into their own structure so the interface can be shared >> where image saving settings are needed. >> currently file out node and render output share this struct& UI. >> -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender osx builds
Hey all! None of the recent osx 64bit builds from builder.blender.org work for me (tried it every once in a while over the course of the last 2 weeks). They instantly crash when opening with the following message: http://www.pasteall.org/26632 Known issue? Greets, Tobi ___ 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 [42041] trunk/blender: move image settings into their own structure so the interface can be shared where image saving settings are
On Tue, Nov 22, 2011 at 8:34 AM, Thomas Dinges wrote: > Another issue: AVI JPEG now misses it's Quality slider in the Render > Output panel. Ill finish up my next commit and look into this after. > Am 21.11.2011 22:30, schrieb Thomas Dinges: >> Hi Campbell, >> nice refactor, still the new UI looks horrible imo, especially in the >> Render Output panel. >> >> Another thing are function names. " BKE_imtype_is_zbuf_ok" should be >> better something like " BKE_imtype_use_zbuf", as the functions are there >> to check if the image format supports these things. "is_zbuf_ok" is >> rather confusing. >> Just my 2 cents. BKE_imtype_use_zbuf is misleaking because its only checking if the format has the capability, perhaps BKE_imtype_is_zbuf_supported (was trying to be brief with `ok` :) ) >> Regards, >> Thomas >> >> Am 21.11.2011 21:20, schrieb Campbell Barton: >>> Revision: 42041 >>> >>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=42041 >>> Author: campbellbarton >>> Date: 2011-11-21 20:19:58 + (Mon, 21 Nov 2011) >>> Log Message: >>> --- >>> move image settings into their own structure so the interface can be shared >>> where image saving settings are needed. >>> currently file out node and render output share this struct& UI. >>> > > > -- > Thomas Dinges > Blender Developer, Artist and Musician > > www.dingto.org > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color wheel proposal
+1. It would make me very happy! Jonathan Williamson http://blendercookie.com http://mavenseed.com On Nov 21, 2011, at 3:25 PM, François T. wrote: > Yet another one :/ > > I have been trying to do lots of grading lately in Blender, and lost half > of my hairs, so here is my proposal to make it (yes IMO, I know) more > confortable > > *1 - where ever I click on the color wheel (CW), the mouse jump to cw cursor > * > right now its the other way around. While I understand it makes it easier > to quickly change to a total different color, it makes it almost impossible > to fine tune the current color. > *2 - precise mode by default *(perhaps with a logarithmic curve on the > mouse ?) > This might be just a color grading thing, but again I find myself more > looking for the color I'd like surrounding the current one, rather than > totally jumping to a total different one. So pressing the shift key is a > bit annoying > > *3 - When releasing the cw cursor the mouse jump to it* > Yet I believe that would be solved by its own if the first step was done. > But just to notice how annoying this behave right now. Especially since you > have to release the cw cursor to see the new values being updated in the > viewer. you would find yourself to click drag release, click drag release, > click drag release. But since the mouse doesn't move to the new location, > you keep going back to the previous color (gr). So you have to think > about moving the mouse as close as possible to the cw cursor which makes > fine tuning IMPOSSIBLE. > > 4 - *having a Hue saturation wheel when in HSV mode* (not a big deal, just > makes it easier to see what you are doing a makes more sense IMO) > > > > - Making everybody happy > > > - click far from the cw cursor makes it jump to the mouse position > - click close to the cw cursor makes the mouse jump (snap) to it > - when releasing the cw cursor the mouse postion gets the cw cursor > (that with the two above makes click-drag-release not so painful) > - (mode selfish ON) pressing shift turn off the precise mode ? 8-) > > > cheers, > > F. > > > > -- > > François Tarlier > www.francois-tarlier.com > www.linkedin.com/in/francoistarlier > ___ > 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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [42041] trunk/blender: move image settings into their own structure so the interface can be shared where image saving settings are
misleaking Great typo! Sounds like a new kind of computer program bug. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color wheel proposal
another +1 for me too actual way of usig color wheel simply drive me crazy! E-Mail Sent via BlackBerry from BT Mobile -Original Message- From: Jonathan Williamson Sender: bf-committers-boun...@blender.org Date: Mon, 21 Nov 2011 19:27:55 To: bf-blender developers Reply-To: bf-blender developers Subject: Re: [Bf-committers] Color wheel proposal +1. It would make me very happy! Jonathan Williamson http://blendercookie.com http://mavenseed.com On Nov 21, 2011, at 3:25 PM, François T. wrote: > Yet another one :/ > > I have been trying to do lots of grading lately in Blender, and lost half > of my hairs, so here is my proposal to make it (yes IMO, I know) more > confortable > > *1 - where ever I click on the color wheel (CW), the mouse jump to cw cursor > * > right now its the other way around. While I understand it makes it easier > to quickly change to a total different color, it makes it almost impossible > to fine tune the current color. > *2 - precise mode by default *(perhaps with a logarithmic curve on the > mouse ?) > This might be just a color grading thing, but again I find myself more > looking for the color I'd like surrounding the current one, rather than > totally jumping to a total different one. So pressing the shift key is a > bit annoying > > *3 - When releasing the cw cursor the mouse jump to it* > Yet I believe that would be solved by its own if the first step was done. > But just to notice how annoying this behave right now. Especially since you > have to release the cw cursor to see the new values being updated in the > viewer. you would find yourself to click drag release, click drag release, > click drag release. But since the mouse doesn't move to the new location, > you keep going back to the previous color (gr). So you have to think > about moving the mouse as close as possible to the cw cursor which makes > fine tuning IMPOSSIBLE. > > 4 - *having a Hue saturation wheel when in HSV mode* (not a big deal, just > makes it easier to see what you are doing a makes more sense IMO) > > > > - Making everybody happy > > > - click far from the cw cursor makes it jump to the mouse position > - click close to the cw cursor makes the mouse jump (snap) to it > - when releasing the cw cursor the mouse postion gets the cw cursor > (that with the two above makes click-drag-release not so painful) > - (mode selfish ON) pressing shift turn off the precise mode ? 8-) > > > cheers, > > F. > > > > -- > > François Tarlier > www.francois-tarlier.com > www.linkedin.com/in/francoistarlier > ___ > 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
