Forums > Jitter

[feature request: jit.gl.vertex] see example below-jit.gl.pix vs jit.gen in mesh



LLT
Dec 13 2013 | 6:47 am

hello team cyclig74, do you intend to create a jit.gl.vertex object?

In the following example, I did a little test performance between jit.gl.pix 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 jit.gl.pix 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 jit.gl.vertex would open new perspectives.

LLT

Dec 16 2013 | 8:24 am

+ 1


JMC
Dec 17 2013 | 12:59 pm

+1


LLT
Dec 30 2013 | 3:22 am

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

Dec 30 2013 | 8:14 am

thanks for the request. noted.


LLT
Dec 30 2013 | 8:48 am

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 ;)

Jan 03 2014 | 11:48 am

+1

Jan 03 2014 | 10:40 pm

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

Jan 04 2014 | 6:58 am

+1

Jul 03 2014 | 7:23 pm

+1

Jul 04 2014 | 1:53 am

+1

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,

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


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

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

+1

Feb 07 2015 | 9:10 am

+ 1

Feb 07 2015 | 9:36 am

+1

Dec 26 2015 | 5:12 pm

Would love this to happen

+ 1


2K
Jun 21 2016 | 10:32 pm

+ 1

Jun 21 2016 | 11:28 pm

[jit.gl.gen] ?

Jun 22 2016 | 7:09 pm

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?

Jun 22 2016 | 7:25 pm

(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.

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 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?

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

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


JMC
Jun 27 2016 | 3:44 am

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

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 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.

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

Luvulongtime!

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

Forums > Jitter