Re: [Bf-committers] Some ideas to improve the Add-Ons section
i think adding keywords to addons would be good, Searching for a specific addon limmited by its name sometimes isnt the best Daniel Salazar 3Developer.com On Sun, May 22, 2011 at 11:58 PM, Hart's Antler bhart...@yahoo.com wrote: The Addons system badly needs a recently added list, that should be the default when going to UserPrefsAddons. The most common question i get from users of my addons is where do i go to enable it. Even if i put in the addon README UserPrefsAddonsSomecategorymyaddon, few seem to figure that out and get lost is the long list of addons presented in the Addon panel. -brett --- On Sun, 5/22/11, mindrones mindro...@gmail.com wrote: From: mindrones mindro...@gmail.com Subject: Re: [Bf-committers] Some ideas to improve the Add-Ons section To: bf-blender developers bf-committers@blender.org Date: Sunday, 22 May, 2011, 1:43 PM Hi! On 05/21/2011 12:31 AM, Doug Hammond wrote: - Ability to keep addons in sync/update with an online repo could work but am wary of this turning into a package manager, we would need to have a branch for each release so addon devs could work on extension trunk as well as the release branch so users get updates too. Since this needs buy-in from existing addon developers I rather leave this for a bit since addons are being actively added/written/removed and the addon community is still quite new. I though work in this direction was already under way, I remember discussing at length with mindrones about addon metadata, development branches, stable branches, binary module URLs etc etc... What happened to all that effort? It's a bit on hold due to my work on the wiki maintenance and real life small disasters (like having to relocate twice :) Some times ago, when we've setup the new wiki server we have also setup a virtual host for the addon dispatcher application that will distribute updates for trunk/contrib, but also for externals addons, like luxrender, yafaray, gamekit, etc... As Doug said, the design is already setup, see http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/External_addons All in all we have dsicussed at length, so we know well what to do, it's a matter of doing it. Sorry to be late on that :/ As Campbell said, we will need to work on branches, so that if a developer has updates for a blender version that has already been released he will have to commit in branches, here: https://svn.blender.org/svnroot/bf-extensions/branches/ If you download a certain version of blender and a developer makes a fix on branch for your revision, you would get notified and download the new version. But it's not that easy because some people develop scripts in the scripts/ dir, so just overwriting the current script with a new one might be undesirable for some people. We need to think about a temp/dev folder to store stuff when we update. About external scripts, there has been a long discussion with Ton in #blendercoders: 1) if a script is developed outside of bf-extensions, like on github or so, BF will only work as mirror at https://svn.blender.org/svnroot/bf-extensions/extern/ 1b) no real development would be allowed on bf-extensions/extern/. - BF would allow developers to make API changes fixes and trivial fixes on bf-extensions/extern, but not more to avoid forking - externals devs should agree to port these fixes to their external repo 2) of course only GPL-compatible scripts would be distributable via bf-extensions/extern/ With all these resctrictions and complications, I agree that this will evolve into a package manager, so it's not that easy to do it quick and dirty. Our goal would be a system like the firefox addons site, but this is a major feature and it has has server-side maintenance implications, so it's not something you develop in blender only. To avoid server-side implications, you should let blender download stuff from wherever you want but according to the discussions we had back then, I doubt BF will allow this on official releases. Hope this has clarifies things a bit :) Regards, Luca ___ 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
Re: [Bf-committers] Some ideas to improve the Add-Ons section
I would like to see one more button - Edit Addon for quicker access to the addon code (I know, I can always navigate my self through folders but why not quicken things). Also, I think that Import-Export category should be divided in two separated Import and Export categories because the fact that not all import-export addons providing both functions and even under File menu they are having separated sub-menus. And one more thing but that one is more related to general design of some pages of User Prefs: Left side with buttons should be separated from the right side with list of addons and both should be scrollable (same would be applicable to theme and input pages of user prefs) Best regards, Damir On 23 May 2011 06:01, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: i think adding keywords to addons would be good, Searching for a specific addon limmited by its name sometimes isnt the best Daniel Salazar 3Developer.com On Sun, May 22, 2011 at 11:58 PM, Hart's Antler bhart...@yahoo.com wrote: The Addons system badly needs a recently added list, that should be the default when going to UserPrefsAddons. The most common question i get from users of my addons is where do i go to enable it. Even if i put in the addon README UserPrefsAddonsSomecategorymyaddon, few seem to figure that out and get lost is the long list of addons presented in the Addon panel. -brett --- On Sun, 5/22/11, mindrones mindro...@gmail.com wrote: From: mindrones mindro...@gmail.com Subject: Re: [Bf-committers] Some ideas to improve the Add-Ons section To: bf-blender developers bf-committers@blender.org Date: Sunday, 22 May, 2011, 1:43 PM Hi! On 05/21/2011 12:31 AM, Doug Hammond wrote: - Ability to keep addons in sync/update with an online repo could work but am wary of this turning into a package manager, we would need to have a branch for each release so addon devs could work on extension trunk as well as the release branch so users get updates too. Since this needs buy-in from existing addon developers I rather leave this for a bit since addons are being actively added/written/removed and the addon community is still quite new. I though work in this direction was already under way, I remember discussing at length with mindrones about addon metadata, development branches, stable branches, binary module URLs etc etc... What happened to all that effort? It's a bit on hold due to my work on the wiki maintenance and real life small disasters (like having to relocate twice :) Some times ago, when we've setup the new wiki server we have also setup a virtual host for the addon dispatcher application that will distribute updates for trunk/contrib, but also for externals addons, like luxrender, yafaray, gamekit, etc... As Doug said, the design is already setup, see http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/External_addons All in all we have dsicussed at length, so we know well what to do, it's a matter of doing it. Sorry to be late on that :/ As Campbell said, we will need to work on branches, so that if a developer has updates for a blender version that has already been released he will have to commit in branches, here: https://svn.blender.org/svnroot/bf-extensions/branches/ If you download a certain version of blender and a developer makes a fix on branch for your revision, you would get notified and download the new version. But it's not that easy because some people develop scripts in the scripts/ dir, so just overwriting the current script with a new one might be undesirable for some people. We need to think about a temp/dev folder to store stuff when we update. About external scripts, there has been a long discussion with Ton in #blendercoders: 1) if a script is developed outside of bf-extensions, like on github or so, BF will only work as mirror at https://svn.blender.org/svnroot/bf-extensions/extern/ 1b) no real development would be allowed on bf-extensions/extern/. - BF would allow developers to make API changes fixes and trivial fixes on bf-extensions/extern, but not more to avoid forking - externals devs should agree to port these fixes to their external repo 2) of course only GPL-compatible scripts would be distributable via bf-extensions/extern/ With all these resctrictions and complications, I agree that this will evolve into a package manager, so it's not that easy to do it quick and dirty. Our goal would be a system like the firefox addons site, but this is a major feature and it has has server-side maintenance implications, so it's not something you develop in blender only. To avoid server-side implications, you should let blender download stuff from wherever you want but according to the discussions we had back then, I doubt BF will allow this on official releases. Hope this has clarifies things a bit :) Regards, Luca
Re: [Bf-committers] Some ideas to improve the Add-Ons section
Maybe change the list to a table with 3 columns for: | addon name | installed | last update | And let the table be sortable by column... From the ongoing discussion it appears to me that you (the blender coders) focus on those addon modules which get distributed with blender-releases. While i was focussing on third party modules which are NOT distributed with blender releases! So IMHO no fancy module-management is needed for these addons (from blender). Maybe this are 2 separate but related issues at the end ? To summarize again my initial post: The most interesting features (for me) are: - Add the ability to deinstall an installed (third party) module - Add the ability to insert persistent customization data for modules. The customization data should persist a blender upgrade and a module upgrade (i have no idea if that is easy or complicated to do) An additional nice to have would be - add an API to query (a third party website) for new versions of an addon module, and possibly add a button for retrieving the addon directly from a (third party) download server instead of first downloading from the web, then updating. This would fit nicely into the list of buttons: [Wiki], [Bug Report], [Check for Update] Cheers, Gaia Am 23.05.2011 07:58, schrieb Hart's Antler: The Addons system badly needs a recently added list, that should be the default when going to UserPrefsAddons. The most common question i get from users of my addons is where do i go to enable it. Even if i put in the addon README UserPrefsAddonsSomecategorymyaddon, few seem to figure that out and get lost is the long list of addons presented in the Addon panel. -brett --- On Sun, 5/22/11, mindronesmindro...@gmail.com wrote: From: mindronesmindro...@gmail.com Subject: Re: [Bf-committers] Some ideas to improve the Add-Ons section To: bf-blender developersbf-committers@blender.org Date: Sunday, 22 May, 2011, 1:43 PM Hi! On 05/21/2011 12:31 AM, Doug Hammond wrote: - Ability to keep addons in sync/update with an online repo could work but am wary of this turning into a package manager, we would need to have a branch for each release so addon devs could work on extension trunk as well as the release branch so users get updates too. Since this needs buy-in from existing addon developers I rather leave this for a bit since addons are being actively added/written/removed and the addon community is still quite new. I though work in this direction was already under way, I remember discussing at length with mindrones about addon metadata, development branches, stable branches, binary module URLs etc etc... What happened to all that effort? It's a bit on hold due to my work on the wiki maintenance and real life small disasters (like having to relocate twice :) Some times ago, when we've setup the new wiki server we have also setup a virtual host for the addon dispatcher application that will distribute updates for trunk/contrib, but also for externals addons, like luxrender, yafaray, gamekit, etc... As Doug said, the design is already setup, see http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/External_addons All in all we have dsicussed at length, so we know well what to do, it's a matter of doing it. Sorry to be late on that :/ As Campbell said, we will need to work on branches, so that if a developer has updates for a blender version that has already been released he will have to commit in branches, here: https://svn.blender.org/svnroot/bf-extensions/branches/ If you download a certain version of blender and a developer makes a fix on branch for your revision, you would get notified and download the new version. But it's not that easy because some people develop scripts in the scripts/ dir, so just overwriting the current script with a new one might be undesirable for some people. We need to think about a temp/dev folder to store stuff when we update. About external scripts, there has been a long discussion with Ton in #blendercoders: 1) if a script is developed outside of bf-extensions, like on github or so, BF will only work as mirror at https://svn.blender.org/svnroot/bf-extensions/extern/ 1b) no real development would be allowed on bf-extensions/extern/. - BF would allow developers to make API changes fixes and trivial fixes on bf-extensions/extern, but not more to avoid forking - externals devs should agree to port these fixes to their external repo 2) of course only GPL-compatible scripts would be distributable via bf-extensions/extern/ With all these resctrictions and complications, I agree that this will evolve into a package manager, so it's not that easy to do it quick and dirty. Our goal would be a system like the firefox addons site, but this is a major feature and it has has server-side maintenance implications, so it's not something you develop in blender
Re: [Bf-committers] Some ideas to improve the Add-Ons section
On Mon, May 23, 2011 at 1:58 AM, Jass gaia.cl...@machinimatrix.org wrote:
--snip--
- add an API to query (a third party website) for new versions of an
addon module, and possibly add a button for retrieving the addon
directly from a (third party) download server instead of first
downloading
from the web, then updating. This would fit nicely into the list of
buttons: [Wiki], [Bug Report], [Check for Update]
I think I (and others) would be kind of weary of blender being able to
download and install software from random websites.
For customizable persistent settings, addon authors could use
_bpy.user_resource('CONFIG', 'plugin_name') to get a (hopefully)
writeable folder to store settings in.
As a bit of an aside, I think _bpy.user_resource() should throw an
exception instead of returning an invalid path when the folder doesn't
exist so one wouldn't have to test for a valid path after calling the
function.
Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
Hi there :)
Yes, the patch is more like spagetty code and for internal development, I
use all of those hacks in order to get a working system first, and only
then start reworking/redisigning into a readable form. UnlimitedClay is
about mixing two very separated functionality in Blender source code:
sculpting and mesh editing, and as a result I have to move around parts of
the code to make them visible to other parts, that's why I have broken the
encapsulation principle but I always think of that as a temporal solution,
not something worth to be taken into account.
I know everyone is busy, so do I releasing the first public beta or
LiveClay for 3DCoat, UnlimitedClay now has two betas ... well, they're
more like alphas ;)
I don't expect too much aid in porting it to new sources rigth now, so I
think I will have to make the migration from EditMesh to BMesh on my own,
also I don't like the modifier approach but only time will tell whether
is better or not to have it as an integral feature of the sculpting
module or as a modifier.
due to the low feedback I'm getting from unlimitedClay for Blender .. are
people still interested on it? I'm still here :(
Hi, Blender Community!
I've reviewed unlimited clay patch yesterday. I haven't been able to
apply patch/compile correctly, so i can't give feedback about how things
are working, but i could give some feedback about patch itself.
- First of all it's created against a bit outdated version of trunk --
some files were moved, some functions renamed and so. It lead to plenty
of rejected hunks in patchs.
- Patch contains plenty of non-functional changes: whitespace changes,
somewhere styling changes, somewhere changed logic -- code in
non-unlimitedclay related code was replaced with different code whick
makes the same things (like normals in getEditMeshDerivedMesh). This
makes patch much more difficult to be applied against newer trunk and
readability of this patch also lower -- can't split what is actually
changes and what's not.
- That including of ED_mesh.h in DerivedMesh.c and pbvh.c. It's not
only ugly usage of absolute path. but it's also a breaking of
archeticure -- blenkernel/ and blenlib/ shouldn't use editors/. I
suppose editmesh is needed for easier changing mesh topology, but i also
suppose it could be made without such hacks. For example add some
utility functions to blenkernel/intern/mesh which would provide list of
verts/edges/faces (similar lists as in editmesh). I think it's the most
worth thing for which EditMesh is used atm.
- I also not sure why it's needed to move structures (like
EditMeshDerivedMesh, StrokeCache, PBVH, PBVHNode and so) from .c-fiels
into headers. This structures aren't supposed to be reused outside of
their module and they should be a blackbox for other modules.
- Styling should be checked. I'd prefer to keep only one style inside
one module. Check comments, brackets, spaces and so.
- Also it looks like there's some unused code adding by patch but which
isn't used.
- I'm not fully like all that new fields inside EditVert. Maybe they
could be moved inside tmp union or EditVert-data could be reused? Or as
i mentioned, EditMesh could be replaced by something more light and
common... Or maybe it'll be special structure for unlimited clay
purposes and functions like {make,load}_clayMesh?
- I'm not sure why stuff like BLI_pbvh_iter_end should be changed?
That's all feedback i could give atm.
We discussed a bit ways to split out unneeded changes with Tom, but not
sure that ways would be useful. I'd prefer if manual reading of patch
would be done -- in this case all outdated stuff would be found.
I hope it'll help to make patch better and acceptable to be commited.
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
- Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana. Cuba.
http://www.congresouniversidad.cu
- Consulte la Enciclopedia Colaborativa Cubana. http://www.ecured.cu
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
Hi raul, people are interested in it, but without it compiling against head, people have difficulty playing with it (even compiling it against the older version of blender that it uses is a bit of a pain - i think only me and jms got it built). Most users need features and fixes from the most recent version of blender so unless they can apply it against head, they won't be able to give much feedback. LetterRip due to the low feedback I'm getting from unlimitedClay for Blender .. are people still interested on it? I'm still here :( ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
due to the low feedback I'm getting fromunlimitedClay for Blender .. are people still interested on it? I'm still here :( This saddens me. I believe much of what Tom posted above is relevant. Right now, UC is unable to get into the hands and minds of the artists that are most capable to run with it and illustrate its brilliance. With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Unlimited clay patch review
Hi Raul, some info I thougth someone has being able to compile it and post a build online ... didn't knew community don't have a build to test with. a build was posted here http://www.zoo-logique.org/3D.Blender/index.php3?zoo=com exactly: http://www.zoo-logique.org/3D.Blender/php/compteur.php?url=win32_unlim_clay-110428 this was downloaded 336 times people played with it, but not much. somehow this build is not stable compared to current Blender builds - so people notice that when they looked at the patch. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
Hi Raul,
Please don't give up on Unlimited Clay, every blender artist i know is excited
about Unlimited Clay.
On a side note: it probably is better to have it as a modifier, at least thats
my feeling.
-brett
--- On Mon, 5/23/11, ra...@info.upr.edu.cu ra...@info.upr.edu.cu wrote:
From: ra...@info.upr.edu.cu ra...@info.upr.edu.cu
Subject: Re: [Bf-committers] Unlimited clay patch review
To: bf-blender developers bf-committers@blender.org
Date: Monday, 23 May, 2011, 12:22 PM
Hi there :)
Yes, the patch is more like spagetty code and for internal
development, I
use all of those hacks in order to get a working system
first, and only
then start reworking/redisigning into a readable form.
UnlimitedClay is
about mixing two very separated functionality in Blender
source code:
sculpting and mesh editing, and as a result I have to move
around parts of
the code to make them visible to other parts, that's why I
have broken the
encapsulation principle but I always think of that as a
temporal solution,
not something worth to be taken into account.
I know everyone is busy, so do I releasing the first public
beta or
LiveClay for 3DCoat, UnlimitedClay now has two betas ...
well, they're
more like alphas ;)
I don't expect too much aid in porting it to new sources
rigth now, so I
think I will have to make the migration from EditMesh to
BMesh on my own,
also I don't like the modifier approach but only time will
tell whether
is better or not to have it as an integral feature of the
sculpting
module or as a modifier.
due to the low feedback I'm getting from unlimitedClay for
Blender .. are
people still interested on it? I'm still here :(
Hi, Blender Community!
I've reviewed unlimited clay patch yesterday. I
haven't been able to
apply patch/compile correctly, so i can't give
feedback about how things
are working, but i could give some feedback about
patch itself.
- First of all it's created against a bit outdated
version of trunk --
some files were moved, some functions renamed and so.
It lead to plenty
of rejected hunks in patchs.
- Patch contains plenty of non-functional changes:
whitespace changes,
somewhere styling changes, somewhere changed logic
-- code in
non-unlimitedclay related code was replaced with
different code whick
makes the same things (like normals in
getEditMeshDerivedMesh). This
makes patch much more difficult to be applied against
newer trunk and
readability of this patch also lower -- can't split
what is actually
changes and what's not.
- That including of ED_mesh.h in DerivedMesh.c and
pbvh.c. It's not
only ugly usage of absolute path. but it's also a
breaking of
archeticure -- blenkernel/ and blenlib/ shouldn't use
editors/. I
suppose editmesh is needed for easier changing mesh
topology, but i also
suppose it could be made without such hacks. For
example add some
utility functions to blenkernel/intern/mesh which
would provide list of
verts/edges/faces (similar lists as in editmesh). I
think it's the most
worth thing for which EditMesh is used atm.
- I also not sure why it's needed to move structures
(like
EditMeshDerivedMesh, StrokeCache, PBVH, PBVHNode and
so) from .c-fiels
into headers. This structures aren't supposed to be
reused outside of
their module and they should be a blackbox for other
modules.
- Styling should be checked. I'd prefer to keep only
one style inside
one module. Check comments, brackets, spaces and so.
- Also it looks like there's some unused code adding
by patch but which
isn't used.
- I'm not fully like all that new fields inside
EditVert. Maybe they
could be moved inside tmp union or EditVert-data
could be reused? Or as
i mentioned, EditMesh could be replaced by something
more light and
common... Or maybe it'll be special structure for
unlimited clay
purposes and functions like {make,load}_clayMesh?
- I'm not sure why stuff like BLI_pbvh_iter_end should
be changed?
That's all feedback i could give atm.
We discussed a bit ways to split out unneeded changes
with Tom, but not
sure that ways would be useful. I'd prefer if manual
reading of patch
would be done -- in this case all outdated stuff would
be found.
I hope it'll help to make patch better and acceptable
to be commited.
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
- Participe en Universidad 2012, del 13 al 17 de febrero de
2012. Habana. Cuba. http://www.congresouniversidad.cu
- Consulte la Enciclopedia Colaborativa Cubana. http://www.ecured.cu
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Re: [Bf-committers] Unlimited clay patch review
On 23 May 2011 22:22, ra...@info.upr.edu.cu wrote: Hi there :) Yes, the patch is more like spagetty code and for internal development, I use all of those hacks in order to get a working system first, and only then start reworking/redisigning into a readable form. UnlimitedClay is about mixing two very separated functionality in Blender source code: sculpting and mesh editing, and as a result I have to move around parts of the code to make them visible to other parts, that's why I have broken the encapsulation principle but I always think of that as a temporal solution, not something worth to be taken into account. I know everyone is busy, so do I releasing the first public beta or LiveClay for 3DCoat, UnlimitedClay now has two betas ... well, they're more like alphas ;) I don't expect too much aid in porting it to new sources rigth now, so I think I will have to make the migration from EditMesh to BMesh on my own, also I don't like the modifier approach but only time will tell whether is better or not to have it as an integral feature of the sculpting module or as a modifier. due to the low feedback I'm getting from unlimitedClay for Blender .. are people still interested on it? I'm still here :( :-o You're kidding right? This is one of the most woo-hoo hurray super-dooper califragilisticexpialidocious feature coming soon to a blender build near you. Please don't give up on it :) ! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
On 24/05/2011 6:13 AM, ra...@info.upr.edu.cu wrote: Thanks for the quick repply. I thougth someone has being able to compile it and post a build online ... didn't knew community don't have a build to test with. (a consecuence of the lack of feedback) my main communication channel is email, I can't barely surf the web and definatelly I cannot longer visit BlenderArtist forums due to the new look (which I praise a lot but has left me out of the game :P) so if I don't get them this way I will miss it :( I can honestly say that there are quite a few people on the BlenderArtist forums still interested in the feature. That said a few people have mention, and I will personally here, that the patch is not working nicely - not to mention that I have been using a more recent version of Blender for everything else (making a return to the older version less palatable). Perhaps a patch against a more recent head would garner more feedback? -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
On 5/24/11 12:55 AM, Ρυακιωτάκης Αντώνης wrote: On 23 May 2011 22:22,ra...@info.upr.edu.cu wrote: Hi there :) Yes, the patch is more like spagetty code and for internal development, I use all of those hacks in order to get a working system first, and only then start reworking/redisigning into a readable form. UnlimitedClay is about mixing two very separated functionality in Blender source code: sculpting and mesh editing, and as a result I have to move around parts of the code to make them visible to other parts, that's why I have broken the encapsulation principle but I always think of that as a temporal solution, not something worth to be taken into account. I know everyone is busy, so do I releasing the first public beta or LiveClay for 3DCoat, UnlimitedClay now has two betas ... well, they're more like alphas ;) I don't expect too much aid in porting it to new sources rigth now, so I think I will have to make the migration from EditMesh to BMesh on my own, also I don't like the modifier approach but only time will tell whether is better or not to have it as an integral feature of the sculpting module or as a modifier. due to the low feedback I'm getting from unlimitedClay for Blender .. are people still interested on it? I'm still here :( :-o You're kidding right? This is one of the most woo-hoo hurray super-dooper califragilisticexpialidocious feature coming soon to a blender build near you. Please don't give up on it :) ! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers +1 on that, keep it up!! ___ 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 [36806] trunk/blender/release/scripts/ startup/bl_ui/properties_object_constraint.py: Fix for [#27333] Translation constraint is b
Hi Thomas, to use ASCII arrows in the ui seems really strange to me. Couldn't we split this in two lines with X, Y, Z in one and the three dropboxes in the other? Regards, Dalai 2011/5/20 Thomas Dinges blen...@dingto.org No idea what happened in the log: Right message: When you set “X” under the Destination’s “Z”, it does not mean that the Z transform of the source should affect the X transform of the destination, but rather that the X transform of the source should affect the Z transform of the destination… Am 20.05.2011 20:26, schrieb Thomas Dinges: Revision: 36806 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=36806 Author: dingto Date: 2011-05-20 18:26:44 + (Fri, 20 May 2011) Log Message: --- Fix for [#27333] Translation constraint is broken. Committing here a patch by Bastien Montagne (mont29), a more understandable Translation Constraint UI. Before: http://www.pasteall.org/pic/12578 Now http://www.pasteall.org/pic/12258 From the description: When you set ?\226?\128?\156X?\226?\128?\157 under the Destination?\226?\128?\153s ?\226?\128?\156Z?\226?\128?\157, it does not mean that the Z transform of the source should affect the X transform of the destination, but rather that the X transform of the source should affect the Z transform of the destination?\226?\128?\166 ___ 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 [36806] trunk/blender/release/scripts/ startup/bl_ui/properties_object_constraint.py: Fix for [#27333] Translation constraint is b
Hi Dalai, sure this would be also possible. We don't have such arrow icons it seems. (which would be best) Will look into it end of this week. Regards, Thomas Am 24.05.2011 05:42, schrieb Dalai Felinto: Hi Thomas, to use ASCII arrows in the ui seems really strange to me. Couldn't we split this in two lines with X, Y, Z in one and the three dropboxes in the other? Regards, Dalai 2011/5/20 Thomas Dingesblen...@dingto.org No idea what happened in the log: Right message: When you set “X” under the Destination’s “Z”, it does not mean that the Z transform of the source should affect the X transform of the destination, but rather that the X transform of the source should affect the Z transform of the destination… Am 20.05.2011 20:26, schrieb Thomas Dinges: Revision: 36806 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=36806 Author: dingto Date: 2011-05-20 18:26:44 + (Fri, 20 May 2011) Log Message: --- Fix for [#27333] Translation constraint is broken. Committing here a patch by Bastien Montagne (mont29), a more understandable Translation Constraint UI. Before: http://www.pasteall.org/pic/12578 Now http://www.pasteall.org/pic/12258 From the description: When you set ?\226?\128?\156X?\226?\128?\157 under the Destination?\226?\128?\153s ?\226?\128?\156Z?\226?\128?\157, it does not mean that the Z transform of the source should affect the X transform of the destination, but rather that the X transform of the source should affect the Z transform of the destination?\226?\128?\166 ___ 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
