PNG Bug

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

PNG Bug

Leemon Baird
Hi,

I've recently started using OpenSCAD and think it's great. There are some bugs related to saving animation PNG files, at least on the Mac, in both version 2010.05 and 2011.01.11.  It looks like this mailing list is the standard place to report bugs, so I will.

When it saves each PNG, it appears to randomly choose which of 3 images to save. It either saves an image of the entire graphics window with the 3D object, or it saves a smaller window that is the same width but 4 pixels smaller in height and with the object slightly smaller, or it saves a blank, solid yellow image.

The shrinking of the window is a problem for animations. There's a noticeable jump when it hits the smaller frames. The jump remains even if I use ImageMagic to stretch the small images by 4 pixels. That's because of the nonlinear way it rescales the object to fit the smaller window. Even orthogonal view doesn't help this. The problem remains, whether the editor and console are hidden or not. It remains whether the window is full screen or not. It remains whether fps is 1 or 1000 or 0.005.

The bug only appears on big scenes that are slow to render. When the scene is complex, and has one small part inside a render() command, it takes about 15 seconds per frame to display on the screen. During most of that time, the screen is yellow. Then it shows the large image for a second. Then it shows the small image for a fraction of a second. All 3 appear on the screen for each frame, but only 1 of the 3 is written to the PNG file. Which one it chooses seems to be nondeterministic. Though the slowest frames have the greatest probability of being blank or short.

I haven't found a workaround for this problem. It's preventing me from creating animations of my file. That's frustrating, especially when I can see the correct image on the screen for a second. But I don't really want to hit the screen capture button manually 500 times.

The other two bugs have easy workarounds. But they should probably be fixed, too. One is that the PNG files are given names that count from 1 to N, followed by 0.  It would be better if 0 came before 1 instead of coming after N.

The other is that it's hard to guess how many files it will create, and what range of values $t will get. For example, if you either set Steps to 3 or set it to 4, you'll get 4 files generated either way. When Steps=4, the time goes through {0, 1/4, 2/4, 3/4}.  When Steps=3, the time goes through {0, 1/3, 2/3, 1}.  My guess is that the code contains a FOR loop like this:

    for (time=0; time<1; time+=1/Steps)

But it should actually be:

    for (i=0; i<Steps+1; i++) {
        time = i/Steps;
        ...
    }

where that division has the correct types for whatever language OpenSCAD is written in.

That would make it predictable, and independent of roundoff error. And it would always render the last frame.

Those last two bugs are minor, but the first one is hard to work around. It would be great if it could be fixed.

Leemon