 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmail com> wrote:
> blah blah blah
> -tgq
And don't forget -uv on the command line.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <aut### [at] runevisioncom> wrote:
> "SharkD" wrote:
> > Anyway, the above code
> > works (as far as I can tell); I super-imposed it over a rotated version of
> > the
> > "top side oblique" rendering I completed earlier, and everything lines up
> > perfectly.
>
> Is it intentional that the side facing the camera is a slight rhombe and not
> a perfect square? You'll see it if you render with a for example 640x480
> resolution. If this is what you call the "jagginess due to roundoff errors"
> then in my experience, these errors are far too large to just be rounding
> errors.
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".
> The camera below will give an identical image, exact that you get a perfect
> square (no "jagginess"):
That does work a lot better. Could you try a shot at this image?
http://img139.imageshack.us/img139/7937/obliquetoprotatedgm6.png
Also, you describe how you derived the float values?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> "Rune" <aut### [at] runevisioncom> wrote:
> > "SharkD" wrote:
> > > Anyway, the above code
> > > works (as far as I can tell); I super-imposed it over a rotated version of
> > > the
> > > "top side oblique" rendering I completed earlier, and everything lines up
> > > perfectly.
> >
> > Is it intentional that the side facing the camera is a slight rhombe and not
> > a perfect square? You'll see it if you render with a for example 640x480
> > resolution. If this is what you call the "jagginess due to roundoff errors"
> > then in my experience, these errors are far too large to just be rounding
> > errors.
>
> 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".
>
> > The camera below will give an identical image, exact that you get a perfect
> > square (no "jagginess"):
>
> That does work a lot better. Could you try a shot at this image?
>
> http://img139.imageshack.us/img139/7937/obliquetoprotatedgm6.png
>
> Also, you describe how you derived the float values?
0.7 ~ 0.707 ~ 1/sqrt(2)
use 1/sqrt(2) for the exact value and everything should be correct and similar
to the one I posted as well.
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
