It would be great to have a fifth optional parameter on the trace()  
function to return a 5 dimensional colour vector at the intersection point.

-- 
-Nekar Xenos-

Post a reply to this message

"Nekar Xenos" <nek### [at] gmailcom> wrote:
> It would be great to have a fifth optional parameter on the trace()
> function to return a 5 dimensional colour vector at the intersection point.
>
> --
> -Nekar Xenos-

Hi Nekar
I hear you!.

I was trying to put an image on a box then use trace to find out what color was
at that location. The idea is to mess with existing images in POV but with no
color returned this turns out to be impossible. Unless of course anybody out
there knows different.

Also how about a read / write function when dealing with files and a pointer
variable would also be helpful.

Post a reply to this message

On 08/11/2014 19:13, kevva wrote:
> "Nekar Xenos" <nek### [at] gmailcom> wrote:
>> It would be great to have a fifth optional parameter on the trace()
>> function to return a 5 dimensional colour vector at the intersection point.
>>
>> --
>> -Nekar Xenos-
> 
> Hi Nekar
> I hear you!.
> 
> I was trying to put an image on a box then use trace to find out what color was
> at that location. The idea is to mess with existing images in POV but with no
> color returned this turns out to be impossible. Unless of course anybody out
> there knows different.

If you know the position and the texture/pigment, all that would be
missing is an evaluation of color at that location. It does not need
trace to be extended, does it ?


> 
> Also how about a read / write function when dealing with files and a pointer
> variable would also be helpful.
> 

you have #read & #write...

http://www.povray.org/documentation/view/3.6.1/238/


pointer ? do you need alias ?
SDL is declarative, once defined you cannot amend an object in the
scene, what would you use pointer for ?

If you need "template", you can #declare/#local your objects to use them
later.

Or do you want to be able to modify an instance of a previously declared
object far far later after its closing brace ?
(I mean modify, not get a copy to alter)

For once, the Java statement of "no pointer" is a good point when
dealing with "artists".

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> On 08/11/2014 19:13, kevva wrote:
> > "Nekar Xenos" <nek### [at] gmailcom> wrote:
> >> It would be great to have a fifth optional parameter on the trace()
> >> function to return a 5 dimensional colour vector at the intersection point.
> >>
> >> --
> >> -Nekar Xenos-
> >
> > Hi Nekar
> > I hear you!.
> >
> > I was trying to put an image on a box then use trace to find out what color was
> > at that location. The idea is to mess with existing images in POV but with no
> > color returned this turns out to be impossible. Unless of course anybody out
> > there knows different.
>
> If you know the position and the texture/pigment, all that would be
> missing is an evaluation of color at that location. It does not need
> trace to be extended, does it ?
>
>
> >
> > Also how about a read / write function when dealing with files and a pointer
> > variable would also be helpful.
> >
>
> you have #read & #write...
>
> http://www.povray.org/documentation/view/3.6.1/238/
>
>
> pointer ? do you need alias ?
> SDL is declarative, once defined you cannot amend an object in the
> scene, what would you use pointer for ?
>
> If you need "template", you can #declare/#local your objects to use them
> later.
>
> Or do you want to be able to modify an instance of a previously declared
> object far far later after its closing brace ?
> (I mean modify, not get a copy to alter)
>
> For once, the Java statement of "no pointer" is a good point when
> dealing with "artists".
>
> --
> IQ of crossposters with FU: 100 / (number of groups)
> IQ of crossposters without FU: 100 / (1 + number of groups)
> IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Whilst I do know the texture/pigment, it is to be an image, taken possibly by a
real camera. Then a trace command or something similar could then be used to
identify the colour of a particular pixel. Then, with the use of some creative
pov code, I could create a second box with a colour that would have been
manipulated by pov code. This box would then be set in just such a place so that
the camera would see the box as a single pixel in the new pov made image. I
could then devise a new colour to appear in the image, that pov would then
produce. Thus, I could manipulate any image that I would choose using pov code
to do it. Think of the possibilities I/we would be able to do anything to any
image, so long as I/we could program it in. e.g. I could enhance a low
resolution picture into a high res picture. If I could find a way of extracting
all the stills from a film, manipulate them, then I could maybe enhance a low
res film into a very high resolution film. Filling in data that can be found on
other frames in the same scene. If this trace command where possible then it
could be that this idea would become possible. The options are then only bounded
by our imaginations. All done in pov code.



create a file that resembled the old style windows.ini files inside it might
look a bit like this.

[state of mind]
Sarcasm = elementary
JumpingGun = true
EngageBrainBeforeTyping = false
PuttingOffNewPovCoders = JumpingGun
[Locations]
Object1=<10,20,30>
Object2=<20,30,10>
Object3=<30,10,20>


I would have to do is to ignore all after [State of mind] (something I would
encourage all pov coders to do!.) until I found the heading [Locations]
(Headings denoted by square brackets) then read all until I found Object2, then

and alter the next number (In this case 30) but of course I cannot write a new
number in at this point because I am in read mode and not write. If I was in
write mode then I could not read in the previous to find the correct location to
put the update in.
The only way I could do this is to read in each part of the old file and at the
same time write that part to a new file, then when I found the correct part of
the old file then change it before writing it into the new file. I would also
have to have some scripting going on. This scripting would have to at the end of
the frame or Postframe command that would destroy or delete the old file and
rename the new file to that it was the same name as the old file. So that next
time around all would be well.
But as in the last version of VB that I used to program in (This was some time

in this case) and writing in the new value. But rather than counting the number
of bytes one could count the number of valid representations e.g. strings or
floats perhaps. But I do feel that an update of the file handling is somewhat
overdue.

I also realise that I have been somewhat negative in this post and this is a
deplorable habit and I do apologise unreservedly for it, but I also believe that
I have a point, with respect to the use of file pointers and trace commands. Let
us not put off future POV coders but encourage them with respect and dignity
that the future deserves. (I am personally now over 50 years old and a rolling

:-0 )

Post a reply to this message

Am 01.01.2015 um 14:24 schrieb kevva:
> Whilst I do know the texture/pigment, it is to be an image, taken possibly by a
> real camera. Then a trace command or something similar could then be used to
> identify the colour of a particular pixel. Then, with the use of some creative
> pov code, I could create a second box with a colour that would have been
> manipulated by pov code. This box would then be set in just such a place so that
> the camera would see the box as a single pixel in the new pov made image. I
> could then devise a new colour to appear in the image, that pov would then
> produce. Thus, I could manipulate any image that I would choose using pov code
> to do it. Think of the possibilities I/we would be able to do anything to any
> image, so long as I/we could program it in. e.g. I could enhance a low
> resolution picture into a high res picture. If I could find a way of extracting
> all the stills from a film, manipulate them, then I could maybe enhance a low
> res film into a very high resolution film. Filling in data that can be found on
> other frames in the same scene. If this trace command where possible then it
> could be that this idea would become possible. The options are then only bounded
> by our imaginations. All done in pov code.

What you're looking for is the "eval_pigment" function.

> But as in the last version of VB that I used to program in (This was some time

> in this case) and writing in the new value. But rather than counting the number
> of bytes one could count the number of valid representations e.g. strings or
> floats perhaps. But I do feel that an update of the file handling is somewhat
> overdue.

While all contemporary file systems and operating systems support 
overwriting portons of a file with new content, this is always (with 
maybe a few exotic exceptions) limited to byte-for-byte replacement. To 
replace any sequence of bytes in a file with a sequence of bytes of 
different length, there is no other way than to (a) create a copy of the 
file with the desired changes and then replace the existing file with 
the new one, or (b) read in the remainder of the file, then overwrite 
the entire remainder of the file from the point of replacement.

Thus, implementing a bytewise replacement instruction is trivial, while 
a word-, line- or whatever-wise replacement instruction is non-trivial, 
time consuming, and would be an unnecessary waste of time to use 
multiple times on the same file.

As for a bytewise replacement instruction, it would only fit a very 
small portion of use cases, as the files operated on will typically be 
text-oriented rather than byte-oriented.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.01.2015 um 14:24 schrieb kevva:
> > Whilst I do know the texture/pigment, it is to be an image, taken possibly by a
> > real camera. Then a trace command or something similar could then be used to
> > identify the colour of a particular pixel. Then, with the use of some creative
> > pov code, I could create a second box with a colour that would have been
> > manipulated by pov code. This box would then be set in just such a place so that
> > the camera would see the box as a single pixel in the new pov made image. I
> > could then devise a new colour to appear in the image, that pov would then
> > produce. Thus, I could manipulate any image that I would choose using pov code
> > to do it. Think of the possibilities I/we would be able to do anything to any
> > image, so long as I/we could program it in. e.g. I could enhance a low
> > resolution picture into a high res picture. If I could find a way of extracting
> > all the stills from a film, manipulate them, then I could maybe enhance a low
> > res film into a very high resolution film. Filling in data that can be found on
> > other frames in the same scene. If this trace command where possible then it
> > could be that this idea would become possible. The options are then only bounded
> > by our imaginations. All done in pov code.
>
> What you're looking for is the "eval_pigment" function.
>
> > But as in the last version of VB that I used to program in (This was some time

> > in this case) and writing in the new value. But rather than counting the number
> > of bytes one could count the number of valid representations e.g. strings or
> > floats perhaps. But I do feel that an update of the file handling is somewhat
> > overdue.
>
> While all contemporary file systems and operating systems support
> overwriting portons of a file with new content, this is always (with
> maybe a few exotic exceptions) limited to byte-for-byte replacement. To
> replace any sequence of bytes in a file with a sequence of bytes of
> different length, there is no other way than to (a) create a copy of the
> file with the desired changes and then replace the existing file with
> the new one, or (b) read in the remainder of the file, then overwrite
> the entire remainder of the file from the point of replacement.
>
> Thus, implementing a bytewise replacement instruction is trivial, while
> a word-, line- or whatever-wise replacement instruction is non-trivial,
> time consuming, and would be an unnecessary waste of time to use
> multiple times on the same file.
>
> As for a bytewise replacement instruction, it would only fit a very
> small portion of use cases, as the files operated on will typically be
> text-oriented rather than byte-oriented.

it would help if eval_pigment worked with uv-mapped meshes.

-Nekar Xenos-

Post a reply to this message