See if this is what you're looking for.  It's my best guess so far.

Post a reply to this message

Attachments:
Download 'asteroid_prototype.png' (381 KB)

Preview of image 'asteroid_prototype.png'

On 10/3/19 9:01 PM, Bald Eagle wrote:
> See if this is what you're looking for.  It's my best guess so far.
> 

Good morning. I've been following this discussion as you've been sorting 
out what's needed.

Am I right it's looking like orthographic camera(s) for the 2d image and 
also to generate an rgb normal image for any particular orientation of 
the object?

If yes, did you generate the normal map on the right with the trace 
command? Asking because I've long carried around the question of whether 
trace returns the raw normal or the texture perturbed raw-normal. Your 
image, if done with trace, makes me think it returns the raw normal.

My uses of trace have needed only the raw normals - the shapes I've 
traced have no explicit texture normal applied.

Bill P.

Post a reply to this message

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


> Am I right it's looking like orthographic camera(s) for the 2d image and
> also to generate an rgb normal image for any particular orientation of
> the object?

After hunting down some discussions on this for Blender and Unity, that's the
way it looks to me.
I think that this Godot engine might need an inverted y normal --- but I'm ...

.... wait for it ...


.... waiting for Godot to answer that.       :D

Literally, it needs to get tested out in the Godot rendering engine to see if
it's correct.

> If yes, did you generate the normal map on the right with the trace
> command? Asking because I've long carried around the question of whether
> trace returns the raw normal or the texture perturbed raw-normal. Your
> image, if done with trace, makes me think it returns the raw normal.

I did not - the averaged slope pattern looked simple and was already
implemented, so I went with that for speed and laziness   :D

I was actually reviewing this in my head this morning, and I realized that I
probably introduced some confusion by adding normal {granite scale 1.5} to the
asteroid for an earlier experiment and didn't remove it from the gray asteroid
in the latest comparison.

I just removed that texture normal, and now the surfaces look the same, and
#declare G = function {pigment {granite scale 1.5}} along with
subtracting G(x,y,z).x*0.25 from the noisy sphere function gives me
normal-perturbed versions of both.

So, that indicates that it's purely a geometric / actual raw normal, not a
normal that is modified by the texture.

Attached is the pigment-function subtracted isosurface.

Post a reply to this message

Attachments:
Download 'asteroid_prototype.png' (1044 KB)

Preview of image 'asteroid_prototype.png'

tweaked slope pigment based on wikipedia.

No texture normal or additional pigment function normal.

Post a reply to this message

Attachments:
Download 'asteroid_prototype.png' (210 KB)

Preview of image 'asteroid_prototype.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> tweaked slope pigment based on wikipedia.
>
> No texture normal or additional pigment function normal.

See attached image - scene file is included below.

This texture should create a suitable bump map, when using an orthographic
camera facing in the +z direction.

You need to use 'assumed_gamma 1.0' in the scene file, and 'File_Gamma=1.0' in
the command line preserve the correct colors.

I have layered the colors using multiple textures & 'transmit' values, as it was
the first method I found that worked to get proper additive color mixing in
Povray.  Since the 'transmit 0.5' halves the 'base' layer and the 'overlay'
layer, the strength of the colors are doubled before adding them together, so
'rgb<2,0,0>' + 'rgb<0,2,0> transmit 0.5' = rgb<1,1,0>.
As I have to do two transmit layers, the first group is doubled twice.


I suspect the RGB values in a normal map are a direct translation of the xyz
VECTOR values for a normalized vector facing in any direction, rather than the
angle, so the Y value for a vector pointing at 45 degrees up would be 0.707 (Sin
45) rather than 0.5.

Because the slope map values are based on the deviation of the ANGLE from a
reference vector, I need to use 'sine_wave' rather than the default 'ramp_wave'
to get the proper output from the color map - I need equivalent vector values
rather than angle values.

I only need the part of the sine wave from the lowest point to the highest
point, so 'frequency 0.5' is added to use only the first half of the full sine
wave.  'phase 0.25' moves the sine wave along to the correct starting point.
Okay, maybe not the *correct* starting point since it now starts at 1 and
transitions down to 0, but *basically* it works if I reverse the color map
entries...

----------------------------------------------------------------

#version 3.7;

// +w500 +h500 File_Gamma=1.0 Display_Gamma=1.0 +am2 +a0.1

#global_settings{assumed_gamma 1.0}

camera{
    orthographic
    location <0, 0, -10>
    up y*10
    right x*10
    look_at <0, 0, 0>
}

// ----------------------------------------------
// TEXTURES
// ----------------------------------------------
#declare FULL_AMBIENT = finish{ambient 1 diffuse 0}

#declare X_RED =
texture{
    pigment{
        slope x
        sine_wave frequency 0.5 phase 0.25
        color_map{
            [0 color rgb<4,0,0>]
            [1 color rgb<0,0,0>]
        }
    }
    finish{FULL_AMBIENT}
}

#declare Y_GRN =
texture{
    pigment{
        slope y
        sine_wave frequency 0.5 phase 0.25
        color_map{
            [0 color rgb<0,4,0> transmit 0.5]
            [1 color rgb<0,0,0> transmit 0.5]
        }
    }
    finish{FULL_AMBIENT}
}

#declare Z_BLU =
texture{
    pigment{
        slope -z
        sine_wave frequency 0.5 phase 0.25
        color_map{
            [0 color rgb<0,0,2> transmit 0.5]
            [1 color rgb<0,0,0> transmit 0.5]
        }
    }
    finish{FULL_AMBIENT}
}

#declare XYZ_NORMAL =
texture{X_RED}
texture{Y_GRN}
texture{Z_BLU}

// ----------------------------------------------
// SCENE
// ----------------------------------------------

sphere{
    <0, 0, 0>, 2.4
    texture{XYZ_NORMAL}
    translate <-2.5, 2.5, 0>
}

intersection{
    plane{<  0,  1, -1>, 0}
    plane{<  0, -1, -1>, 0}
    plane{< -1,  0, -1>, 0}
    plane{<  1,  0, -1>, 0}
    plane{<  0,  0, -1>, -1}
    plane{<  0,  0,  1>, 2.4}
    texture{XYZ_NORMAL}
    translate < 2.5, 2.5, 0>
}

cone{
    <0, 0, 0>, 2.4, <0, 0, -2.4>, 0
    texture{XYZ_NORMAL}
    translate <-2.5, -2.5, 0>
}

#declare f_sphere = function{internal(61)}
#declare f_noise3d = function {internal(76)}

isosurface{
    function{
        f_sphere(x,y,z,2.5)
        + f_noise3d(x,y,z)*0.5
        + f_noise3d(x*8,y*8,z*8)*0.1
    }
    contained_by{sphere{<0, 0, 0>, 4}}
    threshold 0
    accuracy 0.001
    max_gradient 2
    texture{XYZ_NORMAL}
    translate < 2.5, -2.5, 0>
}

Post a reply to this message

Attachments:
Download 'normal_test.png' (123 KB)

Preview of image 'normal_test.png'

On 10/16/19 4:51 AM, NPC wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
...
> 
> #declare f_sphere = function{internal(61)}
> #declare f_noise3d = function {internal(76)}
> 
...
> 
Cool. Results match the examples off that posted web site to my eyes for 
orientation of colors.

Pulling the two lines above out of functions.inc is unconventional. Was 
this done to avoid the new to v38, version after default warning 
message(s)?

Bill P.

Post a reply to this message

"NPC" <nomail@nomail> wrote:

> I have layered the colors using multiple textures & 'transmit' values, as it was
> the first method I found that worked to get proper additive color mixing in
> Povray.  Since the 'transmit 0.5' halves the 'base' layer and the 'overlay'
> layer, the strength of the colors are doubled before adding them together, so
> 'rgb<2,0,0>' + 'rgb<0,2,0> transmit 0.5' = rgb<1,1,0>.
> As I have to do two transmit layers, the first group is doubled twice.

Using average worked well for me (after much painful struggling)  ;)

http://news.povray.org/povray.advanced-users/thread/%3Cweb.5d2ceb7afbee6e2d4eec112d0%40news.povray.org%3E/


> Because the slope map values are based on the deviation of the ANGLE from a
> reference vector, I need to use 'sine_wave' rather than the default 'ramp_wave'
> to get the proper output from the color map - I need equivalent vector values
> rather than angle values.
>
> I only need the part of the sine wave from the lowest point to the highest
> point, so 'frequency 0.5' is added to use only the first half of the full sine
> wave.  'phase 0.25' moves the sine wave along to the correct starting point.
> Okay, maybe not the *correct* starting point since it now starts at 1 and
> transitions down to 0, but *basically* it works if I reverse the color map
> entries...

THAT is some pretty slick work, there.   Nicely done.
I would not have ever thought of using those tools - as I almost never play with
them.
A simple and elegant solution.

I may have to investigate some of this further one day and see if I can make
some interesting scenes that visually "show how this works".

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/16/19 4:51 AM, NPC wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> >
> > #declare f_sphere = function{internal(61)}
> > #declare f_noise3d = function {internal(76)}
> >
> ...
> >
> Cool. Results match the examples off that posted web site to my eyes for
> orientation of colors.
>
> Pulling the two lines above out of functions.inc is unconventional. Was
> this done to avoid the new to v38, version after default warning
> message(s)?
>
> Bill P.

I don't have v3.8 - I just prefer to pull out the two or three functions I'm
going to use instead of including all of them.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Using average worked well for me (after much painful struggling)  ;)
>
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5d2ceb7afbee6e2d4eec112d0%40news.povray.org%3E/
>

>
> THAT is some pretty slick work, there.   Nicely done.
> I would not have ever thought of using those tools - as I almost never play with
> them.
> A simple and elegant solution.
>
> I may have to investigate some of this further one day and see if I can make
> some interesting scenes that visually "show how this works".

Thanks.  I cleaned it up a little bit to use 'average' with a pigment map to
combine the slope patterns instead of layering three separate textures, and
changed the 'phase' so the color maps run in the correct direction this time.

When using 'average' to combine colors, you need to multiply the base color by
the total number of colors being averaged, in order to preserve the full
strength of the output colors.  See below, each of the rgb values are set to '3'
because I am averaging 3 colors together.

I guess the 'average' function *assumes* all input colors are going to be a
maximum of '1', and scales the output to be a maximum of '1', so increasing the
'weighting' value for all colors makes no difference.

// ----------------------------------------------------------------
#version 3.7;
//+w500 +h500 +am2 +a0.1 File_Gamma=1.0 Display_Gamma=1.0
#global_settings{assumed_gamma 1.0}

// ----------------------------------------------------------------
// TEXTURES
// ----------------------------------------------------------------

#declare X_RED =
pigment{
    slope x
    sine_wave frequency 0.5 phase -0.25
    color_map{
        [0 color rgb<0,0,0>]
        [1 color rgb<3,0,0>]
    }
}

#declare Y_GRN =
pigment{
    slope y
    sine_wave frequency 0.5 phase -0.25
    color_map{
        [0 color rgb<0,0,0>]
        [1 color rgb<0,3,0>]
    }
}

#declare Z_BLU =
pigment{
    slope -z
    sine_wave frequency 0.5 phase -0.25
    color_map{
        [0 color rgb<0,0,0>]
        [1 color rgb<0,0,3>]
    }
}

#declare NORMAL_MAP =
texture{
    pigment{
        average
        pigment_map{
            [1 X_RED]
            [1 Y_GRN]
            [1 Z_BLU]
        }
    }
    finish{ambient 1 diffuse 0}
}


// ----------------------------------------------------------------
// SCENE
// ----------------------------------------------------------------

#declare fo_sphere = function{internal(61)}

isosurface{
    function{fo_sphere(x,y,z,1)}
    contained_by{sphere{<0, 0, 0>, 2}}
    accuracy 0.001
    max_gradient 2
    texture{NORMAL_MAP}
}

camera{
    orthographic
    location <0, 0, -10>
    up y*3
    right x*3
    look_at <0, 0, 0>
}

Post a reply to this message

Attachments:
Download 'normal_test.png' (32 KB)

Preview of image 'normal_test.png'