 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've tried using math here but it still doesn't work.
I may have my math wrong
//-----------------------------------//
// begin code
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}
//--------------------------------------------------------------------------
#include "colors.inc"
#include "textures.inc"
#include "glass.inc"
#include "metals.inc"
#include "golds.inc"
#include "stones.inc"
#include "woods.inc"
#include "shapes.inc"
#include "shapes2.inc"
#include "functions.inc"
#include "math.inc"
#include "transforms.inc"
//--------------------------------------------------------------------------
// camera
------------------------------------------------------------------
#declare Camera_0 = camera {perspective angle 75 // front
view
location <0.0 , 1.0 ,-3.0>
right x*image_width/image_height
look_at <0.0 , 1.0 , 0.0>}
#declare Camera_1 = camera {/*ultra_wide_angle*/ angle 90 // diagonal
view
location <2.0 , 2.5 ,-3.0>
right x*image_width/image_height
look_at <0.0 , 1.0 , 0.0>}
#declare Camera_2 = camera {/*ultra_wide_angle*/ angle 90 //right side
view
location <3.0 , 1.0 , 0.0>
right x*image_width/image_height
look_at <0.0 , 1.0 , 0.0>}
#declare Camera_3 = camera {/*ultra_wide_angle*/ angle 90 // top
view
location <0.0 , 3.0 ,-0.001>
right x*image_width/image_height
look_at <0.0 , 1.0 , 0.0>}
camera{Camera_0}
// sun
----------------------------------------------------------------------
light_source{< 3000,3000,-3000> color White}
// sky
----------------------------------------------------------------------
sky_sphere { pigment { gradient <0,1,0>
color_map { [0.00 rgb <0.6,0.7,1.0>]
[0.35 rgb <0.1,0.0,0.8>]
[0.65 rgb <0.1,0.0,0.8>]
[1.00 rgb <0.6,0.7,1.0>]
}
scale 2
} // end of pigment
} //end of skysphere
// ground
-------------------------------------------------------------------
plane{ <0,1,0>, 0
texture{ pigment{ checker color rgb<1,1,1>*1.2 color
rgb<0.25,0.15,0.1>*0}
//normal { bumps 0.75 scale 0.025}
finish { phong 0.1}
} // end of texture
} // end of plane
//---------------------------------------------------------------------------
//---------------------------- objects in scene
----------------------------
//---------------------------------------------------------------------------
// sample sphere
sphere { <0,0,0>, 1.00
texture { Polished_Chrome
//pigment{ color Red } // rgb< 1, 0.0, 0.0>}
//finish { phong 1 reflection {0.40 metallic 0.5}}
} // end of texture
scale<1,1,1> rotate<0,0,0> translate<0,1.35,0>
} // end of sphere -----------------------------------
global_settings { max_trace_level 5 assumed_gamma 1}
#include "Transforms.inc"
//////////////////////////////////////////////////////////////////////////////////////
#declare CamPos= <0.5, 1.5,4 >;
#declare CamLook= <1.3,1.2,0>;
//////////////////////////////////
#declare CamDirect=<0,0,1>;
#declare CamUp=<0,1,0>;
#declare CamWidth=image_width;
#declare CamHeight=image_height;
#declare CamAngle=VAngleD(CamPos, CamLook) ;
#declare CamAngleV=CamLook-CamPos;
#declare ColMapPig=pigment {image_map { png "test.png" once}
translate -0.5*(x+y)
scale <CamWidth/CamHeight,1,1> *2
//<============== *2 ******
}
//#declare PicBox=
box{<-CamWidth/CamHeight,-1,CamDirect.z>,<CamWidth/CamHeight,1,CamDirect.z+0.001>//}
texture {
pigment {ColMapPig}
finish { ambient 1 diffuse 1}
}
//}
translate CamDirect
rotate <degrees( atan2(CamAngleV.y,
CamAngleV.z)) ,degrees( atan2(CamAngleV.z, CamAngleV.x)),0 > *x*y
translate CamPos
}
///////////////////////////////////////////////////
camera {
location CamPos
direction CamDirect
right x*image_width/image_height
look_at CamLook
}
// End code
//-------------------------//
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Speaking of macros, and this whole camera business...
In order to clear this up for myself, and perhaps once and for all (maybe)
putting this baby to bed, I'm working on a pov file and studying screen.inc to
perhaps get a good, thorough nooby tool developed to SHOW what is going on.
This of course leads me to a few problems, and questions that may be
overcomplicating things and in the final result, superfluous.
First, screen.inc would not work until I added an extra parameter (1) to the
Set_Camera input from screen.pov, since it needs 4 parameters, and it was only
supplying 3 - the "ortho" parameter wasn't being passed to the macro.
Second, apparently there is meant to be text diplayed on the "screen" -
#declare MyTextObject =
text {
ttf "crystal.ttf", "target: enemy base", 0.01, <0,0>
scale 0.08
pigment {color <1.0,0.5,0.2>}
finish {ambient 1 diffuse 0}
}
That doesn't show up, and I'm currently investigating why.
Third, my current goal is to write up something that graphically demonstrates
what's going on internally with the render engine so that the User can follow
along with data output to the "screen" showing the values of the relevant
variables. Sort of like a dashboard on a car. Fire up an animation.ini file
that moves the camera around, changes key variables that affect the camera and
view, and those variables and the result are dynamically displayed on the
"screen" as the animation progresses. Display the active directives being used
to alter the screen position or other things happening in the render(s).
Fourth, incorporate some standard scene reference objects - x,y,z axes,
directions of rotation, "pointers" and guides from light sources to show things
like point-at, spotlight fades, etc.
Incorporates some switches to turn those guides on and off so that the user can
either see them or not. Turn on for scene development, turn off for final
render, or after they grasp what is going on.
(I've thought about having a "dual render" - where the scene is rendered without
any interfering stuff, and then a second render is automatically called from
within the SDL at the end of the first render - is this possible?)
In addition to rendering with guides from the viewpoint of the camera, I thought
it would be instructive and helpful to do a "meta-render" where the camera and
scene are actually shown from some other view. A side or diagonal view with a
camera point, with 4 rays extending outwards to the corners of the visible
scene, etc.
While it may be a lot of work, I think it will pay big dividends in the end,
since the newsgroups will be freed from these repetitive questions about basic
fundamentals of how POV-Ray operates, provide a large number of working examples
in the pov code, will make POV-Ray more accessible to people trying to get
started using it, and the final animation would itself make a great advertising
tool to showcase what POV-Ray is capable of doing - because it does what other
things CAN'T.
If this project interests you, I'd appreciate any advice and suggestions as to
what it should include, how it should be implemented, snippets of helpful or
illustrative code or full working examples - perhaps as individual pov or inc
files to be added in, ... basically anything at all that might assist me in
making efficient progress and producing a worthwhile result.
Anyone want to help me beat a few dead horses?
It's National Sado-Necro-Equine Month.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
•On Mon, 19 Aug 2013 21:00:29 +0200, Bald Eagle
<cre### [at] netscape net> wrote:
> Speaking of macros, and this whole camera business...
>
> In order to clear this up for myself, and perhaps once and for all
> (maybe)
> putting this baby to bed, I'm working on a pov file and studying
> screen.inc to
> perhaps get a good, thorough nooby tool developed to SHOW what is goin
g
> on.
>
> This of course leads me to a few problems, and questions that may be
> overcomplicating things and in the final result, superfluous.
>
> First, screen.inc would not work until I added an extra parameter (1)
to
> the
> Set_Camera input from screen.pov, since it needs 4 parameters, and it
> was only
> supplying 3 - the "ortho" parameter wasn't being passed to the macro.
>
> Second, apparently there is meant to be text diplayed on the "screen"
-
> #declare MyTextObject =
> text {
> ttf "crystal.ttf", "target: enemy base", 0.01, <0,0>
> scale 0.08
> pigment {color <1.0,0.5,0.2>}
> finish {ambient 1 diffuse 0}
> }
>
> That doesn't show up, and I'm currently investigating why.
>
> Third, my current goal is to write up something that graphically
> demonstrates
> what's going on internally with the render engine so that the User can
> follow
> along with data output to the "screen" showing the values of the relev
ant
> variables. Sort of like a dashboard on a car. Fire up an animation.i
ni
> file
> that moves the camera around, changes key variables that affect the
> camera and
> view, and those variables and the result are dynamically displayed on
the
> "screen" as the animation progresses. Display the active directives
> being used
> to alter the screen position or other things happening in the render(s
).
>
> Fourth, incorporate some standard scene reference objects - x,y,z axes
,
> directions of rotation, "pointers" and guides from light sources to sh
ow
> things
> like point-at, spotlight fades, etc.
>
> Incorporates some switches to turn those guides on and off so that the
> user can
> either see them or not. Turn on for scene development, turn off for
> final
> render, or after they grasp what is going on.
>
> (I've thought about having a "dual render" - where the scene is render
ed
> without
> any interfering stuff, and then a second render is automatically calle
d
> from
> within the SDL at the end of the first render - is this possible?)
>
> In addition to rendering with guides from the viewpoint of the camera,
I
> thought
> it would be instructive and helpful to do a "meta-render" where the
> camera and
> scene are actually shown from some other view. A side or diagonal vie
w
> with a
> camera point, with 4 rays extending outwards to the corners of the
> visible
> scene, etc.
>
> While it may be a lot of work, I think it will pay big dividends in th
e
> end,
> since the newsgroups will be freed from these repetitive questions abo
ut
> basic
> fundamentals of how POV-Ray operates, provide a large number of workin
g
> examples
> in the pov code, will make POV-Ray more accessible to people trying to
> get
> started using it, and the final animation would itself make a great
> advertising
> tool to showcase what POV-Ray is capable of doing - because it does wh
at
> other
> things CAN'T.
>
> If this project interests you, I'd appreciate any advice and suggestio
ns
> as to
> what it should include, how it should be implemented, snippets of
> helpful or
> illustrative code or full working examples - perhaps as individual pov
> or inc
> files to be added in, ... basically anything at all that might assist
me
> in
> making efficient progress and producing a worthwhile result.
>
> Anyone want to help me beat a few dead horses?
> It's National Sado-Necro-Equine Month.
>
I'm going to give screen.inc a look. Maybe it can solve my problem, thou
gh
I doubt it. I need to have an object defined according to the camera
position and orientation for use with a macro.
So basically what I would like to see is the following:
A) Rotation angle of the camera that can be used as a rotation value for
an object taking into account the up vector as well. For instance if you
wanted to model a specific real-life camera and test it.
B) A look_at(Pos, LookAt, Up) transform macro for objects that rotates a
n
object exactly like a camera.
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So basically what I would like to see is the following:
> A) Rotation angle of the camera that can be used as a rotation value for
> an object taking into account the up vector as well. For instance if you
> wanted to model a specific real-life camera and test it.
I must admit, I don't really know what you're trying to accomplish.
Are you just trying to make sure that the camera is always looking at a
certain object the same way after you move the camera?
> B) A look_at(Pos, LookAt, Up) transform macro for objects that rotates
> an object exactly like a camera.
I think that having a way to position objects absolutely, rather than
relative to the last position would be helpful in certain instances.
Look_at ... what? The camera? There would need to be a way to define
what part of the object was the "front" or however you're thinking about it.
The UP part - do you want to just make sure it's the same vector
direction as the camera UP? You should be able to do this by working
from the line of sight from the camera to the center of view.
Use that axis as the center of your object's rotational movements.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Second, apparently there is meant to be text displayed on the "screen" -
> #declare MyTextObject =
> text {
> ttf "crystal.ttf", "target: enemy base", 0.01, <0,0>
> scale 0.08
> pigment {color <1.0,0.5,0.2>}
> finish {ambient 1 diffuse 0}
> }
>
> That doesn't show up, and I'm currently investigating why.
Alright, I changed the font to arial, and that made the text visible,
but it was being interfered with by the fog or something.
I've now stripped everything else out the scene, but I'm missing
characters now.
"Text size 0.08" Appears as "T 0 08"
commenting out the global_settings {charset utf8} had no effect.
Changing the font to Times only shows a capital T
Changing it to arial, all caps gives me "TEXT S ZE 0 08"
I am truly bewildered.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 20 Aug 2013 21:36:37 +0200, Bald Eagle
<cre### [at] netscapenet> wrote:
>
>> So basically what I would like to see is the following:
>> A) Rotation angle of the camera that can be used as a rotation value for
>> an object taking into account the up vector as well. For instance if you
>> wanted to model a specific real-life camera and test it.
>
> I must admit, I don't really know what you're trying to accomplish.
> Are you just trying to make sure that the camera is always looking at a
> certain object the same way after you move the camera?
I want an object to be able to act just like a camera so that if you
rotate an object shaped like an arrow for instance with the camera
rotation and translate it in the same position as the camera, the arrow
should point at the camera's look_at position.
>> B) A look_at(Pos, LookAt, Up) transform macro for objects that rotates
>> an object exactly like a camera.
>
> I think that having a way to position objects absolutely, rather than
> relative to the last position would be helpful in certain instances.
>
> Look_at ... what? The camera? There would need to be a way to define
> what part of the object was the "front" or however you're thinking about
> it.
>
Look_at a specified point "LookAt".
Revised:
look_at(Pos, LookAt, Up, Front)
Front would be a vector defining what the front of the object is.
> The UP part - do you want to just make sure it's the same vector
> direction as the camera UP? You should be able to do this by working
> from the line of sight from the camera to the center of view.
> Use that axis as the center of your object's rotational movements.
>
If up is y then simply using only the x and y rotations without the z
rotation seems to work. But probably not in all cases.
Thanks for mentioning screen.inc. I had forgotten about it. It might just
help me with my scene.
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (I've thought about having a "dual render" - where the scene is rendered without
> any interfering stuff, and then a second render is automatically called from
> within the SDL at the end of the first render - is this possible?)
>
Not possible strictly from the SDL itself.
What you need for that is to use an ini file that will render the
original scene, then, set some control variable(s) to render the second
scene.
With that, the two renders can have different resolutions and aa
settings if it's not rendered as an animation but as two separate
images. You'll need to explicitely give an image name for at least one
of the renders.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/08/2013 22:09, Alain nous fit lire :
> Le 13-08-19 15:00, Bald Eagle a écrit :
>
>> (I've thought about having a "dual render" - where the scene is
>> rendered without
>> any interfering stuff, and then a second render is automatically
>> called from
>> within the SDL at the end of the first render - is this possible?)
>>
>
That sound a bit like the portal pattern. (or viewport ? I do not
remember exactly, it was some experimental stuff a long time ago)
What I do not get (yet ?), what is in the file generated by the render ?
> Not possible strictly from the SDL itself.
>
> What you need for that is to use an ini file that will render the
> original scene, then, set some control variable(s) to render the second
> scene.
> With that, the two renders can have different resolutions and aa
> settings if it's not rendered as an animation but as two separate
> images. You'll need to explicitely give an image name for at least one
> of the renders.
>
>
> Alain
With 3.7, you should search for clockless animation (+kla, with multiple
cameras definition, and so far you need also realtime raytracing with
+rtr). It disables file saving, so it might not be very useful so far.
> http://wiki.povray.org/content/Documentation:Windows_Section_1#Clockless_Animation
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2013 21:45, schrieb Bald Eagle:
>
>> Second, apparently there is meant to be text displayed on the "screen" -
>> #declare MyTextObject =
>> text {
>> ttf "crystal.ttf", "target: enemy base", 0.01, <0,0>
>> scale 0.08
>> pigment {color <1.0,0.5,0.2>}
>> finish {ambient 1 diffuse 0}
>> }
>>
>> That doesn't show up, and I'm currently investigating why.
>
> Alright, I changed the font to arial, and that made the text visible,
> but it was being interfered with by the fog or something.
>
> I've now stripped everything else out the scene, but I'm missing
> characters now.
>
> "Text size 0.08" Appears as "T 0 08"
>
> commenting out the global_settings {charset utf8} had no effect.
> Changing the font to Times only shows a capital T
>
> Changing it to arial, all caps gives me "TEXT S ZE 0 08"
>
> I am truly bewildered.
Are you using POV-Ray 3.6?
If so, you might be seeing one of two known bugs, FS#162 and FS#200,
that have been fixed in POV-Ray 3.7 (see http://bugs.povray.org/task/162
and http://bugs.povray.org/task/200, respectively).
If not, I'd be interested in the details.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/08/2013 22:27, Le_Forgeron nous fit lire :
> With 3.7, you should search for clockless animation (+kla, with multiple
> cameras definition, and so far you need also realtime raytracing with
> +rtr). It disables file saving, so it might not be very useful so far.
>
>> >
http://wiki.povray.org/content/Documentation:Windows_Section_1#Clockless_Animation
>
Side note for Unix: the code for +rtr is not active by default, a
special compilation is needed (in configure, CPPFLAGS=-DRTR_HACK)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
