|
 |
On 1/26/22 03:19, Kenneth wrote:
> That is really cool. It looks like the technique could be used as 'sort of' a
> substitute for camera blur. And much faster, I assume.
>
I think so too. Sort of fits with my often liking ray traced / rendered
results which don't look to be the typical computer generated kind.
An everything out of blur camera - there is no focal plane through which
the origin and direction are jittered.
Not measured it, but I expect it to be faster, but I often enough get
surprised. Both blurring approaches are affected by settings which very
much effect how fast they run - and what ones to pick for a performance
comparison...
> [about the spheres themselves...]
>> Most puzzling to me is the upper left sphere where I made the micro
>> bump_size large (1.5 I think). It happens once bump_size values get over
>> the usual 0.5 limit where normals can start to invert in one or more of
>> the x,y,z directions due the perturbation values being so large compared
>> to the raw normal values(a).
> I didn't know about this inversion problem; I sometimes use a bump_size > 0.5
> for the bumps pattern (for example), just to get interesting effects...and in my
> camera as well. But I didn't actually stop to notice that the effect of the
> normal might not be correct. I guess I need to do some testing.
>
Suppose I see normal inversion away from the primary raw surface normal
as usually a problem, but if not using fancy finish elements maybe OK...
There are partial inversions (perturbation where there is still a
non-zero dot product with the raw surface normal) which are usually OK.
Inverting a camera's normal might be what you want to do for some effect.
Norbert posted an example of the problem from his "well off people's
apartment with walls of VERY expensive artwork" image to which I
responded maybe a a year back. More detail there.
The 0.5 or less is a good rule of thumb, but where you get inversion
depends primarily on the normal pattern itself and no_bump_scale(a) use.
(a) The behavior of no_bump_scale at some point in POV-Ray's development
became inconsistent. Certain shapes with certain transform types are
flattened into a different shape state internally for performance while
others are not - an action no visible to mere users. In other words, the
transforms for some shapes are getting flattened to help performance,
but that transform going away changes the behavior of no_bump_scale...
With povr I've been using the following sort of scene set up to look at
normals and inversion. Using it I've created the attached image using
normal bumps and bump sizes of 0.5, 1.0 and 5.5 left to right. Where you
see red the normal is now perturbed in such a way as to be facing away
from the camera (be facing into the z plane).
//---
#version unofficial 3.8; // povr
global_settings { assumed_gamma 1 }
#declare VarOrthoMult =
2.1/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
orthographic
location <0,0,-2>
direction z
right VarOrthoMult*x*max(1,image_width/image_height)
up VarOrthoMult*y*max(1,image_height/image_width)
}
#declare White = srgb <1,1,1>;
#declare Red = srgb <1,0,0>;
#declare Green = srgb <0,1,0>;
#declare Blue = srgb <0,0,1>;
#declare Plane00 = plane { -z, 0 }
#declare Nrml00 = normal {
bumps
bump_size +5.5
scale 1/6
}
#declare Txtr00 = texture {
pigment {
aoi function_interval
color_map {
[-1.0 Red]
[+0.0 rgb 0]
[+1.0 Green]
}
}
normal { Nrml00 }
finish { ambient 1.0 }
}
#declare Obj00 = object {
Plane00
texture { Txtr00 }
}
//--- scene ---
camera { Camera01z }
object { Obj00 }
//---
> What is considered a 'raw normal value'? Does it depend on the specific pattern
> used?
>
A raw normal is what the shape or surface itself return's at an
intersection on shape's surface, or on surface's surface. The final
direction of which in global space might or might not go through a
transforms from the local 'object's' space. It's not supposed to have
anything to do with the 'normal { pattern } being applied, but the raw
value 'could' be changed by the pattern I guess.
Or a previously perturbed normal could be considered the raw normal for
a normal pattern coming in a chain of normal patterns after the first.
This is sort of thing currently sitting as a few types in povr's bevy
normal pattern collection, but I don't think it happens in official
POV-Ray code.
>> The reflections which are there are no longer fuzzy though, which has me
>> puzzling. A significant number are pointing away / against the raw
>> surface normal sphere rather than mostly being aligned...
> I wonder if part of that result might be due to the typical behavior of normals
> on a sphere object specifically. It somewhat reminds me of the rather odd
> 'normal' results obtained when using POV-ray's 'trace' feature, to place objects
> on a sphere and to find the surface normal at each point. The objects themselves
> are placed correctly-- but the 'handedness' or rotation of each object, based on
> the found normal, switch 'alignments' depending on where they are placed on the
> sphere. (I'm thinking of the behavior of the Point_At_Trans(...) function when
> used as-is to place the traced-on objects, and which 'aligns' them according to
> particular quadrants on the sphere surface.)
>
> My own thinking is that a normal at any point on a sphere does not intrinsically
> 'know' what its handedness should be(?), in order to be consistent over the
> entire surface.
>
My first take is that effect is somewhat different. I think Bald Eagle
(and Tor Olav ?) posted good explanations after looking at that issue a
while ago.
> This is just a wild guess, of course, and may not have any significance for your
> problem.
>
Significance... There is always an itch where I don't understand what I
see. Half the time it means there is a bug (or bugs) in the code. :-)
Bill P.
Post a reply to this message
Attachments:
Download 'pt5_1pt5_5pt5.jpg' (84 KB)
Preview of image 'pt5_1pt5_5pt5.jpg'
|
|
