vertex shader feedback loop

Jun 12, 2008 at 1:31pm

vertex shader feedback loop

Aloha,

I was wondering if it is theoretically possible to make some vertex
displacement shader which is recursively applied? (am I saying this
right?)

e.g. : the shader gets fed the value of 0. 0. 0., and alters it to
0.1 0.1 0.1, now this value is used in that shader and spits out 0.2
0.2 0.2

I was thinking along the lines of: named matrix > jit.gl.mesh with
shader & matrixoutput > named matrix.

But apart from jit.gl.mesh not working with matrixoutput, I wonder if
it is even possible if it would. If so, there’s a good reason to have
matrixoutput working with jit.gl.mesh after all :)

#38372
Jun 12, 2008 at 2:38pm

if you want to feedback a mesh just use a jit.matrix full of vertices,
before pshing it into jit.gl.mesh. then do a normal feedback using named
matrices, xfade, what ever.

you can feedback fragment shaders, see the recpies for examples.

also see this patch

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 309 325 138 9109513 < < lower dim = happier cpu;
#P newex 203 268 70 9109513 jit.rgb2luma;
#P objectname jit.gl.slab[1];
#P comment 401 299 138 9109513 < < lower dim = happier cpu;
#P newex 203 195 28 9109513 sel 1;
#P newex 203 295 224 9109513 jit.matrix 1 char 100 100 @adapt 0 @interp 1;
#P button 168 217 15 0;
#P newex 167 234 28 9109513 s init;
#P objectname receive[5];
#P number 305 89 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number;
#N vpatcher 530 245 864 465;
#P origin 49 -4;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 18 105 27 9109513 !- 1;
#P window linecount 2;
#P message 18 125 68 9109513 ; jitter cursor $1;
#P window linecount 1;
#P message 71 86 62 9109513 fullscreen $1;
#P newex 147 55 54 9109513 delay 5000;
#P newex 147 29 45 9109513 loadbang;
#P newex 110 111 168 9109513 sel 0 1;
#P message 110 132 152 9109513 size 320 240 , pos 10 463 , border 1;
#P message 153 152 160 9109513 border 0 , size 1024 778 , pos 1024 0;
#P toggle 71 66 15 0;
#P newex 70 44 35 9109513 sel 27;
#P newex 70 21 40 9109513 key;
#P outlet 71 185 15 0;
#P connect 11 0 10 0;
#P fasten 1 0 2 0 75 42 75 42;
#P connect 2 0 3 0;
#P connect 3 0 9 0;
#P connect 9 0 0 0;
#P fasten 4 0 0 0 158 175 76 175;
#P fasten 5 0 0 0 115 166 76 166;
#P fasten 6 0 5 0 115 131 115 131;
#P connect 7 0 8 0;
#P connect 6 1 4 0;
#P pop;
#P newobj 238 167 25 9109513 p fs;
#P newex 238 189 271 9109513 jit.window rott @size 320 240 @floating 1 @pos
10 450;
#P objectname jit.window;
#P newex 265 167 276 9109513 jit.gl.render rott @camera 0 0 3 @erase_color
0. 0. 0. 1.;
#P objectname jit.gl.render;
#P toggle 265 89 20 0;
#P objectname toggle;
#P newex 265 112 64 9109513 qmetro 20;
#P newex 265 134 58 9109513 t b b erase;
#N vpatcher 15 55 469 512;
#P origin 0 9;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P comment 319 111 86 9109513 short attention diff;
#N vpatcher 271 220 568 417;
#P origin 0 61;
#P window setfont “Sans Serif” 9.;
#P flonum 171 37 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 171 59 73 9109513 slide_down $1;
#P flonum 108 37 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 108 59 60 9109513 slide_up $1;
#P newex 50 115 167 9109513 jit.slide @slide_up 3. @slide_down 30.;
#P newex 50 136 109 9109513 jit.matrix 1 char 200 200;
#P newex 50 91 120 9109513 jit.matrix 1 float32 200 200;
#P inlet 50 56 17 0;
#P outlet 50 160 15 0;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P connect 5 0 4 0;
#P connect 7 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 0 0;
#P connect 6 0 5 0;
#P connect 8 0 7 0;
#P pop;
#P newobj 246 110 69 9109513 p dynamicDiff;
#N vpatcher 549 329 840 596;
#P window setfont “Sans Serif” 9.;
#P newex 163 41 45 9109513 loadbang;
#P objectname receive[4];
#P newex 133 65 29 9109513 r intit;
#P objectname jit.matrix[8];
#P newex 163 65 54 9109513 delay 5000;
#P objectname jit.matrix[7];
#P button 117 67 15 0;
#P newex 51 88 48 9109513 pipe 4500;
#P objectname jit.matrix[6];
#P newex 51 129 42 9109513 gate 1 1;
#P objectname jit.matrix[5];
#P newex 51 65 65 9109513 t 0 1;
#P objectname jit.matrix[4];
#P newex 50 176 162 9109513 jit.slide @slide_up 3. @slide_down 3.;
#P newex 106 88 48 9109513 pipe 1500;
#P objectname jit.matrix;
#P newex 50 197 109 9109513 jit.matrix 1 char 200 200;
#P newex 50 152 120 9109513 jit.matrix 1 float32 200 200;
#P inlet 83 33 15 0;
#P outlet 50 221 15 0;
#P connect 7 0 2 0;
#P connect 2 0 5 0;
#P connect 5 0 3 0;
#P connect 3 0 0 0;
#P fasten 9 0 6 0 122 63 56 63;
#P connect 6 0 8 0;
#P fasten 4 0 7 0 111 122 56 122;
#P connect 8 0 7 0;
#P connect 1 0 7 1;
#P connect 6 1 4 0;
#P connect 11 0 9 0;
#P connect 10 0 9 0;
#P connect 12 0 10 0;
#P pop;
#P newobj 246 132 56 9109513 p staticDiff;
#P number 148 211 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 50 209 96 9109513 jit.op @op > @val 20;
#P objectname jit.gl.slab[4];
#P newex 50 85 188 9109513 t l l l l;
#N vpatcher 138 440 507 597;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 134 103 56 9109513 loadmess 1;
#N vpreset 2;
#P preset 81 103 47 27;
#P number 164 42 35 9 0 4 3 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 164 61 45 9109513 mode $1;
#P number 211 42 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 211 60 48 9109513 range $1;
#P flonum 12 38 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 68 38 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 68 61 41 9109513 ring $1;
#P message 12 61 52 9109513 center $1;
#P flonum 112 38 47 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 112 61 49 9109513 ripple $1;
#P window linecount 6;
#P comment 262 40 74 9109513 0 = row ; 1 = column ; 2 = cross ; 3 =
diagonal ; 4 = square ;;
#P outlet 12 83 15 0;
#P connect 7 0 4 0;
#P connect 4 0 0 0;
#P fasten 10 0 0 0 169 80 17 80;
#P fasten 5 0 0 0 73 80 17 80;
#P fasten 8 0 0 0 216 80 17 80;
#P connect 6 0 5 0;
#P connect 13 0 12 0;
#P connect 3 0 2 0;
#P connect 11 0 10 0;
#P connect 9 0 8 0;
#P pop;
#P newobj 103 183 42 9109513 p param;
#P newex 50 183 50 9109513 jit.fastblur;
#P number 137 143 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 50 161 96 9109513 jit.op @op > @val 30;
#P objectname jit.gl.slab[6];
#P newex 50 139 83 9109513 jit.op @op absdiff;
#P objectname jit.gl.slab[5];
#P comment 304 133 49 9109513 static diff;
#P inlet 50 37 15 0;
#P outlet 50 233 15 0;
#P outlet 227 109 15 0;
#P window linecount 1;
#N vpatcher 493 104 869 555;
#P origin 0 61;
#P toggle 116 229 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 116 245 29 9109513 gate;
#P message 203 121 57 9109513 3000. 3000.;
#P message 165 121 37 9109513 15. 15.;
#P message 165 143 122 9109513 slide_up $1 , slide_down $2;
#P newex 213 56 26 9109513 r init;
#P newex 261 121 71 9109513 print readyDIff;
#P newex 203 88 54 9109513 delay 3000;
#P newex 165 56 45 9109513 loadbang;
#P user jit.pwindow 116 267 202 202 0 1 0 0 1 0;
#N vpatcher 15 55 239 193;
#P window setfont “Sans Serif” 9.;
#P flonum 113 50 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 113 67 73 9109513 slide_down $1;
#P flonum 50 50 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 50 67 60 9109513 slide_up $1;
#P outlet 50 89 15 0;
#P connect 2 0 1 0;
#P connect 3 0 0 0;
#P connect 1 0 0 0;
#P connect 4 0 3 0;
#P pop;
#P newobj 267 162 42 9109513 p param;
#P newex 146 186 192 9109513 jit.slide @slide_up 1500. @slide_down 1500.;
#P newex 146 207 109 9109513 jit.matrix 1 char 100 100;
#P newex 146 162 120 9109513 jit.matrix 1 float32 100 100;
#P inlet 146 35 17 0;
#P outlet 146 231 15 0;
#P connect 15 0 14 0;
#P connect 14 0 6 0;
#P fasten 3 0 14 1 151 229 140 229;
#P connect 1 0 2 0;
#P fasten 5 0 4 0 272 183 151 183;
#P connect 11 0 4 0;
#P connect 2 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 0 0;
#P connect 10 0 7 0;
#P connect 7 0 12 0;
#P connect 12 0 11 0;
#P fasten 13 0 11 0 208 140 170 140;
#P fasten 7 0 8 0 170 76 208 76;
#P connect 8 0 13 0;
#P fasten 8 0 9 0 208 114 266 114;
#P pop;
#P newobj 109 110 81 9109513 p dynamicDiffUp;
#P connect 3 0 10 0;
#P connect 10 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 8 0;
#P connect 9 0 8 0;
#P connect 8 0 11 0;
#P connect 11 0 2 0;
#P fasten 10 1 0 0 114 109 114 109;
#P fasten 0 0 5 1 114 131 128 131;
#P connect 7 0 6 1;
#P connect 12 0 11 1;
#P connect 10 3 1 0;
#P pop;
#P newobj 203 321 100 9109513 p backgroundDiff;
#P message 203 217 30 9109513 read;
#P newex 203 245 63 9109513 jit.qt.movie;
#N vpatcher 516 181 981 591;
#P origin 0 -30;
#P window setfont “Sans Serif” 9.;
#P flonum 348 242 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 348 259 73 9109513 slide_down $1;
#P flonum 285 242 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 285 259 60 9109513 slide_up $1;
#P message 72 120 14 9109513 2;
#B color 5;
#P message 59 120 14 9109513 1;
#B color 5;
#P newex 59 140 63 9109513 switch 2 1;
#N vpatcher 35 85 299 307;
#P window setfont “Sans Serif” 9.;
#P newex 63 102 96 9109513 pak map 0 255 0 255;
#P newex 50 128 41 9109513 jit.map;
#P newex 81 81 53 9109513 jit.3m;
#P newex 50 50 85 9109513 xray.jit.distance;
#B color 5;
#P inlet 50 30 15 0;
#P outlet 50 154 15 0;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P fasten 5 0 4 0 68 124 55 124;
#P connect 4 0 0 0;
#P fasten 2 0 3 0 55 77 86 77;
#P connect 3 2 5 2;
#P pop;
#P newobj 85 119 97 9109513 p xray.distancePatch;
#P newex 185 255 97 9109513 jit.matrix displacment;
#P newex 185 277 172 9109513 jit.slide @slide_up 35. @slide_down 10.;
#P newex 27 302 168 9109513 jit.op @op -;
#N vpatcher 13 376 518 687;
#P origin 0 -8;
#P window setfont “Sans Serif” 9.;
#P message 84 37 14 9109513 4;
#P message 71 37 14 9109513 3;
#P message 57 37 14 9109513 2;
#P message 42 37 14 9109513 1;
#P message 28 37 14 9109513 0;
#P message 13 37 16 9109513 -1;
#B color 4;
#P user jit.fpsgui 136 44 60 9109513 3;
#P message 13 55 43 9109513 plane $1;
#P user jit.cellblock 6 76 423 283 139 9 100 100 44 17 0 1 1 0 0 0 1 1 1 0 0
0 255 255 255 0 0 0 0 0 0 191 191 191 0 0 0 215 215 240 1 1 1 0 2 0 0 0;
#P inlet 6 19 15 0;
#N vpatcher 45 100 378 286;
#P inlet 130 41 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 130 147 34 9109513 set $1;
#P newex 130 124 27 9109513 * 22;
#P newex 129 81 77 9109513 route planecount;
#P newex 129 102 40 9109513 change;
#P newex 130 60 60 9109513 jit.matrixinfo;
#P window linecount 0;
#P message 50 72 18 9109513 44;
#P message 50 93 54 9109513 colwidth $1;
#P inlet 50 49 15 0;
#P outlet 50 115 15 0;
#P connect 1 0 3 0;
#P connect 8 0 3 0;
#P connect 3 0 2 0;
#P connect 2 0 0 0;
#P connect 4 0 6 0;
#P connect 6 0 5 0;
#P connect 9 0 4 0;
#P connect 5 0 7 0;
#P connect 7 0 8 0;
#P pop;
#P hidden newobj 57 53 49 9109513 p colwidth;
#P connect 1 0 2 0;
#P hidden fasten 3 0 2 0 18 74 11 74;
#P hidden fasten 0 0 2 0 62 74 11 74;
#P hidden connect 6 0 3 0;
#P hidden connect 8 0 3 0;
#P fasten 10 0 3 0 24 54;
#P hidden connect 5 0 3 0;
#P hidden connect 7 0 3 0;
#P hidden connect 9 0 3 0;
#P hidden connect 5 0 0 0;
#P hidden connect 6 0 0 0;
#P hidden connect 7 0 0 0;
#P hidden connect 8 0 0 0;
#P hidden connect 9 0 0 0;
#P hidden fasten 1 0 0 1 101 34;
#P fasten 1 0 4 0 11 35 141 35;
#P pop;
#P newobj 176 339 52 9109513 p cellblock;
#P newex 27 330 97 9109513 jit.matrix displacment;
#P message 36 179 54 9109513 clear , bang;
#P newex 27 86 82 9109513 t b l;
#P newex 59 220 277 9109513 jit.matrix newDisplacment 2 float32 100 100
@adapt 0 @interp 1;
#P newex 27 276 58 9109513 jit.op @op +;
#P newex 59 246 103 9109513 jit.op @op * @val 0.05;
#P newex 27 198 259 9109513 jit.matrix displacment 2 float32 100 100 @adapt
0 @interp 1;
#P inlet 27 66 15 0;
#P outlet 27 354 15 0;
#P window linecount 2;
#P comment 190 119 132 9109513 gives nicer depth map instead of plain old
onoff luma;
#P connect 2 0 7 0;
#P connect 7 0 3 0;
#P fasten 8 0 3 0 41 196 32 196;
#P connect 3 0 5 0;
#P connect 5 0 11 0;
#P connect 11 0 9 0;
#P connect 9 0 1 0;
#P connect 17 0 15 0;
#P connect 16 0 15 0;
#P connect 15 0 6 0;
#P connect 6 0 4 0;
#P fasten 4 0 5 1 64 269 80 269;
#P connect 7 1 14 0;
#P fasten 14 0 15 1 90 136 90 136;
#P connect 7 1 15 2;
#P fasten 7 0 13 0 32 167 190 167;
#P connect 13 0 12 0;
#P connect 18 0 12 0;
#P connect 20 0 12 0;
#P fasten 12 0 11 1 190 299 190 299;
#P connect 19 0 18 0;
#P connect 21 0 20 0;
#P pop;
#P newobj 203 345 67 9109513 p accumLuma;
#B color 5;
#P newex 324 421 99 9109513 prepend draw_mode;
#P user ubumenu 325 398 68 9109513 0 1 1 0;
#X add points;
#X add lines;
#X add line_strip;
#X add line_loop;
#X add triangles;
#X add tri_strip;
#X add tri_fan;
#X add quads;
#X add quad_strip;
#X add polygon;
#X add tri_grid;
#X prefix_set 0 0 0;
#X pattrmode 1;
#P message 290 421 29 9109513 reset;
#P newex 217 420 91 9109513 jit.gl.handle rott;
#P newex 167 445 374 9109513 jit.gl.mesh rott @draw_mode points @point_size
2 @rotate 71. -0.9 -0.32 -0.2;
#P newex 167 420 60 9109513 jit.pack 3;
#P newex 167 398 64 9109513 jit.unpack 3;
#P newex 167 373 316 9109513 jit.gl.gridshape rott @shape plane @dim 100 100
@matrixoutput 1;
#P window linecount 2;
#P comment 96 224 84 9109513 re intitlaize the backgound >>;
#P comment 429 247 105 9109513 < < change to qt.grab if your mac;
#P connect 26 0 23 0;
#P connect 23 0 13 0;
#P fasten 16 0 24 0 270 110 208 110;
#P connect 16 0 15 0;
#P connect 22 0 21 0;
#P connect 19 0 18 0;
#P fasten 15 0 14 0 270 132 270 132;
#P fasten 14 2 17 0 318 161 270 161;
#P connect 14 0 17 0;
#P connect 20 0 15 1;
#P connect 2 0 3 0;
#P connect 3 0 4 0;
#P fasten 9 0 5 0 329 441 172 441;
#P connect 4 0 5 0;
#P fasten 6 0 5 0 222 442 172 442;
#P connect 3 1 4 1;
#P connect 13 0 10 0;
#P connect 10 0 4 2;
#P fasten 7 0 6 0 215 421;
#P fasten 8 1 9 0 359 417 329 417;
#P fasten 12 0 11 0 208 245 208 245;
#P fasten 14 1 11 0 294 241 208 241;
#P connect 11 0 26 0;
#P connect 24 0 12 0;
#P fasten 24 0 22 0 208 215 173 215;
#P window clipboard copycount 28;

On Thu, Jun 12, 2008 at 4:31 PM, Brecht Debackere
wrote:

> Aloha,
>
> I was wondering if it is theoretically possible to make some vertex
> displacement shader which is recursively applied? (am I saying this right?)
>
> e.g. : the shader gets fed the value of 0. 0. 0., and alters it to 0.1 0.1
> 0.1, now this value is used in that shader and spits out 0.2 0.2 0.2
>
> I was thinking along the lines of: named matrix > jit.gl.mesh with shader
> & matrixoutput > named matrix.
>
> But apart from jit.gl.mesh not working with matrixoutput, I wonder if it is
> even possible if it would. If so, there’s a good reason to have matrixoutput
> working with jit.gl.mesh after all
>

#133624
Jun 12, 2008 at 2:58pm

That’s indeed how I’ve been doing it now, but when using several
jit.expr objects, with different expressions and weight, it becomes
slow very quickly. That’s why I was looking for a way to move what
the jit.expr objects are doing from the cpu to the gpu where I think
they should be.

#133625
Jun 12, 2008 at 3:11pm

As far as I know(so, not further than my nose), you can’t read back
vertex shader results back to cpu, but in theory you should be able to
process the geometry on gpu, as a float texture, using fragment shaders.
In practice, this still doesen’t work reliably… see:

http://www.cycling74.com/forums/index.php?t=msg&goto=137498&rid=0&srch=gl+invalid+operation#msg_137498

best,
nesa

#133626
Jun 12, 2008 at 3:17pm

whats the mesh size? it shouldn’t be slow, and you get a lot of flexibility
with jit.matrix.
shaders work differently then matrices. things happen per vertex (and
parallel) and they have no knowledge about other vertex, thats what makes
them fast.

if you post a patch i’d like to see were its going as i have jit.expr
problems of my own.

On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere
wrote:

> That’s indeed how I’ve been doing it now, but when using several jit.expr
> objects, with different expressions and weight, it becomes slow very
> quickly. That’s why I was looking for a way to move what the jit.expr
> objects are doing from the cpu to the gpu where I think they should be.
>
>
>

#133627
Jun 12, 2008 at 3:19pm

CHOIR:

Hello nesa!

On Thu, Jun 12, 2008 at 6:17 PM, yair reshef wrote:

> whats the mesh size? it shouldn’t be slow, and you get a lot of flexibility
> with jit.matrix.
> shaders work differently then matrices. things happen per vertex (and
> parallel) and they have no knowledge about other vertex, thats what makes
> them fast.
>
> if you post a patch i’d like to see were its going as i have jit.expr
> problems of my own.
>
>
>
> On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere
> wrote:
>
>> That’s indeed how I’ve been doing it now, but when using several jit.expr
>> objects, with different expressions and weight, it becomes slow very
>> quickly. That’s why I was looking for a way to move what the jit.expr
>> objects are doing from the cpu to the gpu where I think they should be.
>>
>>
>>
>
>

#133628
Jun 12, 2008 at 3:19pm

CHOIR:

Hello nesa!

#133629
Jun 12, 2008 at 4:16pm

I’ve been doing some tests with 100×100 matrices (it “should” be
possible to have 10 times as much with a decent framerate, say at
least 20, in theory).
Ultimately I would like to have that amount of textured planes, but
for now it’s just points/lines.

On 12 Jun 2008, at 17:17, yair reshef wrote:

> whats the mesh size? it shouldn’t be slow, and you get a lot of
> flexibility with jit.matrix.
> shaders work differently then matrices. things happen per vertex
> (and parallel) and they have no knowledge about other vertex, thats
> what makes them fast.
>
> if you post a patch i’d like to see were its going as i have
> jit.expr problems of my own.
>
>
> On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere
> wrote:
> That’s indeed how I’ve been doing it now, but when using several
> jit.expr objects, with different expressions and weight, it becomes
> slow very quickly. That’s why I was looking for a way to move what
> the jit.expr objects are doing from the cpu to the gpu where I
> think they should be.
>
>
>

#133630
Jun 12, 2008 at 4:33pm

it seems you r talking about 2 diff things

On Thu, Jun 12, 2008 at 7:16 PM, Brecht Debackere
wrote:

> I’ve been doing some tests with 100×100 matrices (it “should” be possible
> to have 10 times as much with a decent framerate, say at least 20, in
> theory).
> Ultimately I would like to have that amount of textured planes, but for now
> it’s just points/lines.
>
>
> On 12 Jun 2008, at 17:17, yair reshef wrote:
>
> whats the mesh size? it shouldn’t be slow, and you get a lot of flexibility
> with jit.matrix.
> shaders work differently then matrices. things happen per vertex (and
> parallel) and they have no knowledge about other vertex, thats what makes
> them fast.
>
> if you post a patch i’d like to see were its going as i have jit.expr
> problems of my own.
>
>
> On Thu, Jun 12, 2008 at 5:58 PM, Brecht Debackere
> wrote:
>
>> That’s indeed how I’ve been doing it now, but when using several jit.expr
>> objects, with different expressions and weight, it becomes slow very
>> quickly. That’s why I was looking for a way to move what the jit.expr
>> objects are doing from the cpu to the gpu where I think they should be.
>>
>>
>>
>
>
>
>
>
>

#133631
Jun 12, 2008 at 5:09pm

Hi Brecht,
I believe this is possible using Geometry shaders, which are a LOT more work to put together. For using standard Vertex/Fragment shader programs, you’re not going to be able to get recursion. If you post a patch, maybe we can help you find ways to optimize your processes and move things into a vertex program where possible. Keep in mind that 100×100 is 10,000 vertex points, and you might be also encountering drawing bottlenecks.

Let us know how you get on.

Andrew B.

#133632
Jun 12, 2008 at 6:40pm

I’ll get back on it, once I get some stuff cleaned up. I know it is
10 000 vertex points, but looking at some graphics cards tests, the
tiangle/primitive count of a number of tested games goes at least 70x
higher.
I’ll see where it strands.

> it seems you r talking about 2 diff things

not really, it’s basically the same matrix calculations, whether I
use the result to draw points, or use them as positions for the planes.

On 12 Jun 2008, at 19:09, Andrew Benson wrote:

>
> Hi Brecht,
> I believe this is possible using Geometry shaders, which are a LOT
> more work to put together. For using standard Vertex/Fragment
> shader programs, you’re not going to be able to get recursion. If
> you post a patch, maybe we can help you find ways to optimize your
> processes and move things into a vertex program where possible.
> Keep in mind that 100×100 is 10,000 vertex points, and you might be
> also encountering drawing bottlenecks.
>
> Let us know how you get on.
>
> Andrew B.
> –
> Andrew B.
> –
> Cycling ’74 Support

#133633
Jun 12, 2008 at 7:13pm

It’s certainly possible to render around 100,000 points in realtime
and dynamically. When you start rendering planes at this size, you
start to hit the fill-rate bound. For triangle meshes, I can reliably
do around 70,000 points dynamically and on workstation GPUs around
150,000. It’s of course higher with less intensive shaders and more
static data.

The way to get this rate of throughput is via render-to-vertex buffer.
Jitter currently does not support this although it is planned for a
future release. Also, geometry shaders can do what’s called
transform-feedback but again Jitter does not currently support this
but will probably do so in the future.

to give you an idea of how it works with the RTVBO path, you use float
textures as buffer of vertices and process like normal textures with
slabs. Then, when you want to turn them into geometry, you flip a few
switches on the GPU to send the float texture data into a VBO, which
you can then pass to a vertex shader or draw with the fixed function
pipeline.

wes

On Thu, Jun 12, 2008 at 11:40 AM, Brecht Debackere
wrote:
> I’ll get back on it, once I get some stuff cleaned up. I know it is 10 000
> vertex points, but looking at some graphics cards tests, the
> tiangle/primitive count of a number of tested games goes at least 70x
> higher.
> I’ll see where it strands.
>
> it seems you r talking about 2 diff things
>
> not really, it’s basically the same matrix calculations, whether I use the
> result to draw points, or use them as positions for the planes.
>
>
> On 12 Jun 2008, at 19:09, Andrew Benson wrote:
>
> Hi Brecht,
> I believe this is possible using Geometry shaders, which are a LOT more work
> to put together. For using standard Vertex/Fragment shader programs, you’re
> not going to be able to get recursion. If you post a patch, maybe we can
> help you find ways to optimize your processes and move things into a vertex
> program where possible. Keep in mind that 100×100 is 10,000 vertex points,
> and you might be also encountering drawing bottlenecks.
> Let us know how you get on.
> Andrew B.
> –
> Andrew B.
> –
> Cycling ’74 Support
>
>
>

#133634

You must be logged in to reply to this topic.