"SharkD" wrote:
> Well, the face of the cube only diverges from a perfect square by one 
> pixel i
> each direction at 640x480 resolution. Yes, I would call that "jagginess".

That's only because the cube only fills a small part of the image. When you 
put in the grid like in your image below, it becomes clear that the lines 
are not horizontal and vertical at all, but diverges many pixels from the 
top of the image to the bottom. That's not just rounding errors; POV-Ray is 
far more precise than that.

> That does work a lot better. Could you try a shot at this image?
>
> http://img139.imageshack.us/img139/7937/obliquetoprotatedgm6.png

Sure:

#declare CameraDistance = 40;
camera {
   #local CameraArea = 3.03; // arbritary
   #local CameraSkewed = 1/sqrt(2);
   #local AspectRatio = image_width/image_height;
   orthographic
   location <-CameraSkewed,1,-CameraSkewed>*CameraDistance
   direction <CameraSkewed,-1,CameraSkewed>
   up x*CameraArea
   right -z*CameraArea*AspectRatio
}

background {color <0.5,0.7,1.0>}
global_settings {assumed_gamma 1}

light_source {
   <0,0,-100> color rgb 1
   rotate <60,30,0>
   parallel
   shadowless
}

box {-0.5,0.5 pigment {rgb 1}}

#declare Arrow = union {
   cylinder {-x, x, 0.01}
   cone {x, 0.05, 1.1*x, 0}
   scale <1.35,1,1>
}
object {Arrow pigment {red 1}}
object {Arrow rotate 90*z pigment {green 1}}
object {Arrow rotate -90*y pigment {blue 1}}

plane {y, 0
   pigment {
      boxed translate x+z warp {repeat x*2} warp {repeat z*2}
      scale 0.05
      color_map {[0.19, rgb 0.35][0.19, transmit 1]}
   }
}


> Also, you describe how you derived the float values?

I changed the 0.7 to 1/sqrt(2) like Trevor G Quayle wrote. The CameraArea of 
3.03 is arbritary to match your images.

Rune
-- 
http://runevision.com

Post a reply to this message

"Rune" <aut### [at] runevisioncom> wrote:
> "SharkD" wrote:
> > Well, the face of the cube only diverges from a perfect square by one
> > pixel i
> > each direction at 640x480 resolution. Yes, I would call that "jagginess".
>
> That's only because the cube only fills a small part of the image. When you
> put in the grid like in your image below, it becomes clear that the lines
> are not horizontal and vertical at all, but diverges many pixels from the
> top of the image to the bottom. That's not just rounding errors; POV-Ray is
> far more precise than that.
>
> > That does work a lot better. Could you try a shot at this image?
> >
> > http://img139.imageshack.us/img139/7937/obliquetoprotatedgm6.png
>
> Sure:
>
> #declare CameraDistance = 40;
> camera {
>    #local CameraArea = 3.03; // arbritary
>    #local CameraSkewed = 1/sqrt(2);
>    #local AspectRatio = image_width/image_height;
>    orthographic
>    location <-CameraSkewed,1,-CameraSkewed>*CameraDistance
>    direction <CameraSkewed,-1,CameraSkewed>
>    up x*CameraArea
>    right -z*CameraArea*AspectRatio
> }
>
> background {color <0.5,0.7,1.0>}
> global_settings {assumed_gamma 1}
>
> light_source {
>    <0,0,-100> color rgb 1
>    rotate <60,30,0>
>    parallel
>    shadowless
> }
>
> box {-0.5,0.5 pigment {rgb 1}}
>
> #declare Arrow = union {
>    cylinder {-x, x, 0.01}
>    cone {x, 0.05, 1.1*x, 0}
>    scale <1.35,1,1>
> }
> object {Arrow pigment {red 1}}
> object {Arrow rotate 90*z pigment {green 1}}
> object {Arrow rotate -90*y pigment {blue 1}}
>
> plane {y, 0
>    pigment {
>       boxed translate x+z warp {repeat x*2} warp {repeat z*2}
>       scale 0.05
>       color_map {[0.19, rgb 0.35][0.19, transmit 1]}
>    }
> }
>
>
> > Also, you describe how you derived the float values?
>
> I changed the 0.7 to 1/sqrt(2) like Trevor G Quayle wrote. The CameraArea of
> 3.03 is arbritary to match your images.
>
> Rune
> --
> http://runevision.com

Here's my version (a little more exact).

Side view:

camera
{
 #local CameraArea = 5/2;
 #local CameraDistance = 40;
 #local SkewAdjust = (tand(45)/sind(45))/(tand(30)/sind(30));
 #local CameraSkewed = 1/sqrt(2);
 #local CameraPosition =
vnormalize(<-CameraSkewed,CameraSkewed,-1>)*CameraDistance;
 #local AspectRatio = image_width/image_height;
 orthographic
 location CameraPosition
 direction -CameraPosition
 up y*CameraArea*SkewAdjust
 right x*CameraArea*SkewAdjust*AspectRatio
}

Top view:

camera
{
 #local CameraArea = 5/2;
 #local CameraDistance = 40;
 #local SkewAdjust = (tand(45)/sind(45))/(tand(30)/sind(30));
 #local CameraSkewed = 1/sqrt(2);
 #local CameraPosition =
vnormalize(<-CameraSkewed,1,-CameraSkewed>)*CameraDistance;
 #local AspectRatio = image_width/image_height;
 orthographic
 location CameraPosition
 direction -CameraPosition
 up vnormalize(x+z)*CameraArea*SkewAdjust
 right vnormalize(x-z)*CameraArea*SkewAdjust*AspectRatio
}

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> I put together a little diagram that I hope can explain the basic geometry
> behind the numbers  (thi shows cavalier projection, for cabinet, the depth
> becomes 1/2 and 1/sqrt(2) becomes 1/2sqrt(2))
> http://i69.photobucket.com/albums/i52/barberofcivil/Oblique.jpg
>
> -tgq

Is there any way you could upload the image to the cavalier perspective article
on Wikipedia? Some suggestions before (that is, if) you do:
1) Split the image into two separate images.
2) Remove the label "Oblique Projection", as it's not necessary.
3) Rename "View plane" to "Projection plane".
4) Show the ray originating behind the projection plane.
5) Use the SVG format instead of JPG if at all possible.
6) Make another set of images for cabinet perspective.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > I put together a little diagram that I hope can explain the basic geometry
> > behind the numbers  (thi shows cavalier projection, for cabinet, the depth
> > becomes 1/2 and 1/sqrt(2) becomes 1/2sqrt(2))
> > http://i69.photobucket.com/albums/i52/barberofcivil/Oblique.jpg
> >
> > -tgq
>
> Is there any way you could upload the image to the cavalier perspective article
> on Wikipedia? Some suggestions before (that is, if) you do:
> 1) Split the image into two separate images.
> 2) Remove the label "Oblique Projection", as it's not necessary.
> 3) Rename "View plane" to "Projection plane".
> 4) Show the ray originating behind the projection plane.
> 5) Use the SVG format instead of JPG if at all possible.
> 6) Make another set of images for cabinet perspective.

One more thought: the diagram would need to be generalized for all skew angles,
not just 45 degrees. So, it might not be worth it.

Post a reply to this message

"SharkD" wrote:
> Here's my version (a little more exact).

Looks fine, but I'm curious how it is more exact exactly. I mean, sure, 
instead of a CameraArea of 3.03 you effectively use one of

5/2*(tand(45)/sind(45))/(tand(30)/sind(30)) which evaluates to 3.0618621785

But that's just the "zoom" of the image (or the orthographic equivalent of 
zoom) and has nothing to do with the skewing. Your variable name SkewAdjust 
seem confusing that way, since it sounds like it adjusts the skewing, while 
it just adjusts the size of the visible area. The projection itself is 
exactly the same as the one I posted and which several others suggested all 
along.

Rune
-- 
http://runevision.com

Post a reply to this message

"Rune" <aut### [at] runevisioncom> wrote:
> "SharkD" wrote:
> > Here's my version (a little more exact).
>
> Looks fine, but I'm curious how it is more exact exactly. I mean, sure,
> instead of a CameraArea of 3.03 you effectively use one of
>
> 5/2*(tand(45)/sind(45))/(tand(30)/sind(30)) which evaluates to 3.0618621785
>
> But that's just the "zoom" of the image (or the orthographic equivalent of
> zoom) and has nothing to do with the skewing. Your variable name SkewAdjust
> seem confusing that way, since it sounds like it adjusts the skewing, while
> it just adjusts the size of the visible area. The projection itself is
> exactly the same as the one I posted and which several others suggested all
> along.
>
> Rune
> --
> http://runevision.com

More exact because it's less arbitrary?

Here, I created a diagram to show you the derivation of the formula:

http://img263.imageshack.us/img263/8406/cubescomparepe2.png

On the left you see an isometric rendering of a cube. On the right you see the
same rendering, except that the projection plane is skewed so that it becomes
oblique instead of isometric. Now, one result of skewing the projection plane
is that the unit scale in the resulting image is different than in the
original. To fix this, one must simply scale the oblique image by an amount
equal to the ratio of the lengths of some vector that exists in both images,
but is scaled in one.

In this case I wanted to scale the image on the right so that segment c in the
right image is equal in length to segment a in the left image. The formula I
provided does just that.

Here's another way of obtaining the same result, except using a different
formula (one based on the pythagorean theorem):

sqrt(1^2 + tan(45)^2) / sqrt(1^2 + tan(30)^2)

You then multiply this by 5/2 to get the correct projection plane dimensions.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Rune" <aut### [at] runevisioncom> wrote:
> > "SharkD" wrote:
> > > Here's my version (a little more exact).
> >
> > Looks fine, but I'm curious how it is more exact exactly. I mean, sure,
> > instead of a CameraArea of 3.03 you effectively use one of
> >
> > 5/2*(tand(45)/sind(45))/(tand(30)/sind(30)) which evaluates to 3.0618621785
> >
> > But that's just the "zoom" of the image (or the orthographic equivalent of
> > zoom) and has nothing to do with the skewing. Your variable name SkewAdjust
> > seem confusing that way, since it sounds like it adjusts the skewing, while
> > it just adjusts the size of the visible area. The projection itself is
> > exactly the same as the one I posted and which several others suggested all
> > along.
> >
> > Rune
> > --
> > http://runevision.com
>
> More exact because it's less arbitrary?
>
> Here, I created a diagram to show you the derivation of the formula:
>
> http://img263.imageshack.us/img263/8406/cubescomparepe2.png
>
> On the left you see an isometric rendering of a cube. On the right you see the
> same rendering, except that the projection plane is skewed so that it becomes
> oblique instead of isometric. Now, one result of skewing the projection plane
> is that the unit scale in the resulting image is different than in the
> original. To fix this, one must simply scale the oblique image by an amount
> equal to the ratio of the lengths of some vector that exists in both images,
> but is scaled in one.
>
> In this case I wanted to scale the image on the right so that segment c in the
> right image is equal in length to segment a in the left image. The formula I
> provided does just that.
>
> Here's another way of obtaining the same result, except using a different
> formula (one based on the pythagorean theorem):
>
> sqrt(1^2 + tan(45)^2) / sqrt(1^2 + tan(30)^2)
>
> You then multiply this by 5/2 to get the correct projection plane dimensions.

I see what you are trying to do, but actually to be equivilant, segment d should
equal segment b.  You are assuming that a is shown as the correct length, but in
the iso projection, a is shortened from what it should be (ie, not 1:1), whereas
segment b is already the correct length as it has no distortion from the
projection.  This means that the same horizontal camera sizeworks for both

-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> I see what you are trying to do, but actually to be equivilant, segment d should
> equal segment b.  You are assuming that a is shown as the correct length, but in
> the iso projection, a is shortened from what it should be (ie, not 1:1), whereas
> segment b is already the correct length as it has no distortion from the
> projection.  This means that the same horizontal camera sizeworks for both
>
> -tgq

No. In the images, segment d *does* equal segment b. The isometric image uses
the correct unit scale along all three axes (hence the term "isometric", "equal
measure"). The distortion caused by the oblique projection causes the vertical
(in this case) axis to become stretched.

Post a reply to this message

Also, 1/sqrt(2) is equal to sind(45), which is a ratio already mentioned by
someone in a previous post in this thread (go figure). I'm using that in all my
scenes from now on.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > I see what you are trying to do, but actually to be equivilant, segment d should
> > equal segment b.  You are assuming that a is shown as the correct length, but in
> > the iso projection, a is shortened from what it should be (ie, not 1:1), whereas
> > segment b is already the correct length as it has no distortion from the
> > projection.  This means that the same horizontal camera sizeworks for both
> >
> > -tgq
>
> No. In the images, segment d *does* equal segment b. The isometric image uses
> the correct unit scale along all three axes (hence the term "isometric", "equal
> measure"). The distortion caused by the oblique projection causes the vertical
> (in this case) axis to become stretched.

I take that back. You're right. The scaling is not necessary.

Post a reply to this message