Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35470] trunk/blender:
Sorry, I missed to include Log Message.
I paste it here:
Transparency patch: makes sure that materials are not rendered
transparent if the use_transparency check is disabled. Adds a new
transparency option 'MASK' for enabling the old behaviour.
* rationale
The use_transparency check in the transparency panel header may lead
the User to expect that, by unchecking it, every transparency effect
will be disabled.
That’s confusing, since alpha, fresnel and blend parameters are
still used to perform background masking.
* usage
With transparency check ON: the material will render as before.
The new option MASK is analogous for an old material with
transparency check off.
With transparency check OFF:
Every transparency effect in the material will be disabled.
The material will render solid.
- disable alpha, fresnel transp, specular transparency
- disable texture mapped to alpha and transparent facetexture
- disable transparent object color
- will not project transparent shadows
- shadow-only materials will have alpha=1.0
- if reflected or refracted will appear solid
On 11/03/2011 8.59, Ervin Weber wrote:
Revision: 35470
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35470
Author: lusque
Date: 2011-03-11 07:59:43 + (Fri, 11 Mar 2011)
Log Message:
---
Modified Paths:
--
trunk/blender/release/scripts/ui/properties_material.py
trunk/blender/source/blender/blenkernel/BKE_blender.h
trunk/blender/source/blender/blenloader/intern/readfile.c
trunk/blender/source/blender/makesrna/intern/rna_material.c
trunk/blender/source/blender/render/intern/source/convertblender.c
trunk/blender/source/blender/render/intern/source/rayshade.c
trunk/blender/source/blender/render/intern/source/shadeoutput.c
Modified: trunk/blender/release/scripts/ui/properties_material.py
===
--- trunk/blender/release/scripts/ui/properties_material.py 2011-03-11
05:23:56 UTC (rev 35469)
+++ trunk/blender/release/scripts/ui/properties_material.py 2011-03-11
07:59:43 UTC (rev 35470)
@@ -373,11 +373,12 @@
row.prop(mat, transparency_method, expand=True)
split = layout.split()
+split.active = base_mat.use_transparency
col = split.column()
col.prop(mat, alpha)
row = col.row()
-row.active = base_mat.use_transparency and (not mat.use_shadeless)
+row.active = (base_mat.transparency_method != 'MASK') and (not
mat.use_shadeless)
row.prop(mat, specular_alpha, text=Specular)
col = split.column()
Modified: trunk/blender/source/blender/blenkernel/BKE_blender.h
===
--- trunk/blender/source/blender/blenkernel/BKE_blender.h 2011-03-11
05:23:56 UTC (rev 35469)
+++ trunk/blender/source/blender/blenkernel/BKE_blender.h 2011-03-11
07:59:43 UTC (rev 35470)
@@ -44,7 +44,7 @@
* and keep comment above the defines.
* Use STRINGIFY() rather then defining with quotes */
#define BLENDER_VERSION 256
-#define BLENDER_SUBVERSION 2
+#define BLENDER_SUBVERSION 3
#define BLENDER_MINVERSION 250
#define BLENDER_MINSUBVERSION 0
Modified: trunk/blender/source/blender/blenloader/intern/readfile.c
===
--- trunk/blender/source/blender/blenloader/intern/readfile.c 2011-03-11
05:23:56 UTC (rev 35469)
+++ trunk/blender/source/blender/blenloader/intern/readfile.c 2011-03-11
07:59:43 UTC (rev 35470)
@@ -11488,6 +11488,29 @@
}
}
+ if (main-versionfile 256 || (main-versionfile == 256
main-subversionfile3)){
+
+ Material *mat;
+ int tex_nr, transp_tex;
+
+ for(mat = main-mat.first; mat; mat = mat-id.next){
+ if(!(mat-mode MA_TRANSP) !(mat-material_type
MA_TYPE_VOLUME)){
+
+ transp_tex= 0;
+
+ for(tex_nr=0; tex_nrMAX_MTEX; tex_nr++){
+ if(!mat-mtex[tex_nr]) continue;
+ if(mat-mtex[tex_nr]-mapto
MAP_ALPHA) transp_tex= 1;
+ }
+
+ if(mat-alpha 1.0f || mat-fresnel_tra 0.0f
|| transp_tex){
+ mat-mode |= MA_TRANSP;
+ mat-mode= ~(MA_ZTRANSP|MA_RAYTRANSP);
+ }
+ }
+ }
+ }
+
/* put compatibility code here until next subversion bump */
{
Modified:
Re: [Bf-committers] Mapping and Soft Limits suggestions
My comments to your sections, as i see it: + (Change) - Size parameter name to Tiling: Could be usefull, since size is inverted anyway. Meaning the texture is scaled by 0.5 if size is 2. + (Add) - Rotation controls on the Mapping parameters: Don't think that this would be necessary. You can always map to an object/empty. This allows easy control over the rotation scaling and translation. + (Add) - Parameters for Sampling/Blur in Procedural maps: Don't see the need for them. If you have problems with moire effects, you could always adjust the antialiasing settings for the renderer or add focus blur with composite nodes. Then you have sharp lines in the front and no moire in the back. + (Add) - Soft Limit to some parameters: Could be useful but don't know about blenders internal limitations in this cases. But so far i had never an issue with this settings. It are usually much lower for good results. Am 11.03.2011 04:35, schrieb ertuqueque: (I just suscribed to the mailing list so moderators don't need to review my previous message). Hi, to keep it short, I've condensed several mapping and soft limits suggestions and changes in the document below... http://www.tuqueque.org/documents/Suggestions.pdf I use Blender a lot for production work and this simple changes I propose, would be incredibly helpful not only for me but all Blender users I think I'd like to have some feedback from devs. Greets. Robin tuqueque Marín. ___ 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] Mapping and Soft Limits suggestions
On Fri, Mar 11, 2011 at 8:18 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: + (Add) - Parameters for Sampling/Blur in Procedural maps: Don't see the need for them. If you have problems with moire effects, you could always adjust the antialiasing settings for the renderer or add focus blur with composite nodes. Then you have sharp lines in the front and no moire in the back. Those are pretty nasty workarounds and shouldn't be necessary. And depending on what you're using such textures for, (eg. spec/bump maps) even with blurring it can still cause temporal aliasing - flickering. The main problem is that none of blender's textures (other than image maps) are properly filtered/antialiased. For some like clouds, blend, maybe others, it should be possible to do 'analytically' or via fading off higher frequencies etc, for other more complicated ones perhaps oversampling the texture itself could be an option (as opposed to oversampling the entire shading in the render). Regardless, this is a problematic long-standing issue in Blender, that it would be great to see an enthusiastic coder work on - perhaps a good project for someone new looking to get involved. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] armatures, ipos and actions
Hi all, Mike and Joshua, thanks for your answers. Mike Belanger a écrit : Yes the NLA is designed (and very good) at sharing actions. raphael, Here's a file demonstrating the NLA solving your problem. Note that I'm not a huge fan of keying on object level, but it is possible. http://www.pasteall.org/blend/5543 On 2011-03-10, at 7:38 PM, Joshua Leung wrote: Hi, For a moment there I was confused by the terminology you were using. If I understand correctly, you want to have several rigs sharing the same action (pose-bone level animation), but still be able to position the rig objects in different places (object-level animation). There isn't any bug here. By design, a single animation data (1 action + a collection of drivers + a collection of nla-tracks (containing strips referencing actions)) block lives on each ID-block (i.e. Object/Lamp/Material/etc.) Now, PoseBones are data hanging off an Object, just like the Object's transform properties (loc/rot/scale/etc.) Hence, they are affected by the same animation data block. For what you want to accomplish, what you really want to do is to use the NLA system. One strip gets the object-level, another gets the pose-bone level. See http://aligorith.blogspot.com/2010/10/clarifying-animation-workflow-in.html with regards to NLA usage. Hope that helps, Joshua On Fri, Mar 11, 2011 at 3:13 AM, raphael dw...@free.fr wrote: Hi everyone, i was about to make a bug report but i prefer posting here first. (didn't have any answer in supports forum) In blender 2.49, you can have one ipo linked to armature's Object, one action linked to it's data. So, differents armatures can have their own position (+rotate and scale), and sharing the same action. In 2.5, ipos and bones animations are both included in actions, and differents armatures can't share actions and have different movements on the same time. Is it a bug, the result of the new design or something that can be changed in users prefs ? some test files here http://dwarf.free.fr/blender2.5/armatures_249-01.blend http://dwarf.free.fr/blender2.5/armatures_250-01.blend regards raphael ___ 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] Proposal: to remove the TexFace options
Hello there, the code is read, up and running here. I sent it to the tracker because it will make easy for review (I'm going to ask to Benoit to take a look at the BGE changes, but it would be nice if someone could take a quick look at the Blender part as well - Brecht do you think you could take a look at it?). [1] If someone wants to test it I made builds for the three main plataforms [2], [3], [4]. I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Are there bugs? Likely (it's a big patch after all). But I've been chasing them over the week and believe it's all manageable. If you can help testing, please report them in the patch entry. And the one million dollar question is: Can this be incorporated before Blender 2.57 release? if there is no agreement by Sunday I will see if I wake up early to discuss that in the meeting. [1] - Tracker - http://projects.blender.org/tracker/index.php?func=detailaid=26461group_id=9atid=127 [2] - Windows build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1754 [3] - Linux build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1751 [4[ - OSX build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1753 Thanks, Dalai -- www.dalaifelinto.com @dfelinto ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender native compile for headless servers???
Hi Steve, On Wed, Mar 9, 2011 at 6:29 AM, Steve Obbayi st...@sobbayi.com wrote: Hi Brecht, I am planning to implement this so a quick question. Are their any major huddles you came across that are worth mentioning other than what you have stated here? Not that I remember, and probably the issues you run into will be different, given that I didn't use opengl/ghost stubs. Brecht. Hi Brecht, I start working on this come Monday. I will share any unusual occurrences along the way. Steve ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: to remove the TexFace options
Downloading now! How do the changes affect GL view and the texture painting workflow? I have tons of scripts and addons dealing with UV and texture face workarounds, so am curious how this works. On 11/03/11 12:16, Dalai Felinto wrote: Hello there, the code is read, up and running here. I sent it to the tracker because it will make easy for review (I'm going to ask to Benoit to take a look at the BGE changes, but it would be nice if someone could take a quick look at the Blender part as well - Brecht do you think you could take a look at it?). [1] If someone wants to test it I made builds for the three main plataforms [2], [3], [4]. I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Are there bugs? Likely (it's a big patch after all). But I've been chasing them over the week and believe it's all manageable. If you can help testing, please report them in the patch entry. And the one million dollar question is: Can this be incorporated before Blender 2.57 release? if there is no agreement by Sunday I will see if I wake up early to discuss that in the meeting. [1] - Tracker - http://projects.blender.org/tracker/index.php?func=detailaid=26461group_id=9atid=127 [2] - Windows build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1754 [3] - Linux build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1751 [4[ - OSX build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1753 Thanks, Dalai -- www.dalaifelinto.com @dfelinto ___ 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] Blender linux console errors
On Thu, Mar 10, 2011 at 10:48 PM, Campbell Barton ideasma...@gmail.com wrote: I once spent some time trying to track down the allocations valgrind complains about and it seems they are either... * allocations by 3rd party libs - openal/python/x11 for eg, variables that are allocated once and kept * blenders own global C++ variables as mentioned before. * a handful of variables that are not freed on exit correctly like the event, happens with ReportList's sometimes. Each case could be fixed but it means adding extra init/free calls to the game engine for eg, or working out why the last event isn't freed, so its just a fair amount of time spent on tracking down something which isn't really causing anyone to run our of memory. To make valgrind play nice with python you need to build python '--without-pymalloc', for tracking down bugs which are unrelated to python just build without python is easiest. valgrind is really handy but I don't bother with its on exit memory leak messages, mostly our guarded-malloc gives more useful info. Theres a wiki page for more details http://wiki.blender.org/index.php/Dev:Doc/Debugging/Valgrind I recompiled with GUARDEDALLOC turned off and there is no more console output including the GHOST error. Thanks, Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: to remove the TexFace options
Am 11.03.2011 13:16, schrieb Dalai Felinto: Hello there, the code is read, up and running here. ... Are there bugs? Likely (it's a big patch after all). But I've been chasing them over the week and believe it's all manageable. If you can help testing, please report them in the patch entry. How is it working together with GLSL? I feel that probably a even bigger change is on the way which would unify this also. For now it is working well but as soon as I switch to GLSL my Alphas are not there anymore for example. Where is the Collision flag from the Face Textures is handled? I think it can be usefull to have Collision by Face. I think you would also remove Texture Face as option from the Shading in the Property Shelf? Beside this and my doubts about the time when to incorporate this (see below) I think your work is very valuable and simplifies things. And the one million dollar question is: Can this be incorporated before Blender 2.57 release? if there is no agreement by Sunday I will see if I wake up early to discuss that in the meeting. I am still a bit sceptic and feel that it would be fit better in a 2.6 Version, especially as there are bigger changes in the materials proposed for these versions. So my opinion: Wait. And then do a system which serves all cases well: Add material options with all features you can use in rendering, then when you start the Gameengine the materials will be shown as good as the actual graphic card can handle. All automatic. Beside this I would also like to have a lazy mode with more than one texture on a object in GLSL mode. 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 [35457] trunk/blender/intern/ghost/intern: Fix [#26446] Quick extrude (Ctrl+LMB) works only one time
Hi Nathan,
this commit broke building with WinSDK/Nmake/JOM on Win7.
Here's the error message:
[ 80%] Building CXX object
intern/ghost/CMakeFiles/bf_intern_ghost.dir/intern/GHOST_SystemWin32.cpp.obj
GHOST_SystemWin32.cpp
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(473)
: error C2220: warning treated as error - no 'object' file generated
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(473)
: warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in
operation
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(479)
: warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in
operation
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(485)
: warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in
operation
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(491)
: warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in
operation
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(497)
: warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in
operation
W:\ralf\Stuff\b\blender\intern\ghost\intern\GHOST_SystemWin32.cpp(503)
: warning C4805: '!=' : unsafe mix of type 'bool' and type 'int' in
operation
NMAKE : fatal error U1077: 'C:\PROGRA~2\Microsoft Visual Studio
9.0\VC\bin\amd64\cl.exe' : return code '0x2'
The patch at http://www.pasteall.org/19830/diff fixed the issue for me.
2011/3/10 Nathan Letwory nat...@letworyinteractive.com:
Revision: 35457
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35457
Author: jesterking
Date: 2011-03-10 18:56:19 + (Thu, 10 Mar 2011)
Log Message:
---
Fix [#26446] Quick extrude (Ctrl+LMB) works only one time
Reported by Michael R
This was one thing I didn't test when accepting patch [#26364]. It is
important to not
send repeats of modifier keys.
Modified Paths:
--
trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp
trunk/blender/intern/ghost/intern/GHOST_SystemWin32.h
Modified: trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp
===
--- trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp 2011-03-10
18:17:20 UTC (rev 35456)
+++ trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp 2011-03-10
18:56:19 UTC (rev 35457)
@@ -454,8 +454,71 @@
if (ri.header.dwType == RIM_TYPEKEYBOARD)
{
+ GHOST_SystemWin32 *system = (GHOST_SystemWin32
*)getSystem();
+
+ GHOST_ModifierKeys modifiers;
+ system-retrieveModifierKeys(modifiers);
+
*keyDown = !(ri.data.keyboard.Flags RI_KEY_BREAK);
key = this-convertKey(window, ri.data.keyboard.VKey,
ri.data.keyboard.MakeCode, (ri.data.keyboard.Flags(RI_KEY_E1|RI_KEY_E0)));
+
+ // extra handling of modifier keys: don't send
repeats out from GHOST
+ if(key = GHOST_kKeyLeftShift key =
GHOST_kKeyRightAlt)
+ {
+ bool changed = false;
+ GHOST_TModifierKeyMask modifier;
+ switch(key) {
+ case GHOST_kKeyLeftShift:
+ {
+ changed =
(modifiers.get(GHOST_kModifierKeyLeftShift) != *keyDown);
+ modifier =
GHOST_kModifierKeyLeftShift;
+ }
+ break;
+ case GHOST_kKeyRightShift:
+ {
+ changed =
(modifiers.get(GHOST_kModifierKeyRightShift) != *keyDown);
+ modifier =
GHOST_kModifierKeyRightShift;
+ }
+ break;
+ case GHOST_kKeyLeftControl:
+ {
+ changed =
(modifiers.get(GHOST_kModifierKeyLeftControl) != *keyDown);
+ modifier =
GHOST_kModifierKeyLeftControl;
+ }
+ break;
+ case GHOST_kKeyRightControl:
+ {
+ changed =
(modifiers.get(GHOST_kModifierKeyRightControl) != *keyDown);
+
Re: [Bf-committers] Proposal: to remove the TexFace options
Am 11.03.2011 13:16, schrieb Dalai Felinto: I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Just as addition: It breaks all my game engine tutorials for my book, both in look (no alpha, no Add) and in functionality, I think because of the missing collision by face. 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] Code Review
Hi all, I'd like to do an experiment, using a code review tool for blender development, to review changes before they go into trunk. My hope is to improve the quality of commits, with more eyes looking at the code we can prevent bugs, and I find having your code reviewed also generally keeps you on your toes. My intention is not to require the use of this tool, or have it used for every little bugfix, it's just an experiment at this point. Some guidelines: * Only submit code for review if you are a developer with commit rights, or if you found a developer to get your code committed. If the experiment is a success, we can open it up more, but for now I'd like to keep it focused on things that we know are likely to go in. * Anyone can participate in the code review however. * This is not a place to do big interface design discussions or feature requests, stay focused on what is being worked on. * If you reviewed the entire patch, and think the code is good to go in, reply LGTM (looks good to me). To follow code reviews, subscribe to the new bf-codereview mailing list. All messages will be logged there, but comments should be added in the code review tool. http://lists.blender.org/mailman/listinfo/bf-codereview To create a code review, create an issue at http://codereview.appspot.com: * Fill in subject and description. * Base URL should be Blender Trunk (the first one!), Base left empty. * Add bf-coderev...@blender.org to Reviewers. * Attach a diff against current trunk. To comment on a code review, don't reply on the list, but do it in the code review tool. You can click on specific lines of code and add comments inline. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Updated Camera patch
Hola all, I have updated Matt Ebb's patch for adjustable camera sensor sizes. There's also a few changes of my own, so now it is possible to get/set the vertical FOV (mostly important for import/export). Link: http://projects.blender.org/tracker/?func=detailatid=127aid=24427group_id=9 With this patch I believe the Blender Camera is finally where it should have been, having the bare essentials. Besides more advanced features which requires changes to the rendering engine and elsewhere (aperture, shutter, lens distortion, tracking, etc), the only missing feature now is Distance_Affects_FOV. I tried to include this but hit my head on a wall. I don't know how to get the correct distance, and what to do about Scale Units? In any case I hope you will consider including this updated camera. Thanks and have a nice weekend! /Ejnersan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Code Review
Ops! I can't access to any google hosted project/site... Forbidden Your client does not have permission to get URL / from this server. You are accessing this page from a forbidden country. So can I stick to my old way of send my patches? many times I don't have the possibility to choose :( Cheers Raul --- Hi all, I'd like to do an experiment, using a code review tool for blender development, to review changes before they go into trunk. My hope is to improve the quality of commits, with more eyes looking at the code we can prevent bugs, and I find having your code reviewed also generally keeps you on your toes. My intention is not to require the use of this tool, or have it used for every little bugfix, it's just an experiment at this point. Some guidelines: * Only submit code for review if you are a developer with commit rights, or if you found a developer to get your code committed. If the experiment is a success, we can open it up more, but for now I'd like to keep it focused on things that we know are likely to go in. * Anyone can participate in the code review however. * This is not a place to do big interface design discussions or feature requests, stay focused on what is being worked on. * If you reviewed the entire patch, and think the code is good to go in, reply LGTM (looks good to me). To follow code reviews, subscribe to the new bf-codereview mailing list. All messages will be logged there, but comments should be added in the code review tool. http://lists.blender.org/mailman/listinfo/bf-codereview To create a code review, create an issue at http://codereview.appspot.com: * Fill in subject and description. * Base URL should be Blender Trunk (the first one!), Base left empty. * Add bf-coderev...@blender.org to Reviewers. * Attach a diff against current trunk. To comment on a code review, don't reply on the list, but do it in the code review tool. You can click on specific lines of code and add comments inline. Thanks, Brecht. ___ 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] Proposal: to remove the TexFace options
@Michael Williamson: How do the changes affect GL view and the texture painting workflow? It shouldn't affect the texture painting workflow. I haven't test it but the part of the UV struct I'm touching is barely used in Blender itself )other @Carsten Wartmann: How is it working together with GLSL? [Alpha] GLSL handles alpha differently (in 2.49 and trunk). AFAIK for a billboard in Multitexture and Facetexture we set the alpha to 0.0, while in GLSL the alpha has to be 1.0. I find this awful (UI-wise) but this is how Blender has been working since ever (?). I would love to make TextureFace and Multitexture to follow GLSL, it should be easy, a matter of doing a doversion and value=1.0 - value. But since this change has nothing to do with the patch it was left out. Where is the Collision flag from the Face Textures is handled? I think it can be usefull to have Collision by Face. There is a new checkbox by the Physics panel. Turn it off and collision goes away. There is a part in the bullet code that is still checking for TF_COLLISION (old TexFace flag for collision). I haven't touched it yet, but it shouldn't matter. I think you would also remove Texture Face as option from the Shading in the Property Shelf? I'm for GLSL to support Texture Face eventually. Multitexture supports it (it always did). So if we remove it from the Options panel we will loose the functionality of not having to set a specific texture per mesh. It's useful if you have different objects sharing the same material but using different textures. Beside this and my doubts about the time when to incorporate this I think your work is very valuable and simplifies things. It's always good to hear that. Please test with the collision and alpha suggestions above and see it it helps solving part of the problems. Thanks, Dalai 2011/3/11 Carsten Wartmann c...@blenderbuch.de: Am 11.03.2011 13:16, schrieb Dalai Felinto: I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Just as addition: It breaks all my game engine tutorials for my book, both in look (no alpha, no Add) and in functionality, I think because of the missing collision by face. 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
Re: [Bf-committers] Code Review
This is really nice Brecht. The system seems quite innovative. An online svn system, fantastic :) I just sent a patch that was originally sent for blender tracker. Let's see how it works. I had to add it twice because my patch wasn't against the latest latest trunk (it seems that the system can't merge if there is any version mismatch in the files you changed). http://codereview.appspot.com/4289041/ Best regards, Dalai 2011/3/11 ra...@info.upr.edu.cu: Ops! I can't access to any google hosted project/site... Forbidden Your client does not have permission to get URL / from this server. You are accessing this page from a forbidden country. So can I stick to my old way of send my patches? many times I don't have the possibility to choose :( Cheers Raul --- Hi all, I'd like to do an experiment, using a code review tool for blender development, to review changes before they go into trunk. My hope is to improve the quality of commits, with more eyes looking at the code we can prevent bugs, and I find having your code reviewed also generally keeps you on your toes. My intention is not to require the use of this tool, or have it used for every little bugfix, it's just an experiment at this point. Some guidelines: * Only submit code for review if you are a developer with commit rights, or if you found a developer to get your code committed. If the experiment is a success, we can open it up more, but for now I'd like to keep it focused on things that we know are likely to go in. * Anyone can participate in the code review however. * This is not a place to do big interface design discussions or feature requests, stay focused on what is being worked on. * If you reviewed the entire patch, and think the code is good to go in, reply LGTM (looks good to me). To follow code reviews, subscribe to the new bf-codereview mailing list. All messages will be logged there, but comments should be added in the code review tool. http://lists.blender.org/mailman/listinfo/bf-codereview To create a code review, create an issue at http://codereview.appspot.com: * Fill in subject and description. * Base URL should be Blender Trunk (the first one!), Base left empty. * Add bf-coderev...@blender.org to Reviewers. * Attach a diff against current trunk. To comment on a code review, don't reply on the list, but do it in the code review tool. You can click on specific lines of code and add comments inline. Thanks, Brecht. ___ 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] Proposal: to remove the TexFace options
think it can be usefull to have Collision by Face. There is a new checkbox by the Physics panel. Turn it off and collision goes away. It is not clear: is there still an option to turn on/off collision per face? That is a very useful feature we shouldn't drop I think. Thanks, Erwin On 11 March 2011 10:16, Dalai Felinto dfeli...@gmail.com wrote: @Michael Williamson: How do the changes affect GL view and the texture painting workflow? It shouldn't affect the texture painting workflow. I haven't test it but the part of the UV struct I'm touching is barely used in Blender itself )other @Carsten Wartmann: How is it working together with GLSL? [Alpha] GLSL handles alpha differently (in 2.49 and trunk). AFAIK for a billboard in Multitexture and Facetexture we set the alpha to 0.0, while in GLSL the alpha has to be 1.0. I find this awful (UI-wise) but this is how Blender has been working since ever (?). I would love to make TextureFace and Multitexture to follow GLSL, it should be easy, a matter of doing a doversion and value=1.0 - value. But since this change has nothing to do with the patch it was left out. Where is the Collision flag from the Face Textures is handled? I think it can be usefull to have Collision by Face. There is a new checkbox by the Physics panel. Turn it off and collision goes away. There is a part in the bullet code that is still checking for TF_COLLISION (old TexFace flag for collision). I haven't touched it yet, but it shouldn't matter. I think you would also remove Texture Face as option from the Shading in the Property Shelf? I'm for GLSL to support Texture Face eventually. Multitexture supports it (it always did). So if we remove it from the Options panel we will loose the functionality of not having to set a specific texture per mesh. It's useful if you have different objects sharing the same material but using different textures. Beside this and my doubts about the time when to incorporate this I think your work is very valuable and simplifies things. It's always good to hear that. Please test with the collision and alpha suggestions above and see it it helps solving part of the problems. Thanks, Dalai 2011/3/11 Carsten Wartmann c...@blenderbuch.de: Am 11.03.2011 13:16, schrieb Dalai Felinto: I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Just as addition: It breaks all my game engine tutorials for my book, both in look (no alpha, no Add) and in functionality, I think because of the missing collision by face. 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
Re: [Bf-committers] Proposal: to remove the TexFace options
Hi Erwin, as with the rest of functionalities you can't per face but per material. In the tracker there is an image with the UI highlights: http://www.pasteall.org/pic/show.php?id=9863 It's in the header of the Physics tab in the material panel (and it's on by default). Thanks, Dalai 2011/3/11 Erwin Coumans erwin.coum...@gmail.com: think it can be usefull to have Collision by Face. There is a new checkbox by the Physics panel. Turn it off and collision goes away. It is not clear: is there still an option to turn on/off collision per face? That is a very useful feature we shouldn't drop I think. Thanks, Erwin On 11 March 2011 10:16, Dalai Felinto dfeli...@gmail.com wrote: @Michael Williamson: How do the changes affect GL view and the texture painting workflow? It shouldn't affect the texture painting workflow. I haven't test it but the part of the UV struct I'm touching is barely used in Blender itself )other @Carsten Wartmann: How is it working together with GLSL? [Alpha] GLSL handles alpha differently (in 2.49 and trunk). AFAIK for a billboard in Multitexture and Facetexture we set the alpha to 0.0, while in GLSL the alpha has to be 1.0. I find this awful (UI-wise) but this is how Blender has been working since ever (?). I would love to make TextureFace and Multitexture to follow GLSL, it should be easy, a matter of doing a doversion and value=1.0 - value. But since this change has nothing to do with the patch it was left out. Where is the Collision flag from the Face Textures is handled? I think it can be usefull to have Collision by Face. There is a new checkbox by the Physics panel. Turn it off and collision goes away. There is a part in the bullet code that is still checking for TF_COLLISION (old TexFace flag for collision). I haven't touched it yet, but it shouldn't matter. I think you would also remove Texture Face as option from the Shading in the Property Shelf? I'm for GLSL to support Texture Face eventually. Multitexture supports it (it always did). So if we remove it from the Options panel we will loose the functionality of not having to set a specific texture per mesh. It's useful if you have different objects sharing the same material but using different textures. Beside this and my doubts about the time when to incorporate this I think your work is very valuable and simplifies things. It's always good to hear that. Please test with the collision and alpha suggestions above and see it it helps solving part of the problems. Thanks, Dalai 2011/3/11 Carsten Wartmann c...@blenderbuch.de: Am 11.03.2011 13:16, schrieb Dalai Felinto: I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Just as addition: It breaks all my game engine tutorials for my book, both in look (no alpha, no Add) and in functionality, I think because of the missing collision by face. 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
Re: [Bf-committers] Code Review
On Fri, Mar 11, 2011 at 8:55 AM, ra...@info.upr.edu.cu wrote: Ops! I can't access to any google hosted project/site... Unfortunately that probably has to do on the US embargo on Cuba. So can I stick to my old way of send my patches? many times I don't have the possibility to choose :( Obviously you will have to, although others can likely upload the patch for you if you like. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Code Review
Hi Raul, On Fri, Mar 11, 2011 at 8:59 PM, Tom M letter...@gmail.com wrote: So can I stick to my old way of send my patches? many times I don't have the possibility to choose :( Obviously you will have to, although others can likely upload the patch for you if you like. It's not the intention to make this the required way to submit patches just yet, it's only an experiment. So you should be fine sending patches as usual. I'll try to find out if this is a bug or if we can solve it somehow, in any case this tool should not get in the way of submitting patches. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] how add a new modifier in the dropdownbox?
i want add my own modifier if is possible adding from the source code or in the python API adding textboxes and labels how do it? ___ 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 [35479] trunk/blender: Fix [#25659] crash when unwrapping specific mesh
should this change be made for mingw too? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Updated Camera patch
On Fri, Mar 11, 2011 at 8:19 AM, Ejner Fergo ejner...@gmail.com wrote: In any case I hope you will consider including this updated camera. Huge +1 here. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
