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