Transparency on png export of animation

[imported_peterigz]

So, I created a version that makes a log file as I mentioned. I also made an effects file just to test with so I can compare results a bit more easily. Just open the effects file and render as full colour, then attach the animlog.txt file that will be dumped into the installation folder, to a post here or just email to me if that’s easier.

TimelineFX is here: http://www.rigzsoft.co.uk/files/TestFiles/TimelineFXEditorSetup.exe

and here’s the effects file: http://www.rigzsoft.co.uk/files/TestFiles/angletest.eff

Let’s see if it gives us some clues 🙂

[aonyn]

Hi Pete,

Here is the log and the resulting png file.
When I looked through the log myself, the top left pixel colour return on the 1st loop was 0, and all subsequent loops were -16777216, which looks like suspicious data (although of course I don’t know without looking at what the code is doing internally), it just looks odd, especially the negative.

The good news is that all the subsequent values were the same, so here is a sign of consistency with this bug.

I also ran the same test with one of my eff files, and checked that output.
It was identical, same value.

I think this is good news.
In my experience, once I can find consistency, the bug is soon squashed.

Thanks again,
Dave

[imported_peterigz]

Thanks for that. the negative number basically means the rgba value is 0,0,0,255, when it should be all 0’s. So at least it narrows things down more – basically it’s either not clearing the backbuffer with alpha, or grabpixmap is not working properly, but I think that it’s not clearing with alpha.

[imported_peterigz]

Hey, I just recreated this problem on my PC completely by accident lol. Windows booted up and the desktop manager crashed (the aero part of windows) and now the same happens on mine. So it might just be a little easier to fix now. I’ve gotta go meet someone down the pub but hopefully can have a proper look when I get back.

[GfK]

Pete

I remember something from ages ago about GrabPixmap not working properly on certain hardware and the general consensus was that use of it should be avoided wherever possible. I remember because I rewrote a large portion of code for Magicville because of it. I ended up doing all my drawing directly to pixmaps rather than drawing everything to the backbuffer then using GrabPixmap.

I remember there being something about calling GrabPixmap twice would work around it (possibly?) but I can’t verify whether that actually works or not as it worked on my hardware anyway.

[imported_peterigz]

Ok, cheers GfK, I’ll look into that.

[aonyn]

Hi Pete,

Sorry to here you are having the problem now, and were not before, but I guess that is good news for me.
Now that you can reproduce the bug, it should be possible to track down the culprit.

@ GfK – Thanks for the input to possibly assist Pete in solving the problem I am having.

regards,
Dave Marconi

[imported_peterigz]

ok, fingers crossed. This works on my vista machine so let’s hope it works on yours now. I could easily recreate it on mine by ending the desktop window manager process. The problem seemed to be something to do with the effect preview in the main window interfering with the animation window preview. Anyway download is here: http://www.rigzsoft.co.uk/files/TestFiles/TimelineFXEditorSetup.exe

It still creates a log file, so let me know if it works and and I can switch of the logging and make it an official release (i hope!)

[aonyn]

Hi Pete,

This is better, although I am sorry to say, still needs an adjustment somewhere.

Here is what happens. (and I reproduced this exactly several times, including with some of your sample effects.)

On first attempt to export animation as png full color and transparency, the alpha is now correct on all subsequent frames, only now the first frame has 100% alpha and no image.

If on your 1st attempt you render without transparency, then re-render with transparency the second time, it seems to work correctly.
This was consistent with several tests on several eff files.

So the output is usable now, with a workaround procedure, just a bit of adjustment and it will be perfect.

Thanks again,
Dave

[imported_peterigz]

Ok thanks. It looks like we’re almost there then, I could probably render a dummy frame first before doing the full animation and hopefully that might fix the problem for good then 🙂

[imported_peterigz]

Another update here: http://www.rigzsoft.co.uk/files/TestFiles/TimelineFXEditorSetup.exe

This now renders a few dummy frames first before rendering the final animation, it also does a couple more things to hopefully make things more reliable.

[aonyn]

Hi Pete,

This seems to be working ok.
I tested it with a few effects, the same ones as the previous build, and it worked as expected every time.

If I come across anything that breaks it, I will of course let you know, but I think this build is safe to release.

Thanks for all your help.

regards,
Dave

[imported_peterigz]

That’s good to hear 🙂 We got there in the end!

[Author]

Posts