POV-Ray : Newsgroups : povray.documentation.inbuilt : 3.7xx: max_extent (re: image resolution) is missing something? Server Time
28 Sep 2021 16:33:48 EDT (-0400)
  3.7xx: max_extent (re: image resolution) is missing something? (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 8 Jun 2017 14:15:05
Message: <web.593992ed7cb8f4dc883fb31c0@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> Note that there are only  x and y non-zero-values to the max_extent, so that's
> what the addition of the vector in defining Resolution is for (to avoid warnings
> when using scale.
>

Yep, *that* by itself makes sense; good idea. The docs still need some
overhauling.


Post a reply to this message

From: Bald Eagle
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 8 Jun 2017 15:25:01
Message: <web.5939a3997cb8f4dcc437ac910@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> Yep, *that* by itself makes sense; good idea. The docs still need some
> overhauling.

Yes, and I understand, from experience, how difficult a job it is to document
something, well, and keep it updated.

I think that having a few lines of working SDL to demonstrate how something
works is worth pages of documentation and dozens of (often redundant) forum
question and answer threads.

I really liked the following excerpt from Graphics Gems 3:

https://doc.lagout.org/Others/Game%20Development/Programming/Graphics%20Gems%203.pdf

Since the first volume of Graphics Gems was published, I have spoken to many
readers
and discovered that these books have helped people learn graphics by starting
with

with the codes
so freely, but I think I now see why this helps. It is often exciting to start
learning a new
medium by simply messing around in it, and understanding how it flows. My piano
teacher
encourages new students to begin by spending time playing freely at the
keyboard: keep a
few scales or chord progressions in mind, but otherwise explore the spaces of
melody,
harmony, and rhythm. When I started to learn new mediums in art classes, I often
spent
time simply playing with the medium: squishing clay into odd shapes or brushing
paint on
paper in free and unplanned motions. Of course one often moves on to develop
control

springs
from such uncontrolled and spirited play.
It is difficult for the novice to play at programming. There is little room for
simple
expression or error. A simple program does not communicate with the same range
and
strength as a masterfully simple line drawing or haunting melody. A programmer
cannot
hit a few wrong notes, or tolerate an undesired ripple in a line. If the syntax


anything
interesting. There are exceptions to the latter statement, but they are notable
because of

got to do some
things completely right, and everything else almost perfectly. That can be an
intimidating
realization particularly for the beginner: if a newly constructed program

problem could be in a million places, anywhere from the architecture to data
structures,

algorithms, or coding errors. The chance to start with something that already
works
removes the barrier to exploration: your program already works. If you want to
change it,


Post a reply to this message

From: Jim Holsenback
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 08:16:06
Message: <593a9186$1@news.povray.org>
On 6/8/2017 1:26 PM, Kenneth wrote:
> (running 3.7.1 beta 8)
> In the in-built documentation "3.3.1.6.5 Functions"...
> 
> In the section "min_extent/max_extent', concerning the new 3.7xx feature of
> reading the pixel resolution of an image, the example given there seems to be
> missing something. Part of it is written like this...
> 
> ......
> #declare Resolution = max_extent ( MatteImage );
> #declare MatteNormalizationScale =
> ;

you are correct ... however look at 
http://wiki.povray.org/content/Reference:Vector_Expressions#Functions 
and the example is complete. Scroll down a bit further there is another 
example just after the "New" annotation regarding Df3NormalizationScale 
... they didn't make it into the docs most likely due to a foo somewhere 
with regex pattern matching in WikiDocGen. I'll have a look


Post a reply to this message

From: Jim Holsenback
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 08:41:22
Message: <593a9772$1@news.povray.org>
On 6/9/2017 8:15 AM, Jim Holsenback wrote:
> ... they didn't make it into the docs most likely due to a foo somewhere 
> with regex pattern matching in WikiDocGen. I'll have a look

i take it back ... a quick look on the wiki and i think it's the markup 
concerning < and > that appear (and is missing in one place ... the box 
declaration) where > and < should have been used in the predefined 
text blocks that encloses the examples. this weekend i'll make some 
edits and test my theory.


Post a reply to this message

From: clipka
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 12:19:27
Message: <593aca8f$1@news.povray.org>
Am 09.06.2017 um 14:41 schrieb Jim Holsenback:
> On 6/9/2017 8:15 AM, Jim Holsenback wrote:
>> ... they didn't make it into the docs most likely due to a foo
>> somewhere with regex pattern matching in WikiDocGen. I'll have a look
> 
> i take it back ... a quick look on the wiki and i think it's the markup
> concerning < and > that appear (and is missing in one place ... the box
> declaration) where > and < should have been used in the predefined
> text blocks that encloses the examples. this weekend i'll make some
> edits and test my theory.

I concur.

In most pre-formatted blocks, "<" and ">" are represented as "<" and
">", respectively, in both the original Wiki source text as well as
the compiled help file for POV-Ray for Windows; not so in the case of
the max_extent example: There, literal "<" and ">" are used in the Wiki
source, and also exported as such to the compiled help file.

The Wiki seems to be robust enough to display the text as intended, but
the help file viewer apparently misinterprets it as a (malformed) HTML
tag. The text is actually in the help file, but it's not displayed.


Post a reply to this message

From: Kenneth
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 13:45:05
Message: <web.593add807cb8f4dc883fb31c0@news.povray.org>
Jim Holsenback <spa### [at] nothanksnet> wrote:

>
> you are correct ... however look at
> http://wiki.povray.org/content/Reference:Vector_Expressions#Functions
> and the example is complete.

Ah yes, thanks. I didn't think to look on-line, as I was running the latest
POV-Ray beta anyway, with the 'latest' help file.

Wow, I was woefully wrong about
            #declare MatteNormalizationScale = Resolution;

:-O


Post a reply to this message

From: Kenneth
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 14:00:07
Message: <web.593ae15b7cb8f4dc883fb31c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

>
> In most pre-formatted blocks, "<" and ">" are represented as "<" and
> ">", respectively, in both the original Wiki source text as well as
> the compiled help file for POV-Ray for Windows; not so in the case of
> the max_extent example: There, literal "<" and ">" are used in the Wiki
> source, and also exported as such to the compiled help file.
>
> The Wiki seems to be robust enough to display the text as intended, but
> the help file viewer apparently misinterprets it as a (malformed) HTML
> tag. The text is actually in the help file, but it's not displayed.

If the included help file was 'just' HTML, I would fix it myself. But alas, it's
compiled :-(

(A little side note: I can actually open the help file--in its entirety-- in
Windoze Wordpad. The contents are meaningless of course, mostly symbols. But It
doesn't open likewise in POV-Ray-- just one little 'word.' I thought POV was
robust enough to open and display just about any 'programming language.' But
then again, I'm somewhat naive about 'compiled' languages ('somewhat'?? That's
an understatement!!) ;-)


Post a reply to this message

From: Kenneth
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 14:15:02
Message: <web.593ae4e67cb8f4dc883fb31c0@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> I really liked the following excerpt from Graphics Gems 3:
>
> https://doc.lagout.org/Others/Game%20Development/Programming/Graphics%20Gems%203.pdf
>
> Since the first volume of Graphics Gems was published, I have spoken to many
> readers
> and discovered that these books have helped people learn graphics by starting
> with
> working codes and just exploring intuitively....

Yes, that's an excellent 'philosophy', about *anything* in life, actually. I
love to experiment, with anything and everything; it's a wonderful way to learn
new stuff. But as you (and the author) say, there needs to be a 'germ' of
understanding, to begin with. Sometimes that little germ is missing :-(


Post a reply to this message

From: clipka
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 16:00:47
Message: <593afe6f$1@news.povray.org>
Am 09.06.2017 um 19:56 schrieb Kenneth:

> (A little side note: I can actually open the help file--in its entirety-- in
> Windoze Wordpad. The contents are meaningless of course, mostly symbols. But It
> doesn't open likewise in POV-Ray-- just one little 'word.' I thought POV was
> robust enough to open and display just about any 'programming language.' But
> then again, I'm somewhat naive about 'compiled' languages ('somewhat'?? That's
> an understatement!!) ;-)

The help file is a binary file.

Most "compiled" stuff is binary files.

A binary file may contain arbitrary sequences of arbitrary bytes, from 0
to 255 (hexadecimal 00 to FF).

Most notably, a binary file may contain byte value 0 (hexadecimal 00)
anywhere in the file.


The vast majority of programming languages is based on plain ASCII text
files.

A canonical ASCII text file may contain only bytes that represent
_printable_ ASCII characters (32 to 126 = hexadecimal 20 to 7E), as well
as a few select control characters (horizontal tabulator, line feed,
carriage return, end of file = 9, 10, 13, 26 = hexadecimal 09, 0A, 0D, 1A).

Most notably, an ASCII text file must _never_ contain byte value 0
(hexadecimal 00) _anywhere_ in the file.


When a program handles text, it needs to keep track of where the text
ends. One obvious way to do this is to store the length in a separate
numerical data field, but this has the drawback of potentially wasting a
lot of memory if you're working with lots of small yet occasionally
large pieces of text: Unless you want to restrict yourself to at most
255 characters per piece of text, you need to set aside at least 2 extra
bytes per piece of text for that length data field; and if your text
pieces may potentially exceed 65535 characters, you'll need 4 extra
bytes for the length data field.

A more compact scheme is to not store the length of the text, but rather
mark its end with a special pseudo-character; this only requires 1 extra
byte per piece of text (presuming the text uses byte encoding such as
ASCII, or byte-based variable-length encoding such as UTF8). Commonly,
the byte value hex 00 is used as this end-of-string marker, in which
case this scheme is referred to as "null-terminated strings".

Virtually all text editors can cope with files containing arbitrary
characters from the range 1 to 255 (hexadecimal 01 to FF), at least to
some degree; but text editors that happen to use null-terminated strings
to store the lines of text may screw up on any files containing the byte
value hex 00.


The text editor module in POV-Ray for Windows presumably suffers from
this null-terminated-string ailment, while the Windows Wordpad
apparently does not. Whether it is because Wordpad does not use
null-terminated strings, or because it immediately replaces any hex 00
byte value with a placeholder upon loading, I can't tell.


Post a reply to this message

From: Jim Holsenback
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 10 Jun 2017 08:42:04
Message: <593be91c$1@news.povray.org>
On 6/9/2017 12:19 PM, clipka wrote:
> Am 09.06.2017 um 14:41 schrieb Jim Holsenback:
>> On 6/9/2017 8:15 AM, Jim Holsenback wrote:
>>> ... they didn't make it into the docs most likely due to a foo
>>> somewhere with regex pattern matching in WikiDocGen. I'll have a look
>>
>> i take it back ... a quick look on the wiki and i think it's the markup
>> concerning < and > that appear (and is missing in one place ... the box
>> declaration) where > and < should have been used in the predefined
>> text blocks that encloses the examples. this weekend i'll make some
>> edits and test my theory.
> 
> I concur.

confirmed

> the help file viewer apparently misinterprets it as a (malformed) HTML
> tag. The text is actually in the help file, but it's not displayed.

same deal with the nix and mac versions ... i turned on debugging and 
ran WikiDocGen before making the edits on the wiki and discovered a few 
things that i've had to mark as fix me. basically i need to test <pre> 
blocks rather than JUST keep reading until i find </pre> ... btw: i 
looked at the history on the wiki and i guess a mea culpa is in order 
because it looks like i'm the one who busted that passage. check your 
email ... i've posted an update to include in the next release


Post a reply to this message

<<< Previous 2 Messages Goto Initial 10 Messages

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.