 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I made a little pov to check the allignment of the Z-axis (which way do positive
and negative go? That always confuses me)
But this pov (see below) renders a totally useless plane of 2 colors: 1 half is
white, the other black. See http://home.ooijer.com/povzaxis.JPG
Rendering this (using v3.62 on XP (which identifies itself in the about box as
3.6, don't know if that's not how it's programmed) takes a ridiculously long
time, I've added the plane to reduce the rendering depth, but still it's slow -
and I'm on an Intel Quad, BTW, so unlikely that other processes got in the way.
This is not the first odd problem I've had, it's happened several times that
rendering only yields a useless Black&White picture.
Oh, and also, if I put a .inc in the include dir in C:\Program Files\POV-Ray for
Windows v3.62\include and it can't always find them, not even if they're in the
pov's directory.
I know this is multiple bug reports, but in all this seems such weird behaviour
that I put them in one report.
I've reinstalled 3.62 (removing first) and the result was largely the same, if
perhaps it rendered a tad faster. Oh, and most of the settings remained intact
(list of opened files and more) this indicates to me that removal wasn't
complete, which may or may not have had something to do with the result being
the same.
#include "shapes.inc"
#include "colors.inc"
/*#declare Fx = function {sin(5*v)}
#declare Fy = function {v}
#declare Fz = function {cos(5*v)}
parametric { function {Fy(u,v,0)} function {Fz(u,v,0)} <2*pi,-pi>,<4*pi,2.1*pi>
contained_by{box{-2,2}} precompute 18, x,y,z pigment {rgb x}}
*/
#background {White}
camera {
perspective
location <0.0,15.0,0> //location <0.0,0.0,20.0>
direction <0,0.0,.0>
}
plane
{
y,3
}
sphere
{
<0,0,0>,0.5
color Red
}
sphere
{
<0,0,1>,1
color Blue
}
sphere
{
<0,0,-1>,0.25
color Red
}
sphere
{
<0,0,2>,2
color Blue
}
sphere
{
<0,0,-2>,0.25
color Red
}
sphere
{
<0,0,3>,1
color Blue
}
sphere
{
<0,0,-3>,0.25
color Red
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> direction<0,0.0,.0>
I think you are confusing "direction" with "look_at"... this is a
clear case of RTFM (remember that with POV-Ray docs, the "F" in RTFM
*always* stands for "fine").
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/14/2011 09:43 AM, Jaime Vives Piqueres wrote:
>> direction<0,0.0,.0>
>
> I think you are confusing "direction" with "look_at"... this is a
> clear case of RTFM (remember that with POV-Ray docs, the "F" in RTFM
> *always* stands for "fine").
>
lol ... nicely put!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback <jho### [at] povray org> wrote:
> On 05/14/2011 09:43 AM, Jaime Vives Piqueres wrote:
> >> direction<0,0.0,.0>
> >
> > I think you are confusing "direction" with "look_at"... this is a
> > clear case of RTFM (remember that with POV-Ray docs, the "F" in RTFM
> > *always* stands for "fine").
> >
> lol ... nicely put!
No no no gents, I agree that the manual is fine, but this is a case of RTFP,
with P standing for post. my problem lay with the BW rendering, and the weird
results from this particular .pov. My reasons for wanting to render this (too
lazy to read the fine manual) have nothing to do with the results.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No no no gents, I agree that the manual is fine, but this is a case
> of RTFP, with P standing for post. my problem lay with the BW
> rendering, and the weird results from this particular .pov. My
> reasons for wanting to render this (too lazy to read the fine manual)
> have nothing to do with the results.
As I loosely suggested before, try changing the line
direction <0,0.0,.0>
to what I think you wanted instead:
look_at <0,0,0>
and you will get ride of the "weird" result, which is caused by your
choice of a null direction vector and the fact that there is a white
background and a black plane on your scene: what you are seeing is the
part of the white background above the black plane at y=3. No bug here:
your see just what you typed.
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/15/2011 06:45 PM, Marco wrote:
> Jim Holsenback<jho### [at] povrayorg> wrote:
>> On 05/14/2011 09:43 AM, Jaime Vives Piqueres wrote:
>>>> direction<0,0.0,.0>
>>>
>>> I think you are confusing "direction" with "look_at"... this is a
>>> clear case of RTFM (remember that with POV-Ray docs, the "F" in RTFM
>>> *always* stands for "fine").
>>>
>> lol ... nicely put!
>
> No no no gents, I agree that the manual is fine, but this is a case of RTFP,
> with P standing for post. my problem lay with the BW rendering, and the weird
> results from this particular .pov. My reasons for wanting to render this (too
> lazy to read the fine manual) have nothing to do with the results.
>
>
a picture is worth a thousand words:
http://wiki.povray.org/content/Documentation:Reference_Section_3#Placing_the_Camera
the image in this section explains things very clearly ... oh yeah, it
sounds like it wouldn't hurt to read the sections that follow either
lastly ... maybe posting in p.general or p.newusers would have been your
first best bet as this is clearly not a bug ... just a misunderstanding
of the camera attributes on your part
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You're right, I am not fluent in Povray, but, still, why does
http://home.ooijer.com/hsp/bollen-1.pov render like
http://home.ooijer.com/hsp/bollen-1.jpg (in flat B&W)? (and
http://home.ooijer.com/hsp/bollen-01.pov renders like
http://home.ooijer.com/hsp/bollen-01.jpg, which *does* produce a nice 3D-ish
effect) Surely, the camera placement should not influence this (it influences
which way the cam looks, not *how* it looks)?
Mea culpa for posting a bad example. Thanks to all who had the patience to bear
with me.
Oh and te image could perhaps be updated to show z+ and z- as well asl x+ and x-
and y+ and y-. Those are all rather intuitive to me, but the z could (according
to my intuition) swing either way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Addendum to my previous post: I've just continued working on the bollen-01.pov
(see http://home.ooijer.com/hsp/bollen-02.pov and
http://home.ooijer.com/hsp/bollen-02.jpg) What I've done is take this
bollen-01.pov which rendered fine, but not with all the features I wanted, so I
made a few changes to it (commented out the reference to bollen-01.inc and I
commented out texture { AOIDefault_Texture }, in sphere 2
And changed the background { color rgb <0.0,0.0,0.0> } to <1,1,1>.
These are all minor changes which should not affect the sudden lack of color,
right?
BTW the include file mentioned in the previous post is
http://home.ooijer.com/hsp/bollen-01.inc, You can tell, I made this with Art of
Illusion, hence the include file and often unrounds 0 to
-1.6287802428659799E-16> or something like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16/05/2011 10:03, Marco a écrit :
> which *does* produce a nice 3D-ish
> effect) Surely, the camera placement should not influence this (it influences
> which way the cam looks, not *how* it looks)?
because there is one with the light behind the camera (hence 3D effect)
and another where the light is in full front of the camera : the object
is just hiding the light, but get none to send to the camera, so it is a
black dot.
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/16/2011 05:03 AM, Marco wrote:
> Oh and te image could perhaps be updated to show z+ and z- as well asl x+ and x-
> and y+ and y-. Those are all rather intuitive to me, but the z could (according
> to my intuition) swing either way.
you're not thinking 3D here ... isn't -z 180 degrees from +z
i usually set up camera with a location vector of -z so that a rotate of
+x moves the camera up (-x moves it down) and +y moves it clockwise (-y
counterclockwise) ... two separate transforms:
#declare CamPos = <0,0,-10>;
#declare LookAt = <0,0,0>;
camera {
perspective
location CamPos
rotate x*2
rotate y*-10
look_at LookAt
}
this example 2 degrees up and 10 degrees counterclockwise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
