 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Can anyone explain why the following code gives me a black and *GREEN* checkered
plane?
plane {y,-1
texture {
pigment {checker White Black}
finish {ambient .4}
}
hollow
}
--
----------------------
Andy
------------------------------------------------------------------------------------------
-
--The Home Of Lunaland--
--visit my POV-Ray gallery--
--listen to my music--
www.acocker.freeserve.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
because you haven't included colours.inc ??
Andrew Cocker wrote:
>
> Hi,
>
> Can anyone explain why the following code gives me a black and *GREEN* checkered
plane?
>
> plane {y,-1
> texture {
> pigment {checker White Black}
> finish {ambient .4}
> }
> hollow
> }
>
> --
> ----------------------
> Andy
>
------------------------------------------------------------------------------------------
> -
> --The Home Of Lunaland--
> --visit my POV-Ray gallery--
> --listen to my music--
> www.acocker.freeserve.co.uk
--
//Spider
[ spi### [at] bahnhof se ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider <spi### [at] bahnhofse> wrote in message news:371### [at] bahnhofse...
> because you haven't included colours.inc ??
>
...is the wrong answer ;-)
I should have written:
<snip>
plane {y,-1
texture {
pigment {checker White Black}
finish {ambient .4}
}
hollow
}
both colors.inc and textures.inc are loaded.
Andy
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Perhaps you should make sure all your light sources are white.
Chris Capel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andy
You need a comma between the white and the black, then it'll be
ok.
I rendered it and got the green and black, don't know what causes
that, but the comma will sort it out.
Cheers
Steve
Andrew Cocker wrote:
>
> Hi,
>
> Can anyone explain why the following code gives me a black and *GREEN* checkered
plane?
>
> plane {y,-1
> texture {
> pigment {checker White Black}
> finish {ambient .4}
> }
> hollow
> }
>
> --
> ----------------------
> Andy
>
------------------------------------------------------------------------------------------
> -
> --The Home Of Lunaland--
> --visit my POV-Ray gallery--
> --listen to my music--
> www.acocker.freeserve.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Capel <chr### [at] hotmailcom> wrote in message
news:371d1313.0@news.povray.org...
> Perhaps you should make sure all your light sources are white.
>
> Chris Capel
Oh, c'mon now. I'm not that daft. Here's the entire code. It renders as green and
black.
I'm running 3.1e on Win95.
#include "colors.inc"
#include "textures.inc"
#include "metals.inc"
// camera
camera {
location <0,0,-5>
direction 2.0*z
up y
right 4/3*x
look_at <0,0,0>
}
//
// lights
light_source {
0*x
rgb <1,1,1>
translate <10,10,-10>
}
//
plane {y,-1
texture {
pigment {checker rgb 1 rgb 0}
finish {ambient .4}
}
hollow
}
I've noticed this happening for a while..just not mentioned it. I'm sure it never used
to
happen. Someone please confirm my sanity.
Andy
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steve <sjl### [at] ndirectcouk> wrote in message news:371D23F8.580209BF@ndirect.co.uk...
> Andy
>
> You need a comma between the white and the black, then it'll be
> ok.
>
> I rendered it and got the green and black, don't know what causes
> that, but the comma will sort it out.
>
> Cheers
> Steve
Thanks Steve. It did used to work, right? I'm not insane...I'm not!
Andy
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This works:
#include "colors.inc"
#include "textures.inc"
#include "metals.inc"
// camera
camera {
location <0,0,-5>
direction 2.0*z
up y
right 4/3*x
look_at <0,0,0>
}
//
// lights
light_source {
0*x
rgb <1,1,1>
translate <10,10,-10>
}
//
plane {y,-1
texture {
pigment {checker
colour rgb 1
colour rgb 0}
finish {ambient .4}
}
hollow
}
Note that I have added the colour keyword, and broken the lines.
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Try using the keyword 'color' ahead of each color entry.
Steve wrote:
>
> Andy
>
> You need a comma between the white and the black, then it'll be
> ok.
>
> I rendered it and got the green and black, don't know what causes
> that, but the comma will sort it out.
>
> Cheers
> Steve
>
> Andrew Cocker wrote:
> >
> > Hi,
> >
> > Can anyone explain why the following code gives me a black and *GREEN* checkered
plane?
> >
> > plane {y,-1
> > texture {
> > pigment {checker White Black}
> > finish {ambient .4}
> > }
> > hollow
> > }
> >
> > --
> > ----------------------
> > Andy
> >
------------------------------------------------------------------------------------------
> > -
> > --The Home Of Lunaland--
> > --visit my POV-Ray gallery--
> > --listen to my music--
> > www.acocker.freeserve.co.uk
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aolcom?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider <spi### [at] bahnhofse> wrote in message news:371D2967.ADBA7CC3@bahnhof.se...
> This works:
>
>
>
> #include "colors.inc"
> #include "textures.inc"
> #include "metals.inc"
>
> // camera
> camera {
> location <0,0,-5>
> direction 2.0*z
> up y
> right 4/3*x
> look_at <0,0,0>
> }
> //
> // lights
> light_source {
> 0*x
> rgb <1,1,1>
> translate <10,10,-10>
> }
> //
>
> plane {y,-1
> texture {
> pigment {checker
> colour rgb 1
> colour rgb 0}
> finish {ambient .4}
> }
> hollow
> }
>
>
> Note that I have added the colour keyword, and broken the lines.
>
Yeah, thanks. I tried using
pigment { checker rgb 1 rgb 0}
but got an error..didn't think to use color/colour. The seperate lines shouldn't make
a
difference though, should they. Doesn't POV ignore them?
Andy
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes <inv### [at] aolcom> wrote in message news:371D2B03.453AC4C5@aol.com...
> Try using the keyword 'color' ahead of each color entry.
>
Actually, I just realised that aside from the problem I was having, it's a little
embarrasing to publicly admit to rendering a black and white checkered plane. ;-)
I have deleted the offending scene file, and promise never to do it again. Sorry.
Andy
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker wrote:
>
> Hi,
>
> Can anyone explain why the following code gives me a black and *GREEN* checkered
plane?
>
> plane {y,-1
> texture {
> pigment {checker White Black}
> finish {ambient .4}
> }
> hollow
> }
> Andy
Since you now have your solutin I will simply tell you why.
Without the comma between the two colors in the list, as in
your example, Pov does not know that it should use them
seperatly for the two areas of the pattern. It instead adds
them together. The black is a more dominant color so wins the
war for the first color in the list. Since the second color
for the list appears to be missing Pov defaults to the white/
green colors it is programed to use when no colors are
specified for the pattern. Obviously you need to either use
the color keyword seperator of as was mentioned make sure you
have the comma in place if you expect it to perform correctly.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
it doesn't.
but if you use checker Black White, you MUST use a checker Black, White instead.
(note the ,)
Andrew Cocker wrote:
>
> Spider <spi### [at] bahnhofse> wrote in message news:371D2967.ADBA7CC3@bahnhof.se...
> > This works:
> >
> >
> >
> > #include "colors.inc"
> > #include "textures.inc"
> > #include "metals.inc"
> >
> > // camera
> > camera {
> > location <0,0,-5>
> > direction 2.0*z
> > up y
> > right 4/3*x
> > look_at <0,0,0>
> > }
> > //
> > // lights
> > light_source {
> > 0*x
> > rgb <1,1,1>
> > translate <10,10,-10>
> > }
> > //
> >
> > plane {y,-1
> > texture {
> > pigment {checker
> > colour rgb 1
> > colour rgb 0}
> > finish {ambient .4}
> > }
> > hollow
> > }
> >
> >
> > Note that I have added the colour keyword, and broken the lines.
> >
>
> Yeah, thanks. I tried using
>
> pigment { checker rgb 1 rgb 0}
>
> but got an error..didn't think to use color/colour. The seperate lines shouldn't
make a
> difference though, should they. Doesn't POV ignore them?
>
> Andy
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker wrote in message <371d29c1.0@news.povray.org>...
>Chris Capel <chr### [at] hotmailcom> wrote in message
news:371d1313.0@news.povray.org...
>> Perhaps you should make sure all your light sources are white.
>>
>> Chris Capel
>
<snip code>
>
>I've noticed this happening for a while..just not mentioned it. I'm sure it
never used to
>happen. Someone please confirm my sanity.
>
I'll confirm it. I had the same problem. I was doing a quick scene with
multiple
reflective spheres over multiple checkered squares. All were fine til I
added
a checkered square (red/blue). That plane rendered green and blue. I played
with it for a few days then left it. (Was pov 3.0 for win 95). I'll post
the sorce if
anyone's interested.
Gail
*******************************************************************
* gsh### [at] monotixcoza * ERROR: COFFEE.COM not found *
* http://www.rucus.ru.ac.za/~gail/ * Insert cup and press any key *
*******************************************************************
My Software never has bugs, It just develops random features
*******************************************************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw wrote:
> >I've noticed this happening for a while..just not mentioned it. I'm sure it
> never used to
> >happen. Someone please confirm my sanity.
> >
>
> I'll confirm it. I had the same problem. I was doing a quick scene with
> multiple
> reflective spheres over multiple checkered squares. All were fine til I
> added
> a checkered square (red/blue). That plane rendered green and blue. I played
> with it for a few days then left it. (Was pov 3.0 for win 95).
> Gail
The reason you people are seeing this now and perhaps not on
older versions of Pov is because unknown to you the Pov team has
silently been working in the back ground to fix annoying little
things the program does like stopping to inform a user that they
are stupid and misplaced a comma.
More specificaly they have started assigning a default pigment
colors to patterns that none specified by you. This helps because
if you forget to specify a color for the pattern Pov will render
the scene with the default color instead of stopping to issue a
warning message suggesting you fix your work before you try again.
It manifests it's self when you improperly specify color list
patterns like the missing comma seperator in the example today.
It is mentioned in the docs in several catagories concerning
list patterns that a comma seperator is needed or unexpected
results can be expected.
If you want to see ugly attach a bozo pigment pattern to an object
and leave the color specification empty.
The three color list pattern types that the comma seperators are
required for are the Brick, Checker, and Hexagon patterns.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Since you now have your solutin I will simply tell you why.
> Without the comma between the two colors in the list, as in
> your example, Pov does not know that it should use them
> seperatly for the two areas of the pattern. It instead adds
> them together. The black is a more dominant color so wins the
> war for the first color in the list.
If you add black and white you'll get white. It's just a matter of what POV
finds as a last value for the (first) color. If you turn them around you'll get
a white/green checkered plane. That is, if you still forget the comma.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It seems to be a slight bug (?) that appeared in POV 3.0;
In Pov 2.2, you _had_ to write "color" before every color specification.
In Pov 3, the program automatically understands when the vector is a
color.
I quickly noticed that the checker pattern had a slight problem with
that, if you write :
pigment {checker Raspberry Ivory}
Pov seems to ignore these and use the default Green/White colors.
(as some noted, most "genuine" pigments have default colors : bozo,
wood, marble,... the most recent ones have a default grayscale map)
you must thus write :
pigment {checker color Raspberry color Ivory}
and it works perfectly...
Cheers,
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
before correcting his ever-wrong computer date,
Fabien Mosen wrote:
>
> It seems to be a slight bug (?) that appeared in POV 3.0;
> In Pov 2.2, you _had_ to write "color" before every color specification.
> In Pov 3, the program automatically understands when the vector is a
> color.
>
> I quickly noticed that the checker pattern had a slight problem with
> that, if you write :
>
> pigment {checker Raspberry Ivory}
> Pov seems to ignore these and use the default Green/White colors.
> (as some noted, most "genuine" pigments have default colors : bozo,
> wood, marble,... the most recent ones have a default grayscale map)
>
> you must thus write :
>
> pigment {checker color Raspberry color Ivory}
>
> and it works perfectly...
>
> Cheers,
> Fabien.
I'll confirm that.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <371D7729.78C6FFB9@pacbell.net>...
>
> The reason you people are seeing this now and perhaps not on
>older versions of Pov is because unknown to you the Pov team has
>silently been working in the back ground to fix annoying little
>things the program does like stopping to inform a user that they
>are stupid and misplaced a comma.
> More specificaly they have started assigning a default pigment
>colors to patterns that none specified by you. This helps because
>if you forget to specify a color for the pattern Pov will render
>the scene with the default color instead of stopping to issue a
>warning message suggesting you fix your work before you try again.
> It manifests it's self when you improperly specify color list
>patterns like the missing comma seperator in the example today.
>It is mentioned in the docs in several catagories concerning
>list patterns that a comma seperator is needed or unexpected
>results can be expected.
Is this really true? If I make a mistake I want the interpreter to warn
me, not silently go off and do the Wrong Thing. Why would the authors
put in such a horrible misfeature?
--
Ross Smith ................................... mailto:ros### [at] ihugconz
.............. The Internet Group, Auckland, New Zealand ..............
"Perl is the Unix way. 500 million ways of doing the same thing,
and 500 million monster egos all insisting on their way being
the Proper way of doing it." -- David Parsons
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker wrote:
> The seperate lines shouldn't make a
> difference though, should they. Doesn't POV ignore them?
>
> Andy
Correct. You could put the entire scene on one line and, as long as you did not have
any
comments ( // ) in it, it would parse just fine.
Dale
POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ross Smith wrote:
>
>
> Is this really true? If I make a mistake I want the interpreter to warn
> me, not silently go off and do the Wrong Thing. Why would the authors
> put in such a horrible misfeature?
>
>
Partially. Because of the increasing complexity of Pov, it was necessary
to make the syntax a little more ridged in delimiting values and
statements than the earlier versions, to avoid conflicts and bugs. Needing
semi-colons after #declares are an example. In the checker instance, Pov
did not know that White and Black were separate values, and one overrode
the other. When it moved on to the second value, not finding one caused it
to use the default value.
Dale
POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <371D7729.78C6FFB9@pacbell.net>...
>Gail Shaw wrote:
>
>> I'll confirm it. I had the same problem. I was doing a quick scene with
>> multiple
>> reflective spheres over multiple checkered squares. All were fine til I
>> added
>> a checkered square (red/blue). That plane rendered green and blue. I
played
>> with it for a few days then left it. (Was pov 3.0 for win 95).
>> Gail
>
> More specificaly they have started assigning a default pigment
>colors to patterns that none specified by you. This helps because
>if you forget to specify a color for the pattern Pov will render
>the scene with the default color instead of stopping to issue a
>warning message suggesting you fix your work before you try again.
> It manifests it's self when you improperly specify color list
>patterns like the missing comma seperator in the example today.
>It is mentioned in the docs in several catagories concerning
>list patterns that a comma seperator is needed or unexpected
>results can be expected.
Hmmm, I'd appreciate a warning there. Something on the order of
'Warning, colour missing. Using default' something that gives a
clue as to what's wrong.
For a program to assume a value and carry on without informing the
user at all is not very friendly (Yes, I'm a programmer)
Thanks for pointing out what's wrong. Now if I cn fix my hard drive
I'll finish that picture.
Gail
*******************************************************************
* gsh### [at] monotixcoza * ERROR: COFFEE.COM not found *
* http://www.rucus.ru.ac.za/~gail/ * Insert cup and press any key *
*******************************************************************
My Software never has bugs, It just develops random features
*******************************************************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
. . .
Since we are on this topic, I, as a new user have the tendency to use the menu
option that drops predefined objects on the seen an then modify its parameters.
one thing that I have noticed is that some of these predefined object and command
defenitions are buggy. For example the checker patern defenition is missing the
comma, and another example is the defenition of the superellipsoid object which is
missing the "<>" in its defenition.
Since these type are not part of the povengine, could we call them bugs? Is there
a way of correcting them? Are they compiled into one of the DLLs or the engine?
Thanks,
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 22 Apr 1999 15:31:46 -0400, Kevork Abadjian wrote:
>Since these type are not part of the povengine, could we call them bugs? Is there
>a way of correcting them? Are they compiled into one of the DLLs or the engine?
They're actually text files. Look in the "Insert Menu" directory wherever you
installed POV.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yep, Insert Menu was something I delved into once in 3.0 to try
enhancing it, or so I thought anyway, and came across a few
misrepresentations it seemed. Unfortunately I didn't jot down notes
about them. I may have even added some problems along with the ones I
think I fixed. I uploaded the somewhat hazardous template file to AOL
for others to checkout and tried to explain this fact. Mostly intending
to cause others to edit it too if they hadn't already started. Nothings
perfect. Most of us seem to know of things wrong with the help
documents, etc. or at least know to watch out for errors. Goes with the
using.
Ron Parker wrote:
>
> On Thu, 22 Apr 1999 15:31:46 -0400, Kevork Abadjian wrote:
> >Since these type are not part of the povengine, could we call them bugs? Is there
> >a way of correcting them? Are they compiled into one of the DLLs or the engine?
>
> They're actually text files. Look in the "Insert Menu" directory wherever you
> installed POV.
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aolcom?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dale heeft geschreven in bericht <371E63C9.B10CB84D@execpc.com>...
>Partially. Because of the increasing complexity of Pov, it was necessary
>to make the syntax a little more ridged in delimiting values and
>statements than the earlier versions, to avoid conflicts and bugs. Needing
>semi-colons after #declares are an example. <snip>
Great! I am sometimes very puzzled by the anomalies in the POV definition
language. A more rigid syntax design may require more initial typing, but I
am convinced that it strongly reduces the overall TTFR
(Time-To-Final-Render), especially for those users that work as chaotic as I
do.
Some modifications spring to mind:
1 - to require commas between all arguments at all times
2 - make using a texture obligatory (it may only contain a pigment, ok)
3 - introduce separate #end statements: for #if blocks (#endif), #while
blocks (#endwhile), #switch (#endswitch) blocks, and so on
4 - semicolons after all #define commands
The parser will become more redundant, easier to expand, probably faster,
etc. Portability with code for previous may pose a problem. We have already
accomodated a 'break' in backward compatibility with version 3, and a more
rigid language design now may prevent more problems later.
Frans Verbaas
Keep in touch with the Dutch
!!!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Some modifications spring to mind:
>1 - to require commas between all arguments at all times
>2 - make using a texture obligatory (it may only contain a pigment, ok)
If you are going this far, may I suggest you go for making obligatorty
MATERIAL, even if you leave out the interior component
>3 - introduce separate #end statements: for #if blocks (#endif), #while
>blocks (#endwhile), #switch (#endswitch) blocks, and so on
>4 - semicolons after all #define commands
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
