hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > does not for me.  :-(  I get solid (filled) circles, not rings.
> ...
> Sounds like that ex-post facto texturing lots of people would like...

I'd _love_ a trace()-like function which returns a colour (instead of a normal).

> try using 2 "clipped_by" objects instead of an intersection?

good thought, had overlooked that.  so I modified the macro to return the box
dimensions only and used that in a clipped_by, but, no dice.  in fact, visually
identical.

> I really never use that command - so maybe others have advice.

fingers crossed.  and, thank you.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > does not for me.  :-(  I get solid (filled) circles, not rings.
> > ...
> > Sounds like that ex-post facto texturing lots of people would like...
>
> I'd _love_ a trace()-like function which returns a colour (instead of a normal).

That is called eval_pigment, Sir.

http://wiki.povray.org/content/Reference:Functions.inc

Pre defined functions
eval_pigment(Pigm, Vect): This macro evaluates the color of a pigment at a
specific point. Some pigments require more information than simply a point,
slope pattern based pigments for example, and will not work with this macro.
However, most pigments will work fine.

Parameters:

Vect = The point at which to evaluate the pigment.
Pigm = The pigment to evaluate.

Post a reply to this message

good morning,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > I'd _love_ a trace()-like function which returns a colour (instead of a normal).
>
> That is called eval_pigment, Sir.

no, no, no!  not even close, I tried.

if you look at the macro in 'functions.inc' you'll see why, eval_pigment doesn't
"do" objects, all you get is a colour read from the pigment at the given
co-ordinate.  does not work for all pigments as you say (and I'd need it to work
on textures, anyway), and lighting is not taken into account either.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Nope.  It's putting textures in too early.  The clear texture is what eliminates
> > the surface[s] of the slice.
> ...

just for the record, after trying suggested variations (clipped_by, bounded_by),
I also tried with 'no_image' for both object and "slice", separate and together.
 still the same looking output: of 200 frames only the first (and last) twenty
or so result in complete rings, then progressive "break up", to nothing shown at
all for circa ten frames around the middle.


regards, jr.

Post a reply to this message

I did this real quick - I'm off to work - but try putting the object LAST in the
hierarchy so that the CSG inherits ITS texture properties, not the other way
around.

 #version 3.8;
 global_settings {assumed_gamma 1.0 }
 #include "colors.inc"

#declare Aspect = image_width/image_height;

 camera {
  location <0, 5, -10>
  right x*Aspect
  look_at <0, 0, 0>
 }

light_source {<0, 5, -10> color White}

plane {z, 1 pigment {White*0.2}}

#declare Line = 0.015;
#declare LinePigment = pigment {Yellow+White/2}

#declare Slice = 0.1;
#declare Sphere = difference {sphere {0, 0.5 } sphere {0, 0.3 }}
#declare Box = box {<-1, 0, -1> <1, -Slice, 1>}

#declare E = 0.000001;

#for (M, -0.5, 0.5, Slice)
 intersection {
  object {Box translate y*M}
  object {Sphere}

  translate x*M*10
  pigment {Red}
 }
#end

Post a reply to this message

On 10/15/19 5:52 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> Nope.  It's putting textures in too early.  The clear texture is what eliminates
>>> the surface[s] of the slice.
>> ...
> 
> just for the record, after trying suggested variations (clipped_by, bounded_by),
> I also tried with 'no_image' for both object and "slice", separate and together.
>   still the same looking output: of 200 frames only the first (and last) twenty
> or so result in complete rings, then progressive "break up", to nothing shown at
> all for circa ten frames around the middle.
> 

Looks like generally your are looking to do a scan of any object to find 
the edges? Though the use a of transparent box to do this is inspired - 
it won't work reliably for the reasons I suggested in my earlier post.
Expect scanning a box works even less well?

Guessing at what might be confusing, when POV-Ray does CSG, it isn't 
creating intermediate shapes or surfaces. It's describing the treatment 
for the ray surface intersections found along the ray. This means for 
you, you'll have both coincident (sometimes wrongly ordered) 
intersections and ones less and less likely to align with the 
orthographic camera rays as the sampled surface becomes parallel to the 
ray. Such rays, if they hit, would be near tangents to the surface - the 
shortest of these tends to get filtered in many objects too for a few 
reasons.

If you want to try something that might be better with your current set 
up, the new v38 +am3 anti-alias mode might help(1). It can be slow. 
Here, if it works better, it would sort of be picking up 'enough' noise 
(enough intersections in the chance right way) to resolve the edges. I 
still expect it to struggle on the middle most rings no matter and 
perhaps not help much when scanning a box say with whole sides parallel 
to the camera rays.

(1) - And perhaps help more with more aggressive options (more than +am3).

There is edge detection of Bald_Eagle's solid shapes which can be run in 
gimp, photoshop, command line packages like netpbm and such. You can 
emulate edge detection methods in POV-Ray too folks have done it, but 
using something canned for 2d I expect easier/faster.

Your after the textures (and lighting... +AM3 best bet for that) at the 
edges - others have warned in posts about the complications thereof. 
What eval_pigment does is what can somewhat simply and reliably be done. 
For the rest angles of rays camera, shadow, slightly adjacent rays, etc 
play a part in the resultant pixel color.

If your looking to create meshes only for a few of the simpler shapes 
like spheres and boxes you can create meshes from the HF macros in 
shapes.inc.

What are you really trying to do - and for what inputs and outputs? 
Knowing that maybe some method to get you edges can be worked out. Maybe 
someone remembers a macro or two that already does what you need.

Bill P.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I did this real quick - I'm off to work - but try putting the object LAST in the
> hierarchy so that the CSG inherits ITS texture properties, not the other way
> around.
>
>  #version 3.8;
>  global_settings {assumed_gamma 1.0 }
>  #include "colors.inc"
> #declare Aspect = image_width/image_height;
>  camera {
>   location <0, 5, -10>
>   right x*Aspect
>   look_at <0, 0, 0>
>  }
> light_source {<0, 5, -10> color White}
> plane {z, 1 pigment {White*0.2}}
> #declare Line = 0.015;
> #declare LinePigment = pigment {Yellow+White/2}
> #declare Slice = 0.1;
> #declare Sphere = difference {sphere {0, 0.5 } sphere {0, 0.3 }}
> #declare Box = box {<-1, 0, -1> <1, -Slice, 1>}
> #declare E = 0.000001;
> #for (M, -0.5, 0.5, Slice)
>  intersection {
>   object {Box translate y*M}
>   object {Sphere}
>   translate x*M*10
>   pigment {Red}
>  }
> #end


hey, thanks.  ran the following modification with '+kfi0 +kff11':

#version 3.8;

global_settings {assumed_gamma 1.0}

#include "colors.inc"

camera {
  orthographic
  location <0, 5, 0>
  look_at <0, 0, 0>
  sky <0,0,1>
}

light_source {<0, 5, 10> color White}
light_source {<0, 5, -10> color White}
light_source {<10, 5, 0> color White}
light_source {<-10, 5, 0> color White}

#declare Slice = 0.1;
#declare Sphere = sphere {0,.5 pigment {Red}};
#declare Box = box {<-1, 0, -1> <1, -Slice, 1> pigment {srgbt 1}};

#if (11 > frame_number)
  #declare M = -.5 + frame_number * Slice;
  intersection {
    object {Sphere}
    object {Box translate y*M}
  }
#end

order of elements in intersection not the problem, nor the container, as I
understand now.  see reply to Bill P for rest.


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/15/19 5:52 AM, jr wrote:
> > ...
> Looks like generally your are looking to do a scan of any object to find
> the edges? Though the use a of transparent box to do this is inspired -
> it won't work reliably for the reasons I suggested in my earlier post.
> Expect scanning a box works even less well?

had not tried, but now guess that would indeed be the result.

> Guessing at what might be confusing, when POV-Ray does CSG, it isn't
> creating intermediate shapes or surfaces. It's describing the treatment
> for the ray surface intersections found along the ray.

that might explain "strange" interiors.  I did a scan of FMunoz's robot and was
surprised by the "junk" showing up inside.  :-)

> This means for
> you, you'll have both coincident (sometimes wrongly ordered)
> intersections and ones less and less likely to align with the
> orthographic camera rays as the sampled surface becomes parallel to the
> ray. Such rays, if they hit, would be near tangents to the surface - the
> shortest of these tends to get filtered in many objects too for a few
> reasons.

and that's the core problem I guess.  when the surface is seen along the "thin"
edge.  </sigh>

could you please elaborate on "coincident (sometimes wrongly ordered)
intersections"?  with my (admittedly) limited understanding I would have thought
that a box/sphere intersection must be the same as a sphere/box.  in the macro
I'd "oversized" the slice (box) in the plane to avoid coincident surfaces
at/near the bounding box.

> If you want to try something that might be better with your current set
> up, the new v38 +am3 anti-alias mode might help(1). It can be slow.
> Here, if it works better, it would sort of be picking up 'enough' noise
> (enough intersections in the chance right way) to resolve the edges. I
> still expect it to struggle on the middle most rings no matter and
> perhaps not help much when scanning a box say with whole sides parallel
> to the camera rays.

bingo!  yes, using sampling_method=3 in the .ini makes a massive difference, the
rings now stay coherent almost up to the 80th frame.  but, as you thought, the
middle is still no better.

still, worth knowing.  (I tend to use method 2 but will now switch)

> (1) - And perhaps help more with more aggressive options (more than +am3).

?? do you a mean smaller aa threshold?

> There is edge detection of Bald_Eagle's solid shapes which can be run in
> gimp, photoshop, command line packages like netpbm and such. You can
> emulate edge detection methods in POV-Ray too folks have done it, but
> using something canned for 2d I expect easier/faster.

don't really use GIMP/netpbm/ImageMagick very much.  I can imagine having a tool
which, having performed edge detection, could extrapolate, to some degree,
what's missing and fill in.  (never had the need to even want such a tool :-))

> Your after the textures (and lighting... +AM3 best bet for that) at the
> edges - others have warned in posts about the complications thereof.
> What eval_pigment does is what can somewhat simply and reliably be done.
> For the rest angles of rays camera, shadow, slightly adjacent rays, etc
> play a part in the resultant pixel color.

yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
variant of 'trace' would be nice; perhaps reversing the normal and use it as a
camera ray to get the colour.  it would be useful, even given the provisos you
mention, because it would work on an in-situ object as is.

> If your looking to create meshes only for a few of the simpler shapes
> like spheres and boxes you can create meshes from the HF macros in
> shapes.inc.

no, no meshes.  since I don't have modelling software, I've (currently) little
exposure to them.

> What are you really trying to do - and for what inputs and outputs?

:-)  my current "motivation" is creating .. fodder for my shiny, new program.
it reads three DF3s (with the RGB components) and outputs a VRML PROTO with that
data as a 'PointSet'.

inputs - arbitrary ("pretty" :-)) objects (or whole, small-ish scenes).

> Knowing that maybe some method to get you edges can be worked out. Maybe
> someone remembers a macro or two that already does what you need.

no, I think you're probably correct about the limitations of the approach.  the
only alternative I think of now would be to scan a given object six times (from
either end of each axis) and somehow "stitch together" one result from that
data; I'm doing something like that already in the 'xmlVolumeFromObject' macro
that came with the 'df3-tools', but that results in many redundant points (which
bloat the already large files).  not quite sure where to go from here..


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> > Your after the textures (and lighting... +AM3 best bet for that) at the
> > edges - others have warned in posts about the complications thereof.
> > What eval_pigment does is what can somewhat simply and reliably be done.
> > For the rest angles of rays camera, shadow, slightly adjacent rays, etc
> > play a part in the resultant pixel color.
>
> yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
> variant of 'trace' would be nice; perhaps reversing the normal and use it as a
> camera ray to get the colour.  it would be useful, even given the provisos you
> mention, because it would work on an in-situ object as is.

Well, we've played with locating 3D points in space based on 2D screen
coordinates, and I and at least one other have played with analyzing the color
maps of existing images - so you could render your frames, and then use
eval_pigment to scan the final rendered/lit/textured/shadowed, etc result in a
2-stage process using the rendered frames as image_maps in Step 2.

So perhaps you could use trace in Step 1 to compile a list of pixels to analyze
and store, and then use eval_pigment in Step 2 to only look at those pixels in
an image map of the rendered frames...

With regard to the slicing problem:
I'm wondering if you can use/abuse the orthographic camera itself to get what
you want.
I came across this when Ton posted a link to FL's site.
see:
http://www.f-lohmueller.de/pov_tut/scale_model/s_mod_150e.htm

Maybe with some sort of no_shadow or double_illuminate keywords, you could get
it to light the surface of that interior "slice".

Post a reply to this message

On 10/15/19 10:26 AM, jr wrote:
...
> 
>> This means for
>> you, you'll have both coincident (sometimes wrongly ordered)
>> intersections and ones less and less likely to align with the
>> orthographic camera rays as the sampled surface becomes parallel to the
>> ray. Such rays, if they hit, would be near tangents to the surface - the
>> shortest of these tends to get filtered in many objects too for a few
>> reasons.
> 
> and that's the core problem I guess.  when the surface is seen along the "thin"
> edge.  </sigh>
> 
> could you please elaborate on "coincident (sometimes wrongly ordered)
> intersections"?  with my (admittedly) limited understanding I would have thought
> that a box/sphere intersection must be the same as a sphere/box.  in the macro
> I'd "oversized" the slice (box) in the plane to avoid coincident surfaces
> at/near the bounding box.
> 

.........then the troll-of-inside_tests jumps from under the bridge... :-)

I can elaborate some, but I don't understand it all. What exactly 
happens depends on much. Scene scale, what objects and so what 
intersection code, which solvers, the inside tests are often coded 
differently for performance relative to the intersection tests -and 
more.

When there are coincident or near coincident surfaces POV-Ray can get 
confused about the actual order (or existence) of intersections. I don't 
know gaming engines, but others have said the problem is similar to the 
z buffer problem in gaming. So. I was speaking of this fundamental 
internal issue when I said "sometimes wrongly ordered." Nothing to do 
with your intersection object order - which shouldn't matter to a 'first 
order.' Though, I'd not be too surprised if sometimes it did.

---
Starting a little ahead of your question, when we talk about coincident 
surfaces in these newsgroups we really mean coincident, as in box face 
overlapping a box face; intersecting surfaces, where one surface flows 
through another surface - and sometimes we get patches/effective surface 
patches sharing all or part of an edge.

Where you want to see red, you have the second type - intersecting surfaces.

Ray tracing runs in a numerically noisy environment. Where we hit the 
coincident surface issue it means we have surfaces and intersections all 
within some ever changing (ray to ray and more) numerically noisy 
window/tolerance.

I'm not going to try to enumerate particular situations where your 
approach works and it doesn't with respect to coincident surfaces / 
numerical noise issues; other than to say, sometimes you get the result 
you want and sometimes not.

I believe there are two issues in your approach. I think +am3 is able to 
help with the coincident surfaces type, but not the 'things got so 
small' they are sitting between our camera rays(a) type.

(a) - Hmm, you might get some improvement too by moving to larger 
renders for this reason. Ray spacing is relative to the scene is smaller 
the larger the render.

> 
>> (1) - And perhaps help more with more aggressive options (more than +am3).
> 
> ?? do you a mean smaller aa threshold?
> 

Maybe. I was though thinking more about AA depth (+r<n>) and IIRC +am3 
has a confidence setting of some kind. I've played with the new AA 
method 3, but not much. It can be very slow. When I was working on those 
mazes, I had a situation where with +am3 running fine and I changed the 
ground color. Suddenly the runs times went up 100 fold - as if the 
adaptive mechanism was suddenly off. Maybe a bug, maybe just the 
behavior - not gotten back to look.

Aside: Method 3's ability to hone in on detail missing the original 
camera rays also makes it good at enhancing bugs/artefacts! I recommend 
using it when you are trying to pick up tiny details, and method 2 
otherwise.

> 
> yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
> variant of 'trace' would be nice; perhaps reversing the normal and use it as a
> camera ray to get the colour.  it would be useful, even given the provisos you
> mention, because it would work on an in-situ object as is.
> 

Hmm. Another bit of code I've hardly used. I have it in my head 
eval_pigment is passed a pigment and it returns the raw pigment value at 
the x,y,z of the intersection. No normals no other factors, but maybe 
that's sort of your point? You want something which evaluates - maybe - 
overlapped textures on an object at a point?

We do have the user defined functional camera in v38. If we can capture 
the normal and intersections, it should be these can be turned into 
object facing camera rays the reverse of raw surface normal.

Still glossing over lots of detailed issues about what folks 'really' 
want vs what we'd really get.

>> What are you really trying to do - and for what inputs and outputs?
> 
> :-)  my current "motivation" is creating .. fodder for my shiny, new program.
> it reads three DF3s (with the RGB components) and outputs a VRML PROTO with that
> data as a 'PointSet'.
> 
> inputs - arbitrary ("pretty" :-)) objects (or whole, small-ish scenes).
> 

:-) I didn't completely follow what your trying with VRML. I don't know 
it. If you get something going, fire off a news post or two. I'll keep 
thinking about the edge detection, maybe something will pop into my head 
worth trying.

Will mention some were creating cartoon images on the fly from scenes 
years ago. Prior work which might be worth looking over. I think most 
approached it with multiple renders, but...long time ago.

Aside: I play with df3s and have downloaded several of your utilities 
with the intent of giving them a whirl. Not gotten to it... :-(

Bill P.

Post a reply to this message