Forums > Jitter

[feature request:] see example vs jit.gen in mesh

Dec 13 2013 | 6:47 am

hello team cyclig74, do you intend to create a object?

In the following example, I did a little test performance between and jit.gen with the same code. And a 300×300 matrix with the CPU (in this example) does not follow.
I know that is a pixel shader but it would be great to have a vertex shader to generate mesh with the GPU.

There are probably other ways to do the same with the most efficient CPU so but would open new perspectives.


Dec 16 2013 | 8:24 am

+ 1

Dec 17 2013 | 12:59 pm


Dec 30 2013 | 3:22 am

we are only 3 to dream of a

Dec 30 2013 | 8:14 am

thanks for the request. noted.

Dec 30 2013 | 8:48 am

thank you for your attention rob, I’m nervous to see more. will do a lot of things.

and more jit.phys in the GPU too ;)

Jan 03 2014 | 11:48 am


Jan 03 2014 | 10:40 pm

Getting pixel and vertex shaders done in gen + export features would open up new worlds

Jan 04 2014 | 6:58 am


Jul 03 2014 | 7:23 pm


Jul 04 2014 | 1:53 am


Jul 04 2014 | 4:13 am

+1000 ;-)

LLT, in your patch, if you’re benchmarking the two approaches, you should have turned off vsync in jit.window. Nice patch, by the way!

Jul 15 2014 | 8:34 am

On my sample code,’s cpu usage is more less than jit.gen’s.
but, jit.gen’s fps is larger than’s.

CPU usage : 60% / jit.gen : 140%

fps(@sync 0) : 70fps / jit.gen : 100fps

-- Pasted Max Patch, click to expand. --

  • This reply was modified 2 years by  mirrorboy.
Jan 28 2015 | 11:06 pm


Feb 07 2015 | 9:10 am

+ 1

Feb 07 2015 | 9:36 am


Dec 26 2015 | 5:12 pm

Would love this to happen

+ 1

Jun 21 2016 | 10:32 pm

+ 1

Jun 21 2016 | 11:28 pm

[] ?

Jun 22 2016 | 7:09 pm

I also appreciate the symmetry of providing a something for the vertex shader, to complement how can do some of what a fragment shader can do. But apart from saying +1, I would want to know what would a actually look like. If the goal is to replace GLSL-coding with visual patching, then the main features found in vertex shaders need to be covered. The program would run per vertex. Uniforms are taken care of by params. The matrix inputs (in 1, in 2, etc.) I presume would map to position, normal, color, etc. other arbitrary GL-vertex attributes coming in. Fine. But how would you get textures into the, distinguishing them from attribute matrices? What are the outputs? There’s no mechanism for varyings, and more importantly there’s no corresponding mechanism for varyings in In fact, I think we’d really need a separate to make this work. And, how do we get these into the scene? Does itself behave a bit like a (being an ob3d object in its own right), or does it work more like a that other ob3d’s can use?

Jun 22 2016 | 7:25 pm

(being an ob3d object in its own right)
replace the jit.matrix all together. basically be a functions the same but runs on the gpu.

Jun 22 2016 | 11:11 pm

But what does that mean? The nearest thing to a jit.matrix on the GPU is a texture, and we already have et al. The next nearest thing (and perhaps closer to the OP) is a vertex buffers, but OpenGL isn’t really designed for arbitrary computation on vertex buffers (it’s mostly assumed that happens on the CPU, or in vertex shaders, which as I noted have their own set of weird constraints). Beyond that there’s GPGPU, but that still seems messed up enough to be a support nightmare.

And anyway, jit.matrix isn’t an ob3d. Did you mean replace Are you all just looking for a way to turn texture data into geometry?

Jun 22 2016 | 11:29 pm

Maybe that was a bit negative. Probably the most interesting path is OpenCL, which *can* modify GL-based vertex buffers in-place with arbitrary code, and thus would be a suitable target language; and maybe it is less flaky and finicky than it was when I tried it a few years ago. But it’s still a bit of a vague request. What would be some examples of what you’d like to do with a hypothetical

Jun 23 2016 | 8:44 am

i’m honestly not sure i’m on topic, but i’d like to see something akin to [history] and [delay] operator of the audio domain, or ability to reference external textures (matrices ?) for time-dependant operations….doing this kind of feedback operations with chained is not always easy. keep in mind it’s a naive feature request

Jun 23 2016 | 2:09 pm

Basically I am also naive in the true details of how things work, I don’t know glsl. Just use some of it features with

Basically I know , there are pixel shaders and vertex shaders.

and basically when one does particle type work , or depth map mesh
It is better to do all the calculation on the GPU. Right now we are stuck doing quite most of this using matrices on CPU.

Even with jit.bfg and such,
Could there be a way get this happening all on a the GPU.

Sorry , holes in my knowledge keeps me from being more precise.


Jun 27 2016 | 3:44 am


@graham in my case I just need a with texture inputs instead of matrixes (with the same data inside). It could be an update of with texture and matrix inputs.

I’ve developed with Mathieu Chamagne some particules tools with jit.gen that we could be easily port to (as it could have several outputs now), but I use to display those particules, and it takes only matrixes in input.
A few month ago, I have used a fluid model that I’ve created with several (see here) to control particules motion (with the fluid velocity map). The problem is that I had to copy the velocity map to the CPU to get it work. It will be better for me to keep all in GPU.


Jun 30 2016 | 7:48 pm

As far as I know there’s no standard OpenGL way to generate geometry from textures directly on the GPU.

However, I did spend a few days last week looking into OpenCL, and it seems likely that one could generate vertex buffer data (i.e. geometry) from an OpenCL compute program, entirely on the GPU; even potentially from texture-based inputs. I’m going to keep investigating this as & when I have time over the coming weeks.

Jun 30 2016 | 10:47 pm

I’ve used vertex shaders primarily for displacement maps applied to vertices of objects, sampling input textures but interpreting them as modifiers for vertex position along arbitrary vectors. The more interesting experiments made use of dynamic normal maps generated with jit.bfg, and calling to gl_normal in the displacement routine.

I’d vote for to be a replacement for, so that they could be applied to any OB3D, not just I suppose that a object might also be needed, but I’m not sure of how the linkages would work.

I’d be excited to see vertex buffers exposed in any fashion within Max.

Jul 02 2016 | 12:24 am

Hi Jessie,

Would you mind sharing a basic example of the setup you describe? I’ve always struggled with this and some insight would be of great assistance :)

And yes +1 for (for max6 too please :p )


Sep 14 2016 | 8:52 am


OpenCL+ vertex buffers+ GPU Bullet Physics :)

Sep 28 2016 | 11:55 am

hey guys, our friend over in the jitter facebook group just posted this tutorial demonstrating vertex texture fetching using

i’ve reworked the original patch posted at the top of this thread to show how to use vertex texture fetches with to generate geometry directly from a texture without a matrix readback. the trick is to set rectangle 0 on the (or input and output textures. this forces the texture dims to be a power of two, so probably best to start with POT dims on the input matrices (although not necessary).

this also means you sample using texture2D rather than texture2DRect in the vertex program.

hope this helps those that want to use textures to generate geometry.

Sep 29 2016 | 6:53 am

Rob, thank you. That is incredibly helpful.

Sep 29 2016 | 7:42 am

endless thx rob

Sep 29 2016 | 1:22 pm

So automatically is the texture number 0! Cool insight Rob

Sep 29 2016 | 8:09 pm

Thanks for sharing this Rob, its amazing!
So, I manage to add an amount param to control xyz displacement individually to achieve a Rutt-Etra like fx more efficiently. Although it works, I feel like I’m doing some things wrong. Can anyone confirm? Attached goes a gen version of xyz.displacement, vade’s Rutt-Etra patch and my mod of Rob’s vtf.jxs shader so you can compare.

Thx in advance


Sep 30 2016 | 9:29 am

I just realised that there is a typo in the vtf.jxs I shared yesterday. Not big deal, still works but should be 1. instead of 100. in line 25.

Sep 30 2016 | 9:32 am

hey kevin, this looks great to me. what are you thinking is wrong?
how’s the performance compare to the matrix version?

Sep 30 2016 | 11:25 am

Hi Rob, with 1280×720 and my Macbook i5 late 2013:

– gen version (all cpu): 19fps.
– gl.pix to geometry without matrix readback: 35fps.
– gl.pix to geometry with matrix readback: 17fps.

Viewing 38 posts - 1 through 38 (of 38 total)

Forums > Jitter