Re: [Bf-committers] Safety request for ctrl-U and File-Save User Prevs
Zes, it's true! Agree,agree! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Safety request for ctrl-U and File-Save User Prevs
Ctrl+U does ask you to confirm if you want to save it. What you want is the same dialog when you call it from the menu? -- Dalai dalaifelinto.com 2011/2/1 Ρυακιωτάκης Αντώνης kal...@gmail.com Zes, it's true! Agree,agree! ___ 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] Safety request for ctrl-U and File-Save User Prevs
Or a cascade of files from new to older. They are small enough and hard drives are huge these days so this should be no problem, even with 100 of them. 2011/2/1 Dalai Felinto dfeli...@gmail.com Ctrl+U does ask you to confirm if you want to save it. What you want is the same dialog when you call it from the menu? -- Dalai dalaifelinto.com 2011/2/1 Ρυακιωτάκης Αντώνης kal...@gmail.com Zes, it's true! Agree,agree! ___ 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 -- 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
Hi Daniel, Whether there are good or bad reasons, it's important to get backup by people who maintain the code, this to prevent everyone to just commit their personal preferences! When no explicit maintainers are mentioned you can always run it via me too :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 1 Feb, 2011, at 0:29, Daniel Salazar - 3Developer.com wrote: I don't think we should be prohibited from making a change because of a screenshot. I'll try to explain my reasons: The legacy empty is cluttered. All that XYZ information is hardly ever needed and when you do need it you can use the manipulators to check the empties coordinate. (legacy empty is older than the manipulator even). The legacy empty is visually shifted to only the positive sides which, with lots of close together empties ends up making selection and recognition difficult http://www.pasteall.org/pic/show.php?id=8469 In the few cases you feel you actually need to see the positive axis arrows theres always the option to set it that way. It's not that I've removed it cheers Daniel Salazar www.3developer.com 2011/1/31 Carsten Wartmann c...@blenderbuch.de: Am 27.01.2011 22:05, schrieb Daniel Salazar: Revision: 34535 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34535 Author: zanqdo Date: 2011-01-27 21:05:01 + (Thu, 27 Jan 2011) Log Message: --- More logical ordering of Empty draw types. Made Plain Axes default for new empties So I have to redo all screenshots containing an Empty in my comming book? Beside the places where I describe the look of Empties or even use them for the reader as hint which axis to choose. I wish such changes would be communicated a bit (better) here. Why do you think this is a better drawtype than the mini-axis? Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ 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] Cleanup Patch for ED_armature_from_edit() from editarmature.c
I'm currently searching for bugs inside the armature code. Not that I
was looking for, but as I'm on it, I found some needless copying (result
will be overwritten anyways) and one computed, but never used matrix
variable (M_boneRest) inside ED_armature_from_edit().
As I read on the mainpage I can either post the patch to the tracker or
mail it on this list. Since it is very minor (changing no functionality)
patch, I hope it gets applied immediately.
Patch is inside the appendix
Greatings from
Tobias Oelgarte
Index: source/blender/editors/armature/editarmature.c
===
--- source/blender/editors/armature/editarmature.c (Revision 34599)
+++ source/blender/editors/armature/editarmature.c (Arbeitskopie)
@@ -398,15 +398,15 @@
/* remove zero sized bones, this gives instable restposes */
for (eBone=arm-edbo-first; eBone; eBone= neBone) {
- float len= len_v3v3(eBone-head, eBone-tail);
- neBone= eBone-next;
+ float len = len_v3v3(eBone-head, eBone-tail);
+ neBone = eBone-next;
if (len = 0.01f) { /* FLT_EPSILON is too large? */
EditBone *fBone;
/* Find any bones that refer to this bone */
for (fBone=arm-edbo-first; fBone; fBone= fBone-next)
{
- if (fBone-parent==eBone)
- fBone-parent= eBone-parent;
+ if (fBone-parent == eBone)
+ fBone-parent = eBone-parent;
}
if (G.f G_DEBUG)
printf(Warning: removed zero sized bone:
%s\n, eBone-name);
@@ -416,59 +416,52 @@
/* Copy the bones from the editData into the armature */
for (eBone=arm-edbo-first; eBone; eBone=eBone-next) {
- newBone= MEM_callocN(sizeof(Bone), bone);
- eBone-temp= newBone; /* Associate the real Bones with the
EditBones */
+ newBone = MEM_callocN(sizeof(Bone), bone);
+ /* Associate the real Bones with the EditBones */
+ eBone-temp = newBone;
+
BLI_strncpy(newBone-name, eBone-name, sizeof(newBone-name));
- memcpy(newBone-head, eBone-head, sizeof(newBone-head));
- memcpy(newBone-tail, eBone-tail, sizeof(newBone-tail));
- newBone-flag= eBone-flag;
+ newBone-flag = eBone-flag;
if (eBone == arm-act_edbone) {
- newBone-flag |= BONE_SELECTED; /* important, editbones
can be active with only 1 point selected */
- arm-act_edbone= NULL;
- arm-act_bone= newBone;
+ /* important, editbones can be active with only 1 point
selected */
+ newBone-flag |= BONE_SELECTED;
+ arm-act_edbone = NULL;
+ arm-act_bone = newBone;
}
newBone-roll = 0.0f;
-
newBone-weight = eBone-weight;
newBone-dist = eBone-dist;
-
newBone-xwidth = eBone-xwidth;
newBone-zwidth = eBone-zwidth;
- newBone-ease1= eBone-ease1;
- newBone-ease2= eBone-ease2;
- newBone-rad_head= eBone-rad_head;
- newBone-rad_tail= eBone-rad_tail;
- newBone-segments= eBone-segments;
+ newBone-ease1 = eBone-ease1;
+ newBone-ease2 = eBone-ease2;
+ newBone-rad_head = eBone-rad_head;
+ newBone-rad_tail = eBone-rad_tail;
+ newBone-segments = eBone-segments;
newBone-layer = eBone-layer;
if(eBone-prop)
- newBone-prop= IDP_CopyProperty(eBone-prop);
+ newBone-prop = IDP_CopyProperty(eBone-prop);
}
/* Fix parenting in a separate pass to ensure ebone-bone
connections
are valid at this point */
- for (eBone=arm-edbo-first;eBone;eBone=eBone-next) {
- newBone= (Bone *)eBone-temp;
+ for (eBone=arm-edbo-first; eBone; eBone=eBone-next) {
+ newBone = (Bone *)eBone-temp;
if (eBone-parent) {
- newBone-parent= (Bone *)eBone-parent-temp;
+ newBone-parent = (Bone *)eBone-parent-temp;
BLI_addtail(newBone-parent-childbase, newBone);
-
{
- float M_boneRest[3][3];
float M_parentRest[3][3];
float
Re: [Bf-committers] Safety request for ctrl-U and File-Save User Prevs
Me too, i managed to override the default blend once in a while and is pretty annoying, because it doesn't happens all the time and you are not prepared for that, loosing all the changes you made. Not even a confirmation option, to me this is almost surreal, also a good point to bring back to the table the discussion of confirmation pocess in blender, sometimes blender abuses that you have precision of the robot when you are only a simple human being. Cheers. 2011/2/1 Knapp magick.c...@gmail.com Or a cascade of files from new to older. They are small enough and hard drives are huge these days so this should be no problem, even with 100 of them. 2011/2/1 Dalai Felinto dfeli...@gmail.com Ctrl+U does ask you to confirm if you want to save it. What you want is the same dialog when you call it from the menu? -- Dalai dalaifelinto.com 2011/2/1 Ρυακιωτάκης Αντώνης kal...@gmail.com Zes, it's true! Agree,agree! ___ 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 -- 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 ___ 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 [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
This issue could probably be solved for all parties involved if/when we get user definable defaults for all operators. On 2011/02/01 01:10 PM, Ton Roosendaal wrote: Hi Daniel, Whether there are good or bad reasons, it's important to get backup by people who maintain the code, this to prevent everyone to just commit their personal preferences! When no explicit maintainers are mentioned you can always run it via me too :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 1 Feb, 2011, at 0:29, Daniel Salazar - 3Developer.com wrote: I don't think we should be prohibited from making a change because of a screenshot. I'll try to explain my reasons: The legacy empty is cluttered. All that XYZ information is hardly ever needed and when you do need it you can use the manipulators to check the empties coordinate. (legacy empty is older than the manipulator even). The legacy empty is visually shifted to only the positive sides which, with lots of close together empties ends up making selection and recognition difficult http://www.pasteall.org/pic/show.php?id=8469 In the few cases you feel you actually need to see the positive axis arrows theres always the option to set it that way. It's not that I've removed it cheers Daniel Salazar www.3developer.com 2011/1/31 Carsten Wartmannc...@blenderbuch.de: Am 27.01.2011 22:05, schrieb Daniel Salazar: Revision: 34535 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34535 Author: zanqdo Date: 2011-01-27 21:05:01 + (Thu, 27 Jan 2011) Log Message: --- More logical ordering of Empty draw types. Made Plain Axes default for new empties So I have to redo all screenshots containing an Empty in my comming book? Beside the places where I describe the look of Empties or even use them for the reader as hint which axis to choose. I wish such changes would be communicated a bit (better) here. Why do you think this is a better drawtype than the mini-axis? Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ 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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Question about bone allocation (Chicken or the egg)
Im currently reviewing the armature code to fix the loss of precession while switching between edit mode and pose mode. Basically the locations and roll angles are computed back and forth every time. Since it is done with floating point precession the rig tends to fall apart. To correct that i will have to know how the Bone struct is allocated. Does it even get allocated? Meaning that it will always be the result from a conversion from struct EditBone to struct Bone? The question is basically about the fact which kind of struct is created first. From using blender i would assume that Editbones get created first and will then be converted to Bones, when you leave editmode. On the other hand: How it is handled while loading an existing file? Are the Editbones (for editmode) stored or the Bones (for Posemode and anything else)? What i basically want to do is to store the untransformed head and tail locations together with the boneroll as separate variables inside the Bone struct. That seams to me the only way to get rid of the steady conversions, which will end up destroying the bone locations in editmode. Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about bone allocation (Chicken or the egg)
Why are heads and tails stored anyway? This would be a great opportunity to make editbones loc, rot, length. The difference between edit and pose is bizarre from both a user's and developer's perspective, and a huge HUGE headache when importing/exporting. On 01/02/2011 2:13, Tobias Oelgarte wrote: Im currently reviewing the armature code to fix the loss of precession while switching between edit mode and pose mode. Basically the locations and roll angles are computed back and forth every time. Since it is done with floating point precession the rig tends to fall apart. To correct that i will have to know how the Bone struct is allocated. Does it even get allocated? Meaning that it will always be the result from a conversion from struct EditBone to struct Bone? The question is basically about the fact which kind of struct is created first. From using blender i would assume that Editbones get created first and will then be converted to Bones, when you leave editmode. On the other hand: How it is handled while loading an existing file? Are the Editbones (for editmode) stored or the Bones (for Posemode and anything else)? What i basically want to do is to store the untransformed head and tail locations together with the boneroll as separate variables inside the Bone struct. That seams to me the only way to get rid of the steady conversions, which will end up destroying the bone locations in editmode. Tobias Oelgarte ___ 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] Question about bone allocation (Chicken or the egg)
I don't know. Maybe it is easier to write code for the positioning of the bones in edit-mode and it wastes less space while storing. The real issue behind this is the steady conversion between this two types of structs. Everytime it will compute the boneroll, head and tail again as you enter edit-mode. A first more simple fix would be store this three properties along with Bone struct. (It has the same variable names, but they store different values) If i would add this three additional variables (float e_roll, float e_head[3], float e_tail[3]) then they could simply be copied back. This would at least result in no loss of precession. The more general approach would be to make no difference and use one struct for both of them. This will store a bunch of extra information, but seriously, how many bones do you use? May it 1000 bones, then its still less then any normal sized texture. But it still does not answer my main question. Is any Bone Object allocated somewhere before it's corresponding EditBone Object? If not, then it would be easy to implement the three additional variables. The recomputation of roll, head and tail could be omitted while switching from pose- to edit-mode. The next step then could be to get rid of the EditBone-struct and the needles conversations, copying of properties. Am 01.02.2011 16:00, schrieb Tom Edwards: Why are heads and tails stored anyway? This would be a great opportunity to make editbones loc, rot, length. The difference between edit and pose is bizarre from both a user's and developer's perspective, and a huge HUGE headache when importing/exporting. On 01/02/2011 2:13, Tobias Oelgarte wrote: Im currently reviewing the armature code to fix the loss of precession while switching between edit mode and pose mode. Basically the locations and roll angles are computed back and forth every time. Since it is done with floating point precession the rig tends to fall apart. To correct that i will have to know how the Bone struct is allocated. Does it even get allocated? Meaning that it will always be the result from a conversion from struct EditBone to struct Bone? The question is basically about the fact which kind of struct is created first. From using blender i would assume that Editbones get created first and will then be converted to Bones, when you leave editmode. On the other hand: How it is handled while loading an existing file? Are the Editbones (for editmode) stored or the Bones (for Posemode and anything else)? What i basically want to do is to store the untransformed head and tail locations together with the boneroll as separate variables inside the Bone struct. That seams to me the only way to get rid of the steady conversions, which will end up destroying the bone locations in editmode. Tobias Oelgarte ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
Daniel Salazar - 3Developer.com zan...@gmail.com wrote: I don't think we should be prohibited from making a change because of a screenshot. I'll try to explain my reasons: Without getting into the details of the merits of which default draw type is the best, framing this as prohibition because of a screenshot is a bit of a convenient oversimplification of the situation. Carsten isn't the only one this change affects. There are a lot of people documenting Blender now and changes to default settings impacts all of us. It just would've been nice to have a heads-up on this list prior to making such a change. That way, at the very least, we're prepared for it... and at best, we can provide some feedback. Thanks. -Jason ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about bone allocation (Chicken or the egg)
OK. Now i wrote a patch against it. It's a little bit a hack, since i need to ensure that the roll is at least computed once while importing older files. New Files will store the roll after applying this patch. What it does: * It prevents any modification onto the bones while switching between bone-edit-mode and something else. * It copies the current head, tail, roll to the Bone structs that are used in pose-mode * When entering edit-mode it just copies the values back, ensuring no issues caused by floating point errors. The good things: * Bones are now fixed and you can't destory you rig anymore by just tabbing between pose- and editmode. * Copying is faster then computation (not a real problem) The bad things: * Additional memory used for Bone struct (not a real problem) * A little hack, to ensure compatibility to older files. Otherwise you can't open them without destroying the rig The patch: * http://pastebin.com/mV5BwHqW What could be done: * I do not know in which way blender stores the bones. I assume it stores the Bone structs. But i couldn't find the location in the code where they are read in. The problem is, that i have to setup the additional variables at least once, idealy when importing/creating the Bone structs. As long i can not fix this, i will have to use the variable e_used introduced by the patch. Greetings from Tobias Oelgarte, hoping on any kind of response, since this is a major bug. (I might be a bit angry, because my last rig got fucked up ^^) Am 01.02.2011 16:00, schrieb Tom Edwards: Why are heads and tails stored anyway? This would be a great opportunity to make editbones loc, rot, length. The difference between edit and pose is bizarre from both a user's and developer's perspective, and a huge HUGE headache when importing/exporting. On 01/02/2011 2:13, Tobias Oelgarte wrote: Im currently reviewing the armature code to fix the loss of precession while switching between edit mode and pose mode. Basically the locations and roll angles are computed back and forth every time. Since it is done with floating point precession the rig tends to fall apart. To correct that i will have to know how the Bone struct is allocated. Does it even get allocated? Meaning that it will always be the result from a conversion from struct EditBone to struct Bone? The question is basically about the fact which kind of struct is created first. From using blender i would assume that Editbones get created first and will then be converted to Bones, when you leave editmode. On the other hand: How it is handled while loading an existing file? Are the Editbones (for editmode) stored or the Bones (for Posemode and anything else)? What i basically want to do is to store the untransformed head and tail locations together with the boneroll as separate variables inside the Bone struct. That seams to me the only way to get rid of the steady conversions, which will end up destroying the bone locations in editmode. Tobias Oelgarte ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Campbell,
I must object strongly to what you've done here. Once again you've crippled
my addon (and perhaps others) at the drop of a hat, and again without giving
any prior notice or discussion on the issue.
Consider the design of an export/render addon:
1. Create an operator that exports the scene to file
2. Add an entry in file-export for that operator
3. USE that same operator to export the scene prior to rendering
Now that you've effectively disabled the scene export operator during
RenderEngine.render(), you've broken this addon design.
The only way I can possibly make the rendering work again is to duplicate a
whole load of code that forms the scene export operator into the render()
method, and this is clearly a bad idea.
Yours sincerely annoyed,
Doug Hammond.
On 1 February 2011 00:32, Campbell Barton ideasma...@gmail.com wrote:
Revision: 34590
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34590
Author: campbellbarton
Date: 2011-02-01 00:32:50 + (Tue, 01 Feb 2011)
Log Message:
---
workaround [#25845] Empty UI panels
- now writing to RNA is disabled when inside render() call.
- disallow calling operators when writes are disabled.
Rendering runs in a thread so running operators from the thread is not safe
unless rendering becomes a blocking operator again.
Modified Paths:
--
trunk/blender/source/blender/python/intern/bpy_operator.c
trunk/blender/source/blender/python/intern/bpy_rna.c
trunk/blender/source/blender/python/intern/bpy_rna.h
Modified: trunk/blender/source/blender/python/intern/bpy_operator.c
===
--- trunk/blender/source/blender/python/intern/bpy_operator.c 2011-01-31
23:54:51 UTC (rev 34589)
+++ trunk/blender/source/blender/python/intern/bpy_operator.c 2011-02-01
00:32:50 UTC (rev 34590)
@@ -138,6 +138,11 @@
return NULL;
}
+ if(!pyrna_write_check()) {
+ PyErr_Format(PyExc_SystemError, Calling operator
\bpy.ops.%s\ error, can't modify blend data in this state
(drawing/rendering), opname);
+ return NULL;
+ }
+
if(context_str) {
if(RNA_enum_value_from_id(operator_context_items,
context_str, context)==0) {
char *enum_str=
BPy_enum_as_string(operator_context_items);
Modified: trunk/blender/source/blender/python/intern/bpy_rna.c
===
--- trunk/blender/source/blender/python/intern/bpy_rna.c2011-01-31
23:54:51 UTC (rev 34589)
+++ trunk/blender/source/blender/python/intern/bpy_rna.c2011-02-01
00:32:50 UTC (rev 34590)
@@ -83,7 +83,19 @@
}
return FALSE;
}
+#endif // USE_PEDANTIC_WRITE
+
+#ifdef USE_PEDANTIC_WRITE
+int pyrna_write_check(void)
+{
+ return !rna_disallow_writes;
+}
+#else // USE_PEDANTIC_WRITE
+int pyrna_write_check(void)
+{
+ return TRUE;
+}
#endif // USE_PEDANTIC_WRITE
static Py_ssize_t pyrna_prop_collection_length(BPy_PropertyRNA *self);
@@ -5324,8 +5336,9 @@
PyGILState_STATE gilstate;
#ifdef USE_PEDANTIC_WRITE
+ const char *func_id= RNA_function_identifier(func);
/* testing, for correctness, not operator and not draw function */
- const short is_readonly= strstr(draw,
RNA_function_identifier(func)) || !RNA_struct_is_a(ptr-type,
RNA_Operator);
+ const short is_readonly= strstr(draw, func_id) ||
strstr(render, func_id) || !RNA_struct_is_a(ptr-type, RNA_Operator);
#endif
py_class= RNA_struct_py_type_get(ptr-type);
Modified: trunk/blender/source/blender/python/intern/bpy_rna.h
===
--- trunk/blender/source/blender/python/intern/bpy_rna.h2011-01-31
23:54:51 UTC (rev 34589)
+++ trunk/blender/source/blender/python/intern/bpy_rna.h2011-02-01
00:32:50 UTC (rev 34590)
@@ -108,4 +108,6 @@
PyObject *pyrna_math_object_from_array(PointerRNA *ptr, PropertyRNA
*prop);
int pyrna_array_contains_py(PointerRNA *ptr, PropertyRNA *prop, PyObject
*value);
+int pyrna_write_check(void);
+
#endif
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about bone allocation (Chicken or the egg)
On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote: The patch: * http://pastebin.com/mV5BwHqW Blender has a Patch Tracker. Putting patches in our tracker makes it easier to review and maintain them. Making it easier for patch reviewers is making it easier to get your patch applied. -- Stephen Swaney sswa...@centurytel.net ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about bone allocation (Chicken or the egg)
Hi, This patch and the other one you posted contain many formatting changes, please keep those out of patches, it's hard to see what you changed. Regarding this fix, it would be better to store original roll/head/tail + loc/rot/scale on entering edit mode in the EditBone, and then use that when you convert back from EditBone to Bone, if the roll/head/tail didn't change (maybe need to check for parent changes too). That keeps it nice localized. Better not store duplicate state in files, not because of memory usage, but because it's better to keep such hacks in runtime code. Brecht. On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaney sswa...@centurytel.net wrote: On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote: The patch: * http://pastebin.com/mV5BwHqW Blender has a Patch Tracker. Putting patches in our tracker makes it easier to review and maintain them. Making it easier for patch reviewers is making it easier to get your patch applied. -- Stephen Swaney sswa...@centurytel.net ___ 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 [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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 [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. I think there should be a dedicated mailing list for changes in the python API. Even if it is not stable or official yet, it's a de-facto API and people are using it. On Tue, Feb 1, 2011 at 12:57 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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] Question about bone allocation (Chicken or the egg)
@ Brecht Van Lommel:
You are right. I should have not made any further changes.
But regarding the storage of the variables i can't imagine a better
place, since the editmode is where the precession comes from. If you
store the restpositions in editmode and check with some delta against
it, you will end up with the same problem again (floating point errors).
The only right position for bones is the location inside the editmode.
The editmode can have an effect on the the posemode, but whatever you do
should have NO effect on the locations in editmode.
For example: A mesh will be deformed, but kept locally as it is. The
same paradigm must be applied to bones.
The hack inside my code will be only necessary for importing. Once
imported, it isn't needed anymore. But i could not find the codesection
that creates the Bone structs while importing. Thats why i wrote it the
way it is. Anything in if (curBone-e_used == 0) { should be moved
there and no hack will be needed anymore. The variable e_used could be
removed.
Maybe you want to give me a hint in which file the Bone structs are
created. As soon i will know, i can implement a short check and set them
up correctly without the need of additional variables, except for
e_roll, e_head and e_tail.
Greetings from Tobias Oelgarte
Am 01.02.2011 18:47, schrieb Brecht Van Lommel:
Hi,
This patch and the other one you posted contain many formatting
changes, please keep those out of patches, it's hard to see what you
changed.
Regarding this fix, it would be better to store original
roll/head/tail + loc/rot/scale on entering edit mode in the EditBone,
and then use that when you convert back from EditBone to Bone, if the
roll/head/tail didn't change (maybe need to check for parent changes
too). That keeps it nice localized. Better not store duplicate state
in files, not because of memory usage, but because it's better to keep
such hacks in runtime code.
Brecht.
On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaneysswa...@centurytel.net wrote:
On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote:
The patch:
* http://pastebin.com/mV5BwHqW
Blender has a Patch Tracker. Putting patches in our tracker
makes it easier to review and maintain them.
Making it easier for patch reviewers is making it easier to
get your patch applied.
--
Stephen Swaney
sswa...@centurytel.net
___
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] Question about bone allocation (Chicken or the egg)
I fixed the issues with the patch and uploaded it to the tracker: http://projects.blender.org/tracker/index.php?func=detailaid=25901group_id=9atid=127 The only thing that is missing is a check for older files. (See the description on the tracker for further information) I still need to find out, where the Bone structs getting allocated while opening and existing file. A small check for 0 and one initial computation with the current method should do the job. Any files that are stored afterwards will be fine, since the check will always fail. Am 01.02.2011 18:47, schrieb Brecht Van Lommel: Hi, This patch and the other one you posted contain many formatting changes, please keep those out of patches, it's hard to see what you changed. Regarding this fix, it would be better to store original roll/head/tail + loc/rot/scale on entering edit mode in the EditBone, and then use that when you convert back from EditBone to Bone, if the roll/head/tail didn't change (maybe need to check for parent changes too). That keeps it nice localized. Better not store duplicate state in files, not because of memory usage, but because it's better to keep such hacks in runtime code. Brecht. On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaneysswa...@centurytel.net wrote: On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote: The patch: * http://pastebin.com/mV5BwHqW Blender has a Patch Tracker. Putting patches in our tracker makes it easier to review and maintain them. Making it easier for patch reviewers is making it easier to get your patch applied. -- Stephen Swaney sswa...@centurytel.net ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Another side effect of this is that it's no longer possible to call my UI message operator if something goes wrong with the render process. I'm forced to revert to printing to console, which many of our users are unable to find or copy/paste from correctly (example: http://www.luxrender.net/forum/viewtopic.php?f=13t=5369 ). So, some new way to cause UI messages to appear would be great ;) Cheers, Doug. On 1 February 2011 18:07, Shaul Kedem shaul.ke...@gmail.com wrote: Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. I think there should be a dedicated mailing list for changes in the python API. Even if it is not stable or official yet, it's a de-facto API and people are using it. On Tue, Feb 1, 2011 at 12:57 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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] Question about bone allocation (Chicken or the egg)
Hi,
We should continue discussion in the patch tracker, please open a
report there. I'll reply later trying to explain what I mean, I still
think this is the wrong solution...
Brecht.
On Tue, Feb 1, 2011 at 7:12 PM, Tobias Oelgarte
tobias.oelga...@googlemail.com wrote:
But regarding the storage of the variables i can't imagine a better
place, since the editmode is where the precession comes from. If you
store the restpositions in editmode and check with some delta against
it, you will end up with the same problem again (floating point errors).
The only right position for bones is the location inside the editmode.
The editmode can have an effect on the the posemode, but whatever you do
should have NO effect on the locations in editmode.
For example: A mesh will be deformed, but kept locally as it is. The
same paradigm must be applied to bones.
The hack inside my code will be only necessary for importing. Once
imported, it isn't needed anymore. But i could not find the codesection
that creates the Bone structs while importing. Thats why i wrote it the
way it is. Anything in if (curBone-e_used == 0) { should be moved
there and no hack will be needed anymore. The variable e_used could be
removed.
Maybe you want to give me a hint in which file the Bone structs are
created. As soon i will know, i can implement a short check and set them
up correctly without the need of additional variables, except for
e_roll, e_head and e_tail.
Greetings from Tobias Oelgarte
Am 01.02.2011 18:47, schrieb Brecht Van Lommel:
Hi,
This patch and the other one you posted contain many formatting
changes, please keep those out of patches, it's hard to see what you
changed.
Regarding this fix, it would be better to store original
roll/head/tail + loc/rot/scale on entering edit mode in the EditBone,
and then use that when you convert back from EditBone to Bone, if the
roll/head/tail didn't change (maybe need to check for parent changes
too). That keeps it nice localized. Better not store duplicate state
in files, not because of memory usage, but because it's better to keep
such hacks in runtime code.
Brecht.
On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaneysswa...@centurytel.net
wrote:
On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote:
The patch:
* http://pastebin.com/mV5BwHqW
Blender has a Patch Tracker. Putting patches in our tracker
makes it easier to review and maintain them.
Making it easier for patch reviewers is making it easier to
get your patch applied.
--
Stephen Swaney
sswa...@centurytel.net
___
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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about bone allocation (Chicken or the egg)
What do you mean with please open a report? I already added a patch
proposal at:
https://projects.blender.org/tracker/index.php?func=detailaid=25901group_id=9atid=127
Did you mean something else, a bugreport maybe? (Im not familiar with
the tracker)
Am 01.02.2011 21:11, schrieb Brecht Van Lommel:
Hi,
We should continue discussion in the patch tracker, please open a
report there. I'll reply later trying to explain what I mean, I still
think this is the wrong solution...
Brecht.
On Tue, Feb 1, 2011 at 7:12 PM, Tobias Oelgarte
tobias.oelga...@googlemail.com wrote:
But regarding the storage of the variables i can't imagine a better
place, since the editmode is where the precession comes from. If you
store the restpositions in editmode and check with some delta against
it, you will end up with the same problem again (floating point errors).
The only right position for bones is the location inside the editmode.
The editmode can have an effect on the the posemode, but whatever you do
should have NO effect on the locations in editmode.
For example: A mesh will be deformed, but kept locally as it is. The
same paradigm must be applied to bones.
The hack inside my code will be only necessary for importing. Once
imported, it isn't needed anymore. But i could not find the codesection
that creates the Bone structs while importing. Thats why i wrote it the
way it is. Anything in if (curBone-e_used == 0) { should be moved
there and no hack will be needed anymore. The variable e_used could be
removed.
Maybe you want to give me a hint in which file the Bone structs are
created. As soon i will know, i can implement a short check and set them
up correctly without the need of additional variables, except for
e_roll, e_head and e_tail.
Greetings from Tobias Oelgarte
Am 01.02.2011 18:47, schrieb Brecht Van Lommel:
Hi,
This patch and the other one you posted contain many formatting
changes, please keep those out of patches, it's hard to see what you
changed.
Regarding this fix, it would be better to store original
roll/head/tail + loc/rot/scale on entering edit mode in the EditBone,
and then use that when you convert back from EditBone to Bone, if the
roll/head/tail didn't change (maybe need to check for parent changes
too). That keeps it nice localized. Better not store duplicate state
in files, not because of memory usage, but because it's better to keep
such hacks in runtime code.
Brecht.
On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaneysswa...@centurytel.net
wrote:
On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote:
The patch:
* http://pastebin.com/mV5BwHqW
Blender has a Patch Tracker. Putting patches in our tracker
makes it easier to review and maintain them.
Making it easier for patch reviewers is making it easier to
get your patch applied.
--
Stephen Swaney
sswa...@centurytel.net
___
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 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 [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Reverted the render part of this commit which checks for render() calls, r25845. Re-opened the bug and assigned to Brecht. Since this functionality is broken (not thread safe and causes python to give errors), I didn't think existing scripts depended on this. If disabling operator calls during draw() functions is also a problem I can revert that part of the commit too but I really think this is bad practice so left in for now. - Campbell On Tue, Feb 1, 2011 at 7:23 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Another side effect of this is that it's no longer possible to call my UI message operator if something goes wrong with the render process. I'm forced to revert to printing to console, which many of our users are unable to find or copy/paste from correctly (example: http://www.luxrender.net/forum/viewtopic.php?f=13t=5369 ). So, some new way to cause UI messages to appear would be great ;) Cheers, Doug. On 1 February 2011 18:07, Shaul Kedem shaul.ke...@gmail.com wrote: Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. I think there should be a dedicated mailing list for changes in the python API. Even if it is not stable or official yet, it's a de-facto API and people are using it. On Tue, Feb 1, 2011 at 12:57 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about bone allocation (Chicken or the egg)
It's fine, I received your last e-mail after I sent mine.
Brecht.
On Tue, Feb 1, 2011 at 9:19 PM, Tobias Oelgarte
tobias.oelga...@googlemail.com wrote:
What do you mean with please open a report? I already added a patch
proposal at:
https://projects.blender.org/tracker/index.php?func=detailaid=25901group_id=9atid=127
Did you mean something else, a bugreport maybe? (Im not familiar with
the tracker)
Am 01.02.2011 21:11, schrieb Brecht Van Lommel:
Hi,
We should continue discussion in the patch tracker, please open a
report there. I'll reply later trying to explain what I mean, I still
think this is the wrong solution...
Brecht.
On Tue, Feb 1, 2011 at 7:12 PM, Tobias Oelgarte
tobias.oelga...@googlemail.com wrote:
But regarding the storage of the variables i can't imagine a better
place, since the editmode is where the precession comes from. If you
store the restpositions in editmode and check with some delta against
it, you will end up with the same problem again (floating point errors).
The only right position for bones is the location inside the editmode.
The editmode can have an effect on the the posemode, but whatever you do
should have NO effect on the locations in editmode.
For example: A mesh will be deformed, but kept locally as it is. The
same paradigm must be applied to bones.
The hack inside my code will be only necessary for importing. Once
imported, it isn't needed anymore. But i could not find the codesection
that creates the Bone structs while importing. Thats why i wrote it the
way it is. Anything in if (curBone-e_used == 0) { should be moved
there and no hack will be needed anymore. The variable e_used could be
removed.
Maybe you want to give me a hint in which file the Bone structs are
created. As soon i will know, i can implement a short check and set them
up correctly without the need of additional variables, except for
e_roll, e_head and e_tail.
Greetings from Tobias Oelgarte
Am 01.02.2011 18:47, schrieb Brecht Van Lommel:
Hi,
This patch and the other one you posted contain many formatting
changes, please keep those out of patches, it's hard to see what you
changed.
Regarding this fix, it would be better to store original
roll/head/tail + loc/rot/scale on entering edit mode in the EditBone,
and then use that when you convert back from EditBone to Bone, if the
roll/head/tail didn't change (maybe need to check for parent changes
too). That keeps it nice localized. Better not store duplicate state
in files, not because of memory usage, but because it's better to keep
such hacks in runtime code.
Brecht.
On Tue, Feb 1, 2011 at 6:36 PM, Stephen Swaneysswa...@centurytel.net
wrote:
On Tue, Feb 01, 2011 at 06:04:59PM +0100, Tobias Oelgarte wrote:
The patch:
* http://pastebin.com/mV5BwHqW
Blender has a Patch Tracker. Putting patches in our tracker
makes it easier to review and maintain them.
Making it easier for patch reviewers is making it easier to
get your patch applied.
--
Stephen Swaney
sswa...@centurytel.net
___
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 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
You should use the reporting API for that. It logs to the internal console, so users will be able to copy/paste and whatnot. Martin --- On Tue, 2/1/11, Doug Hammond doughamm...@hamsterfight.co.uk wrote: From: Doug Hammond doughamm...@hamsterfight.co.uk Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels To: bf-blender developers bf-committers@blender.org Received: Tuesday, February 1, 2011, 2:23 PM Another side effect of this is that it's no longer possible to call my UI message operator if something goes wrong with the render process. I'm forced to revert to printing to console, which many of our users are unable to find or copy/paste from correctly (example: http://www.luxrender.net/forum/viewtopic.php?f=13t=5369 ). So, some new way to cause UI messages to appear would be great ;) Cheers, Doug. On 1 February 2011 18:07, Shaul Kedem shaul.ke...@gmail.com wrote: Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. I think there should be a dedicated mailing list for changes in the python API. Even if it is not stable or official yet, it's a de-facto API and people are using it. On Tue, Feb 1, 2011 at 12:57 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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 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 [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Reporting is only available inside operators, which I can't use from the RenderEngine Cheers, Doug. On 1 February 2011 21:17, Martin Poirier the...@yahoo.com wrote: You should use the reporting API for that. It logs to the internal console, so users will be able to copy/paste and whatnot. Martin --- On Tue, 2/1/11, Doug Hammond doughamm...@hamsterfight.co.uk wrote: From: Doug Hammond doughamm...@hamsterfight.co.uk Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels To: bf-blender developers bf-committers@blender.org Received: Tuesday, February 1, 2011, 2:23 PM Another side effect of this is that it's no longer possible to call my UI message operator if something goes wrong with the render process. I'm forced to revert to printing to console, which many of our users are unable to find or copy/paste from correctly (example: http://www.luxrender.net/forum/viewtopic.php?f=13t=5369 ). So, some new way to cause UI messages to appear would be great ;) Cheers, Doug. On 1 February 2011 18:07, Shaul Kedem shaul.ke...@gmail.com wrote: Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. I think there should be a dedicated mailing list for changes in the python API. Even if it is not stable or official yet, it's a de-facto API and people are using it. On Tue, Feb 1, 2011 at 12:57 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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 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 [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels
Then it should be made available inside a RenderEngine (I was thinking of the render log thingy). Martin --- On Tue, 2/1/11, Doug Hammond doughamm...@hamsterfight.co.uk wrote: From: Doug Hammond doughamm...@hamsterfight.co.uk Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels To: bf-blender developers bf-committers@blender.org Received: Tuesday, February 1, 2011, 4:25 PM Reporting is only available inside operators, which I can't use from the RenderEngine Cheers, Doug. On 1 February 2011 21:17, Martin Poirier the...@yahoo.com wrote: You should use the reporting API for that. It logs to the internal console, so users will be able to copy/paste and whatnot. Martin --- On Tue, 2/1/11, Doug Hammond doughamm...@hamsterfight.co.uk wrote: From: Doug Hammond doughamm...@hamsterfight.co.uk Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34590] trunk/blender/source/blender/ python/intern: workaround [#25845] Empty UI panels To: bf-blender developers bf-committers@blender.org Received: Tuesday, February 1, 2011, 2:23 PM Another side effect of this is that it's no longer possible to call my UI message operator if something goes wrong with the render process. I'm forced to revert to printing to console, which many of our users are unable to find or copy/paste from correctly (example: http://www.luxrender.net/forum/viewtopic.php?f=13t=5369 ). So, some new way to cause UI messages to appear would be great ;) Cheers, Doug. On 1 February 2011 18:07, Shaul Kedem shaul.ke...@gmail.com wrote: Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. I think there should be a dedicated mailing list for changes in the python API. Even if it is not stable or official yet, it's a de-facto API and people are using it. On Tue, Feb 1, 2011 at 12:57 PM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: Though it should be quite simple to fix things without duplicate code in your case, by making a function that both the operator and render engine call? Yes, indeed this is what I've done - in fact the refactoring is not as big an issue as the lack of communication here and the fact that I end up having several addon users complaining at me that things have stopped working every time this happens! Please please, for the sake of everyone's sanity, start communicating to the API users before changing it. Doug. ___ 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 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
OK guys, no matter what, blender will not look the same in the future. That is why you documenters always have new stuff to show right? Greater changes are being made all the time, it's your job to keep up. Of course I could have told about it in this list but I do believe this is getting out of hand. Blender is continually being changed all over the place. What I changed is only a default, I didn't remove the draw option. I've changed tons of stuff like this in the past, defaults and limits for settings everywhere, added options on the UI.. and all of them based on my experience working on blender everyday. I don't think documentation has to be *perfectly* up to date either. You are not teaching robots are you? With all that said, I will try to be more communicative in the future but hope this doesnt become a considerable limit for my efforts in blender cheers Daniel Salazar 2011/2/1 Jason van Gumster ja...@handturkeystudios.com: Daniel Salazar - 3Developer.com zan...@gmail.com wrote: I don't think we should be prohibited from making a change because of a screenshot. I'll try to explain my reasons: Without getting into the details of the merits of which default draw type is the best, framing this as prohibition because of a screenshot is a bit of a convenient oversimplification of the situation. Carsten isn't the only one this change affects. There are a lot of people documenting Blender now and changes to default settings impacts all of us. It just would've been nice to have a heads-up on this list prior to making such a change. That way, at the very least, we're prepared for it... and at best, we can provide some feedback. Thanks. -Jason ___ 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 [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
Hi, zan...@gmail.com (2011-02-01 at 1830.42 -0600): OK guys, no matter what, blender will not look the same in the future. Why does it have to change? Change for the sake of change sucks (or you are trying to sell something and your only way is changing the paint). This new default is less informative than before. Try rotating an empty. Ooops, you do not see what is XYZ anymore, because default manipulator mode does not match. It only works as old empties when it is set to the right mode and the empty is selected. Before it was a quick glaze, now it requires selection and maybe even changing the manipulator mode (and back to what you were using, and select whatever you had before, of course). That does not sound a change for better, but one that makes things slower. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
My $0.02: I'm with ZanQdo here. And I know very well how a last minute default change can screw up documentation. Large portions of my second book were seriously borked by the change to add objects in Object mode rather than Edit mode, which was a decision made after the first or second test build of the version had already been released. I got a lot of 1 star reviews on amazon over that! :(. For situations like that, at the stage of debug builds, I think changes should be as strictly as possible limited to debugging, and changes that affect workflow at that late stage should be seriously (re)considered and communicated. But we're not at that stage now, we're at beta, and at beta all kinds of things can change. And if the changes don't affect workflow (like the default draw of Empties) then I don't see much of an issue. Redoing screenshots isn't even necessary. Unless the book has already gone to press then one line of text can explain the different draw type. And if the book has gone to press, well, that's what happens when you write about beta software. Documenters (and learners) just need to live with that. A book isn't obsolete just because an icon looks different or an empty is drawn differently, and anybody who thinks it is should probably stay away from Blender books. T OK guys, no matter what, blender will not look the same in the future. That is why you documenters always have new stuff to show right? Greater changes are being made all the time, it's your job to keep up. Of course I could have told about it in this list but I do believe this is getting out of hand. Blender is continually being changed all over the place. What I changed is only a default, I didn't remove the draw option. I've changed tons of stuff like this in the past, defaults and limits for settings everywhere, added options on the UI.. and all of them based on my experience working on blender everyday. I don't think documentation has to be *perfectly* up to date either. You are not teaching robots are you? With all that said, I will try to be more communicative in the future but hope this doesnt become a considerable limit for my efforts in blender cheers Daniel Salazar ___ 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 [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
No doubts. I hope that there's no misunderstanding here. Blender is by far one of the most documenter-friendly environments around. In fact, I'd go so far as to say that we're pretty spoiled if things like this are all we have to complain about. I'm well aware that defaults have changed before and I've ridden the wave with those as well. My comment was that it's sometimes nice to have a touch of warning when it comes to the more visible changes. Whether or not that actually happens, I'll deal with it... and I'll probably deal with it with a smile on my face. The silver lining here is that the issue has been raised and addressed. In other development communities, we might not even get that much. :) Thanks! Jason Tony Mullen tony.mul...@gmail.com wrote: My $0.02: I'm with ZanQdo here. And I know very well how a last minute default change can screw up documentation. Large portions of my second book were seriously borked by the change to add objects in Object mode rather than Edit mode, which was a decision made after the first or second test build of the version had already been released. I got a lot of 1 star reviews on amazon over that! :(. For situations like that, at the stage of debug builds, I think changes should be as strictly as possible limited to debugging, and changes that affect workflow at that late stage should be seriously (re)considered and communicated. But we're not at that stage now, we're at beta, and at beta all kinds of things can change. And if the changes don't affect workflow (like the default draw of Empties) then I don't see much of an issue. Redoing screenshots isn't even necessary. Unless the book has already gone to press then one line of text can explain the different draw type. And if the book has gone to press, well, that's what happens when you write about beta software. Documenters (and learners) just need to live with that. A book isn't obsolete just because an icon looks different or an empty is drawn differently, and anybody who thinks it is should probably stay away from Blender books. T OK guys, no matter what, blender will not look the same in the future. That is why you documenters always have new stuff to show right? Greater changes are being made all the time, it's your job to keep up. Of course I could have told about it in this list but I do believe this is getting out of hand. Blender is continually being changed all over the place. What I changed is only a default, I didn't remove the draw option. I've changed tons of stuff like this in the past, defaults and limits for settings everywhere, added options on the UI.. and all of them based on my experience working on blender everyday. I don't think documentation has to be *perfectly* up to date either. You are not teaching robots are you? With all that said, I will try to be more communicative in the future but hope this doesnt become a considerable limit for my efforts in blender cheers Daniel Salazar ___ 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] Do you have think create the engine for xbox 360 and PS3 game development?
I thinking about 'if blender game engine also works over xbox 360 and PS3 ' some know if blender will be adapt in a future? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do you have think create the engine for xbox 360 and PS3 game development?
The BGE cannot link against closed source libraries. Both the 360 and PS3 SDKs are closed source, which means the BGE can never support them. Cheers, Mitchell Stokes ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
