William F Pokorny <ano### [at] anonymousorg> wrote:
> The warp.cpp source code has long had some unfinished normal related
> warp and unwarp hooks. Those of us working on the code of late haven't
> really understood them - as far as I know.

So, when I was coding some C++ stuff, I had to puzzle out passing things by
pointer, reference, or value.  Some of the code in the section we're talking
about I can read just fine - the stuff with the "->", notsomuch.


> While working of late on normal block patterns it hit me we don't warp
> the incoming normal, but rather the perturbation patterns/methods via
> the unwarped / warped EPoint(1). We cannot today warp the incoming raw
> normals with warp{}s.

I have read that 4 or 5 times, and I think I understand it and agree.  :)

> So, I started to play with an idea for new normal pattern which
> allows/enables this. It's currently working with the difference between
> the intersection location and the warp{} / turbulence affected EPoint.
> In other words, there isn't an actual specific perturbation method /
> pattern - it's whatever your warp{}s create.

So it would be much like doing normal {null warp repeat x turbulence 0.3}
where "null" is just sort of like an identity matrix - no change.

>
> Attached are a couple of images. One uses three repeat warps and a touch
> of turbulence. The second a spiral -> turbulence -> spiral combination.

That second one seems like it has real potential.  Given that one of the mothods
for arranging things "evenly" on the surface of a sphere is using a spiral /
loxodrome, then accomplishing a very close approximation to that using only a
simple normal statement would be a really powerful and welcome development.

This reminds me of my unsolved problem applying normals to bezier patches:

http://news.povray.org/web.5f6a91889d9b31d91f9dae300%40news.povray.org
regarding
https://news.povray.org/povray.binaries.images/message/%3Cweb.5f45adba5d69181b1f9dae300%40news.povray.org%3E/#%3Cweb.5f
45adba5d69181b1f9dae300%40news.povray.org%3E

Do you have any inkling if the uv-mapping coordinates affect the application of
the normal pattern, and where in the code that factors in?  Because I see that
as being another thing that's hiding in there that we might not be fully aware
of.
So I guess maybe what I'm asking is, do the uv-mapping vectors override the
global POV-space location vectors, in essence (locally/temporarily) redefining
the EPoint?  And with regard to applying a global normal pattern that is
dependent upon an object's location in POV-space, is this desirable, expected,
and can it be overridden?

Post a reply to this message