|
|
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
|
|