sharing is fun - Math Surface Shader


    Sep 14 2007 | 1:39 am
    Hi folks,
    Here's a shader and patch I made following the "Calculate Normals In
    Shader" blog entry on http://tonfilm.blogspot.com/ . It should be
    quite easy to plug in other equations from
    This one implements the Tranguloid Trefoil equation:
    wes

    • Sep 14 2007 | 2:22 am
      Nice one :)
      I just picked up the Orange Book today, its been super helpful
      already. Ive been able to properly antialias some of the procedural
      texture generators ive made.
      Might be interesting to put in two formulas and add mix() to morph
      between vertex targets. Hmmm :)
      On Sep 13, 2007, at 9:39 PM, Wesley Smith wrote:
      > Hi folks,
      > Here's a shader and patch I made following the "Calculate Normals In
      > Shader" blog entry on http://tonfilm.blogspot.com/ . It should be
      > quite easy to plug in other equations from
      > http://local.wasp.uwa.edu.au/%7Epbourke/surfaces_curves/ .
      >
      > This one implements the Tranguloid Trefoil equation:
      > http://www.mat.ucsb.edu/~whsmith/ShaderSurface.zip
      >
      >
      > wes
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 14 2007 | 2:30 am
      That's kind of what electric sheep is doing with iterated function
      systems. That system works by having 14 equations each with its own
      weight where they all add up to 1. It morphs between functions by
      changing relative weights. The only trouble with doing that in a
      vertex shader is how many equations th shader can take before it
      becomes slow. I bet it could handle 3 on a good card, maybe more if
      they're not very complicated.
      wes
      On 9/13/07, vade wrote:
      > Nice one :)
      >
      > I just picked up the Orange Book today, its been super helpful already. Ive
      > been able to properly antialias some of the procedural texture generators
      > ive made.
      >
      > Might be interesting to put in two formulas and add mix() to morph between
      > vertex targets. Hmmm :)
      >
      >
      > On Sep 13, 2007, at 9:39 PM, Wesley Smith wrote:
      >
      > Hi folks,
      > Here's a shader and patch I made following the "Calculate Normals In
      > Shader" blog entry on http://tonfilm.blogspot.com/ . It should be
      > quite easy to plug in other equations from
      > http://local.wasp.uwa.edu.au/%7Epbourke/surfaces_curves/ .
      >
      > This one implements the Tranguloid Trefoil equation:
      > http://www.mat.ucsb.edu/~whsmith/ShaderSurface.zip
      >
      >
      > wes
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      >
      >
      >
    • Sep 14 2007 | 2:42 am
      I was actually thinking of staggering it, so each shader has 2
      forumals in it, weighted between 0 and 1,
      so you have shader "A" which has 1,2, shader b has 2 and 3, shader
      c forumals 3 and 4
      when you go from 1 to 2, you can then switch to shader b, go form 2
      to 3, then to shader c which has 3 to 4 ?
      I dunno, does having the shader uploaded but not bound waste GPU
      cycles? I dont think so right?
      Might be a solution :)
      Either way, very cool.
    • Sep 14 2007 | 2:53 am
      erm, formulas. Has someone been spending too many hours on forum-
      las ? *sigh* :)
    • Sep 14 2007 | 2:59 am
      That's cool, Wes. I'm gonna definitely play around with this. And
      thanks for sharing that blog. Some cool stuff there.
      AB
    • Sep 14 2007 | 3:00 am
      I was thinking something similar as well but with 3 instead of 2 but 2
      might be just as good with careful mixing. Doing it this way
      shouldn't be a problem at all GPU cycle-wise.
      wes
    • Sep 14 2007 | 3:46 am
      this looks cool, but i'm shocked and saddened about how slow it is on
      my 1.67g4 albook. is that a surprise? it feels like 5fps.
      On Sep 13, 2007, at 9:39 PM, Wesley Smith wrote:
      > Hi folks,
      > Here's a shader and patch I made following the "Calculate Normals In
      > Shader" blog entry on http://tonfilm.blogspot.com/ . It should be
      > quite easy to plug in other equations from
      > http://local.wasp.uwa.edu.au/%7Epbourke/surfaces_curves/ .
      >
      > This one implements the Tranguloid Trefoil equation:
      > http://www.mat.ucsb.edu/~whsmith/ShaderSurface.zip
      >
      >
      > wes
      >
    • Sep 14 2007 | 3:54 am
      Try reducing the dimensions of the input matrix. I set it quite high.
      BTW, what graphics card do you have? Radeon 9700? If so all of the
      trigonometric stuff might kill it and if the shape takes up large
      portion of the screen, the per-pixel lighting won't help either.
      wes
      On 9/13/07, joshua goldberg wrote:
      > this looks cool, but i'm shocked and saddened about how slow it is on
      > my 1.67g4 albook. is that a surprise? it feels like 5fps.
      >
      >
      > On Sep 13, 2007, at 9:39 PM, Wesley Smith wrote:
      >
      > > Hi folks,
      > > Here's a shader and patch I made following the "Calculate Normals In
      > > Shader" blog entry on http://tonfilm.blogspot.com/ . It should be
      > > quite easy to plug in other equations from
      > > http://local.wasp.uwa.edu.au/%7Epbourke/surfaces_curves/ .
      > >
      > > This one implements the Tranguloid Trefoil equation:
      > > http://www.mat.ucsb.edu/~whsmith/ShaderSurface.zip
      > >
      > >
      > > wes
      > >
      >
      >
    • Sep 14 2007 | 3:56 am
      lower the vert count. its currently at 100 ?
      On Sep 13, 2007, at 11:46 PM, joshua goldberg wrote:
      > this looks cool, but i'm shocked and saddened about how slow it is
      > on my 1.67g4 albook. is that a surprise? it feels like 5fps.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 14 2007 | 10:37 am
      hi wes!
      that
    • Sep 14 2007 | 3:02 pm
      Hi Didi,
      Here's your patch as a shader. Not quite as smooth as nurbs but still nice.
      wes
      ////////////////////////////////////////////////////////////////Shader
      Shader Phong per-pixel lighting in GLSL
    • Sep 14 2007 | 3:44 pm
      I couldn't let Wes have all the fun, so here is a version that does
      Spherical Harmonics. I also threw in my special normal-dependent
      pixel-disposal sauce to make it that much more interesting. Try
      animating the delta value and changing the fig/thresh params. Also, the
      sphere param mixes between a sphere and the distorted shape, and of
      course you can extrapolate. For those of you not running the latest and
      greatest hardware, I recommend lowering the jit.matrix dims. It does
      look really nice at 500x500 though
      I'm not usually a big supporter of mathematical surfaces, but I guess
      I'm beginning to see the light.
      Happy Patching!
      Andrew B.
    • Sep 14 2007 | 3:52 pm
      oops, that patch had a minor issue. This one will work better.
      AB
    • Sep 14 2007 | 4:28 pm
      All it did on my computer was completely kill the framerate for a black screen.
      Max 4.6.3 Jitter 1.6.3
      1.67 Ghz Powerbook G4
      OS 10.4.10
      May just be my problem,
      Keith
      On 9/14/07, Andrew Benson wrote:
      > oops, that patch had a minor issue. This one will work better.
      >
      > AB
      >
      >
      >
      >
    • Sep 14 2007 | 4:44 pm
      Hi Kieth,
      Try lowering the dimensions of the shape matrix to something reasonable
      (say 50x50) or something and see if that helps. It could just be that
      the shader pushes the limits of your graphics card. I'll have a look at
      it later and see if I can streamline the code a little.
      AB
    • Sep 14 2007 | 5:07 pm
      > Try lowering the dimensions of the shape matrix to something reasonable
      > (say 50x50) or something and see if that helps.
      That helped with the framerate. I was confused by the complete black
      jit.window. A little jit.gl.handle and parameter tweaking did the
      trick too.
      Thanks,
      Keith
    • Sep 14 2007 | 5:37 pm
      Andrew Benson skrev:
      > oops, that patch had a minor issue. This one will work better.
      Looks fantastic!
      I have just one issue with it, and that is that the texture params "fig"
      and "thresh" control an effect that seems quite jagged - is there a way
      to antialias there? That would make it even more awesome.
      Andreas.
    • Sep 14 2007 | 5:52 pm
      andrew.
      can you show the web forum some love?
      many thanks to all
    • Sep 14 2007 | 6:04 pm
      Unfortunately, this effect makes use of the "discard" method, which is
      either on or off. Basically, it's just throwing out pixels if the
      output of a formula falls below a threshold. If you don't care about
      depthbuffering, you can use a
      smoothstep(thresh,thresh+fwidth(goop)*fade,goop); and apply that to the
      glFragColor alpha.
      If you do want to keep the depthbuffering and need antialiasing, you
      could always render to a double-size texture and do averaging
      downsamples, as has been discussed previously.
      Best,
      Andrew B.
    • Sep 14 2007 | 6:50 pm
      Oh, sorry. Here you go.
      AB
    • Sep 17 2007 | 1:16 pm
      Here's a random question about this... not to provoke an argument,
      but simply because I'm always curious about the "best" way of doing
      anything.
      Why do all this in a shader, why not use jit.expr to calculate
      geometry for surfaces and then the normals? Is there a benefit to
      first calculating a normal-distribution-based coordinate spread for a
      plane, and then using that as input into a shader?
      I have a friend who does a lot of OpenGL programming, and he swears
      by using only vertex arrays (especially cached) and standard opengl
      blend modes. But he doesn't know shaders well, I feel like there
      could be something he's missing.
      Cheers
      Evan
      On Sep 14, 2007, at 2:39 AM, Wesley Smith wrote:
      > Hi folks,
      > Here's a shader and patch I made following the "Calculate Normals In
      > Shader" blog entry on http://tonfilm.blogspot.com/ . It should be
      > quite easy to plug in other equations from
      > http://local.wasp.uwa.edu.au/%7Epbourke/surfaces_curves/ .
      >
      > This one implements the Tranguloid Trefoil equation:
      > http://www.mat.ucsb.edu/~whsmith/ShaderSurface.zip
      >
      >
      > wes
    • Sep 17 2007 | 2:51 pm
      On Sep 17, 2007, at 3:16 PM, evan.raskob [lists] wrote:
      > Here's a random question about this... not to provoke an argument,
      > but simply because I'm always curious about the "best" way of doing
      > anything.
      I guess my general practice is to let the system breathe... So stuff
      as much as you can on a GPU, until it strats to choke.
      > Why do all this in a shader, why not use jit.expr to calculate
      > geometry for surfaces and then the normals? Is there a benefit to
      > first calculating a normal-distribution-based coordinate spread for
      > a plane, and then using that as input into a shader?
      It is simple, and since the vertices are sent only once - there's
      almost no performance hit.
      Also, as far as I know, shaders are incapable of creating new vertices.
      > I have a friend who does a lot of OpenGL programming, and he swears
      > by using only vertex arrays (especially cached) and standard opengl
      > blend modes. But he doesn't know shaders well, I feel like there
      > could be something he's missing.
      he's missing a lot! Many of the patches posted lately on the list
      would be very hard, if not impossible, to recreate while using only
      GPU without the shaders.
      just my 0.2RSD
      nesa
    • Sep 17 2007 | 3:30 pm
      > > Why do all this in a shader, why not use jit.expr to calculate
      > > geometry for surfaces and then the normals? Is there a benefit to
      > > first calculating a normal-distribution-based coordinate spread for
      > > a plane, and then using that as input into a shader?
      >
      Imagine doing this:
      x = 2 sin(3 u) / (2 + cos(v))
      y = 2 (sin(u) + 2 sin(2 u)) / (2 + cos(v + 2 pi / 3))
      z = (cos(u) - 2 cos(2 u)) (2 + cos(v)) (2 + cos(v + 2 pi / 3)) / 4
      with jit.expr at 30fps on a 50x50 grid. You're framerate will crawl
      if not die if you do it on the CPU. On the GPU you can warp the
      coordinate range and other fun stuff dynamically for smooth
      animations. jit.gl.mesh does use VBOs under the hood for sending the
      planar data so that is also fast.
      > It is simple, and since the vertices are sent only once - there's
      > almost no performance hit.
      > Also, as far as I know, shaders are incapable of creating new vertices.
      >
      Not entirely true. With Geometry shaders, you can generate quite a
      large number of vertices on the GPU.
      >
      > > I have a friend who does a lot of OpenGL programming, and he swears
      > > by using only vertex arrays (especially cached) and standard opengl
      > > blend modes. But he doesn't know shaders well, I feel like there
      > > could be something he's missing.
      VBOs are definnitely best practice for dispatching data to the GPU but
      shaders are required for complex rendering effects. Blend modes are
      nice but limited. For example, you can't do per-pixel lighting with
      just VBOs and blend modes.
      wes
    • Sep 17 2007 | 5:10 pm
      > Not entirely true. With Geometry shaders, you can generate quite a
      > large number of vertices on the GPU.
      ah yes!(that is too new for my hardware:)
      also, how would one do that with jitter?
    • Sep 17 2007 | 6:10 pm
      > also, how would one do that with jitter?
      Wait for a version of Jitter that supports it.
      wes
    • Sep 18 2007 | 2:37 am
      Hiya peepz,
      I've been following this thread for a while and it is really fun.
      This is my first attempt at 3D open GL, so I am having quite a time
      with it. I sat and watched Dan Vatsky at Share the other week and we
      were wondering why it isn't possible to morph a 3D shape he had
      designed in maya in Jitter. And you guys point us in the some near
      direction of that now!
      Basically I wrote the shader to mix() between two of the shapes
      documented on the website mentioned in the beginning of this thread.
      Values for the param "sphere" - 0. shows the owl shape and 1. shows
      the mobius strip. After some tuning of the incoming points each
      formula seems to work and the fade does too. What I am having
      difficulty with is the lighting and adding a video texture.
      Am I right to assume that the lighting and texturing is done for each
      point on the shape (and only one "side") and not as a shape in
      general and that is why the lighting and texturing don't quite work?
      Surprisingly I could figure out the math, but I am fairly new to
      this. Any explanation on what is happening with lighting and
      texturing and how it might work would help.
      Thanks again for all the sharing and the great ideas on the list.
      (())_n
    • Sep 18 2007 | 2:51 am
      Nice. Here's a question for you:
      How do you imagine the video on the form looking? Is is mapped to the
      surface directly? Is it reflection mapped? For the former, you will
      have to generate texture coordinates in some fashion. The simplest
      way it linearly with the input points. For the latter, just take the
      fragment shader portion of the refract.reflect shader I posted last
      week and it should work.
      wes