Looking at this image
https://github.com/nophead/NopSCADlib/blob/master/libtest.png
It looks like the large box at the back is wider at the back than the
front. If I measure it on screen it is actually narrower at the back as it
should be. However all the lines seem to be converging towards a point
below and to the right of the camera.
That image is produced on a very large canvas with the command line:
openscad --colorscheme=Nature --projection=p --imgsize=4096,4096
--camera=0,0,0,50,0,340,500 --autocenter --viewall -o libtest.png
libtest.scad
If I view it in the GUI from the same angle I get this:
[image: image.png]
This seems to be wrong the opposite way. I.e.it seem to diverge
towards the front. So it seems the canvas size affects the perspective but
neither seem quite right. Obviously things nearer the camera should be
bigger, and they are, but they should look to be the same size if the
perspective is correct.
Actually I think it is related to how big it is shown on the screen.
Changing the zoom level of the browser changes it from looking too big at
the back to too big at the front with the same image. I think it just means
we need a field of view parameter which is set relative to how far we are
from our screens and how big the image is.
On Fri, 24 Apr 2020 at 09:24, nop head nop.head@gmail.com wrote:
Looking at this image
https://github.com/nophead/NopSCADlib/blob/master/libtest.png
It looks like the large box at the back is wider at the back than the
front. If I measure it on screen it is actually narrower at the back as it
should be. However all the lines seem to be converging towards a point
below and to the right of the camera.
That image is produced on a very large canvas with the command line:
openscad --colorscheme=Nature --projection=p --imgsize=4096,4096
--camera=0,0,0,50,0,340,500 --autocenter --viewall -o libtest.png
libtest.scad
If I view it in the GUI from the same angle I get this:
[image: image.png]
This seems to be wrong the opposite way. I.e.it seem to diverge
towards the front. So it seems the canvas size affects the perspective but
neither seem quite right. Obviously things nearer the camera should be
bigger, and they are, but they should look to be the same size if the
perspective is correct.
Perspective shouldn't change as you zoom, but it will be affected by moving
the camera closer or further from the subject. Changing the distance to the
subject and the zoom level simultaneously is how the dolly zoom effect
(made famous by Hitchcock's Vertigo) effect is achieved, in which the
subject's apparent size in the frame remains constant, but the background
gets bigger/smaller.
Openscad's zoom function doesn't appear to be a true zoom, though. Rather,
the "camera" is being moved closer/further from the subject to make things
bigger or smaller. In orthographic view, these are equivalent, but in
perspective view, they are not.
In order to control how renders appear, we need some way to quantify the
(angular) field of view being used. This appears to be a constant value for
the vertical axis of the preview pane, while the horizontal field of view
varies as the aspect ratio changes.
Incidentally, I've been thinking about bringing up this subject because
I've beed creating a lot of renders from Openscad, and I've been
considering trying to create identical images via render and photograph,
but doing so would require determining the equivalent focal length of the
renderer's virtual camera.
On April 24, 2020 at 02:38:12, nop head (nop.head@gmail.com) wrote:
Actually I think it is related to how big it is shown on the screen.
Changing the zoom level of the browser changes it from looking too big at
the back to too big at the front with the same image. I think it just means
we need a field of view parameter which is set relative to how far we are
from our screens and how big the image is.
On Fri, 24 Apr 2020 at 09:24, nop head nop.head@gmail.com wrote:
Looking at this image
https://github.com/nophead/NopSCADlib/blob/master/libtest.png
It looks like the large box at the back is wider at the back than the
front. If I measure it on screen it is actually narrower at the back as it
should be. However all the lines seem to be converging towards a point
below and to the right of the camera.
That image is produced on a very large canvas with the command line:
openscad --colorscheme=Nature --projection=p --imgsize=4096,4096
--camera=0,0,0,50,0,340,500 --autocenter --viewall -o libtest.png
libtest.scad
If I view it in the GUI from the same angle I get this:
[image: image.png]
This seems to be wrong the opposite way. I.e.it seem to diverge
towards the front. So it seems the canvas size affects the perspective but
neither seem quite right. Obviously things nearer the camera should be
bigger, and they are, but they should look to be the same size if the
perspective is correct.
OpenSCAD https://www.openscad.org/version 2019.12.20 (git 2a943a57)For
MacOS X.
This piece of code is used, as is, in another design, with different
dimensions and it works well. I've treated to change the dimensions on
this one but seems that here do not affect the result.
This is the result when I press F5 (Preview)
And this is the result when I press F6 (Render)
The blue walls on the left and Right hand of the inner of the cube
disappear.
Next is the code:
module MainBox(Sunshade = false){ union(){ difference(){
union(){ difference(){ //cube to be
emptied by another little one cuboid([BoxX, BoxY, BoxZ],
fillet = 2, edges = EDGE_TOP_BK + EDGE_TOP_FR +
EDGE_TOP_RT + EDGE_TOP_LF+
EDGE_FR_LF + EDGE_FR_RT + EDGE_BK_LF + EDGE_BK_RT,
center = false, $fn=36); //inner
cube to subsctract translate([wall, wall, -mgn])
cube([BoxX - wall + mgn, BoxY-(wall-mgn)-(wall-mgn),
BoxZ - wall + dblmgn]); } // prism to hold the
screw of the cover. translate([BoxX - wall - wall, BoxY/2,
BoxZ - wall + dblmgn]) rotate([180, 0, 0]) prismoid(size1
= [5, 8], size2 = [0, 8], shift=[2.5, 0], h = 5);
//THIS TWO FIGURES ARE WHO CAUSES THE PROBLEM
// Right hand PCB separator color("blue", 1)
translate([wall, BoxY - wall - 1.90, BoxZ - wall - PCB_Gap
// Sunshade for the leds if (Sunshade){
translate([0, 50, BoxZ+30]) rotate([-70,
0, 0]) cuboid([BoxX, BoxY-31, 4],
fillet = 2, edges = EDGE_TOP_BK + EDGE_TOP_FR + EDGE_TOP_RT +
EDGE_TOP_LF+ EDGE_FR_LF +
EDGE_FR_RT + EDGE_BK_LF + EDGE_BK_RT, center =
false, $fn=36); } } //holes on the top
union(){ //switch hole translate([BoxX
Could you attach the code or upload it somewhere, see below
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Juan C.Cilleruelo
Sent: Wed, 27 May 2020 16:50
To: discuss@lists.openscad.org
Subject: [OpenSCAD] Objects that while rendering disappears.
https://www.openscad.org/ OpenSCAD version 2019.12.20 (git 2a943a57) For MacOS X.
This piece of code is used, as is, in another design, with different dimensions and it works well.
I've treated to change the dimensions on this one but seems that here do not affect the result.
This is the result when I press F5 (Preview)
And this is the result when I press F6 (Render)
The blue walls on the left and Right hand of the inner of the cube disappear.
Next is the code:
module MainBox(Sunshade = false){ union(){ difference(){ union(){
difference(){ //cube to be emptied by another little one
cuboid([BoxX, BoxY, BoxZ], fillet = 2, edges = EDGE_TOP_BK + EDGE_TOP_FR +
EDGE_TOP_RT + EDGE_TOP_LF+ EDGE_FR_LF + EDGE_FR_RT +
EDGE_BK_LF + EDGE_BK_RT, center = false, $fn=36); //inner
cube to subsctract translate([wall, wall, -mgn]) cube([BoxX - wall +
mgn, BoxY-(wall-mgn)-(wall-mgn), BoxZ - wall + dblmgn]); } // prism to hold
the screw of the cover. translate([BoxX - wall - wall, BoxY/2, BoxZ - wall + dblmgn])
rotate([180, 0, 0]) prismoid(size1 = [5, 8], size2 = [0, 8], shift=[2.5, 0], h = 5);
//THIS TWO FIGURES ARE WHO CAUSES THE PROBLEM
// Right hand PCB separator color("blue", 1) translate([wall,
BoxY - wall - 1.90, BoxZ - wall - PCB_Gap + mgn]) cube([PCB_X, 2, PCB_Gap]); // Left
hand PCB separator color("blue", 1) translate([wall, wall-mgn ,
BoxZ - wall - PCB_Gap + mgn]) cube([PCB_X, 2, PCB_Gap]);
// Sunshade for the leds if (Sunshade){ translate([0, 50,
BoxZ+30]) rotate([-70, 0, 0]) cuboid([BoxX, BoxY-31, 4],
fillet = 2, edges = EDGE_TOP_BK + EDGE_TOP_FR + EDGE_TOP_RT + EDGE_TOP_LF+
EDGE_FR_LF + EDGE_FR_RT + EDGE_BK_LF + EDGE_BK_RT, center = false,
$fn=36); } } //holes on the top union(){
//switch hole translate([BoxX - 25, BoxY-56-wall, BoxZ - wall-10]) rotate([90, 0 ,0])
cylinder(h = 8, d = 7); // embedded anagram color("Yellow", 1.0)
translate([BoxX - 40, BoxY-55-wall, BoxZ - mgn-1]) rotate([0, 0, 45]) logoSenCille();
//rail hole right translate([wall, BoxY-wall, 2]) cube([BoxX - wall + mgn, 1.7, 2.7]);
//rail hole left translate([wall, wall-1.7, 2]) cube([BoxX - wall + mgn, 1.7, 2.7]);
// Front rail color("Gray", 1) translate([wall-1.7, wall-1.7, 2])
cube([1.7, BoxY-wall-wall + 1.7 + 1.7, 2.7]); //Balls of Table tennis
translate([LED_X_RED + wall, LED_Y + wall, PCB_Gap+19.6]) sphere(d = 39.5, $fn = 100);
translate([LED_X_YELLOW+ wall, LED_Y + wall, PCB_Gap+19.6]) sphere(d = 39.5, $fn = 100);
translate([LED_X_GREEN + wall, LED_Y + wall, PCB_Gap+19.6]) sphere(d = 39.5, $fn = 100);
// Right hand PCB separator color("blue", 1) translate([wall, BoxY - wall -
1.90, BoxZ - wall - PCB_Gap + mgn]) cube([PCB_X, 2, PCB_Gap]); // Left hand PCB
separator color("blue", 1) translate([wall, wall-mgn , BoxZ - wall
--
This email has been checked for viruses by AVG.
https://www.avg.com