Hi Elisa, thanks for the suggestion. I see how the lack of progress reporting in the layer import feature can be confusing, this is certainly something we could improve.
Regarding the screen grabbing part, I assume this refers to how the camera layer determines the output region for video export. This is expected, including the need to specifically select the camera layer for import in addition to the other layers if desired, even if it might seem a little unexpected at first. If you need to import both a bitmap/vector layer and the associated camera layer at once, you can use Ctrl+Click to select both of them at the same time, and once you start the import they will both be imported in one operation.
What I don’t quite understand is the part about the debris from the edit process as well as the crash. Can you clarify what you mean by “debris from the edit process” and under which circumstances it is included in the playback? And can you please add some step-by-step instructions on how to reproduce the crash you mentioned, as well as the version of Pencil2D and the operating system that you are using (from Help→About in the main menu)?
Sorry for the delay, I haven’t been entirely on top of my forum notifications lately. First of all, you need to understand that Pencil2D doesn’t really have an dedicated internal player at all. There’s just the canvas that you use for editing and then the playback is sort of tacked on to it. So when you play your animation in Pencil2D, no files are generated, all it does is to automatically increase the current frame counter by one, wait for 1/fps seconds, repeat until the end of the playback range is reached and occasionally skip a frame if the playback falls behind. Some parts of the program like onion skins behave differently when playback is active, but again, nothing is being generated specifically for playback, it’s just slight differences in behaviour.
Accordingly, when you export your animation to a GIF or MP4 file, that file is generated not from some intermediate playback files (because there are none) but directly from the original frame data.
I’m glad you were able to find a workaround for the debris issue, but I’d still appreciate if you could describe that issue in more detail so we can fix it properly. Saving and reopening the project should not be necessary. This goes for the crash mentioned in your original post as well. A crash is a pretty severe issue, and I’d be grateful if you could share the exact steps that lead to it as well as your Pencil2D version and operating system so we can properly fix it.
I’ve now done some more research and as a result I cam now define the problem much more precisely.
If I have a project called Jim-5.pclx and I load layers into it using the import layer option. This allows me to define and load the layers. If I then save the project as Jim-5T.pclx. then leave Pencil2D, restart Pencil2D and then open Jim-5T.pclx I get a file that doesn’t cause a Pencil2D crash. I’m using the T in the filename to indicate a temporary file.
But if I attempt to proceed directly from the import to any other operation, say selection of another layer, or moving the frame pointer by scrubbing the Timeline, then Pencil2D will crash.
When the user starts Pencil2D and opens a project file, this housekeeping is automatically triggered as part of the project opening process.
If I make cup of Tea, drink it and then attempt to proceed to select another layer etc, then Pencil2D doesn’t crash. The conclusion must be that Pencil2D takes time to do housekeeping tasks. An indication of this would be very helpful.
You can even open the project, straight after saving it, without restarting Pencil2D and no crash occurs and the layer I was loading during these tests was 3 frames of 35 kbytes per frame.
I had to experiment a little, but I’ve now figured out how to reproduce the crash. I still need to investigate exactly why it happens and how to fix it, but now that I can reproduce the crash I have something to work with! Thanks for taking the time to narrow it down.
I’ve been having problems with debris generated during editing being displayed when using the internal player and being exported into .mp4 and .gif files.
I’ve used the work around that Animation Elisa has suggested, namely saving the files and then reloading them and have found that this solves the debris problem too.
My interpretation of this is that Pencil2D is processing the frame files in the Data directory, the Pallet file and the main.xml files correctly. But that errors occur when generating the modifications to the on screen images, but when this process startsfrom scratch don’t occur. This inicates to me that some of the internal data is corrupted in these situations.
What about a command that resets the project, without wiping the projects files from the internal memory within Pencil2d?
I’ve made some changes which I believe will fix the crash you described. Please give it a try: 64-bit Windows / 32-bit Windows / macOS / Linux. Please note that these builds are based on the experimental nightly builds, so compared to 0.6.6 there are also many other changes which have not been tested as extensively yet.
The crash was caused by some internal data corruption and on top of that I found an issue where the colours of imported vector layers would not be handled correctly, which I’ve also fixed. It is possible that this also resolves the debris issue that you’re seeing. If it does not resolve the debris issue, please describe in more detail what that debris you’re seeing looks like, ideally with a screenshot. So far I still don’t have a good idea of what exactly you two mean by debris, which makes it difficult to investigate.
This is a lot easier said than done. You might as well ask for a clockwork mechanism that is able to repair itself when one of its own gears comes loose.
The recovery mechanism you are referring to recovers data from temporary storage after Pencil2D has crashed and its internal memory has been lost. StopMotionVector was asking for a recovery mechanism that retains internal memory.
I suppose this might be a misunderstanding because we have different ideas of what “internal memory” means. When I mention internal memory, I am referring to the primary storage (aka RAM) of your computer. However, to reduce memory consumption, Pencil2D will also put some data in a temporary location on the secondary storage (i.e. the hard disk or SSD) of your computer in addition to primary storage. The recovery process you mentioned only recovers data from that temporary location in secondary storage. However, recovering data from primary storage (= internal memory) when it becomes corrupted, that’s the difficult part, because that data is extremely closely tied to the inner workings of the software and corruption can easily degrade the stability of the program. In fact, it was precisely this kind of corruption that caused the crash you experienced.