[Bf-committers] Drivers Delayed (Dependency Issue)
I made some tests with the drivers and found out that they are delayed. Actually they get evaluated first. Before the objects they are depending on are getting updated. Even if there is no cyclic dependency they will be first, getting the input of the previous frame, making them lag one frame behind the changes. I posted a bugreport yesterday, but the tracker seams to be down currently. Since i think, that this is a serious issue, i posted it also on this mailing list. I uploaded a very simple example to http://www.pasteall.org/blend/5309 It contains a tiny armature consisting of one parent bone base, followed by a chain of the bones consisting of rot1 and rot2. rot2 is animated and will be used as the input for bone driven, that is a child of base. Last steps ensures that rot1/rot2 are not depending on driven. driven has a single driver that updates the location of the bone, depending on the rotational difference between rot1 and rot2. Ideally rot2 would be changed by the animation first, then driven would evaluated. But instead the driver is evaluated first, ignoring the dependency. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Drivers Delayed (Dependency Issue)
Incorrect analysis... ... and it's not really a bug by our tracker definitions either! What is really happening is this: - Animation is ALWAYS executed first (this is done per frame change, not per update). This is before any data (namely objects) get evaluated. For the bones here, the values get written to the pchan-loc/eul/quat/size/etc. vars at this point. - Before updates occur (including frame change), the depsgraph only tags objects with their object and/or object data needing updates. - When updates occur, objects are evaluated by these block tags. In this case, it means that the pose matrices (pchan-pose_mat), which give the final transforms of bones (which you see in the viewport), are calculated for all bones that an object has (in a single pass/step) when the object has an object data tag - Drivers for bones (strictly speaking, for PoseChannels, also known via the PyAPI as PoseBones) and also for animation data are rooted at Object-level. That is why you'll find the actions for posebone animation attached to the Object-level AnimData block, as the Pose data which contains the collection of PoseBones is attached to the Object NOT Armature datablock. - The practical implication for this story here, is that Object-level data (including drivers) is evaluated before Object-data gets evaluated (i.e. the Drivers will be run BEFORE any of the PoseBones get evaluated) - Rotational difference uses the pose matrices of the bones it depends on (i.e. pchan-pose_mat) - Hence, the phenomenon you see is all caused by the drivers reading the last values they could find in the pchan-pose_mat's of the bones it uses as input. Since the drivers are run before the pchan's will get updated by being evaluated using newly flushed animation values (and thus updating their pose_mat's), you will get a lagging phenomenon. On Sun, Feb 20, 2011 at 9:39 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I made some tests with the drivers and found out that they are delayed. Actually they get evaluated first. Before the objects they are depending on are getting updated. Even if there is no cyclic dependency they will be first, getting the input of the previous frame, making them lag one frame behind the changes. I posted a bugreport yesterday, but the tracker seams to be down currently. Since i think, that this is a serious issue, i posted it also on this mailing list. I uploaded a very simple example to http://www.pasteall.org/blend/5309 It contains a tiny armature consisting of one parent bone base, followed by a chain of the bones consisting of rot1 and rot2. rot2 is animated and will be used as the input for bone driven, that is a child of base. Last steps ensures that rot1/rot2 are not depending on driven. driven has a single driver that updates the location of the bone, depending on the rotational difference between rot1 and rot2. Ideally rot2 would be changed by the animation first, then driven would evaluated. But instead the driver is evaluated first, ignoring the dependency. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Drivers Delayed (Dependency Issue)
Without trying to insult anyone: Please tell me a solution. How could i drive a bone depending on the animation of another bone without 1 frame lag? It seams to be impossible and makes drivers for bone-properties useless to me. (pointless feature) What you describe is horrible. Why do we have dependencies for bones if they are not accounted for? Any combination without circular dependencies should be allowed to be evaluated in one frame without lag. - Animation first is fine - Drivers on object level are really ugly, they should be always evaluated last or in dependency order. Why not update by dependency only (child/parent, driver/source, ...)? Am 20.02.2011 10:29, schrieb Joshua Leung: Incorrect analysis... ... and it's not really a bug by our tracker definitions either! What is really happening is this: - Animation is ALWAYS executed first (this is done per frame change, not per update). This is before any data (namely objects) get evaluated. For the bones here, the values get written to the pchan-loc/eul/quat/size/etc. vars at this point. - Before updates occur (including frame change), the depsgraph only tags objects with their object and/or object data needing updates. - When updates occur, objects are evaluated by these block tags. In this case, it means that the pose matrices (pchan-pose_mat), which give the final transforms of bones (which you see in the viewport), are calculated for all bones that an object has (in a single pass/step) when the object has an object data tag - Drivers for bones (strictly speaking, for PoseChannels, also known via the PyAPI as PoseBones) and also for animation data are rooted at Object-level. That is why you'll find the actions for posebone animation attached to the Object-level AnimData block, as the Pose data which contains the collection of PoseBones is attached to the Object NOT Armature datablock. - The practical implication for this story here, is that Object-level data (including drivers) is evaluated before Object-data gets evaluated (i.e. the Drivers will be run BEFORE any of the PoseBones get evaluated) - Rotational difference uses the pose matrices of the bones it depends on (i.e. pchan-pose_mat) - Hence, the phenomenon you see is all caused by the drivers reading the last values they could find in the pchan-pose_mat's of the bones it uses as input. Since the drivers are run before the pchan's will get updated by being evaluated using newly flushed animation values (and thus updating their pose_mat's), you will get a lagging phenomenon. On Sun, Feb 20, 2011 at 9:39 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I made some tests with the drivers and found out that they are delayed. Actually they get evaluated first. Before the objects they are depending on are getting updated. Even if there is no cyclic dependency they will be first, getting the input of the previous frame, making them lag one frame behind the changes. I posted a bugreport yesterday, but the tracker seams to be down currently. Since i think, that this is a serious issue, i posted it also on this mailing list. I uploaded a very simple example to http://www.pasteall.org/blend/5309 It contains a tiny armature consisting of one parent bone base, followed by a chain of the bones consisting of rot1 and rot2. rot2 is animated and will be used as the input for bone driven, that is a child of base. Last steps ensures that rot1/rot2 are not depending on driven. driven has a single driver that updates the location of the bone, depending on the rotational difference between rot1 and rot2. Ideally rot2 would be changed by the animation first, then driven would evaluated. But instead the driver is evaluated first, ignoring the dependency. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
Am 20.02.2011 06:47, schrieb Dalai Felinto: Any final word on whether this will be reverted or not? Seems not. Silence in the woods as we say in Germany ;-) If the commit is here to stay I think for BGE we will need some changes. What are theese? 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
Am 20.02.2011 06:47, schrieb Dalai Felinto: Any final word on whether this will be reverted or not? I don't think so. ;-) I guess it will stay in trunk. If the commit is here to stay I think for BGE we will need some changes. -- Dalai # -- Re: New Render Pipeline Panel # ___ 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
On 20.02.2011 04:24, Campbell Barton wrote: Whats supported isn't set in stone, its more a case of which configurations are tested known to work. OK, thanks. And what is mostly used for the Windows releases? this works for me. - windows xp - mingw-gcc4.5.2, (from mingw's main site) - cmake 2.8 (build type set to Release or RelWithDebInfo) - blender (tested r34959) I had a little bit outdated checkout with 4.4, W7-64Bit, and problems with release and debug. A crash on startup may be a real bug rather then lack of support, you could run with gdb and see why its crashing. If you are unable to figure out how to fix you could file a bug and include a backtace. I assume not really a error in blender code, it's the mixture of pre-compiled binaries, compiler used for blender, OS, and runtime libraries. Best is to build everyting with the same compiler. Another way to help find the cause of the crash is to disable all WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR ... etc. If this works you could try again with usable settings (so you get an interface), all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL. I already had the idea to try it without python ;) After that its trial and error to see which library causes the crash, the offending lib could be disabled by default with mingw until its fixed properly. One other thing, you were getting the error 'PyModule_Create2' interestingly I got this error too on Linux when trying to load a library built with a debug python but finding a release library. I could link against the lib/windows version with attached patch. On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmelsyntheti...@gmx.net wrote: Tested it with cmake too. It links after a small fix, but crashes immediately after starting. Seems mingw isn't supported. Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Index: python/lib/python31_d.def === --- python/lib/python31_d.def (revision 34883) +++ python/lib/python31_d.def (working copy) @@ -56,6 +56,7 @@ PyEval_ReleaseThread PyExc_AttributeError PyExc_ImportError +PyExc_IOError PyExc_IndexError PyExc_KeyError PyExc_MemoryError Index: python/lib/python_mw_update.bat === --- python/lib/python_mw_update.bat (revision 34883) +++ python/lib/python_mw_update.bat (working copy) @@ -1,5 +1,5 @@ -cd X:\b\lib\windows\python\lib -C:\MinGW\mingw32\bin\dlltool.exe --dllname python31_d.dll --input-def python31_d.def --output-lib python31mw_d.lib -C:\MinGW\mingw32\bin\dlltool.exe --dllname python31.dll --input-def python31_d.def --output-lib python31mw.lib +::cd X:\b\lib\windows\python\lib +dlltool.exe -v --dllname python31_d.dll --input-def python31_d.def --output-lib python31mw_d.lib +dlltool.exe -v --dllname python31.dll --input-def python31_d.def --output-lib python31mw.lib @ECHO OFF SET USRINPUT= ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Another svn/projects migrate coming!
Hi all, Last December the projects site and svn were migrated to a new server. Since then this system has given weird errors occasionally. There's something bad with the hardware apparently. We'll ditch this server and move it all to a new system (there's a spare). Currently the server is down and not responding to remote reboots, will try to get in the colocation center today to kick it with some terminal magic :) This means the bug trackers and svn is not accessible until further notice. We're on it! -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
Re: [Bf-committers] normal maps, red/green channel inverted
Hi, I think Carsten's proposal is the nicest way, even when a bit ugly. We can add a version patch in .blend files that sets this button active for all old .blends, but not active for newly created textures. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 19 Feb, 2011, at 23:47, Carsten Wartmann wrote: Am 19.02.2011 23:08, schrieb Dalai Felinto: I wonder if instead of a commandline it would be possible to do this conversion with Python. I'm not sure of the current status of bpy for image handling, but it would be neat to have an addon for that. My idea was having a Button inside the Texture Context, Image Tab (beneath the Normal Map Button) to use old Blender Normal maps. 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] normal maps, red/green channel inverted
Instead of old Blender Normal maps couldn't it be invert color channels [tooltip: old Blender Normal Maps - invert red/green channels? Or Blender was really the only software out there using those inverted? I remember this being discussed a while ago (1year or +) but don't remember what was the outcome of it. -- Dalai 2011/2/20 Ton Roosendaal t...@blender.org: Hi, I think Carsten's proposal is the nicest way, even when a bit ugly. We can add a version patch in .blend files that sets this button active for all old .blends, but not active for newly created textures. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 19 Feb, 2011, at 23:47, Carsten Wartmann wrote: Am 19.02.2011 23:08, schrieb Dalai Felinto: I wonder if instead of a commandline it would be possible to do this conversion with Python. I'm not sure of the current status of bpy for image handling, but it would be neat to have an addon for that. My idea was having a Button inside the Texture Context, Image Tab (beneath the Normal Map Button) to use old Blender Normal maps. 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] MinGW debug builds do not run
IIRC MSVC2008 full version is used for releases, I have a free MSVC2010 which has a similar problem to MinGW, debug builds fail to run with strange popup dialog error. Re Crash on startup: If its a crash (not a linking/error message), best not assume blender is without fault, debug info call-stack can help a lot in tracking down these problems. The IOError define is already in lib/windows, committed shortly after changing the exception. I use an update alias which does both repo's before building to prevent these kinds of errors. Do you still get the crash on startup? On Sun, Feb 20, 2011 at 11:54 AM, Peter Kümmel syntheti...@gmx.net wrote: On 20.02.2011 04:24, Campbell Barton wrote: Whats supported isn't set in stone, its more a case of which configurations are tested known to work. OK, thanks. And what is mostly used for the Windows releases? this works for me. - windows xp - mingw-gcc4.5.2, (from mingw's main site) - cmake 2.8 (build type set to Release or RelWithDebInfo) - blender (tested r34959) I had a little bit outdated checkout with 4.4, W7-64Bit, and problems with release and debug. A crash on startup may be a real bug rather then lack of support, you could run with gdb and see why its crashing. If you are unable to figure out how to fix you could file a bug and include a backtace. I assume not really a error in blender code, it's the mixture of pre-compiled binaries, compiler used for blender, OS, and runtime libraries. Best is to build everyting with the same compiler. Another way to help find the cause of the crash is to disable all WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR ... etc. If this works you could try again with usable settings (so you get an interface), all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL. I already had the idea to try it without python ;) After that its trial and error to see which library causes the crash, the offending lib could be disabled by default with mingw until its fixed properly. One other thing, you were getting the error 'PyModule_Create2' interestingly I got this error too on Linux when trying to load a library built with a debug python but finding a release library. I could link against the lib/windows version with attached patch. On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmelsyntheti...@gmx.net wrote: Tested it with cmake too. It links after a small fix, but crashes immediately after starting. Seems mingw isn't supported. 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
so mine :) 2011/2/19 Mats Holmberg mats.holmb...@2me.fi On 19.2.2011, at 20.20, ra...@info.upr.edu.cu wrote: Is on the way ;) This comment really made my day =D Thanks. -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
On Sat, 19 Feb 2011 00:57:39 +0200, Michael Fox mfoxd...@gmail.com wrote: i don't like how size is now being used as ui tend to use size deflect with some random size which means if i increase the size, hence the radius then the particles will float above the collision object. I've used size deflect in pretty much all my fluid tests and using particle size to influence the interaction radius too only seems natural to me. Perhaps I didn't make it clear enough that the idea is not to have interaction radius = particle size, but that the size defines a sensible radius so that enough neighbors are included in the calculations (for example 4 * size). So I don't quite get how this would make the particles float above the surface.. but can you please explain your work flow a bit more so I can understand the problem? On Sat, 19 Feb 2011 01:11:28 +0200, Carsten Wartmann c...@blenderbuch.de wrote: BTW: Is there a documentation in one place for all the new particles? Even in your blog it is hard to keep track. Yes the existing documentation is quite outdated. Once I get these changes ready I'll make a proper tutorial or perhaps even a couple on how to use the fluids in different cases, so that will hopefully help to get you started. And yes I do know that this will break old simulations, and that you book writers have to do some pages all over again, but my sincere intention is a better user experience with the particle fluids, so please forgive me. See above ;-) Beside us writers I don't think there is much use of them at the moment beside self contained demos and some effects, so I think it is acceptable to break some old simulations. This is very nice to hear :) And yes like Raul said surfacing is being worked on by him and Stephen, so hopefully we'll have some really usable fluid particles before the 2.6 is out! :) janne ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] IRC Meeting minutes February 20 2011
Hi, we had a short meeting, here some infos: 1) Blender 2.5x project -Infos about the improvements for the fluid particles are on c.b.o http://code.blender.org/index.php/2011/02/particle-fluids-refactoring-under-way/ Janne Karhu asks for some feedback :) If there are no big issues he can commit during next week. -New Material Pipeline panel For normal materials we will stick to the old interface, for node materials we will use the pipeline panel. This should clear things up again. :) Erwin Weber will do a new patch. Thomas Dinges will review and commit. -First stable 2.5 version (2.57) is still planned for March. Priority remains on bug fixing and to-do items. 2) Current projects / branches -Sergey Sharybin// mentions that the svg importer is nearly finished and can be committed to addons repository soon. This is still wip, so please contact him directly if you find bugs. -Janne Karhu want to implement paged particles into Blender. This would bring back Reactor particles for example. -particles-2010 branch: Lukas Tönne reports work has been done on node basics and especially group handling over the past few days -Jeroen Bakker will give more infos about his Tile based / OpenCL compositor project next week. Thanks, Thomas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
Am 20.02.2011 16:27, schrieb Janne Karhu: On Sat, 19 Feb 2011 00:57:39 +0200, Michael Foxmfoxd...@gmail.com wrote: ... hopefully we'll have some really usable fluid particles before the 2.6 is out! :) Erm, the next release is 2.5x I am not wrong, and Roland is not a clairvoyant ;-) So you got 1 or 2 years ;-) Carsten, hopes you meant 2.5x -- 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] Another svn/projects migrate coming!
Hi, SVN and trackers are running again. An fsck does miracles :) Still, according our sysadm the motherboard is rotten, so we'll move it over asap. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 14:29, Ton Roosendaal wrote: Hi all, Last December the projects site and svn were migrated to a new server. Since then this system has given weird errors occasionally. There's something bad with the hardware apparently. We'll ditch this server and move it all to a new system (there's a spare). Currently the server is down and not responding to remote reboots, will try to get in the colocation center today to kick it with some terminal magic :) This means the bug trackers and svn is not accessible until further notice. We're on it! -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
Re: [Bf-committers] Another svn/projects migrate coming!
Hi, Oh, he just decided to do this right away :) In the process, svn/ trackers are not accessible! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 17:01, Ton Roosendaal wrote: Hi, SVN and trackers are running again. An fsck does miracles :) Still, according our sysadm the motherboard is rotten, so we'll move it over asap. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 14:29, Ton Roosendaal wrote: Hi all, Last December the projects site and svn were migrated to a new server. Since then this system has given weird errors occasionally. There's something bad with the hardware apparently. We'll ditch this server and move it all to a new system (there's a spare). Currently the server is down and not responding to remote reboots, will try to get in the colocation center today to kick it with some terminal magic :) This means the bug trackers and svn is not accessible until further notice. We're on it! -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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Drivers Delayed (Dependency Issue)
Why are bones are not treated like separate objects? Driven Shapekeys on objects are not lagging behind. Neither do Constraints. But on Bones anything (location, rotation,... , influence on constraints,...) lags behind. I think this is a big issue, since you can't drive a bone with a bone correctly, as long they are inside the same armature. So far you stated the reason for this behavior. I can follow the reasons and it seams correct to me. But isn't this not a general design flaw? As far as i can see, anything should be handled in one dependency tree. Updating anything first, that does not depend on anything else. Bones should also be part of this tree and not be treated separately. Otherwise not anything is animatable. At least not in a way you want to. Am 20.02.2011 10:29, schrieb Joshua Leung: Incorrect analysis... ... and it's not really a bug by our tracker definitions either! What is really happening is this: - Animation is ALWAYS executed first (this is done per frame change, not per update). This is before any data (namely objects) get evaluated. For the bones here, the values get written to the pchan-loc/eul/quat/size/etc. vars at this point. - Before updates occur (including frame change), the depsgraph only tags objects with their object and/or object data needing updates. - When updates occur, objects are evaluated by these block tags. In this case, it means that the pose matrices (pchan-pose_mat), which give the final transforms of bones (which you see in the viewport), are calculated for all bones that an object has (in a single pass/step) when the object has an object data tag - Drivers for bones (strictly speaking, for PoseChannels, also known via the PyAPI as PoseBones) and also for animation data are rooted at Object-level. That is why you'll find the actions for posebone animation attached to the Object-level AnimData block, as the Pose data which contains the collection of PoseBones is attached to the Object NOT Armature datablock. - The practical implication for this story here, is that Object-level data (including drivers) is evaluated before Object-data gets evaluated (i.e. the Drivers will be run BEFORE any of the PoseBones get evaluated) - Rotational difference uses the pose matrices of the bones it depends on (i.e. pchan-pose_mat) - Hence, the phenomenon you see is all caused by the drivers reading the last values they could find in the pchan-pose_mat's of the bones it uses as input. Since the drivers are run before the pchan's will get updated by being evaluated using newly flushed animation values (and thus updating their pose_mat's), you will get a lagging phenomenon. On Sun, Feb 20, 2011 at 9:39 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I made some tests with the drivers and found out that they are delayed. Actually they get evaluated first. Before the objects they are depending on are getting updated. Even if there is no cyclic dependency they will be first, getting the input of the previous frame, making them lag one frame behind the changes. I posted a bugreport yesterday, but the tracker seams to be down currently. Since i think, that this is a serious issue, i posted it also on this mailing list. I uploaded a very simple example to http://www.pasteall.org/blend/5309 It contains a tiny armature consisting of one parent bone base, followed by a chain of the bones consisting of rot1 and rot2. rot2 is animated and will be used as the input for bone driven, that is a child of base. Last steps ensures that rot1/rot2 are not depending on driven. driven has a single driver that updates the location of the bone, depending on the rotational difference between rot1 and rot2. Ideally rot2 would be changed by the animation first, then driven would evaluated. But instead the driver is evaluated first, ignoring the dependency. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Another svn/projects migrate coming!
That explains a lot. Thanks Steve Obbayi: Software Developer Homepage: http://www.sobbayi.com - Ton Roosendaal t...@blender.org wrote: Hi, Oh, he just decided to do this right away :) In the process, svn/ trackers are not accessible! -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 17:01, Ton Roosendaal wrote: Hi, SVN and trackers are running again. An fsck does miracles :) Still, according our sysadm the motherboard is rotten, so we'll move it over asap. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 14:29, Ton Roosendaal wrote: Hi all, Last December the projects site and svn were migrated to a new server. Since then this system has given weird errors occasionally. There's something bad with the hardware apparently. We'll ditch this server and move it all to a new system (there's a spare). Currently the server is down and not responding to remote reboots, will try to get in the colocation center today to kick it with some terminal magic :) This means the bug trackers and svn is not accessible until further notice. We're on it! -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 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
A bit unrelated maybe but a possible cause of crashes for MinGW, both Scons and cmake is (unfortunately) ray-traced optimizations. It only happens on render. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] blender-snapshot
I'm pretty sure simply changing the name of the .deb package to blender-snapshot doesn't actually fix the 'bug' that was reported. From what I understand the 'a' -- i.e. 2.49a -- was the issue and not the package name which the debian folks solved by converting the subversions to numbers, 2.49a = 2.49.1, 2.49b = 2.49.2, etc... And, to top it all off, the blender-snapshot package conflicts with the regular (stable) blender package so you can't even have two different versions installed which is the only valid reason I can come up with to have a different name. To summarize, the issue is the way *blender* names releases and has nothing to do with the debian package (which is what I said multiple times in the bug report). So, not a bug and as author of the original patch I'd appreciate if the name were changed back. Dan ___ 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
It compiles now out of the box but still crashes. Seems I have to go the 'hard' way you described. On 20.02.2011 14:46, Campbell Barton wrote: IIRC MSVC2008 full version is used for releases, I have a free MSVC2010 which has a similar problem to MinGW, debug builds fail to run with strange popup dialog error. Re Crash on startup: If its a crash (not a linking/error message), best not assume blender is without fault, debug info call-stack can help a lot in tracking down these problems. The IOError define is already in lib/windows, committed shortly after changing the exception. I use an update alias which does both repo's before building to prevent these kinds of errors. Do you still get the crash on startup? On Sun, Feb 20, 2011 at 11:54 AM, Peter Kümmelsyntheti...@gmx.net wrote: On 20.02.2011 04:24, Campbell Barton wrote: Whats supported isn't set in stone, its more a case of which configurations are testedknown to work. OK, thanks. And what is mostly used for the Windows releases? this works for me. - windows xp - mingw-gcc4.5.2, (from mingw's main site) - cmake 2.8 (build type set to Release or RelWithDebInfo) - blender (tested r34959) I had a little bit outdated checkout with 4.4, W7-64Bit, and problems with release and debug. A crash on startup may be a real bug rather then lack of support, you could run with gdb and see why its crashing. If you are unable to figure out how to fix you could file a bug and include a backtace. I assume not really a error in blender code, it's the mixture of pre-compiled binaries, compiler used for blender, OS, and runtime libraries. Best is to build everyting with the same compiler. Another way to help find the cause of the crash is to disable all WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR ... etc. If this works you could try again with usable settings (so you get an interface), all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL. I already had the idea to try it without python ;) After that its trial and error to see which library causes the crash, the offending lib could be disabled by default with mingw until its fixed properly. One other thing, you were getting the error 'PyModule_Create2' interestingly I got this error too on Linux when trying to load a library built with a debug python but finding a release library. I could link against the lib/windows version with attached patch. On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmelsyntheti...@gmx.netwrote: Tested it with cmake too. It links after a small fix, but crashes immediately after starting. Seems mingw isn't supported. 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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
Hi Janne, Thanks for putting together this proposal. - Original Message - I've been refactoring the fluid particles recently, and before I actually start getting ready to commit this I'd like to get some feedback on my current progress and ideas. http://code.blender.org/index.php/2011/02/particle-fluids-refactoring-under-way/ We have been using the SPH solver for engineering simulations. In our experiments, we often vary the fluid interaction radius independently from the collision radius. For example, if the size of a hole in a container mesh changes, I might want to make the collision radius smaller. Then again, it might make sense to make the interaction radius smaller too, so that the particles still flow nicely through the hole. I suppose what I really want to do is change the resolution of the simulation without drastically changing the way the fluid behaves (e.g. double the number of particles, but maintain the same volume). If you can acheive this by changing the rest density at the same time as the interaction radius, I'm all for it. Will there be a way to find out what the interaction radius is, for the sake of writing reports? Also, what will the Advanced Rest Length setting do? One big challenge for us has been finding out how the parameters presented in the UI relate to physical quantities. The information doesn't seem to be available in the paper the Blender SPH code is based on: http://www.iro.umontreal.ca/labs/infographie/papers/Clavet-2005-PVFS/ Perhaps the simulation in Blender is unphysical. We intend to implement a classical SPH algorithm, i.e. one without the double density relaxation, to perform further experiments with. We expect it will be more physically accurate (although perhaps lacking surface tension), and easier to make multi-threaded. Cheers, Alex -- Alex Fraser Software Engineer The Victorian Partnership for Advanced Computing ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender-snapshot
Dan, since you added the debian package spec best you to make decisions on this. If its a simple rename I can commit otherwise send in a patch. On a related topic, just moved release/VERSION vars into BKE_blender.h This way we can construct version strings from scanning the header in either format... 2.56a-beta - external release name we use on blender.org. 2.56.2 - internal version string using subversion, internal blender use. the string thats currently 'beta' could be used to detect if blender is a release or not for generating packages. the value could be set to 'alpha/beta/rc/release', and check for 'release', to made a package without the svn revision included. I'd rather not become too involved in packaging discussions, devs who maintain package spec's can choose which name, version string to use which fits with their own distro/package guidelines. - Campbell On Sun, Feb 20, 2011 at 9:21 PM, Dan Eicher d...@trollwerks.org wrote: I'm pretty sure simply changing the name of the .deb package to blender-snapshot doesn't actually fix the 'bug' that was reported. From what I understand the 'a' -- i.e. 2.49a -- was the issue and not the package name which the debian folks solved by converting the subversions to numbers, 2.49a = 2.49.1, 2.49b = 2.49.2, etc... And, to top it all off, the blender-snapshot package conflicts with the regular (stable) blender package so you can't even have two different versions installed which is the only valid reason I can come up with to have a different name. To summarize, the issue is the way *blender* names releases and has nothing to do with the debian package (which is what I said multiple times in the bug report). So, not a bug and as author of the original patch I'd appreciate if the name were changed back. Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
