 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> 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".
nice.
had a very cursory look at the FL page, not sure I understood but using the
direction vector is .. interesting, and I'll give this a try.
already using no_shadow but will see if double_illuminate (on the slice) makes a
difference.
thank you very much + "bless yr little cotton socks". :-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.
ok, understood.
> 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.
yes. not knowing the innards of POV-Ray, object order _should_ not matter, but
there's always the occasional .. stab of doubt (particularly when things aren't
going well. :-)).
> ...
> Where you want to see red, you have the second type - intersecting surfaces.
wondering whether[*] making the slice have an interior with explicit ior etc
might make a difference.
[*] will try later.
> ...
> 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.
will give this a try too, later (Wednesdays usually busy with RL).
the current render outputs 256x256, will check whether doubling makes a visual
difference.
> >> (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.
I've never used confidence, and usually stay away from the recursion limit.
still, much to think about, interplay of options etc, will tinker with those
too. thanks.
> > 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?
sure. the "problem" I have with eval_pigment is that it works irrespective of
lighting, which is unhelpful (imo).
you're right, evaluating a point on a (textured) surface is indeed what I'm
after; a feature/function sorely missing from POV-Ray, cf the feedback available
(for cameras etc) in 'hgpovray'.
> 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.
I do not even understand the concept, I guess. (when I first heard "mesh
camera" I'd naively thought it'd be like an insect's compound eye view. :-))
> ...
> >> 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.
basically, "export" RGB DF3 data to a custom (VRML) node, making it available as
a 'PointSet' (node type). the idea is to take some object made with POV-Ray,
scan it into DF3, export it, and view/peruse at leisure in some virtual world;
my pet project/ambition is to fashion a gallery with various .. exhibits.
I posted a grayscale version of 'spiral.df3' a month or so ago (cf BE) but
cannot find it now. :-( will in the coming days start a new off-topic thread
on the subject.
> 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.
maybe one of the other "old timers" reads this _and_ can remember. </grin>
> Aside: I play with df3s and have downloaded several of your utilities
> with the intent of giving them a whirl. Not gotten to it... :-(
:-) (when (if!) you do, I really could do with some feedback. (he said,
selfishly))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 10/15/19 10:26 AM, jr wrote:
> > ...
> > 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.
>
> will give this a try too, later (Wednesdays usually busy with RL).
> the current render outputs 256x256, will check whether doubling makes a visual
> difference.
> > >> (1) - And perhaps help more with more aggressive options (more than +am3).
I added 'double_illumination' to both of objects in the intersection ("slice"),
as per BE's suggestion, and a transparent 'interior_texture' to the box, and
found that helped some. I then doubled the resolution of the render (to
512x512), and tried "better" values for antialias_{confidence,depth,threshold},
again, small improvements. I've posted an animation of it in p.b.misc, same
subject. as can be seen, Bill P's advice re the near parallel (to camera) rays
was v accurate -- unfortunately. I want to avoid going down the multi-pass
approach suggested, given that, in the end, the colour would still be
"generated" by eval_pigment. so I'll use the rig as is now, and accept that
I'll have to drop resolution in some instances or avoid some shape(s)
altogether, and will have a look at the camera (cf BE Lohmueller tip) when I
find the .. energy. meanwhile new ideas/insights would be appreciated.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
