 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] ihug conz
.............. 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
|
|
| |
| |
|
|
|
|
| |
