Looking to improve vertex displacement with fractal noise on a sphere

    Jan 09 2016 | 5:54 pm
    I'm aiming for a spherical amoeba shape. So far i've been able to create this:
    which is pretty good. but every so often I can get some broken seams. One heinous break that was happening earlier was this:
    I figured out that was caused by my input noise texture to my [jit.gl.mesh] not having matching boundaries on the vertical edges. Also making sure everything had similar dimensions was key. So I mirrored my noise texture along the center vertical edge/y-axis, so it looked like this:
    I sure if I mirror it along the x-axis as well, to get this 4 corner/quadrant mirroring thing, it should fix all seams....
    However with all this mirroring, I lose some of the randomness fractal qualities of the original noise and the resulting vertex displacement doesn't look as great. I've taken a look at the method used in this thread: https://cycling74.com/forums/jit-gl-model-keep-mesh-coherent-when-applying-vertex-manipulations/ but applying it here doesn't really quite work the way I want it to. Maybe I'm going about it wrong.
    An insight into better vertex displacement is much appreciated. Here's my patch:

    • Jan 09 2016 | 6:03 pm
      wow, i'm not sure whats going on with this forum and editing posts, but since i'm not allowed to edit my original post anymore and couldn't figure out the proper formatting for posting an inline image, here's the direct links to the 3 images referenced above
      -also i was a little unclear in my original post. What i meant by the unmatched boundaries is that the image's left and right side weren't the same, so if you lined up duplicate images of them it wouldn't look continuous. Having the perfect mirrored image (a circular/polar coordinate pattern might work better) was the key to unbroken seams when using my method of vertex displacement. The "similar dimensions" comment was basically referencing the fact that the sphere and the noise texture should have the same dimensions.
    • Feb 04 2016 | 6:26 pm
      This patch crashes max 7 every time i try to open it.
    • Feb 05 2016 | 4:36 am
      weird, it works fine on mine. I took a screenshot to show you my patching:
    • Feb 05 2016 | 1:07 pm
      which version of Max do you have ? Still crashes my system. I have the latest version.
    • Feb 05 2016 | 1:09 pm
    • Feb 05 2016 | 1:12 pm
      maybe that auto-enable on jit.world is breaking it. Here it is without it:
      I'm also getting an error: "jit.glue: mismatch type", let me look into that
      edit: ok just added a plane and type information ("1 float32") to the [jit.glue], so no more errors. here it is, hopefully this works:
    • Feb 06 2016 | 6:29 pm
      No clue whats going on. Both patches crash max instantly with me. Have you removed any externals that are in there ?
    • Feb 07 2016 | 4:20 am
      ok i removed the syphonserver external, but honestly that shouldn't break it, it should just show up as a missing external/object.
      one interesting thing that does happen when i open the compressed patch is I get this message: "viddll.engine version: 0.1.0" despite having no [jit.movie @engine viddll] objects, and my preference is set to "avf". So if the patch below doesn't work, try installing the viddll package, and if that fixed it, i should submit a bug report about it. If you already have viddll, and this final patch still doesn't work, I can send in my patch to C74 team and see what they can find.
      thanks for sticking with me on this. if nothing else works and you find yourself bored, you can try to recreate my patch from the screenshot :)
    • Feb 07 2016 | 5:46 am
      Hey I can open your patches with no problem (Yosemite 10.10.5 with Max 7.1.. with viddll installed). Nice work, btw... I would be inclined to use [jit.gl.pix] to generate 3d noise directly... using modified fragments from something like this: https://www.shadertoy.com/view/4lfSzs
    • Feb 07 2016 | 6:10 am
      Ya, i definitely want to move forward from jit.bfg into the GL objects. That shader looks real nice, but unfortunately i'm not too experienced with integrating shaders into Max, still have yet to jump into that awesome tutorial about porting shaders. Is that shader you linked able to be ported completely into Max to get a render looking the same as the one on shadertoy? Because that would be pretty awesome. However, you're right, i could use a fragment (the noise section "// iq's 3D noise" i think) and be alright with that. But that shader as a whole is sexy. Maybe i'll jump into those tutorials tonight. cheers.
    • Feb 07 2016 | 7:24 am
      Hmm.. I don't think it's possible to port that particular shader because of the array in line 56. I was mostly just throwing something on the table. The closer I look at the shader, the less useful it appears.. but you get the general idea.
      Search for "seamless perlin". Some good info here:
      Sorry I can't help you more. If anything, I'm the one learning from your patch. :)
    • Feb 07 2016 | 8:36 am
      thanks for the link. will check it out.
      Generating the sphere vertices inside of [jit.gen] using the [sphere] gen-object and then multiplying them by noise created inside [gen] as well (need to find a fractal noise / perlin shader for this) should output the seamless mesh i need for [jit.gl.mesh]... i don't really know though...
      When i see how [jit.gl.mesh] works with the input sphere matrix, by using the first column of pixels from the matrix and layering over the last column of pixels from the matrix so essentially two vertices (one pixel from the first column is a vertex, and the pixel in the last column that is on the same row is the other vertex) are sharing the same xyz position, AND the top row of pixels all correspond to the same vertex (but again is truly just a bunch of vertices stacked on top of each other, rather than being a single one), same with the bottom row [edit: think i'm wrong about the bottom row]. It makes me wonder if i should just give my input matrix a single pixel white border on top and bottom, so all the stacked vertices will be in the same position (and the mirroring i'm already doing is taking care of the first column and last column being seamless).
      sorry if that is confusing, it's hard to explain. I can create an example showing you what I mean if you want. I might actually create that bordered matrix and see how it looks, and post it up here if it looks nice.
      on another note, using [jit.gen] to create the matrix that gets pumped into the gl.mesh, makes weird things happen to culling back/front faces (aka it doesn't cull at all)
    • Feb 08 2016 | 5:21 pm
      ok, here's my example for understanding how the matrix coordinates get mapped to the sphere and how the x-boundary matrix coordinates that correspond to the vertices along the 0°/360°/prime meridian are actually disconnected and not seamless. The north and south poles are similar in the fact that it's actually multiple vertex points stacked on each other, rather than being a single point for the pole.
      to use my patch, first bang out the matrix from the gridshape (this can also be used as a reset if your mesh becomes too warped). at the bottom of the patch is a [jit.cellblock] and if you open up the gate, it will show each vertex points x/y/z coordinate depending on which plane you are look at (plane 0/1/2). There is a gate because the cellblock might be a little intensive on the processing and you might not always want to keep it active.
      In the Pole section, you can adjust each one of the stacked pole points and it's z position. north pole all have the original z-position value of 1.0, and south pole are -1.0. The starting rotation position of the sphere makes it a bit tricky to see how the pole gets affected, so make sure to rotate it in the jit.window to get a better view.
      In the Meridian section you can control either the 0° meridian (first column of the matrix), 360° meridian (last column of the matrix), or the 180° degree meridian (middle column of the matrix). You can affect the vertex point along each meridian and how far it is extruded. Set the multiplier first and then enter the coordinate you want to affect. Try multiplying the 0°/first meridian coordinates 0 through 19 by 2.0 (i'd suggest incrementing the coordinate number box using the up arrow), then rotate the sphere a bit. You should be able to see a clear break along the meridian, and be able to actually look inside the sphere. Now do the same multiplication along the 360°/last meridian. it should look resealed and a nice extruded arc. Reset the sphere mesh, and finally do this same multiplication along the 180° meridian. This time the mesh is not broken, and looks similar to when both 0° and 360° meridians (which should share the same exact vertices) were extruded together.
      Hopefully the weirdness of using a matrix to create a mesh, and affecting that matrix to affect the mesh, is clear through this patch and walkthrough. Definitely looking for unbroken ways to do this all in GL land.
      oh and i included a mini [jit.pwindow] to show you how that output matrix looks in RGB.
    • Feb 09 2016 | 3:31 am
      oh, and i meant to add that if the meridian break isn't clear because the rendered perspective looks strange, try changing the poly mode to wireframe (1 1), or cull the back faces or the best way might be to turn on auto_colors for the mesh:
      i should also note that while the 180° Meridian Control says "[10, i]", i actually patched it inside as [9, i], whoops. If you want it actually as [10, i] go and change the three instances of "9" inside that subpatcher to "10"
      here's a bonus ufo i made with that patch:
    • Nov 24 2016 | 11:17 am
      does anybody knows how to get the light work properly with vertex displacement? The light works with the sphere but not with the displacement of the sphere. I found various displacement patches but the light always not work correct. It affect ever only the base shape not the displacement on it.
    • Nov 28 2016 | 3:40 pm
      if you are doing your displacements using jit.matrices to jit.gl.mesh, simply set @auto_normals 1 on your jit.gl.mesh to automatically calculate lighting normals each time a matrix is received.
    • Dec 01 2016 | 11:05 am
      Thanks Rob!! I was trying all attributes but oversee auto_normals. (I guess you mean "using jit.matrices" not like a object named jit.matrices, rather using the jitter matrix)?
    • May 12 2017 | 11:04 am
      interesting work, how did this go on?