William F Pokorny <ano### [at] anonymousorg> wrote:

> > sorry, still "no good".  I'd hoped for something along the lines "reading the
> > code at ...", that is for some "evidence-based" words.
>
> First, let me say I don't really know what you are after. :-) And, Bill
> W, I saw your recent post responding to jr's post.

I think he was under the impression that there was some definitive code fragment
that would unambiguously establish the solidness of a primitive.

> We have in our documentation:
>
> https://wiki.povray.org/content/Reference:Interior#Empty_and_Solid_Objects
>
> which introduces a couple concepts. Those two concepts don't map
> directly to anything in the code - though users (including me) commonly
> use those terms(*).

Nice.  With regard to sor:  "By default all objects are assumed to be solid."
:P

"You should be aware that solid objects are conceptual things. If you clip away
parts of the sphere you will clearly see that the interior is empty and it just
has a very thin surface.

This is not contrary to the concept of a solid object used in POV-Ray. It is
assumed that all space inside the sphere is covered by the sphere's interior."

So, I'd say that we either have:
misleading documentation - with regard to the terminology used and the
implication of words
Code that needs to be rewritten to better represent objects to meet user
expectations
buggy code

or just a whole pile of things that collectively are "POV-Ray" and need to be
better hashed-out and better organized to more accurately represent what's going
on.   That's just the nature of an open source project that has organically
grown over the past 30 years.

> In the code we do track patch objects / shapes in the base object class
> with a flags integer for which the bit used is PATCH_OBJECT. The
> PATCH_OBJECT bit being on, when initially constructed, essentially means
> the shape does not, start, with an inside test which can return true.
>
> Patch class shapes are derived from a helper class called NonsolidObject
> which inherits from the base object class. That helper class currently
> sets an integer value that maps directly to the particular patch type.
> The additional information is never used that I see. Despite the class
> name it is way to track the patch type (TypeOfPatchObject would be a
> better class name I think, but, I lean toward it being deleted from the
> class hierarchy).

As I get deeper into these things, it's very helpful to read this kind of
brass-tacks explanation.

> Strictly speaking, all we have inside the ray tracer are ray-surface
> intersections. We can link functionality to those surfaces - that's
> it(**).

Mmmmmm - I think we have at least a little more than that.
We can conduct insidedness tests without actually raytracing anything, and
probably a few more things that I can't bring to mind atm.

> Bill W, I agree shapes can situationally, appear to be solid,
> but it's always conditional in POV-Ray(***).

Yes, but I'm trying to not step into the trap of incomplete / poorly implemented
 code, or code that has bugs that haven't yet been rooted out.
I'd like to approach these things from "what ought to be the case" in some sort
of "this is what other mature, production raytracing/rendering packages do / are
capable of" with some form of formal Boolean logical result.

> We have disc{} and height_field{} which are arguably patch objects that
> are not because someone created inside test code that can return true.
> With the height_field that inside test can be adjusted using water_level.

Aye, but I make a distinction in those cases - because
1. we have a convention for things like planes and discs where one side is
"inside" and the other side is "outside".  It's not unexpected that how a plane
works got extended to a circular subset of a plane - a disc.
and
2. we can conceptually extend/project the edges of a heightfield onto a plane,
which provides the boundaries for making the object solid.   What was once
hollow is now solid, because the user invoked a special keyword.
Just like when a user takes a solid of revolution which is assumed to be solid,
and makes it hollow by invoking the open keyword.  {zing!} :D

> We have mesh{} and mesh2{} which start as patch objects, but that status
> bit is cleared on seeing inside_vector.

Which makes sense, because it's only a small conceptual jump between having an
inflatable Stanford Bunny, and a solid one.

> We can effectively corrupt (or turn off) the inside test with many
> shapes by collapsing one dimension of the shape as with box {
> <-1,-1,0>,<1,1,0>}.

Yes - and I'm sure that if we closely analyzed what we are doing in source, and
what the meaning of our return values from the c++ functions are, then we might
discover that there are better ways to conceptually represent what we are doing,
which would allow us to straighten a lot of these funny things out.
I have a feeling that that would be a lot like how we deal with things like
i=sqrt(-1), pow (0, 0), representing 4th dimensional objects, etc.

It might not have made much sense at one time, but math matured.
There may have been more limited examples that initially got developed, but like
splines, more general forms were worked out that allow a broader range of things
to be represented by a single more general form.

And I think I would like to see a more general form for a lot of our primitives.
   That doesn't exclude us having more nimble single-purpose primitives for
speed and efficiency, but I think we would be well served to try and
conceptualize all of our shapes so that they can all be described by similar
attributes, data structures, and raytracing algorithms.
We have a lot of redundant code in the code base.

> We can perform CSG with patch objects so long as another shape in the
> CSG has a inside test which returns true in a way that covers at least
> part of the patch object's surface. The result has no effective inside
> test where it is later used in CSG.

Hmmm.  That would be an interesting case to render as an example.

> Where we have or 'intersect' / 'and' regions where inside tests are
> true, but the originating surfaces for the inside test are not in scope,
> nothing shows up unless we stick other surface(s) into that region.

I'll have to a lot of thinking on that one to understand what you mean.

> Code wise nothing stops us from:
>
> - Defining an inside test which can return true for existing patch
> objects where today the inside test always returns false.

Probably.   It's just that no one ever got around to writing the inside ()
function for that primitive.

> - Implementing functionality which twiddles with the behavior of the
> inside test for effects / modified CSG results.

I'm sure that there's all sorts of interesting tricks one can play with that!
:)

> - Adding a shape option which forces an existing inside test sometimes
> returning true to always return false - 'inside off', perhaps.

I would say that now we're deep into the details of the primitives and the
consequences of how they are evaluated, then we should begin compiling a list of
better terminology.

Having said that, something like no_inside would probably fit better with
current SDL keyword forms.


> (***) - See attached image. Is the sphere solid in this situation? Code
> used:

And here I was still thinking that Tekno Franansia was the Evil Supergenius!
Master Pokorny is a tricksy little hobbit, yes, yes, very tricksy, my Precious.

> ...
> #declare Sphere00 = sphere {
>      0, 0.7
>      texture { pigment { White } finish { ambient 0.02 } }
>      interior_texture {
>          pigment { rgb <1,0,1> }
>          finish { ambient 0.02 }
>      }
> }
> #declare Cyl00 = cylinder { 0.0, <1,1,-1>, 1 open }
>
> difference {
>      object { Sphere00 }
>      object { Cyl00 }
>      cutaway_textures
> }

Now, I would have to say that in this instance it seems that this might just be
the result of buggy code, because we have not formally worked out what the
"proper" CSG result ought to be, and made our code consistent with that.

Still - a very clever and unexpected result!


> > and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> > required "infrastructure" exist already (in part, at least) ?
>
> No. As Bill W suggested there might be some brute force ways to approach
> it. Where we have value field defined shapes, it should be we could come
> up with optimizations. Whether we could ever get to something which
> would work well enough for on the fly ray-surface intersections, I'm not
> sure.

I think we could - it would just a project of its own.
I have looked into signed distance functions of meshes, and people have worked
out how to do that, so it may very likely be possible.

> Mechanical engineers surely have software which can determine the
> rotational volume required for 3D things - whether any methods are fast
> enough to run real time (without massive parallelism) I have doubts, but
> who knows. I've not dug.

I would guess that those are either triangle-based (FEM) or some other similar
numerical method.

Once again I will briefly reiterate the need for some sort of editable to-do
list, program management software, or other means of logging ideas, references,
proofs of concept, partial or naive implementations in SDL, c++ or other
languages, etc.

Experiments that languish on my hard drive don't do the development of POV-Ray
any good.  Adding them to a collection of ideas, references, and functional code
would.

- BW

Post a reply to this message