- User Since
- Nov 7 2010, 8:47 PM (359 w, 4 h)
Feb 24 2017
Feb 22 2017
Anyone make any progress on this? This still appears to be an issue on 2.78 (3c04373), and I'm fairly surprised that animation layers have remained broken for this long.
May 7 2016
Nov 5 2015
Tested on ce49c70 since that's the newest build that just came up on the builder. Still crashed with 9 subdivisions.
Nov 4 2015
I certainly am not running out of memory. I'm using < 4GB out of 8. If that was the issue, you would expect the crash to occur regardless of whether the async argument was True or False. I only meant that the state the system's memory is in (e.g. what chunks of memory the OS decides to allocate to Blender, how big they are, the order they're in, etc.) likely effects whether the crash will occur or not.
Crashed immediately multiple times on 2.76 (e43b6e2) with only 9 subdivisions.
Oct 21 2015
I've noticed that the crash seems to occur less frequently on newer versions of Blender. On 2.76 with 9 subdivisions (262,144 faces), I've been able to open Blender and run load.blend upwards of 10 times without it crashing even when completely closing Blender between each run. However, it eventually does still crash. Going up to 10 subdivisions (~1 million faces) causes the crash to occur every single time again.
Oct 18 2015
It still appears to crash on 2.76 bfdb420. The only message I get in the console is:
However, the crash does seem to happen less frequently. Generally, it would only crash about 1/4 of the times I started Blender. If it did not crash the first time the game engine was started, it would almost never crash unless I completely closed Blender and reopened it.
Sep 4 2015
I'm fairly certain that this is not the desired behavior for actions to have. Even if it was intentional, the behavior is inconsistent in its current implementation as the "bouncing" does not occur at higher animation playback speeds and will stop after the point were the action would have completed if left to play by itself.
Sep 1 2015
By "bouncing", I mean that on a logic tick where I call setActionFrame(frameNumber), the cube will be place at position corresponding to frameNumber. On next logic tick (where setActionFrame() is not called) the cube is place at the position corresponding to the start frame value used in the original call to playAction().
Aug 29 2015
Jul 24 2015
Jul 2 2015
Jul 1 2015
Jun 13 2015
Jun 3 2015
Jun 2 2015
May 21 2015
May 16 2015
What Blender version are you using and what are your system specs? I just tested it again on the following:
Mar 20 2015
Mar 7 2015
Checking the vector during a post_draw call isn't really a valid solution since the scene has already been rendered at that point, so any changes I make are not shown.
Feb 24 2015
Nov 13 2014
Oct 23 2014
Something else I noticed:
If you change the viewport shading to Solid instead of Textured/Material, the transparency is changed correctly when in GLSL. This has the opposite effect in Multitexture mode, e.i. the plane's transparency is not changed when using Solid viewport shading in Multitexture mode.
Oct 22 2014
Oct 10 2014
The same problem occurs when using LibNew instead of LibLoad. As you can see in this file, it the crash occurs even if you load and free a different object each time. All that seems to matter is that the loaded object is using a material.
For me, the crash occurs on the second call to LibFree.
Sep 30 2014
Mar 27 2014
Accidentally added the Addons tag to this report and am unable to remove it. Please disregard.