Re: [Bf-committers] mkktspace broke compilation for gcc 4.2.4 - patch
applied patch - r34894, thanks! 2011/2/16 Ρυακιωτάκης Αντώνης kal...@gmail.com: The modifications in mkktspace broke compilation on gcc 4.2.x This is a patch proposed by sparky_ on irc. Special thanks to cobe571 for being persistent on the matter. ___ 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] MinGW debug builds do not run
Thanks, but the DLL doesn't have it either. It has PyModule_Create2TraceRefs instead. On 15/02/2011 11:44, Peter Kümmel wrote: On 13.02.2011 14:42, Tom Edwards wrote: The procedure entry point PyModule_Create2 could not be located in the dynamic link library python31_d.dll. There is a script which extracts the symbols from python31_d.dll (which is not build with mingw) for mingw. Maybe it helps when you delete 'python31mw_d.lib' and rerun 'python_mw_update.bat'. In python31_d.def is no 'PyModule_Create2' so maybe python31mw_d.lib was outdated. All these files are in 'your blender path\lib\windows\python\lib' Peter ___ 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] Relaxation patch (Farsthary)
Hi guys :) As you may know, recently I have being working on several relaxation algorithms that prove to be useful for mesh editing to extend funtionality of the current somoothing algorithm implemented in Blender. Well, I have made a patch with the two best relaxation algorithm I have being working on, the Improved Laplacian relaxation, with no shape shrinkage and the HC relaxation with low shape shrinkage. The feature is fairly easy to use and it has toggable shape border preservation. Stay tunned to my site as it will be uploaded soon (http://farsthary.wordpress.com) Hope you like this Farsthary PS: imagine my connection speed that Pasteall does not loead for me O.o! ___ 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
Am 16.02.2011 20:39, schrieb Thomas Dinges: Revision: 34914 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34914 Author: dingto Date: 2011-02-16 19:39:45 + (Wed, 16 Feb 2011) Log Message: --- Commit patch [#25939] material panel proposal by Ervin Weber (lusque). Thanks! From the patch description: A new panel is proposed to bring togheter all the properties of a material that belong to the render pipeline level. Such properties are currently not mixable with node materials, as nodes operate on a shader level. Commiting this patch as approved in the sundy meeting. Roadmap: Beta = Final Feature Set, Ready for Documentation. Could we now stop changing things? This is not a bug or something that stops the now so adulated beginners from using Blender 2.5x. I mean I take a high risk waiting for stabilisation, which means that other authors, who may don't care about correctness, take much of the sales just putting a book on the market as soon as possible. BTW: I am not quite sure if this is all so good placed now, maybe technically correct (shouldn't be Shadeless also there?) but I think it is possibly not very good for the workflow. I would not search in a Render Pipeline Panel for Transparency at the first shot. Nor would I expect Shadow Casting (Casting Alpha, Cast XXX) options NOT in the Shadow panel. 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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
This goes against all of the 2.5 UI design principles and pardigms and
show be removed or onlt be visible when needed, as its a clear case of
craming chikens into a basket, a big ugly mess
On that note it seems the design principles and paradigms that was set
when 2.5 was being desinged seem to have been trown out the window, its
a bloody mess, didn't parts behave differently share same info
differently, the UI of 2.5 is really getting more and more like 2.49 its
not funny, please can we get back on track instead of tacking on UI
elements like in the 2.4 series
On Wed, 2011-02-16 at 19:39 +, Thomas Dinges wrote:
Revision: 34914
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34914
Author: dingto
Date: 2011-02-16 19:39:45 + (Wed, 16 Feb 2011)
Log Message:
---
Commit patch [#25939] material panel proposal by Ervin Weber (lusque). Thanks!
From the patch description:
A new panel is proposed to bring togheter all the properties of a material
that belong to the render pipeline level.
Such properties are currently not mixable with node materials, as nodes
operate on a shader level.
Commiting this patch as approved in the sundy meeting.
Modified Paths:
--
trunk/blender/release/scripts/ui/properties_material.py
Modified: trunk/blender/release/scripts/ui/properties_material.py
===
--- trunk/blender/release/scripts/ui/properties_material.py 2011-02-16
18:29:26 UTC (rev 34913)
+++ trunk/blender/release/scripts/ui/properties_material.py 2011-02-16
19:39:45 UTC (rev 34914)
@@ -34,6 +34,16 @@
return None
+def check_material(mat):
+if mat is not None:
+if mat.use_nodes:
+if mat.active_node_material is not None:
+return True
+return False
+return True
+return False
+
+
class MATERIAL_MT_sss_presets(bpy.types.Menu):
bl_label = SSS Presets
preset_subdir = sss
@@ -116,9 +126,16 @@
elif mat:
split.template_ID(space, pin_id)
split.separator()
-
+
if mat:
layout.prop(mat, type, expand=True)
+if mat.use_nodes:
+row = layout.row()
+row.label(text=, icon='NODETREE')
+if mat.active_node_material:
+row.prop(mat.active_node_material, name, text=)
+else:
+row.label(text=No material node selected)
class MATERIAL_PT_preview(MaterialButtonsPanel, bpy.types.Panel):
@@ -129,16 +146,66 @@
self.layout.template_preview(context.material)
+class MATERIAL_PT_pipeline(MaterialButtonsPanel, bpy.types.Panel):
+bl_label = Render Pipeline Options
+bl_options = {'DEFAULT_CLOSED'}
+COMPAT_ENGINES = {'BLENDER_RENDER', 'BLENDER_GAME'}
+
+@classmethod
+def poll(cls, context):
+mat = context.material
+engine = context.scene.render.engine
+return mat and (mat.type in ('SURFACE', 'WIRE', 'VOLUME')) and
(engine in cls.COMPAT_ENGINES)
+
+def draw(self, context):
+layout = self. layout
+
+mat = context.material
+#split = layout.split()
+mat_type = mat.type in ('SURFACE', 'WIRE')
+
+row = layout.row()
+row.active = mat_type
+row.prop(mat, use_transparency)
+sub = row.column()
+sub.prop(mat, offset_z)
+sub.active = mat_type and mat.use_transparency and
mat.transparency_method == 'Z_TRANSPARENCY'
+
+row = layout.row()
+row.active = mat.use_transparency or not mat_type
+row.prop(mat, transparency_method, expand=True)
+
+layout.separator()
+
+split = layout.split()
+col = split.column()
+
+col.prop(mat, use_raytrace) #
+col.prop(mat, use_full_oversampling) #
+sub = col.column()
+sub.active = mat_type
+sub.prop(mat, use_sky)
+sub.prop(mat, invert_z)
+
+col = split.column()
+col.active = mat_type
+
+col.prop(mat, use_cast_shadows_only, text=Cast Only)
+col.prop(mat, shadow_cast_alpha, text=Casting Alpha)
+col.prop(mat, use_cast_buffer_shadows)
+col.prop(mat, use_cast_approximate)
+
+
class MATERIAL_PT_diffuse(MaterialButtonsPanel, bpy.types.Panel):
bl_label = Diffuse
COMPAT_ENGINES = {'BLENDER_RENDER', 'BLENDER_GAME'}
@classmethod
def poll(cls, context):
-mat = active_node_mat(context.material)
+mat = context.material
engine = context.scene.render.engine
-return mat and (mat.type in ('SURFACE', 'WIRE')) and (engine in
cls.COMPAT_ENGINES)
-
+return check_material(mat) and (mat.type in ('SURFACE', 'WIRE'))
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
The reason those options are there is because they apply to the entire shader tree. It makes perfect sense if you know how it works and actually could lead to a better understanding. This is a great chance to explain this in your book! 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
Just to explain a bit more after talking to some people in IRC. Shadeless is an example of a shader level option. so it should be *local*. You can also control how much of transparency a shader's got locally; BUT the option to enable transparency or not is *global* for the entire shader tree. Same goes with the other settings in the pipeline panel. SO we can say the old UI was wrong and leads to questions like why does one shader in a nodetree overwrites another shader? hope it helps Daniel Salazar 2011/2/16 Daniel Salazar - 3Developer.com zan...@gmail.com The reason those options are there is because they apply to the entire shader tree. It makes perfect sense if you know how it works and actually could lead to a better understanding. This is a great chance to explain this in your book! 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
Am 16.02.2011 22:45, schrieb Thomas Dinges: Hi Carsten, Am 16.02.2011 22:15, schrieb Carsten Wartmann: Roadmap: Beta = Final Feature Set, Ready for Documentation. As I already said before: I don't care about definitions of Beta or Alpha or RCs, I trust in the word (and I really have to, not beeing anymore in (or near) the core of Blender development) and this clearly says what I quoted above. Its not my words its from: http://www.blender.org/development/release-logs/blender-256-beta/ Not a blog of somebody but a highly offical website b.o. But: What If you would be a documenter for Max or Maya? You could only But I am not, and will never be. I put my heard, brain and blood into Blender for over 10 years now, so maybe I am not a neutral person for such discussions but there is a clear gap between what Blender claims to be an what Blender is nowadays. Ok but I stop now. For the Max/Maya analogies: If I would work for autodesk I would *surely* use the real Beta versions of their products an getting fired if the final Book does not match the final version... I think Zanqdo explained the reasoning well. :) Yea, surely helpfull. So could we come to a way of working where changes get documentated by the developer in a way a documentation monkey or a user can understand AND find it? I think thats a big problem with Blender today. It grows faster that the docs. I think (from my POV) a new feature should not be going to trunk unless the developer provides a documentation. I offered my help here in the past, so devs, get you a docu-monkey and an artist. 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
Re: [Bf-committers] MinGW debug builds do not run
On 16.02.2011 12:27, Tom Edwards wrote: Thanks, but the DLL doesn't have it either. It has PyModule_Create2TraceRefs instead. I mean you should generate the .lib before linking, maybe it could link anyway, then it should also start. Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MinGW debug builds do not run
On 16.02.2011 23:21, Peter Kümmel wrote: On 16.02.2011 12:27, Tom Edwards wrote: Thanks, but the DLL doesn't have it either. It has PyModule_Create2TraceRefs instead. I mean you should generate the .lib before linking, maybe it could link anyway, then it should also start. The relevant definition is in - python3.1/modsupport.h: #ifdef Py_TRACE_REFS /* When we are tracing reference counts, rename PyModule_Create2 so modules compiled with incompatible settings will generate a link-time error. */ #define PyModule_Create2 PyModule_Create2TraceRefs #endif PyAPI_FUNC(PyObject *) PyModule_Create2(struct PyModuleDef*, int apiver); #define PyModule_Create(module) \ PyModule_Create2(module, PYTHON_API_VERSION) PyAPI_DATA(char *) _Py_PackageContext; - python3.1/object.h: #if defined(Py_DEBUG) !defined(Py_TRACE_REFS) #define Py_TRACE_REFS #endif - pyconfig.h is #ifdef _DEBUG # define Py_DEBUG #endif So maybe scons doesn't set _DEBUG in debug mode. Peter ___ 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
On 16/02/11 21:56, Tobias Oelgarte wrote: What i really dislike is the confusion between program internal view and the users perspective. We have a panel that is called Transparency. But you can't get transparency with this panel alone I would have to agree... It would seem to me that moving these checkboxes to the pipeline section makes sense at some levels but muddies the waters at the same time. Surely usability should be paramount. A simple solution to keep all parties happy would be to simple duplicate the checkboxes... why not have the button in pipeline (where it makes sense for nodes) and in the transparency panel where it just made a lot of sense? Duplicating the button is so trivial, and personally I think workflow for blender could be greatly enhanced with more places to access functions from. it needn't be this or that it can be both! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MinGW debug builds do not run
- pyconfig.h is #ifdef _DEBUG # define Py_DEBUG #endif So maybe scons doesn't set _DEBUG in debug mode. To test simply uncomment the #ifdef _DEBUG: //#ifdef _DEBUG # define Py_DEBUG //#endif and rebuild. Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Compositer redesign
I submitted two bugs several months ago, but they are really oversights mover than bugs. But what I suggest should be implemented to make the Image Nodes work they way they people will expect them to. Ton seemed to agree, and I'm hoping these can get into the new compositer. I'm donating right now. Here are the two submissions I made to the 2.5 tracker: #25005 #25280 ___ 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 [34921] trunk/blender/source/blender/ windowmanager/intern/wm_event_system.c: Bugfix: Tweaking Markers was working incorrectly
mm this is almost working now. but when you want to cancel with a RMB during
transfom it actually accepts too
cheers!
Daniel Salazar
www.3developer.com
2011/2/16 Joshua Leung aligor...@gmail.com
Revision: 34921
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34921
Author: aligorith
Date: 2011-02-17 01:24:52 + (Thu, 17 Feb 2011)
Log Message:
---
Bugfix: Tweaking Markers was working incorrectly
WM_modal_tweak_exit() was making incorrect use of the user-pref option
Release Confirms Transform, indicated by confused coder comment
(quoteXXX: WTH is this?/quote).
This manisfested when moving markers by just click-dragging and
existing marker, and having it drop whereever the mouse was released
regardless of the user-pref option. This was quite confusing as it was
inconsistent with the way that all other transforms worked when this
option is off, where you would usually start the transform (click-
drag), release the button, move around a bit, and then finally click
to end.
Modified Paths:
--
trunk/blender/source/blender/windowmanager/intern/wm_event_system.c
Modified:
trunk/blender/source/blender/windowmanager/intern/wm_event_system.c
===
--- trunk/blender/source/blender/windowmanager/intern/wm_event_system.c
2011-02-16 21:57:26 UTC (rev 34920)
+++ trunk/blender/source/blender/windowmanager/intern/wm_event_system.c
2011-02-17 01:24:52 UTC (rev 34921)
@@ -2099,21 +2099,29 @@
/* for modal callbacks, check configuration for how to interpret exit with
tweaks */
int WM_modal_tweak_exit(wmEvent *evt, int tweak_event)
{
- /* user preset or keymap? dunno... */
- // XXX WTH is this?
- int tweak_modal= (U.flag USER_RELEASECONFIRM)==0;
+ /* if the release-confirm userpref setting is enabled,
+* tweak events can be cancelled when mouse is released
+*/
+ if (U.flag USER_RELEASECONFIRM) {
+ /* option on, so can exit with km-release */
+ if (evt-val == KM_RELEASE) {
+ switch (tweak_event) {
+ case EVT_TWEAK_L:
+ case EVT_TWEAK_M:
+ case EVT_TWEAK_R:
+ return 1;
+ }
+ }
+ }
+ else {
+ /* this is fine as long as not doing km-release, otherwise
+* some items (i.e. markers) being tweaked may end up
getting
+* dropped all over
+*/
+ if (evt-val != KM_RELEASE)
+ return 1;
+ }
- switch(tweak_event) {
- case EVT_TWEAK_L:
- case EVT_TWEAK_M:
- case EVT_TWEAK_R:
- if(evt-val==tweak_modal)
- return 1;
- default:
- /* this case is when modal callcback didnt get
started with a tweak */
- if(evt-val)
- return 1;
- }
return 0;
}
___
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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
Michael Fox mfoxd...@gmail.com wrote: This goes against all of the 2.5 UI design principles and pardigms and show be removed or onlt be visible when needed, as its a clear case of craming chikens into a basket, a big ugly mess I'd like to reaffirm this. Not only is this antithetical to the 2.5 design, but it simply makes *less* sense from the end-user perspective. There must be a better way of doing it than this. I would suggest that this be reverted until a properly designed solution is presented. I understand the rationale for creating this panel, but the panel looks like a grab-bag of mixed functionality. It's a UI change for worse. This only barely makes sense in the context of node-based materials. If it's critical that these options be grouped together, why not put this in the Properties region of the Node Editor for materials and leave the Materials section of the Properties editor as it was? -Jason ___ 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
This conversation brings me directly back to a link that Ton posted a couple weeks ago: http://www.codesimplicity.com/post/open-source-community-simplified/ I keep seeing the same arguments popping up again and again about documentation, and I think it highlights a larger problem with our development process. As stated in the link above, we have long bug fix phases that no new features are added to Blender. I think this would be just fine if they lasted a couple of weeks, or even a month. But this 'bug fixing' phase has now lasted at least 5 months if we take the Sintel online release as the date of the start of the bug fixing phase. There are now developers who have been chomping on the bit for near half a year to get their hard work into our product to help us! Just as changing the way the code works in late development is bad for documenters, making eager developers wait for half a year to get code integrated is bad and very frustrating for developers. This will make all but the most stubborn developers lose interest and leave. This most definitely is not good for the community as a whole. (I for one am still eagerly awaiting many of the improvements from the last SoC to be integrated, even as the next one is almost upon us). Once again, the article above highlights quite possibly a very good solution. When working towards a release have a release tagged branch for any 'bug only fixes' and always keep trunk as the development branch. When commiting bug fixes - commit to both the tagged release branch and the trunk. It's more overhead, but it would lead to much happier documenters because they could write a book on a not constantly changing program, and it would make the developers much happier because they could work on what they love to work on, adding cool new features, improving workflow, and doing whatever else makes our ever changing product so much fun to work on. If blokes want the 'bleeding edge' they get trunk - otherwise go for a tagged and well documented release. Food for thought -Sean On Wed, Feb 16, 2011 at 6:43 PM, Jason van Gumster ja...@handturkeystudios.com wrote: Michael Fox mfoxd...@gmail.com wrote: This goes against all of the 2.5 UI design principles and pardigms and show be removed or onlt be visible when needed, as its a clear case of craming chikens into a basket, a big ugly mess I'd like to reaffirm this. Not only is this antithetical to the 2.5 design, but it simply makes *less* sense from the end-user perspective. There must be a better way of doing it than this. I would suggest that this be reverted until a properly designed solution is presented. I understand the rationale for creating this panel, but the panel looks like a grab-bag of mixed functionality. It's a UI change for worse. This only barely makes sense in the context of node-based materials. If it's critical that these options be grouped together, why not put this in the Properties region of the Node Editor for materials and leave the Materials section of the Properties editor as it was? -Jason ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- ||-- Instant Messengers -- || ICQ at 11133295 || AIM at shatterstar98 || MSN Messenger at shatte...@hotmail.com || Yahoo Y! at the_7th_samuri ||-- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
