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

> So... We have in the code two slightly different ways to set up patch
> like objects. Why? Why? Why! you ask.

Why, Bill?  :D


> "Parse Warning:
> Patch object used in difference{} or intersection{} block. If a mesh{}
> or mesh2{} shape consider defining an 'inside_vector' to enable inside
> testing."

That's like one of the best POV-Ray warning messages I've ever read.  :)


> We could then too use bounded_by{} to do much of what clipped_by{} can
> do, but more efficiently.

Why more efficiently?

> The obvious downside, I think, is the behavior is less intuitive /
> obvious to users (me included). Thoughts?

Well, that depends on the documentation and examples provided, right?
I'm sure that given everything that gets learned, all of that should be
documented/preserved in a directory specific to that object type.
Scene files, comments, and supplementary documentation files are cheap - but the
preservation of the insights and lessons are invaluable.
Detailed diagrams and even animations are cheaply stored in the distro as .pov
and .ini files.

> In any case, all has me leaning even more toward changing the default in
> V4.0 to preserving user specified bounding as the default. These days,
> mostly, there is only auto-bounding in scenes. Where a user specifies
> bounded_by{} he probably wants to use that bounding.

We would assume so, yes.

Now that you're that deep into the code for disc, which is a simple object,
could you at some point help a few of us POV-bros out and give a general layout
of how POV-Ray .h and .cpp files go about "making" the object?

Perhaps in a dedicated thread?

The faster I'm able to learn to navigate my way through one object, the easier
the rest of them will be.  Even I can't start writing various bug fixes and
features from scratch, I can at least start writing up good, accurate, and truly
helpful documentation and diagrams.

-----

Hugely tangentially related, have you thought about using that as a test object
(simple normal code) for developing things like surface normal pigment
functions, directional gradient pigment functions, and surface curvature pigment
functions?
Applying that to a sphere would allow anisotropic scaling to then start to
really test those out.  I'm sure even mistakes would yield interesting results.


- BW

Post a reply to this message