> Ahh, but that's the beauty of mine is it works in 3.5 and is all done with
> procedurals (hence the orthographic camera)
slope_maps to detect the edges?

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Slime wrote:
> So, how do these work? Are they functions that take the
> cross product of the normal with the vector from the camera?

The dot product would be cheaper and more appropriate.

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

whats the difference between slope_map and slope pattern?

--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local
i=asc(substr("oqshilacefg",r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4pigme
nt{rgb 10}}_(r+1)#end#end _(1)//KL

Post a reply to this message

> whats the difference between slope_map and slope pattern?

slope_map is for normals, it maps the apparent slope of the surface normals.

slope pattern is a pattern that is dependent on the slope of the surface of
the object applied to.


-tgq

Post a reply to this message

> slope_map is for normals, it maps the apparent slope of the surface
normals.
>
> slope pattern is a pattern that is dependent on the slope of the surface
of
> the object applied to.

Sounds similar to me. I've fiddled with this myself recently, but not enough
to understand. You mean, a slope pattern may use a slope_map, like pigment
bumps take a pigment_map..? Documentation is a little complex I think.

Regards,
Hugo

Post a reply to this message

> Sounds similar to me. I've fiddled with this myself recently, but not
enough
> to understand. You mean, a slope pattern may use a slope_map, like pigment
> bumps take a pigment_map..? Documentation is a little complex I think.

I'll try this again.

You understand what surface normals are.  They are a perturbance of the
surface to give it a bumy appearance without actually changing the surface.
When using gradient pattern pattern as a normal pattern, by default you get
a sawtooth appearance:

 /| /| /| /|
/ |/ |/ |/ |

if you set the waveform to sine_wave, scallop_wave, cubic_wave , etc.  the
normal gains the associated appearance.  Slope_map furthers this to allow
you to specify your own surface normal waveform.
from 6.7.2.1:

    slope_map {
      [0   <0, 1>]   // start at bottom and slope up
      [0.5 <1, 1>]   // halfway through reach top still climbing
      [0.5 <1,-1>]   // abruptly slope down
      [1   <0,-1>]   // finish on down slope at bottom
    }
would give the same appearance as the triangle_wave waveform

    slope_map {
      [0    <0.5, 1>]   // start in middle and slope up
      [0.25 <1.0, 0>]   // flat slope at top of wave
      [0.5  <0.5,-1>]   // slope down at mid point
      [0.75 <0.0, 0>]   // flat slope at bottom
      [1    <0.0, 0>]   // finish flate slope at bottom
    }
this would give a a more complex normal.

see 'slopemap1.png' and 'slopemap2.png', the previos normals and slope_maps
are applied to a cylinder using the wood pattern. the bump_size has been
exagerated.

The slope pattern is not related to normals at all, it is a pattern not a
map.  It is applied the same as any other pattern, i.e, it can be used for
pigments, textures, normals, etc.  The slope pattern calculates the slope of
the object's surface at each point and applies the texture according to the
slope value. If you had a red sphere and wanted it white everywhere the
slope was less than 45degrees, you calculate the position by hand and use a
gradient pattern, but if you wanted to do it to, say, a blob shape, it would
be very difficult to do this way.  If we use the slope pattern it is very
easy:
    pigment{
      slope y
      color_map{
        [0.0 red 1]
        [0.75 red 1]
        [0.75 rgb 1]
        [1.0 rgb 1]
      }
    }

if we apply this to any shape the object will be white anywhere its slope
(relative to the direction vector 'y') is less than 45degrees see
'slope1.png'

the direction vector (y in this case) represents the direction the slope is
based on

slope values
0.0 = negative horizontal slope
0.25 = -45 degrees
0.5 = vertical
0.75 = 45 degrees
1.0 = positive horizontal
...etc.

this pattern can be very useful in several applications.  One place I use it
constantly is to apply dust to objects:

#declare TDusty=
texture{
  pigment{
    slope y
    color_map{
      [0.5 rgbt 1]
      [1.0 rgbt<0.65,0.65,0.60,0.75>]
    }
    poly_wave 1.1
  }
  finish{
    ambient 0
    diffuse 0.85
    brilliance .33
  }
}

see 'Slope2.png'

I hope this explains a little better.

-tgq

Post a reply to this message

Attachments:
Download 'slope2.png' (14 KB) Download 'Slope1.png' (14 KB) Download 'Slopemap1.png' (8 KB) Download 'slopemap2.png' (11 KB)

Preview of image 'slope2.png'

Preview of image 'Slope1.png'

Preview of image 'Slopemap1.png'

Preview of image 'slopemap2.png'

> whats the difference between slope_map and slope pattern?
A lot... :)
I meant the slope pattern of course... :)

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"The United States Government just asked us to save the world. Anyone wanna
say no?"

Post a reply to this message

Hi Tincanman,

Thank you, wow that was a real explanation! I got it now. Yes, actually I
got the part about slope patterns just a few days ago, and this is a great
feature. I just didn't know about slope_maps. Now I understand, thank you!

Regards,
Hugo

Post a reply to this message

Thanks !

for the keyboard - remove the keys and just plain water to clean the
mechanisms (perhaps some light soap added) will get you going again,
keyboards are normally very sturdy and can take some water, more complex
liquids (especially with sugar (Coke etc.)) are more problematic

Wolfgang

"Andrew" <ast### [at] hotmailcom> wrote in message
news:3cc8497b@news.povray.org...
> I_think_that_the_effect_should_be_called_"cel_shading",
> as_it_emulates_traditional_cel_animation_(ie_cartoons).
> Cel_is_of_course_short_for_celluloid,_the_medium_on
> which_"normal"_animation_is_drawn.
>
> (Underscores_courtesy_of_my_clumsy_friend_who_spilt
> beer_on_the_keyboard_at_the_weekend,_rendering_the
> space_bar_useless...)
>
> "Wolfgang Manousek" <wol### [at] hotmailcom> wrote in message
> news:3cc7aa18@news.povray.org...
> > well - nice ..
> >
> > can someone point me to a description of the term cell-shader?
> >
> > thx
> > Wolfgang
> > "Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in
> message
> > news:3cc7709d@news.povray.org...
> > > Sometimes I wonder why I'm always copying other people's work...
> > > Maybe because I don't need inspiration for that, and inspiration is
> > exactly what
> > > I don't have these days...
> > >
> > > Anyway, this is my version of the cell-shader.  It works with
> > > perspective-cameras.
> > >
> > > Comments welcome, as always :)
> > >
> > > cu!
> > > --
> > > camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro
> L(b,e,k,l)#local
> > C=0
> > > ;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient
> 1}}#local
> > C=C+1
> > > ;#end#end
> > L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
> > > <.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK
> > http://www.povplace.be.tf
> > >
> > >
> > >
> >
> >
>
>

Post a reply to this message

Nice. Did you 'invented' this shader by yourself? ARM book contains 
examples of such shaders. Unfortunately most advanced of them can't be 
applied to POVMan, as POVMan doesn't support surface derivatives, which 
are necessary for calculation of cel lines with uniform width. As it 
could be seen on this picture and other 'pure-povray' approaches, line 
widths depend from object geometry. Perhaps better results could be 
achieved with specific patch by J. Grimbert, but this requires as well 
surface derivative calculation...

Post a reply to this message