- User Since
- Nov 26 2011, 2:33 PM (395 w, 2 d)
Jun 2 2017
here the log from an none affected in case of interest:
sorry for that frequence of posting.
the only difference i could see between an affected system and a none affected system is, that on the affected system there is an event type "RIGHT_ALT"
wm_event_do_handlers: Handling event wmEvent type:214 / RIGHT_ALT, val:1 / PRESS, shift:0, ctrl:0, alt:1, oskey:0, keymodifier:0, mouse:(200,601), ascii:'', utf8:'', keymap_idname:(null), pointer:0x7fb5dc9bee88
that never appear on the log on a none affected system.
on a none affected system i only can see the "UNKNOWN" events at the time when i press or release the ALT key on the keyboard.
on an affected system i see the "RIGHT_ALT" followed by "UNKNOWN" at pressing and only two "UNKOWN" events at releasing the alt key.
will be quickly hitting keys detected as DOUBLE_CLICK on the keyboard ?
??? i see some key events in the log with val:4 / DOUBLE_CLICK ... i never touched my mouse in that time.
i used the --debug-events option. with that option enabled it is way harder to force blender to go into that issue situation. sometimes i can not reproduce that issue anymore...
BTW: that screen cast was made on the system, where TeamViewer is istalled (but not running).
now i downloaded and installed the old "ScreenCast Keys" - addon (space_view3d_screencast_keys.py) to see what it will display in that issue situation.
unfortunately (for me in this situation) it does not show up in the text editor but when i quickly move the mouse cursor to the 3d view, some of the last pressed keys of the text editor will show up in the 3d view.
it looks like the [Alt]-key will stick, when that issue appears, even i do not hold the [Alt]-Key anymore. but i found out i can unlock the [Alt]-key, when i press the [Alt]-key again without pressing any other key
(in the Video shown as ALT + NONE).
hi, i have only access to german keyboards.
but i tried blender out on other computers and OS'es.
Jun 1 2017
Feb 6 2017
as from the other discussion from the other forum, i grabbed some additional information:
Windows 10 Pro x64
Jan 19 2015
Jan 18 2015
it is a duplicate of T43198 and it is fixed already
Jan 12 2015
i tested a bunch of old ms3d and blend files... i can not see a problem in that addon.
and is that your answer https://developer.blender.org/T43192 to here?
i this the answer of that report https://developer.blender.org/T43173 ???
if so, then there is no bug...
Jan 11 2015
can you take a look to this topic https://developer.blender.org/T43198
should be fixed with that script there as well.
yes, replace the current script inside blender, as long there is no official blender >2.73 available (2.73a?).
the script i gave is not committed yet, so you currently will not get is in a buildbot version of blender either.
Jan 10 2015
can you try this script...
did you tried blender 2.73? there was a change from 2.72 to 2.73, possibly you catched a version it was not ready yet.
i am not sure, what you mean/want...
you tell, every think works fine (thank you), but where is the bug?
Dec 8 2014
Sep 17 2014
witch version you was using before?
as long as i know, the add-on was removed by intention/choice.
Sep 16 2014
I can confirm that strange behavior. (windows 8.1 64bit, blender 2.71 64bit)
the shown workarounds are not satisfactory to me.
the behavior should be the same in all cases - with or without using nodes - it should give the same result.
I would like to see a easy, logical and consistent solution here.
Sep 2 2014
@Bastien Montagne (mont29): oh, sorry, i did not noticed that you asked me something...
(most of the developer email notifications are classified as spam in GMX.)
i just tested it with the recent build bot version:
Jun 25 2014
Jun 21 2014
you can dissolve the inner edges of the fan, first. ([del]-key + "Dissolve Edges")
then add the bevel to the object to get the expected result...
i think the bevel algorithm is not able to figure out, what part of the object should be handled in what way - different users, different tastes of what the user expects.
Jun 7 2014
May 14 2014
May 13 2014
Apr 1 2014
@Sergey Sharybin (sergey), no no no... its all fine.
(in the past not all frames where cached/where marked as cached while tracking. now i can see the light blue line is without gaps - i think it is good)
looks good to me now. i tested build 62dc18c717ea8c47c87e825b94a568486f93c452 and it seems to be fixed now.
(and now the lightblue line on the bottom of the viewport - (cached frames?) - is now without gaps)
i just recompiled blender (e95fd79) and there i can see an other backtrace:
i now used "gdb" to get some more detailed informations in backtrack.
Mar 31 2014
i compiled blender with option BF_DEBUG=True, but i can not see any difference in the log / backtrace
maybe i made something wrong.
@Sergey Sharybin (sergey), i never tried to compile blender (either windows nor linux).
but i can run some debug builds, if somebody can provide me these debug builds.
Mar 30 2014
i just switched to ubuntu 13 and "blender-2.70-b64bdb2-linux-glibc211-x86_64.tar.bz2" here i have other strange behaviours.
it crashes also on my computer... (it remembers me very well to this issue T38281)
Windows 8.1 x64,
Feb 14 2014
yes, i can confirm, blender-2.69-b096845-win64.zip works well... thanks!
Feb 11 2014
i tested with "blender-2.69-2038eb1-linux-glibc211-x86_64.tar.bz2" and it looks ok to me - so i closed this track.
constant fluid bake time from bake to bake (~136.6s, ~111.4, ~109s, is see the differences as normal latency)
Feb 4 2014
yes, to me, blender "blender-2.69-6a2c467-win64.zip" still crash in the same way as described in the initial post.
Feb 3 2014
yes, all issues are still there with "blender-2.69-15f449c-win64.zip" on Windows 8.1 64 bit
(the issue with the IK constraint, and the issue with delayed updating name)
Feb 1 2014
i can confirm that issue on windows as well:
following the steps,
by parenting curve to Cube ([Ctrl]+[P], Object)
i get a message on the console:
i have the same issue. (in sculpt mode no sculpt brush is doing anything, no dynamic topology)
Windows 8 64bit
Jan 26 2014
i get more and more confused with this report...
i scare about to tell you, but i think there was a mistake in that commit rB18db6c58ec6b (by accident, a good code line was turning to a bad one)
Jan 25 2014
@Sergey Sharybin (sergey): oops, i overlooked your comment (Wed, Jan 15, 2014-01-15T20:44:21+01:00 - then we can just close the report?)
Jan 24 2014
@Sergey Sharybin (sergey): no, not on my three computers.
i can not observe any abnormal or extensive memory usage on my computer.
on the tiniest laptop with 4GB RAM, blender uses ~1GB during tracking.
the memory usage follows a normal loading curve with saturation at ~1GB usage long before blender will crash.
Jan 21 2014
@Sergey Sharybin (sergey): unfortunately no, in the blender.crash.txt is nothing usefully that would point to the cause of the crash.
i have a second computer with exact the same hardware, but different GPU - on that computer blender crash as well.
and my third, my business laptop (i Core2 Duo T7500, 4GB, Windows 7 64bit SP1, )
what i exactly was doing:
- downloaded blender (blender-2.69-fd0b104-win64.zip-version)
- extracted to here ("D:\_DOWNLOADS\_unsorted\blender-2.69-fd0b104-win64")
- deleted "%AppData%\Blender Foundation" folder to be sure noting old will interfering
- downloded "0001-2654.mp4" (to "D:\_TEMP\0001-2654.mp4")
- opened blender
- changed screen to "Motion Tracking"
- on the lower "Movie Clip Editor" i clicked to "Open" (bpy.ops.clip.open())
- navigate to "0001-2654.mp4" file destination and selected that file
- clicked "Open Clip" (bpy.ops.file.execute())
- changed in lowest time line view the end frame to 2654 (bpy.data.scene["Scene"].frame_end)
- in the "Movie Clip Editor" view, i scrolled "two" times the mouse wheel to decrease the view size of the video clip to fit to the view
- on the "Movie Clip Editor"s left Marker panel i clicked "Detect Features" (bpy.ops.clip.detect_features())
- in the "Movie Clip Editor"s left Track panel, i clicked ">" (bpy.ops.clip.track_markers(backwards=False, sequence=True))
- i leave the system & mouse & keyboard untouched... and watch the progress in the viewport
(the crash happens on different frames from computer to computer and sometimes from try to try)
Jan 20 2014
in the post from 2014-01-19 01:32:38
i uploaded a wrong log file... here is a one with a crash
Jan 19 2014
Jan 12 2014
no, not fully fixed yet, "the doc of bmesh.types.BMDeformVert is swapped too" issue is still present.
bmesh.types.BMDeformVert.items.doc shows doc of values()
bmesh.types.BMDeformVert.values.doc shows doc of items()
Jan 11 2014
i am sorry about that comment.
(it gives me the feel, pushing new functionalities has highest priority, but documentation these has no priority)
the doc part is now corrected with the last commit,
BUT still the functionallitiy is incorrect!
Jan 10 2014
Jan 9 2014
Jan 6 2014
also an issue on linux (ubuntu 13.x 64bit / intel HD4000)...
Jan 1 2014
@Thomas Dinges (dingto) i did not noticed that symbol in in the browser. yes, that will fix the first issue.... thanks
Dec 30 2013
Dec 21 2013
Dec 19 2013
Dec 10 2013
i noticed all the above shown issues (strange lines and game engine) do not exist in the same hardware but windows 8.1 64bit and blender 2.69.x.
i have no windows 7 anymore, so i don't know, if the issues are gone by newer intel graphic drivers or if the reason is in blender 2.69.x...
with blender 2.69.7 the link is again not up-to-date and link you to a non-existing webpage.
i want to point to, that there should be a better solution / automatism / or what ever, to keep the "blender API reference" functionality an the webpage in sync.
Dec 6 2013
blender 2.69.4 is out, but again, the "Python API Reference" is pointing to a non-existing web-page