 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > The yuqk fork has no 'eval_pigment', but it does have a munction called
> > M_evaluate_pigment(). The following runs in about 4.5 seconds,
> > elapsed, on my old i3.
> ...
> have not tried tried to install the renamed branch yet, will try later tonight
> to get your code to run with last-but-one-before-renaming version.
Parse Warning:
Scene uses features not supported by any current official POV-Ray version.
The povr release 7 (3.8.0-x.povr_0883e2b6) version is: v0.6.1.0
----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects: 307200
Infinite Objects: 0
Light Sources: 0
Total: 307200
----------------------------------------------------------------------------
Parser Time
Parse Time: 0 hours 0 minutes 3 seconds (3.614 seconds)
using 1 thread(s) with 3.570 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.471 seconds)
using 1 thread(s) with 0.470 CPU-seconds total
----------------------------------------------------------------------------
Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........Off
----------------------------------------------------------------------------
Render Statistics
Image Resolution 960 x 720
----------------------------------------------------------------------------
Pixels: 691200 Samples: 0 Smpls/Pxl: 0.00
Rays: 691200 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Sphere 307200 307200 100.00
Bounding Box 44635591 4401534 9.86
----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 0 seconds (0.454 seconds)
using 4 thread(s) with 1.277 CPU-seconds total
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
>
> proof of concept (640x480 image source). ~20 minutes ;-)
>
[then...]
> Modifying my posted code to junk the array and call
> 'eval_pigment' inside the 'texture{}', I get parsing down to just
> under 5.5 secs (plus ~1s render) using the beta.2.
You *might* get it to run even faster by copy/pasting the eval_pigment macro
from functions.inc directly into your scene code, instead of 'including' the
full .inc file.
#macro eval_pigment(pigm, vec)
#local fn = function { pigment { pigm } }
#local result = (fn(vec.x, vec.y, vec.z));
result
#end
I rarely use the .inc files directly, just the bits and pieces that I need.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Kenneth" <kdw### [at] gmailcom> wrote:
> > Modifying my posted code to junk the array and call
> > 'eval_pigment' inside the 'texture{}', I get parsing down to just
> > under 5.5 secs (plus ~1s render) using the beta.2.
>
> You *might* get it to run even faster by copy/pasting the eval_pigment macro
> from functions.inc directly into your scene code, instead of 'including' the
> full .inc file.
> ...
> I rarely use the .inc files directly, just the bits and pieces that I need.
same here, things like 'RRand()' etc just copy from the .inc. did a v quick
check with alpha.9945627, no real difference. the macro caching seems to work
"as advertised" :-).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
>
> you can use an image as a pattern and you can use a pattern in a function. Then
> you can sample the "image function" to fill arrays. But, the image will already
> be interpolated.
>
This is interesting, and something that I have been trying to figure out for
quite awhile with no luck. Once the image is in function form, HOW do you
extract or 'sample' usable info from it? For example, finding a particular
individual pixel's color, or its location in the original image?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> "ingo" <nomail@nomail> wrote:
> >
> > you can use an image as a pattern and you can use a pattern in a function. Then
> > you can sample the "image function" to fill arrays. But, the image will already
> > be interpolated.
> >
>
> This is interesting, and something that I have been trying to figure out for
> quite awhile with no luck. Once the image is in function form, HOW do you
> extract or 'sample' usable info from it? For example, finding a particular
> individual pixel's color, or its location in the original image?
We have been over this before, and you probably need to discard certain ideas
that you have about what is going on.
The image is never "in function form" - POV-Ray simply has a mechanism by which
a function is indexed into the image by its pixel location - the x, y, and z
arguments of the function call.
You sample usable information from it by telling the function where in the image
you want to sample from, and POV-Ray looks up the color information at that part
of the image. It's nothing but a lookup table. "What piece is on the chess
board at THIS (<x, y, z> square?"
The pixel's color IS the information that gets returned from the function.
It's location is the location that you specify in the function.
You're not going to be able to (easily) do that in reverse, for a whole host of
reasons - but you could certainly process the information after you copy all the
pixel color info into a 1D or 2D array, and then make a cumulative distribution
function, or simply search for all of the pixels that have the rgb value you're
looking for.
It's nothing but a lookup algorithm.
https://news.povray.org/povray.binaries.images/message/%3Cweb.60344b9fa906d8e31f9dae300%40news.povray.org%3E/#%3Cweb.60
344b9fa906d8e31f9dae300%40news.povray.org%3E
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > For example, finding a particular
> > individual pixel's color, or its location in the original image?
>
> We have been over this before...
Yes indeed ;-)
The aforementioned link...
https://news.povray.org/povray.binaries.images/message/%3Cweb.60344b9fa906d8e31f9dae300%40news.povray.org%3E/#%3Cweb.60
344b9fa906d8e31f9dae300%40news.povray.org%3E
> ..and you probably need to discard certain ideas
> that you have about what is going on.
Alas, I'm still a dunce as to where my thinking has gone wrong. :-(
Of course, I could pull out the two pieces of information that I want-- PRIOR to
turning the image into a function-- by using eval_pigment + loop on the image or
image_map itself. But Ingo's comment implies that there is a code trick
POST-function to get (at least one of?) those values, which he would then enter
into an array.
>
> The image is never "in function form"...
'under the hood' that is, if I understand your older comments...but the user
creates and sees a single entity, 'the function', at the SDL-code level
> POV-Ray simply has a mechanism by which
> a function is indexed into the image by its pixel location - the x, y, and z
> arguments of the function call.
>
> You sample usable information from it by telling the function where in
> the image you want to sample from, and POV-Ray looks up the color
> information at that part of the image. It's nothing but a lookup table.
> "What piece is on the chess board at THIS (<x, y, z> square?"
>
> The pixel's color IS the information that gets returned from the function.
>
> It's location is the location that you specify in the function.
>
That's the unknown mystery to me-- if I'm not still off-base with my thinking!
Let's say that I turn an image into a function...
#declare MY_IMAGE_AS_FUNCTION=
function{pigment{png "MY_IMAGE.png}}
Now, I could manipulate the function to pull out the grayscale values of only
the RED color channel for example, using dot notation...
pigment{function{MY_IMAGE_AS_FUNCTION(x,y,z).red}
then create an image_map of just that segregated channel. But that is for ALL of
the pixels at once. The dot notation trick provides no individual-pixel
'location' information; nor do the (x,y,z) function arguments-- they can be
thought of as overall pixel 'scalers', like (3*x,y,z).
Yet, your comments and Ingo's seem to imply that there IS a further
code-manipulation trick to extract a single pixel's color value (a grayscale
value in my example). And/or "It's *location* is the location that you specify
in the function." How to do either of those in SDL is my main question (and
mystery).
Am I still wrong-headed about this possibility?
------
My apologies to Ilya for going off-topic here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Of course, I could pull out the two pieces of information that I want-- PRIOR to
> turning the image into a function-- by using eval_pigment + loop on the image or
> image_map itself.
You can. Which in most regards in not really any different than what we're
talking about here.
If you look at the old thread, and the source code I quoted, eval_pigment is
making a function {pigment{image_map}} and using that to get your pixel info.
> But Ingo's comment implies that there is a code trick
> POST-function to get (at least one of?) those values, which he would then enter
> into an array.
Ingo said, "you can use an image as a pattern and you can use a pattern in a
function. Then
you can sample the "image function" to fill arrays. But, the image will already
be interpolated."
All he's doing there is your loop / eval_pigment thing.
The point he's trying to make is that stuff under the hood is going to be doing
interpolation between pixels, which may or may not be wanted.
> > The image is never "in function form"...
>
> 'under the hood' that is, if I understand your older comments...but the user
> creates and sees a single entity, 'the function', at the SDL-code level
Yes. The function.
But the function is the function. The image still remains untouched.
The function is merely a pointer into the image, like a computer-controlled
laser pointer might be used to light up a certain point on a painting.
> Let's say that I turn an image into a function...
> #declare MY_IMAGE_AS_FUNCTION=
> function{pigment{png "MY_IMAGE.png}}
You instantiate a "function" that is linked to a specific image.
> Now, I could manipulate the function to pull out the grayscale values of only
> the RED color channel for example, using dot notation...
> pigment{function{MY_IMAGE_AS_FUNCTION(x,y,z).red}
Much of what goes on with the dot-notation is simple a matter of POV-Ray's
function parser not being very robust or flexible.
You do not need to use the dot notation with a pigment function when directly
using the result.
https://wiki.povray.org/content/Reference:Function
"Declaring User-Defined Color Functions
Right now you may only declare color functions using one of the special function
types. The only supported type is the pigment function. You may use every valid
pigment. This is a very simple example:"
The peculiarities of the function parser require you to choose a single scalar
color channel if the result will be further used in a more complex function, but
that's the function parser's problem, not anything to do with what the pigment
function natively returns, which is an <r, g, b> color vector.
> then create an image_map of just that segregated channel. But that is for ALL of
> the pixels at once. The dot notation trick provides no individual-pixel
> 'location' information; nor do the (x,y,z) function arguments-- they can be
> thought of as overall pixel 'scalers', like (3*x,y,z).
It does nothing to the image pixels. It only ever returns information for a
single pixel at any given time. The image_map is restricted to the <0, 0, 0> to
<1, 1, 0> range due to the way POV-Ray imports it into an internal data
structure.
A sane way to handle this information is to use max_extent to get the image size
/ resolution of the image and scale the image_map by that. Then you link a
function to it, and then every x, y position is a 1:1 correspondence to the
image pixels.
> Yet, your comments and Ingo's seem to imply that there IS a further
> code-manipulation trick to extract a single pixel's color value (a grayscale
> value in my example). And/or "It's *location* is the location that you specify
> in the function."
In the carpet I made for the 2014 Secret Passage TCRTC competition, I used TdG's
eval_pigment method to make a nice carpet from an image.
Here's a direct copy-paste from the .inc file that I wrote for that scene.
#declare ImageMap = pigment {image_map {jpeg "NYLON-carpet-2001.jpg" once} };
#declare Resolution = max_extent (ImageMap);
#declare Resolution = Resolution + <0, 0, 1>;
#declare Carpet =
union {
#declare CarpetX = 0;
#while (CarpetX < Resolution.x)
#declare CarpetY = 0;
#while (CarpetY < Resolution.y)
#declare Tilt = (rand (Seed1)-0.5)*4;
#declare Rotate = rand (Seed2)*360;
#declare X = CarpetX/Resolution.x;
#declare Y = CarpetY/Resolution.y;
#declare Strand = eval_pigment (ImageMap, <X, Y, 0>);
#declare Point1 = <X*XSize, Y*(Resolution.y/Resolution.x)*XSize, 0>;
#declare Point2 = <X*XSize, Y*(Resolution.y/Resolution.x)*XSize, 0> + <0, 0,
-0.5>;
#declare Length = 0.25*rand (Seed3);
cone {0, 0.25, <0, 0, -(0.25+Length)>, 0.125 pigment {Strand} rotate x*Tilt
rotate y*Rotate translate Point1}
#debug concat("Strand = <", vstr(3, Point2, ", ", 0, 1), ">, to <", vstr(3,
Point1, ", ", 0, 1), ">, rgb <", vstr(3, Strand, ", ", 0, 1), "> "," \n")
#declare CarpetY = CarpetY + 5;
#end
#declare CarpetX = CarpetX + 5;
#end
}
As you can see, I use fractional values based on the resolution, which spans the
0-1 range of the imported image - which is just an arbitrary choice. It works
just as well either way.
#declare Strand = eval_pigment (ImageMap, <X, Y, 0>);
Give me a full color vector that I then use to pigment my carpet strand
primitives.
NO. MAGIC.
The very interesting thing that I do see here is that I have:
#macro eval_pigment (pigm, vec)
#local fn = function {pigment {pigm} }
#local result = (fn(vec.x, vec.y, vec.z));
result
#end
which apparently allowed me to use dot notation in function _arguments_, which
I've experienced trouble with on numerous occasions. I'll have to look into
and experiment to find what the limitations on that are.
(Thanks for making me look back at that scene :) )
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> Ilya Razmanov <ily### [at] gmailcom> wrote:
> > Greeting,
> >
> > continuing experiments with Python (which continues to piss me off), I
> > decided to write small program to convert image heightfields into
> > triangle meshes. ...
> > The latter looks to me significantly better than POVRay heightfield
> > rendering ...
>
> for data "extrapolated" from a 64x64 image, that last image looks real good I
> think.
>wondering if the calculation could not be done in SDL ?
>
> regards, jr.
I didn't really know where I should post this so here it is...
A while back when I was exploring mars. They had just out with fairly large
Mars maps.(4096*2048) But even so, at that resolution it was still around 2
kilometers
per pixel. I wanted to get closer. What I did was take a chuck of the main map
and
using a large array , a pigment function and splines, I blew it up into any size
I liked. When I saw these posts I had to go back and find That code.
To make a long story short I found it and modified it but it needs a lot of
work to present it. But I have to show ya something I'm proud of. Using a 16*16
image
I made a Mesh2 with 12800 triangles and 81*81 pov units square.
Post a reply to this message
Attachments:
Download 'flat_inter.png' (203 KB)
Preview of image 'flat_inter.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Leroy" <whe### [at] gmailcom> wrote:
> But I have to show ya something I'm proud of. Using a 16*16 image.
> I made a Mesh2 with 12800 triangles and 81*81 pov units square.
Wow, such smooth recreated detail-- and from a crude 16X16-pixel area!
Yes, definitely post your code when it's ready. Very impressive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Leroy" <whe### [at] gmailcom> wrote:
> I made a Mesh2 with 12800 triangles and 81*81 pov units square.
Very very nice!
I always wondered why POV-Ray does not interpolate the image for height fields,
as it can for image_maps. It is one of the reasons I wrote my curves.inc. The
idea to use it to interpolate images with different splines to vary the HF
output. Imagine using a TCB spline and vary the tension of the curvature.
But then I got side tracked by doing the curves.nim version and povmesh.nim to
speed things up a lot, but never got to create any proper HF mesh with it.
curve.inc:
https://ingoogni.nl/download/
curve.nim:
https://gist.github.com/ingoogni/490d2d50710bab4fe5e689714e9ef287
(the Nim version has better explanation of what the various parameters do than
the inc file)
povmesh.nim:
https://gist.github.com/ingoogni/ca030e955daf7f8138cedfe488ca0013
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
