Size of intermediate png files (4096x4096) too large?

[martinbudden]

The build system generates intermediate png files with dimensions of 4096x4096. These are then resized down to an image with a maximum dimension of 1024 (plus a tiny image). This is presumably to anti-alias the image.

As an experiment I've changed this to 2048x2048 and have not noticed any deterioration in the quality of the final assembly files.

The motivation for this was primarily for a faster build, but it might also help with issue #137.

[nophead]

Yes it is for anti aliasing taking into account that OpenScad's ---viewall doesn't fill the screen, so about half the pixels are trimmed off leaving around 2000 to be resampled to 1000.

I don't think it will affect the speed much at all. The time to actually draw the pixels is normally a small fraction of a second as the GUI does it every time you interact with the mouse.

Do you see any difference in build times?

[nophead]

Regarding speed, have you tried the new stl() / dxf() child method that allows views.py to use the STL and DXFs instead of drawing them with CSG. That gives a big speed up for my projects.

[martinbudden]

I hadn't noticed the addition of the child handling by stl() and dxf(). I've just looked back through the commits and found it. It looks good - I'll give it a go.

As for build time differences using 2048 rather than 4096, I haven't actually done any measurements. I'll try and make time for that at some point.

[martinbudden]

I've now done some benchmarks on this.

There seems to be about a 10% speed improvement using 2048x2048. I don't think this is from the rendering, I actually think it is from the image comparison. But an improvement is an improvement.

If you are concerned about the image quality, have a look at my MaybeCube and BabyCube images - they were all produced at 2048x2048.

--imgsize=4096,4096

  52.9   2.7 tests/BackFace.scad
  68.7   4.7 tests/Base.scad
 165.5  13.1 tests/Main.scad
 287.1  20.5 TOTAL

  52.7   3.1 tests/BackFace.scad
  67.3   5.8 tests/Base.scad
 165.1  16.4 tests/Main.scad
 285.1  25.3 TOTAL

--imgsize=2048,2048

  49.6  -3.2 tests/BackFace.scad
  61.4  -7.2 tests/Base.scad
 148.7 -16.9 tests/Main.scad
 259.8 -27.3 TOTAL

  49.3  -3.4 tests/BackFace.scad
  60.9  -6.3 tests/Base.scad
 148.5 -16.7 tests/Main.scad
 258.8 -26.4 TOTAL

[nophead]

How can it affect the image comparison when it is the downsized images that are compared, not the larger ones output by OpenSCAD

[nophead]

I only got a 6% speed improvement in the time taken by OpenSCAD but the images of fine threads don't look as good in the second image.

As I said earlier for proper anti-aliasing you want at least twice as many pixels in each dimension.

[martinbudden]

Agreed, the second threads in the second image are noticeably worse. I think you can close this issue.

(And yes, I'd overlooked that it was the downsized images that were compared.)

[nophead]

The first pass of image magick that crops and downsizes probably takes a little longer but is only around a second anyway. None of the magick time is included in the times reported. They are just the OpenSCAD times.

I just noticed the edge of the ring nuts isn't anti-aliased in the second image and still locks jagged but it is is smooth in the first image. That is a better illustration.

Worst case, with 2048 the resampling will be about 1:1 because a lot gets cropped because OpenSCAD's Viewall fits the diagonal of the bounding cube to the vertical size of the viewport to cope with the worst case orientation of the object.

So a cube orientated with its diagonal vertical will fill the view but assemblies that are wider than they are tall orientated normally don't.

$vpr = [45, 45, 0];
cube(10);