- User Since
- Aug 30 2010, 3:36 PM (554 w, 5 d)
Tue, Apr 6
It did not lock up if I used one frame stretched to the whole duration, it seems to be necessary to use a real image sequence.
Since VSE can't pack images, you could try any image sequence you have on your harddisk (please don't delete & create but edit the path in the sequences, just to be sure). If you don't have one, you could use ffmpeg to convert e.g. a blender movie to single frames
ffmpeg -i input.mp4 -t 01:44 -vf fps=25 out%04d.jpg
Sun, Apr 4
With my project, I can reproduce the issue quite reliably in 5 minutes, but sometimes it does not work.
I compiled a debug build and tried it in the terminal: no output on lock-up, so I ran the debug build from QTCreator and as Blender locked up, I clicked Pause GDB and copied the stack trace:
Fri, Apr 2
Sorry, I downloaded https://builder.blender.org/download/blender-2.93.0-d91fec1a85d9-linux64.tar.xz but there is no blender_debug_log.cmd included.
Have you tried it with a larger project?
As I've written, scrubbing has been bugged in 2.91 - it would freeze the computer, so it is not possible to reach the point of the lock-up. It seems to be the same in 2.83.8 and presumably earlier versions.
Since I am still not sure what is triggering the issue and if continuing to scrub after 10 minutes would trigger it, it is quite difficult.
After replacing the missing images files, I also could not reproduce the issue with this blend.
My impression is that it is very difficult or impossible to reproduce with simple setups. It might be necessary to use a more real project like in my case 2500 rgba frames in 1920x1080 at 29.97 fps and even then it gets quite tedious, but sometimes the lock-up happened after just one minute.
Wed, Mar 31
Fri, Mar 26
On the right, both planes get darker if I deactivate diffuse on the lower plane because the light does not bounce back towards the upper plane and the camera, I believe.
Unfortunately, transmission is only vaguely defined in the blender wiki as "Transmission: the ray is generated by a transmission through a surface.", that is all I know, so I expect transparency and translucency to create transmission samples, but both do not react to the transmission ray visibility.
If you change the translucent shader on the upper plane to a transparent shader, then toggling transmission (on the upper or lower plane) also has no effect.
Thu, Mar 25
New testscene: the selected objects (".. receiver") should receive Volume Scatter/Transmission rays and therefore be lit if the respective toggles are on. If the toggles are off, the selected objects should not receive light.
To me it always looks like this:
But if Transmission and Volume Scatter are off, I would expect it to look something like this:
So there is a visible change if you switch off Transmission on the plane above the cube? To me, it looks completely identical even in a F12 render.
Camera/Diffuse/Glossy/Shadow are fixed in version: 2.93.0 Alpha, branch: master, commit date: 2021-03-25 15:06, hash: rB5ebe74e77903
but Transmission and Volume Scatter toggles don't seem to have an effect.
Fri, Mar 19
Mar 18 2021
Okay, I begin to understand that this is not about metadata from photo cameras (Nikon/Canon photo metadata is not displayed), but about metadata blender exports with it's frames using tEXt tags that are also used by inkscape, so this text is displayed. While the metadata display toggle has already been present in 2.92 it is only working in 2.93.
Mar 10 2021
Sorry, it is not fixed completely, retesting in version: 2.93.0 Alpha, branch: master, commit date: 2021-03-04 19:20, hash: rB1668f883fbe5 shows that the following problem is still present:
If you switch the Outliner to Scenes mode and drag a collection to another collection, "Link inside Collection" is displayed but in reality, the collection is moved and you have to press Ctrl to link it.
Jan 30 2021
So I found the reason of this issue: I have set a custom path for Temporary Files (in Blender Preferences - File Paths) in most older Blender versions that I had not set in some newer versions.
Blender does not seem to use the system clipboard but its Temporary Files location for storing copied content, so there were two separate clipboards, one using the default location and one using my custom location.
BTW: saving Auto Saves to /tmp by default which is automatically deleted upon boot isn't a good preset - if the computer crashes, the Auto Save is lost, too, so I had to change the directory.
Jan 24 2021
Jan 22 2021
Dec 16 2020
Nov 25 2020
Following the steps from the description, I could reproduce it again in 2.90.1 and version: 2.92.0 Alpha, branch: master, commit date: 2020-11-24 15:05, hash: rB256a9d983d48
An NLA strip on rig is lost, but an NLA strip on meta-rig is saved/restored properly.
Nov 20 2020
Nov 13 2020
@Luc Revardel (lrevardel)
That's it, thanks a lot!
So if there is no animation added to the source object, it should always be possible to add an animation to the override?
Because while it works in tests, it does not work in my project. I simplified my rig ("Problematic") and built a new version ("Working"). NLA strips can be added to the linked override of the new version and will be retained upon reload, but on the old version, NLA strips are gone upon reload (tested with today's master).
Perhaps you could have a look at my files, I fail to see the difference. If it is supposed to work, I can create a separate report if you like.
Nov 12 2020
Nov 10 2020
There are certainly more important problems, but a shortcut seemingly stopping to work for no apparent reason is quite irritating. So its a papercut.
Nov 9 2020
Pasting of the copied objects worked after factory resetting the originating blender instance event though I reactivated all plugins that were active before.
I never touched the keymap, and there was the "object copied to buffer" notification (and I can paste to a different instance of the same version), so the object was actually copied.
Yes, you can resize it as long as its visible, otherwise you have to resize the editor or use the tab. Biggest problem is that it is saved in the blend, so days may pass and suddenly N seems to stop working, while in reality just the panel got enlarged too much the last time that specific editor was used.
Nov 8 2020
Nov 2 2020
The problem seems to be in the earlier versions, not in 2.92: if I run the earlier version with --factory-startup I can copy/paste an object to 2.92. Without that, although I get the message "Copied 1 selected object(s)", I can only paste to the same blender version, e.g. copy in 2.90, can't paste in 2.92 but can paste to another instance of 2.90.
Deactivating all plugins (without restarting blender) in the earlier version did not help though.
Oct 30 2020
The permissions of the executables are identical and I did not change anything permission related. Also tested on a second Manjaro system and it's the same there, too.
Oct 25 2020
Thanks for the link! Also happens with --factory-startup btw.
Oct 22 2020
@Philipp Oeser (lichtwerk) your files crashed Blender if I clicked the Armature object in the Outliner prior to using make local. There is no problem using make local on the object data-block, the armature data-block is the one I can't make local (unless I use the workaround).
Confirmed in 2.90.1 and 2.91.0 Alpha, branch: master, commit date: 2020-10-21 09:38, hash: rB819b1a7f9da0
Only a local armature will retain NLA strips.
Oct 8 2020
Yes, it still looks the same after that.
Yes, it has improved slightly, but the artifacts are still there:
branch master, commit date 2020-10-07 17.31, hash rB833066088e4a
Oct 1 2020
Sep 30 2020
Sep 28 2020
Thanks for finding the source of the problem.
While it's not Blender's fault, shouldn't users be warned that this format is an exception and that the alpha channel will be lost if the video will be used in Blender?
I tried adding it here https://docs.blender.org/manual/en/dev/files/media/video_formats.html, but this page can't be edited by me (a warning in the UI would be more effective of course).
Sep 20 2020
Sep 17 2020
Backdrop rendering looks normal in version: 2.91.0 Alpha, branch: master, commit date: 2020-09-17 20:18, hash: rB9ee588cd4af8, but F12 rendering still has artifacts.
Sep 14 2020
You are right, it works in kdenlive, too. But VLC, mpv and Blender don't recognize the alpha channel in the VP9.
Sep 13 2020
Sep 9 2020
Correction: the bug is still there, but not as bad as it was: F12 rendering seems working fine - at least I haven't found issues yet.
But rendered viewport is still broken in some situations. In the Example scene:
- switch to rendered viewport shading, deactivate camera ray visibility: either the reflection is gone, too or it has artifacts.
- switch the camera ray visibility to off before activating rendered viewport, then switch it off (still working) and on again - now the mesh is in tatters.
Its working in version: 2.91.0 Alpha, branch: master, commit date: 2020-09-09 00:05, hash: rBb8840c105a4e. Don't know which commit fixed it.
Sep 4 2020
Sep 2 2020
It's pretty basic, just trying to cover every ray type
Loading defaults did not help.
Tried it my notebook, same OS, but intel integrated graphics (again only cpu rendering):
viewport: slightly different artifact (in the reflection), but after the first deactivating/reactivating any ray visibility, the switches do work without issue.
F12 render: no issue
I can't render using my gpu.
The first time I switch a visibility property to off, I get artifacts. After switching it back on and off again, it just does not change visibility at all, always looking like on the left side of this image:
Sep 1 2020
Yes, it's solved. Thanks!
Aug 31 2020
I can't reproduce it anymore, too. Closing.
Aug 30 2020
Like I said, deactivating "Use Nodes" in the compositing nodes of scene B does not help, nor does setting the rendering resolution to the same value as scene A.
Aug 28 2020
Still crashed, but took 3 clicks. Terminal output:
Aug 27 2020
Aug 21 2020
It has improved a bit
2.91.0 Alpha, branch: master, commit date: 2020-08-20 18:28, hash: rBce0bcd5fbf40
Aug 14 2020
Aug 5 2020
Aug 4 2020
Jul 29 2020
Jul 28 2020
Jul 25 2020
Jul 23 2020
Seems like it is animation nodes. How do I proceed now - open a ticket on their tracker?
Jul 22 2020
You are right, it does not crash after resetting to defaults. Does this mean that there is a setting that is causing the crash so I should investigate further or is it old/incompatible preference data that just needed to be deleted?
Jul 21 2020
Jul 15 2020
Yes, the file is just for convenience.
Thanks, done: https://developer.blender.org/T78958
The copying crash is solved (version: 2.90.0 Alpha, branch: master, commit date: 2020-07-15 09:06, hash: rBe8b26a05018b), but the other isn't. It seems to crash more reliably with:
- shift-clicking the material override icon of a linked material in the material properties editor
- click the icon again (to make fully local)
- click the icon again (to make fully local)
Should I file a separate report or does this belong to "known issue"?