[feature request: jit.gl.vertex] see example below-jit.gl.pix vs jit.gen in mesh
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.
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 ;)
Getting pixel and vertex shaders done in gen + export features would open up new worlds
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.
jit.gl.pix : 60% / jit.gen : 140%
jit.gl.pix : 70fps / jit.gen : 100fps
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 2068.3oc6bssjahCD8Y6uBJp8wYmEIPbYeJaseFylxE1HaqDt3EjmKIUdced +F2ujUW.LXCXYBVimjYRESrDf59zsZcZ0ZxWmOybY1y3BSie23AiYy957YyD MwaXV42mYlD97p3vBwsYtJKIAmRMuS1GE+LUz9mHz62fSMdrvP7OiueG4Yi+ Jc4KFeHgjmmkuL6kpmJljhWksOU7nvxFIQhWT1xO8q11U245rT55vUXdW1ks ktOgjFioBABz3FKHeQbiPm6spZNeyRdSV0srKjtZKIcyhb7JpTyg9rdMfH9m 1.O9EW1CX7wCCX1dZ0HZ0XDSCSDin4ejSBiM4c7s4y4ebmh3IMaylXrYGX.n pQ4XSeYGVJtlDNv8wgPiNTR6.66QUZI.FTeoG07vqJmojTb9BbZ3xXgLXMBE sOGm+6e92+baX5FrQkKzu0vCpCfA5Xppi..dYNB1dPAF4XKPGjkvuPWtBK2S oYocowvdcEVxPtC9B6xwELLNjRxRanVN.KoqMfewp7iK1CB5KbZrKmtbNvAL oPfkhPfxJiM3ZqLo3mXhdeQJ6PIAndUR1CsHIjlymQXXdF0smo.c4vyPAlCu si.Ejt8CfBv982aNF37RToDVXO.IF+HNuf4W1PPmYFtaWilm03Q3X4mxDuH2 6pahjJaBT2TN9QR0y6U2ZXNSSoL0betTHe120T1Iy9Mu5QqcFDN1txOsD9BN nFv.yRuYUVrbrefM4I3tFe.ZeiwYq9LNpQ3Al4bGNkj1b1YqtivqC2GSWzsc qc+UKF1YmcZSlYtImDkkxEhVOIu4pg6AVzNYLulJi3NRC20wCWvzi8EKCy4v e4xBvpNoYYws6p1hylxDlRXtxXJQJrPq5WJIYWNQxJntM4pNaKVkmEG25UI6 4wN5Ih4TrB+DIhtsULedOramrqxDXViQQjM3BZ61ngaJZ2RK5RM8VaFKnU6C ESncbghmHewfuJUiNaDb.0r8ShOTGQn2nBCDYnunCHQHRjbZA53XC8yYXn0D mUEGsbt3ziijTCPOXHXrXn03wPQzDfiXwFq2JXHSd5EDcLuBdZRTxRRA2SAX x5hgoCg03oezyrXgrw6ua7qHae9pJ+kROJi1hIKBCkjVGj+g5YuGceaIQQsi oJCCUvCpEUyx9r15KUhQJJwNSjDa7w4GZY5XPUQF5TRT1uVjnjjHQnwShZRY LGL0Ll8kYE43b8XLuOYIi7XGFU2ASF9NkzoKvhZEvsnkwiNaZfvgRUdRs18L gXW3mYyUs5ZWD5E25ArfiFrj9EmEr.SJfrgwZhIQvtl.z+FnLvze3.JJPLOG JWextLY3w4ULwoS12dk.fCFLbS7B96gmjzUHfHLvpwdM8SXZk.nKTjKo+6YV 9dlkuhYVtiM2AOtbht6JkaITDD0StuSpP3GdimaIR+4VJwPaWAF57dtkCgR. Ycc9QL2Rm2b4VBtAxsLAWTDtAeBep06iiYQxw3TieAzEsRzjPo197EjzwCcO DYGX4dmguzINPSzp6spjP2ospjkZp8AMEpZBDWYd06LXKn2EB3Ml7pstXe.F KQTajwQPlDBFiOva6xyfZTdFGIIZeq24F+N2XEYiHmizCmCek3bzYrKImKny giOBDoLyhpCDgPU0C0qBbrQc7qSBrMHAVQrsgSF.NdJZRjDHYmcZYnuUSG3y 3WFUVUk6Y4oWtJYITBtxCABRrYcmAbctMH.CUjNo+MCAXUorCmZBvkquWD9H NZAaDXV+EgTZNY4dpzbzb89u2k1N+RmWP79NEhAF79FTFEfkgwkLbpe1NVV4 pTOpmHoQYOYTd4CqKXw12yVMlYl+.WZ4DWXopy91xr7HbtAfeSgg79aeyujt pysxG3OLwyobGbkzxQVd0jOQ.asVWKty6dRGvfi6kl+0kq9.PYBXGzefxE1f K4xRyILzlSJrvc0VuqXSmPCbLE7XrNG1VBGBe4QKDoI2hgKBBKm9s0SAC2Sy XLdIq3S0n4goEqyxSVvSGfxapHIKitcQw1vHl9wm5wehEhciundGpZeVks6X Zoy2W8lCtb72QbJUs8kLN8fU6g5qsEHMiTfMrMVGmERsgLWDK9e6JVFP6Eo2 pj3iv4E35p0nYW7QAMP23SoSUYM67g+jVxt.anr3tn2qX266JwsYE6BdcpXW 4YzS5a7CQI67dsNNndkgUdujcC5pIWj9sTI67TL++falcrH3GiiCJi7eNNkm WcE8+dyiV6oQCckEuy04VfyI0Xo3O37vhtpvm2YgmiuJeSSLlI2TcOuy.YN5 .x96DLMOynqpA6LlhABGIn.j6jqKRqGwxdqEL5ZTJXfCTsiWrdpBLKS1Hoe9 791h+Qc9puXSuEp5WKYMZ56cS3zvdv442XSNFwtuEkG9zhjrHrodfDn+0GSp Np0xiMG7raI6ofBIQM3P7BayLRhNGyunDiNgWgcqRgzWYPZeSmvn3T1DmXsT Ud.JKO.sHOPeEjGf9vGXvsk73ph33nO2Gzsk7D7FDdfvaJ3g+eo.5BdrUwbg zl7nRrG8Yr7TPZ70pzX+cJMIjncYLRvkqcFfj+OuR0ucqUe4vnLoRO7bV1fK S78buG3x9wgK1vpDQrY+3zcS.aYltAhRJH91UPUUIji9h.5nzBV5yM1QAwwS aRiJw+f5CbfpDxA5pO4QEmGn9Ve.htsblgpPdOPuhC3bvi9V.Enh6i8sm3.t cDGn97dNxwnGuGMZtTPbFanG41HbTs84BxQ0z+n54eZs76qN9rw4ay+e.XZS 4wC -----------end_max5_patcher-----------
- This reply was modified 2 years by mirrorboy.
Would love this to happen
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.
Sorry , holes in my knowledge keeps me from being more precise.
@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.
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.
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 )
OpenCL+ vertex buffers+ GPU Bullet Physics :)
Forums > Jitter