+ 1

+1

we are only 3 to dream of a jit.gl.vertex?

thanks for the request. noted.

thank you for your attention rob, I'm nervous to see more.

jit.gl.vertex will do a lot of things.

and more jit.phys in the GPU too ;)

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

+1

+1

+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!

On my sample code,

jit.gl.pix's cpu usage is more less than jit.gen's. but, jit.gen's fps is larger than jit.gl.pix's.

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

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

+1

Would love this to happen

+ 1

+ 1

[jit.gl.gen] ?

I also appreciate the symmetry of providing a jit.gl something for the vertex shader, to complement how jit.gl.pix can do some of what a fragment shader can do. But apart from saying +1, I would want to know what would a jit.gl.vertex 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 jit.gl.vertex 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 jit.gl.vertex, 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 jit.gl.pix. In fact, I think we'd really need a separate jit.gl.fragment to make this work. And, how do we get these into the scene? Does jit.gl.vertex/jit.gl.fragment itself behave a bit like a jit.gl.mesh (being an ob3d object in its own right), or does it work more like a jit.gl.shader that other ob3d's can use?

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

But what does that mean? The nearest thing to a jit.matrix on the GPU is a texture, and we already have jit.gl.texture/jit.gl.slab/jit.gl.pix 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 jit.gl.mesh? Are you all just looking for a way to turn texture data into geometry?

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 jit.gl.vertex?

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 jit.gl.pix is not always easy. keep in mind it's a naive feature request

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 jit.gl.pix.

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.

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

phiol

Hello,

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

I've developed with Mathieu Chamagne some particules tools with jit.gen that we could be easily port to jit.gl.pix (as it could have several outputs now), but I use jit.gl.mesh 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 jit.gl.pix (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.

Jean-Michel

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.

I've used vertex shaders primarily for displacement maps applied to vertices of jit.gl.mesh 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 jit.gl.vertex to be a replacement for jit.gl.shader, so that they could be applied to any OB3D, not just jit.gl.mesh. I suppose that a jit.gl.fragment 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.

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 jit.gl.vertex (for max6 too please :p )

Luvulongtime!

hi,

OpenCL+ vertex buffers+ GPU Bullet Physics :)

hey guys, our friend over in the jitter facebook group just posted this tutorial demonstrating vertex texture fetching using jit.gl.shader: https://www.youtube.com/watch?v=CsEVJNbKMms&feature=share

i've reworked the original patch posted at the top of this thread to show how to use vertex texture fetches with jit.gl.pix to generate geometry directly from a texture without a matrix readback. the trick is to set rectangle 0 on the jit.gl.pix (or jit.gl.slab) 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.

Rob, thank you. That is incredibly helpful.

endless thx rob

So jit.gl.pix automatically is the texture number 0! Cool insight Rob

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

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.

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

Hi Rob, with 1280x720 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.

hey guys, the vtf feature is now a part of jit.gl.material. check my post here for more info: https://cycling74.com/forums/new-7-3-2-jitter-features/

Hi Rob,

Thanks for the work :)