q about example renderparticle_primitives
I love this example. I love hacking at it, n00b as I am, and I like the
output of it.
However, can anyone help me dissect the [p drawing] subpatch at the
bottom of the screen? – I reckon that there must be a cleaner version of
this patch somewhere… this one is somewhat silly in its spaghettidom.
Andreas. (hoping to start "giving back" soon!)
not got much time at moment to dissect it completely…
from what i can follow the left inlet of "p drawing" receives list messages from what looks like a feeback loop for the particle system in the main patcher:
matrix brahma > jit.p.shiva > jit.p.vishnu > jit.p.bounds > matrix brahma
jit.p.bounds sends a matrix list:
1st item in list is the colour
next 3 items are the xyz coordinates to tell gridshape (inside "p drawing") where to move shapes.
the spaghetti is probably there because it’s very important in open gl to make sure you send the messages in the right order before you send the bang (draw) to jit.render.
hopefully this will give you an insight.
also check the jit.p.bounds help file, it’s not exactly the same but it is layed out more clearly.
> not got much time at moment to dissect it completely…
Thanks for the input though, Justin. What I really meant to say that if
anyone has a cleaned up patch of this one I would love to have a look.
The [p drawing] should be really simple with a few send/receive pairs
and less loadbang mess – the loadbang is causing most of the spaghetti,
really, and has nothing to do with trigger order, as far as I can tell.
Quote: Wetterberg wrote on Thu, 15 February 2007 20:09
> The [p drawing] should be really simple with a few send/receive pairs
> and less loadbang mess – the loadbang is causing most of the spaghetti,
> really, and has nothing to do with trigger order, as far as I can tell.
well, it is still important at initialising all of the parameters of the objects in [p drawing] to the correct settings before you send the data to be rendered. but i agree it looks a bit messy!
alternatively, you could simplify it by using attributes (eg. @erase_color 0. 0. 0. 1. in jit.gl.render) in the relevant objects instead of using loadbang to trigger messages…
just a thought!