POV-Ray : Newsgroups : povray.unofficial.patches : On the long unfinished normal related warps in warp.cpp. : Re: On the long unfinished normal related warps in warp.cpp. Server Time
9 Jun 2023 21:47:42 EDT (-0400)
  Re: On the long unfinished normal related warps in warp.cpp.  
From: Bald Eagle
Date: 17 May 2021 14:30:00
Message: <web.60a2b54ee71bfb471f9dae3025979125@news.povray.org>
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:


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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.