[Bf-committers] GPL v2/v3 problem.
Alex Fraser alerted me to fact blender has some GPL3 code (which implies blender IS GPLv3 AFAIK). This is a bit of a problem because 'elbeem' is version 2 only. GPL2 ONLY, no 'version 2 or later' clause 1 ./intern/elbeem/extern/elbeem.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 2 ./intern/elbeem/intern/controlparticles.cpp:4:// All code distributed as part of El'Beem is covered by the version 2 of the 3 ./intern/elbeem/intern/controlparticles.h:4:// All code distributed as part of El'Beem is covered by the version 2 of the 4 ./intern/elbeem/intern/elbeem.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 5 ./intern/elbeem/intern/elbeem_control.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 6 ./intern/elbeem/intern/elbeem_control.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 7 ./intern/elbeem/intern/mvmcoords.cpp:4:// All code distributed as part of El'Beem is covered by the version 2 of the 8 ./intern/elbeem/intern/mvmcoords.h:4:// All code distributed as part of El'Beem is covered by the version 2 of the 9 ./intern/elbeem/intern/solver_class.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 10 ./intern/elbeem/intern/solver_control.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 11 ./intern/elbeem/intern/solver_control.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 12 ./intern/elbeem/intern/solver_interface.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 13 ./intern/elbeem/intern/solver_interface.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 14 ./intern/elbeem/intern/solver_relax.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the AFAIK all by 'Nils Thuerey' GPL3 or later python scripts: 1 ./release/scripts/addons/io_export_directx_x.py:5:# the Free Software Foundation, either version 3 of the License, or 2 ./release/scripts/addons/io_export_unreal_psk_psa.py:5:# the Free Software Foundation, either version 3 of the License, or 3 ./release/scripts/modules/console/__init__.py:5:# the Free Software Foundation, either version 3 of the License, or 4 ./release/scripts/modules/console/complete_calltip.py:5:# the Free Software Foundation, either version 3 of the License, or 5 ./release/scripts/modules/console/complete_import.py:5:# the Free Software Foundation, either version 3 of the License, or 6 ./release/scripts/modules/console/complete_namespace.py:5:# the Free Software Foundation, either version 3 of the License, or 7 ./release/scripts/modules/console/intellisense.py:5:# the Free Software Foundation, either version 3 of the License, or console code by 'Stani Michiels', addons by Chris Foster (Kira Vakaan) and 'Darknet/Optimus_P-Fat/Active_Trash/Sinsoft' - from addon string. GPL3 or later C/C++ code. 1 ./extern/Eigen2/Eigen/src/Array/BooleanRedux.h:9:// version 3 of the License, or (at your option) any later version. 2 ./extern/Eigen2/Eigen/src/Array/CwiseOperators.h:9:// version 3 of the License, or (at your option) any later version. 3 ./extern/Eigen2/Eigen/src/Array/Functors.h:9:// version 3 of the License, or (at your option) any later version. 4 ./extern/Eigen2/Eigen/src/Array/Norms.h:9:// version 3 of the License, or (at your option) any later version. 5 ./extern/Eigen2/Eigen/src/Array/PartialRedux.h:10:// version 3 of the License, or (at your option) any later version. 6 ./extern/Eigen2/Eigen/src/Array/Random.h:9:// version 3 of the License, or (at your option) any later version. 7 ./extern/Eigen2/Eigen/src/Array/Select.h:9:// version 3 of the License, or (at your option) any later version. 8 ./extern/Eigen2/Eigen/src/Cholesky/CholeskyInstantiations.cpp:9:// version 3 of the License, or (at your option) any later version. 9 ./extern/Eigen2/Eigen/src/Cholesky/LDLT.h:9:// version 3 of the License, or (at your option) any later version. 10 ./extern/Eigen2/Eigen/src/Cholesky/LLT.h:9:// version 3 of the License, or (at your option) any later version. 11 ./extern/Eigen2/Eigen/src/Core/Assign.h:11:// version 3 of the License, or (at your option) any later version. 12 ./extern/Eigen2/Eigen/src/Core/Block.h:10:// version 3 of the License, or (at your option) any later version. 13 ./extern/Eigen2/Eigen/src/Core/CacheFriendlyProduct.h:9:// version 3 of the License, or (at your option) any later version. 14 ./extern/Eigen2/Eigen/src/Core/Coeffs.h:9:// version 3 of the License, or (at your option) any later version. 15 ./extern/Eigen2/Eigen/src/Core/CommaInitializer.h:10:// version 3 of the License, or (at your option) any later version. 16
[Bf-committers] Autorefresh Renderlayers
In the hopes of bringing the compositor closer to an integrated 3D environment and tackle the interactivity problem I want to propose this feature. RenderLayer Auto Refresh (optional per render layer input node): https://docs.google.com/drawings/edit?id=1N8MgmeRdjxRv7AcjfQZ1Dexcy5K9axHMTgz1blTYdr4hl=enauthkey=CITBi5AB Now I know it sounds scary but I believe we can leave to to the user the task of setting it up in a way that is fast to render (use a simplified scene/renderlayer with heavy render features turned off etc) The above diagram is of course just one example of usage, but I don't think this will limit to 2D masking. It could be tracking a 3D mask or a complex object (modifiers etc) with ob ID or who knows. hope to hear comments from other compo people cheers Daniel Salazar www.3developer.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [#25436] Crash when using high resolution smoke sim
Hi, I tried to reproduce the bug and a similar one occured. I'm using Ubuntu Linux 10.10 and I have ATI graphics card. I ran the file attached with the bug report in today's svn blender version by using CLI: ~/blender-build/cmake/bin/blender --redner-anim filename.blend UI opened and I used alt+a to play the animation without any modifications to the file. It didn't crash, and baking was not crashing while in blender, but when I exited blender it complained about corrupted double linked list It might be a problem with graphics settings of the Ubuntu desktop because X server is complaining about: AtiCallFGLComposite in the backtrace. In situations like this, as for what I can remember usually removing compiz package and installing original ATI graphics drivers would solve most of the problems. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GPL v2/v3 problem.
Hi, Eugen: http://eigen.tuxfamily.org/index.php?title=Main_Page#License http://eigen.tuxfamily.org/index.php?title=Main_Page#Licenseis OK for GPL2 Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPL v2/v3 problem.
Hi, For as long as possible, I'd prefer to stick to 2 or later. For all code committed to Blender that has been the default anyway, also when not explicitly mentioned. - the gpl3 py scripts then need update - elbeem wouldn't be an issue I'm sure (will ask Nils Daniel Genscher) - eigen shouldn't be an issue either. (either they have, or we downgrade to older eigen?) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Feb, 2011, at 13:01, Campbell Barton wrote: Alex Fraser alerted me to fact blender has some GPL3 code (which implies blender IS GPLv3 AFAIK). This is a bit of a problem because 'elbeem' is version 2 only. GPL2 ONLY, no 'version 2 or later' clause 1 ./intern/elbeem/extern/elbeem.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 2 ./intern/elbeem/intern/controlparticles.cpp:4:// All code distributed as part of El'Beem is covered by the version 2 of the 3 ./intern/elbeem/intern/controlparticles.h:4:// All code distributed as part of El'Beem is covered by the version 2 of the 4 ./intern/elbeem/intern/elbeem.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 5 ./intern/elbeem/intern/elbeem_control.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 6 ./intern/elbeem/intern/elbeem_control.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 7 ./intern/elbeem/intern/mvmcoords.cpp:4:// All code distributed as part of El'Beem is covered by the version 2 of the 8 ./intern/elbeem/intern/mvmcoords.h:4:// All code distributed as part of El'Beem is covered by the version 2 of the 9 ./intern/elbeem/intern/solver_class.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 10./intern/elbeem/intern/solver_control.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 11./intern/elbeem/intern/solver_control.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 12./intern/elbeem/intern/solver_interface.cpp:4: * All code distributed as part of El'Beem is covered by the version 2 of the 13./intern/elbeem/intern/solver_interface.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the 14./intern/elbeem/intern/solver_relax.h:4: * All code distributed as part of El'Beem is covered by the version 2 of the AFAIK all by 'Nils Thuerey' GPL3 or later python scripts: 1 ./release/scripts/addons/io_export_directx_x.py:5:# the Free Software Foundation, either version 3 of the License, or 2 ./release/scripts/addons/io_export_unreal_psk_psa.py:5:# the Free Software Foundation, either version 3 of the License, or 3 ./release/scripts/modules/console/__init__.py:5:# the Free Software Foundation, either version 3 of the License, or 4 ./release/scripts/modules/console/complete_calltip.py:5:# the Free Software Foundation, either version 3 of the License, or 5 ./release/scripts/modules/console/complete_import.py:5:# the Free Software Foundation, either version 3 of the License, or 6 ./release/scripts/modules/console/complete_namespace.py:5:# the Free Software Foundation, either version 3 of the License, or 7 ./release/scripts/modules/console/intellisense.py:5:# the Free Software Foundation, either version 3 of the License, or console code by 'Stani Michiels', addons by Chris Foster (Kira Vakaan) and 'Darknet/Optimus_P-Fat/Active_Trash/Sinsoft' - from addon string. GPL3 or later C/C++ code. 1 ./extern/Eigen2/Eigen/src/Array/BooleanRedux.h:9:// version 3 of the License, or (at your option) any later version. 2 ./extern/Eigen2/Eigen/src/Array/CwiseOperators.h:9:// version 3 of the License, or (at your option) any later version. 3 ./extern/Eigen2/Eigen/src/Array/Functors.h:9:// version 3 of the License, or (at your option) any later version. 4 ./extern/Eigen2/Eigen/src/Array/Norms.h:9:// version 3 of the License, or (at your option) any later version. 5 ./extern/Eigen2/Eigen/src/Array/PartialRedux.h:10:// version 3 of the License, or (at your option) any later version. 6 ./extern/Eigen2/Eigen/src/Array/Random.h:9:// version 3 of the License, or (at your option) any later version. 7 ./extern/Eigen2/Eigen/src/Array/Select.h:9:// version 3 of the License, or (at your option) any later version. 8 ./extern/Eigen2/Eigen/src/Cholesky/CholeskyInstantiations.cpp:9:// version 3 of the License, or (at your option) any later version. 9 ./extern/Eigen2/Eigen/src/Cholesky/LDLT.h:9:// version 3 of the License, or (at your option) any later version. 10./extern/Eigen2/Eigen/src/Cholesky/LLT.h:9:// version 3 of the License, or (at your
Re: [Bf-committers] GPL v2/v3 problem.
Yes, there also seems to be some confusion with GPL and LGPL. Even if Eigen was not additionally lisenced as GPL2+, the main license is LGPL3 and not GPL3 so a GPL2 prog (or even a proprietary program) can use it without problem. 2011/2/6 Sergey Kurdakov sergey.fo...@gmail.com Hi, Eugen: http://eigen.tuxfamily.org/index.php?title=Main_Page#License http://eigen.tuxfamily.org/index.php?title=Main_Page#Licenseis OK for GPL2 Regards Sergey ___ 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] openexr msvc10
I successfully build trunk with cmake and msvc10 by disabling openexr.
The problem with openexr is that the libs in /lib/windows/openexr/lib_vs2010
are not correctly build. They are linked against the static runtime library
of msvc which gives the linker errors (LNK2005).
With attached patch and updated openexr libraries blender should also build
completely with msvc10.
Peter
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 34671)
+++ CMakeLists.txt (working copy)
@@ -546,18 +546,25 @@
set(FFMPEG_LIBPATH ${FFMPEG}/lib)
endif()
- if(WITH_IMAGE_OPENEXR)
- set(OPENEXR ${LIBDIR}/openexr)
- set(OPENEXR_INC ${OPENEXR}/include ${OPENEXR}/include/IlmImf ${OPENEXR}/include/Iex ${OPENEXR}/include/Imath)
- set(OPENEXR_LIB Iex Half IlmImf Imath IlmThread)
+ if(WITH_IMAGE_OPENEXR)
if(MSVC80)
-set(OPENEXR_LIBPATH ${OPENEXR}/lib_vs2005)
+set(MSVC_LIB _vs2005)
+set(MSVC_INC)
+ elseif(MSVC90)
+set(MSVC_LIB _vs2008)
+set(MSVC_INC)
+ elseif(MSVC10)
+set(MSVC_LIB _vs2010)
+set(MSVC_INC _vs2010)
else()
-set(OPENEXR_LIBPATH ${OPENEXR}/lib_msvc)
+set(MSVC_LIB msvc)
+set(MSVC_INC)
endif()
- if(MSVC90)
-set(OPENEXR_LIBPATH ${OPENEXR}/lib_vs2008)
- endif()
+ set(OPENEXR ${LIBDIR}/openexr)
+ set(OPENEXR_LIB Iex Half IlmImf Imath IlmThread)
+ set(OPENEXR_LIBPATH ${OPENEXR}/lib${MSVC_LIB})
+ set(OPENEXR_INCUDE ${OPENEXR}/include${MSVC_INC})
+ set(OPENEXR_INC ${OPENEXR_INCUDE}/ ${OPENEXR_INCUDE}/IlmImf ${OPENEXR_INCUDE}/Iex ${OPENEXR_INCUDE}/Imath)
endif()
if(WITH_IMAGE_TIFF)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer irc meeting minutes 6 feb 2011
Hi all, Here's a summary of today's meeting: 0) General notes - Terry Wallwork added Blender Gamekit2 now entirely in wiki: http://wiki.blender.org/index.php/Doc:2.4/Books/GameKit_2 - the server with svn and FusionForge (trackers) is having hardware troubles. It's being monitored full time, and if problems persist it will be moved to new system. - Luca Bonavita is working on the wiki migration to a dedicated server, new install and css and skin updates together with Francesco Siddi. Expectation is that it goes live in a week. 1) Blender 2.5x proceedings - Sergey Sharybin notices that usage of symmetric brush and crazy space sculpting (on deformed meshes) still has issues. He'll work on it. - The Python script registry discussion is still unresolved. - We have a couple of GPL conflicts in our code base (GPL 2, 2 or later, and 3). Ton will contact the C code authors, Luca checks the the addon scripts and fixes template: https://svn.blender.org/svnroot/bf-extensions/contrib/dev-tools/gpl.py 2) Other projects, branches - No branches news! - A long discussion went on about fundraiser models, based on doubts expressed that money is given out personally to developers, without any guarantee it will end up with something. Ton will consult other OS foundations if there's experience and policies for this. For as now, BF prefers to have community driven bounty systems organized independently, and involve volunteering or paid developers on equal basis. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] SOC ideas
Hi All, I noticed that many previous SOC ideas were great and brought a lot to Blender, it could be a little bit selfish, but still, I would like to share few ideas for possible SOC applications. idea 1. triangle mesh - quads - nurbs workflow see docs and code http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.6839rep=rep1type=pdf http://www.netlib.no/netlib/a/pcp2nurb.tar.gz http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.1240rep=rep1type=pdf ( see more links here http://www.blender.org/forum/viewtopic.php?t=18026 ) adaptive quads are already here in https://svn.blender.org/svnroot/bf-blender/branches/soc-2010-rohith291991 based on proposal http://wiki.blender.org/index.php/User:Rohith291991/Gsoc2010/Proposal so workflow at least partially implemented ( to some degree subsurfs also already exists ). So all this might be enhanced in Blender to make direct workflow mesh-nurbs-mesh possible. and that is great as nurbs could allow drilling and other fancy features ... idea 2 while kinect is a new toy - it can greatly enhance motion capture experience. available opensource drivers allow capture of rough skeleton https://github.com/OpenNI/OpenNI/tree/master/Samples/NiUserTracker (see demo at youtube http://www.youtube.com/watch?v=vI7iLmLDdoA ), but does not allow detailed motion capture, now what comes to mind in respect to Blender? There is an approach to fit mesh to video (other works are inside pdf ): http://openmesh.org/uploads/media/Hornung_TR10.pdf there is already makehuman with tools to generate desired skeletons and also makehuman rig ( and autorig too ), so coupling ready skeleton with fitting depth info to skeleton mesh - it is possible to accurately capture human pose with kinect. this approach, possibly, might make development of human motions with Blender to be exeptionally popular. So definetely should be tried - as almost all components are here for such a great task. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer irc meeting minutes 6 feb 2011
Hi, on GameKit2: - Terry Wallwork added Blender Gamekit2 now entirely in wiki: http://wiki.blender.org/index.php/Doc:2.4/Books/GameKit_2 Those are great news. I have a question though. Is it valid to do some errata or the idea is to keep it a straight copy of the book? E.g. the link for the FTBlender app is no longer valid. That means users are pretty much on their own on figuring out how to create a bitmap font for BGE [1]. Maybe the real problem is that we have no official Blender.org page hosting FTBlender, but still if we had/create one would be good to update the link? E.g.2.: Shared and ObColor options of TexFace were already obsolete when the book was released [2]. AFAIK they don't affect the render in any way. So I'm not talking about updating the book to Blender 2.5x, but instead to make amends to its original content to keep it a valid reference for 2.49. Those are examples I knew by heart, but there are probably others. It would be also interesting to see part of it adapted to the official wiki (BGE Logic Bricks page has more than half of the items missing/not written). But I guess nothing never stopped anyone for doing that :) Anyhoo just some kind remark on the current status of the BGE official documentation. Sincerely thanks a lot for the work here. I'm pretty sure it will help a lot of people. I love the GameKit2 and will certainly spread this link a lot. -- Dalai [1] - http://wiki.blender.org/index.php/Doc:2.4/Books/GameKit_2/13.Reference#Bitmap_Text [2] - http://wiki.blender.org/index.php/Doc:2.4/Books/GameKit_2/13.Reference#UV_Texturing 2011/2/6 Ton Roosendaal t...@blender.org Hi all, Here's a summary of today's meeting: 0) General notes - Terry Wallwork added Blender Gamekit2 now entirely in wiki: http://wiki.blender.org/index.php/Doc:2.4/Books/GameKit_2 - the server with svn and FusionForge (trackers) is having hardware troubles. It's being monitored full time, and if problems persist it will be moved to new system. - Luca Bonavita is working on the wiki migration to a dedicated server, new install and css and skin updates together with Francesco Siddi. Expectation is that it goes live in a week. 1) Blender 2.5x proceedings - Sergey Sharybin notices that usage of symmetric brush and crazy space sculpting (on deformed meshes) still has issues. He'll work on it. - The Python script registry discussion is still unresolved. - We have a couple of GPL conflicts in our code base (GPL 2, 2 or later, and 3). Ton will contact the C code authors, Luca checks the the addon scripts and fixes template: https://svn.blender.org/svnroot/bf-extensions/contrib/dev-tools/gpl.py 2) Other projects, branches - No branches news! - A long discussion went on about fundraiser models, based on doubts expressed that money is given out personally to developers, without any guarantee it will end up with something. Ton will consult other OS foundations if there's experience and policies for this. For as now, BF prefers to have community driven bounty systems organized independently, and involve volunteering or paid developers on equal basis. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] remove MVert.mat_nr
From what I can tell MVert.mat_nr isn't used anywhere, removing as well as a padding variable saves 4 bytes per vertex. Heres the patch. http://projects.blender.org/tracker/index.php?func=detailaid=25961group_id=9atid=127 Anyone know why this would still be useful to keep? -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] remove MVert.mat_nr
If it's not used anywhere, not even in do_versions and not exposed through any api, it's pretty safe to drop I would think. Martin --- On Sun, 2/6/11, Campbell Barton ideasma...@gmail.com wrote: From: Campbell Barton ideasma...@gmail.com Subject: [Bf-committers] remove MVert.mat_nr To: bf-blender developers bf-committers@blender.org Received: Sunday, February 6, 2011, 8:55 PM From what I can tell MVert.mat_nr isn't used anywhere, removing as well as a padding variable saves 4 bytes per vertex. Heres the patch. http://projects.blender.org/tracker/index.php?func=detailaid=25961group_id=9atid=127 Anyone know why this would still be useful to keep? -- - Campbell ___ 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] Calling operators when drawing a panel
Hi Campbell, as I'd like to hide unnecessary properties and avoid any user interaction, those workarounds don't fit in my desired workflow. However, there may be an intermediate solution, propably easier and safer to implement than callbacks: if we have an extra function that we could override in our subpanel's subclass and that is called each time before switching to the 'draw' context, it would probably do the job in an elegant way. Unless you choose a name already used by an addon, it would not affect at all existing addons. Such a function could return a flag indicating that it may have changed properties from another subpanel, so the process could be restarted. A counter of function calls can prevent calling again the function that triggered such an event so we don't fall into an infinite loop for a single draw sequence. Is it something realistic? Cheers, Lionel Le 06/02/2011 08:35, Campbell Barton a écrit : Hi Lionel, we had this discussion a while ago. for my rationale on why writes are disabled on draw see: http://markmail.org/message/6sg2clhu3ouap2oc I was aware this change might not be practicle in some use cases when making it, so one line comment can enable write access again if this is not workable but Im still not convinced that this should be changed back. You were able to work around it by calling an operator but this still has the same problems as changing the value directly, and if calling operators is to be allowed in a draw function we can better just remove the limitation altogether (operators may register themselves or have an undo push which would be annoying). In your case I'd suggest to define your own panels which alert the user when unsupported settings are selected. (set the red-alert on the value or add a text label). You could also have an operator which enforces octane compatible settings accessed from a button in the render panel. This is not ideal but even if you enforce the settings within the draw function there is nothing stopping someone from loading a blend file and pressing render immediately, so relying on the panel to be drawn on each material is weak too. You have a valid point that we need python integration: IMHO scripts should be able to handle notifiers and ability to define update functions for python defined properties. Python defined update functions I can do but handling notifiers should be discussed with Ton first since it may relate to python handling events which is a bigger project, will ask about it before the meeting tonight. - Campbell On Sat, Feb 5, 2011 at 5:03 PM, Lionel Zamouth - BElio...@zamouth.be wrote: Hi, if you've no alternate method ready, then I kindly suggest you let us do our dirty workarounds in the meantime :-) Cheers, Lionel Le 05/02/2011 15:23, Ton Roosendaal a écrit : Hi, We've had several people who work on render exporters already complain :) I think the issue is mostly to get a decent method to send notifiers (UI updates) and data-updates (depsgraph) in place, as soon as possible. I'm quite sure this change by Campbell was done to prevent crashing and bugreports; but I'm curious to know what his idea is for for a timely solution? -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 5 Feb, 2011, at 14:25, Lionel Zamouth - BE wrote: Hi, I'm writing here following a chat I had with Campbell about recent changes that made impossible to call operators from the 'draw' section of custom panels. He suggested I submit here my problems with this behaviour. This technique is used since a previous change where directly writing into properties has been forbidden. I understand that bad coding could lead to some deadlocks or infinite loops but having the ability for a script to react to property changes is quite important and not achievable otherwise due to the lack of callbacks (so far I know). Here's the situation I'm facing: I've written an unofficial (both from Blender and Refractive Software point of view) addon to allow smooth export of blender scene/anim to the unbiased render Octane. From the user perspective it consists of 3 custom panels, replacing the default 'render', 'material' and 'texture' ones. I'm proud to say it has became quite popular and allows a nice workflow to happen. The need for tracking properties is due to my wish to prevent the user accessing or modifying values that can't be taken in account by Octane. For instance the custom texture panel forces the type to 'Image', coordinates to 'UV' and the Projection to 'Flat', as these are the only values that can work with Octane (and are hidden by the custom panel). Another example is the main 'render' panel automatically resetting the x and y aspect ratio to 1 as Octane only renders
Re: [Bf-committers] Calling operators when drawing a panel
On Sun, Feb 6, 2011 at 9:54 PM, Lionel Zamouth - BE lio...@zamouth.be wrote: Hi Campbell, as I'd like to hide unnecessary properties and avoid any user interaction, those workarounds don't fit in my desired workflow. if some_prop: draw code for sometimes hidden properties That doesn't work? Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
Le 07/02/2011 06:02, Dan Eicher a écrit : On Sun, Feb 6, 2011 at 9:54 PM, Lionel Zamouth - BElio...@zamouth.be wrote: Hi Campbell, as I'd like to hide unnecessary properties and avoid any user interaction, those workarounds don't fit in my desired workflow. if some_prop: draw code for sometimes hidden properties That doesn't work? Dan ___ If I hide a property that has a non suitable value, then the user can't correct it (and I can't rely on the user for setting up the good value). I still can display those properties only when I'm unhappy with their values but I've no guarantee the user will make the appropriate change. In addition, stuff like aspect_x/aspect_y must be fixed realtime so the camera view in blender always match the render in Octane. Lionel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
