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