GL softshapes (smoke, clouds, flames, ..)
Hello!
I'm trying to make some soft shapes shaded and smoothed directly with OpenGL obects. The result should be something similar to a flame, or smoke, with that typical fading transparency.
When using alpha, with blend enable on gridshape, the borders of the, let's say, sphere are always visible. Should I try to make close surfaces with nurbs, and play with transparency ? Or maybe something more oriented to particles clouds ? Could importing a .obj model help?
The goal is to avoid the 3D object sensation of the render to give the feeling of a more shady and organic shape. (ie osx screensaver)
The jitter bfg objects make something similar to start from but, I must use OpenGL for performance reasons.
Does anyone have an idea?
Thanx a lot.
livio
One thing that will help you a great deal is to begin using textures
with an alpha channel, or using any old texture with additive blend mode
(blend_mode 6 1). Make sure to turn blend_enable on.
For an example, check out the Jitter Recipe Book, number 09:
ParticleRave-a-delic.
Cheers,
Andrew B.
Hi Andrew,
thank you for your reply.
I took a look to your 9th recipe.
I applied the textures with alpha to other shapes then a plane.
The shape's shape is always visible, because the texture will not always be transparent on the borders (borders seen from camera angle).
I'd need something like a fat spline made with coloured gas :)
That's why particles maybe useful but I don't see how, I can't render 2000 half transparent particles to have the smoky mouvement on a spline...
best,
livio
There are a number of ways to get what you're looking for. If you
have splines like you sugggest, you just need to make them view
aligned and your texture should be transparent on the borders.
Alternatively, you can use shaders for shapes that curve around like a
torus or sphere. You can make the transparent based on the dot
product of the view vector (camera location to vertex location) and
the normal of the surface. Normals facing 90 degrees from the view
vector will most likely be edge vertices and thus can be rendered
transparent.
Most fire and such is rendered with point sprites backed by a particle
system. So this might be the way to go for you.
wes
On 11/2/06, livio wrote:
>
> Hi Andrew,
>
> thank you for your reply.
> I took a look to your 9th recipe.
> I applied the textures with alpha to other shapes then a plane.
> The shape's shape is always visible, because the texture will not always be transparent on the borders (borders seen from camera angle).
> I'd need something like a fat spline made with coloured gas :)
> That's why particles maybe useful but I don't see how, I can't render 2000 half transparent particles to have the smoky mouvement on a spline...
>
> best,
> livio
>
hello livio,
you should also check jit.gl.volume help patch
hth,
nesa
hello
so, if i got it right, the jit.gl.volume does automatically what wes suggest to do manually. Programming it by my own will open to of course to a wiser possibility of creating shapes.
jit.gl.volume works on a cube model, I don't find how to make it work on a nurbs volume.. if it would be possible that would be a solution. Or maybe I'll try to work on more defined textures in a big cubic volume..
(from html referece .. jit.gl.volume creates a 3d jit.gl.texture object and applies it to multiple view-aligned slices of geometry. The resulting slices are then blended together..)
wes, this is mostly like your first suggestion ?
and concerning your second hint, i can't totally understand this:
> Alternatively, you can use shaders for shapes that curve around
> like a torus or sphere.
how exactly to find the shader I need? looking in jit.gl.shader reference it seems like I should write a specific GL shader. I checked out the shaders in the help patch and I can't find one that really fit. And it's quite normal, I understand..
> You can make the transparent based on the
> dot product of the view vector (camera location to vertex
> location) and the normal of the surface. Normals facing 90
> degrees from the view vector will most likely be edge vertices
> and thus can be rendered transparent.
I guees this is an hint to write my own shader. It seems like I'm entering a 5th dimension, I guess I have to pass by some pages of the openGL red book..
Thank you for this advices. They hook me to something, now it's matter to spend time in programming my own thingy. If you have some examples, or other comments, that would be, of course, extremely welcome.
cheers,
livio
Here's the shader I was talking about. It's a per-pixel lighting
Phong shader with an alpha dependent on how much the triangle's normal
faces the camera. This is all done in Eye Coordinates, so I'm just
taking the Z component of the Normal vector in Eye Space and applying
a power function to it for a nice falloff. You can adjust the falloff
from the patch. Anyway, below is the patch and shader. If the shader
doesn't show up in the email, it's your email reader's fault and not
mine. Sometimes email programs eat the JXS XML tags thinking that
they're HTML tags.
wes
----------------------------------mat.phong.edge.jxs------------------------
Shader for for modifying image contrast by interpolation
and extrapolation
Hello Wes,
thank's for the example.
unfortunaly both on gmail and on the forum (tried with safari and firefox) the jxs does not show up entirely..
could you join an attachement? or I can try to read the post differently..
and thank you for the explaination about the process, it's rather clearer to me now.
livio
Hello
I received your phong shader and it looks fine, it's a great base to start playing with shaders. Thank you!!
Unfortunately I have a problem using transparency and turing the object. Jitter renders some slices in it that should not be there..
Since it does the same on a normal gridshape with normal shader, the problem seems to come from my config, MBP 2.16 with an ATI Radeon X1600. Kind of openGL compatibility issue? Or I'm missing something.. I tried the cull_face, depth_stuff..
I join a picture.
cheers
livio
oups
This has nothing to do with your config but with the fact that opengl
doesn't do depth sorting for you with translucent triangles. What
you're seeing is the front side being rendered first and then the back
side being rendered last causing the blending artifacts. You might
want to adjust your blend mode to something like @blend_mode 1 6 or 6
1?? I can't rememeber exactly right now. Anyway, make it something
additive.
wes
On 11/5/06, livio wrote:
> oups
>
>
>
>
>
>
animated normals
I tried with all blend_modes, no changes.. still the slices, lighter or darker.
Isn't it strange that if I just turn the shape backside it shows me these artifacts? I mean, it's a rather simple operation.. at least I thought.
I never noticed these drawing incoherences before, not directly on an help patch, I don't understand..
I can't read the javascript you posted on the second message.
Still thanking you :)
cheers
livio
> I never noticed these drawing incoherences before, not directly on an help patch, I don't understand..
Probably because there weren't any translucent shape with @blend_mode
1. It only shows in this case. For an idea as to what's going on
search google for "depth peeling". This is the *only* way to get
around these artifacts if you don't first depth sort your vertices,
which Jitter doesn't do. It one of those pain in the arse things
about opengl that you're just going to have to work with.
wes
wow, ok. I see. almost.
I passed through different white papers, cross reading.
Now the question is, should I go deeper in those readings and try to program vertex depth sorting shader ? Is there something similar already existing for jit.gl objects?
I see different methods proposed around the web, on different programming languages. But I don't understand where and how to apply this code. And I read it's a quite resource consuming process .. ?
ohm
livio
Hej,
after spending the last 8 hours reading (and this could be extended to lifetime) about the graphics pipeline, vertex shaders, pixel shaders I got a vague idea of what is behind the curtain.
I'm downloading the Jitter SDK :)
Some more hints about "depth peeling" in Jitter? Is it a vertex shader task?
wiser ohm
livio
Hi Livio,
Depth peeling is a multipass fragment shader algorithm where you use
depth textures to write the final fragment color. It's a but on the
expensive side, but I've never implemented it myself so I can't say
for sure. The technique from what I understand is alot like shadow
mapping. My reccomendation would be to not do it and just work with
opengl how it is for now. Although, I don't know what you're doing,
so I can't say how critical it is. If you are in to 3d graphics,
definitely download the Jitter SDK if you know C and make some custom
objects that do the drawing the way you want. Alternatively,
jit.gl.mesh might be your solution as you can draw orbitrary forms
stored in matrices with it.
wes
On 11/6/06, livio wrote:
>
> Hej,
> after spending the last 8 hours reading (and this could be extended to lifetime) about the graphics pipeline, vertex shaders, pixel shaders I got a vague idea of what is behind the curtain.
> I'm downloading the Jitter SDK :)
> Some more hints about "depth peeling" in Jitter? Is it a vertex shader task?
> wiser ohm
> livio
>
Hi,
after googling keywords offered by Wesley, I ran into this paper:
which offers algorithm and has a sample glsl shader, but I haven't tested it
yet, so I _hope_ it works... it has a few 'if's and 'for's though...
best,
nesa
Hey that's a neat patch. Thanks for posting it.
I'd love to get the shader working for textures, so it uses the
texture color instead of the ambient, spectral, etc. colors you have
in the patch. I attempted to do this but failed miserably... perhaps
someone could tell me what I'm doing wrong? (Yes I need to buy the
Orange book...)
this is a (non-working) replacement for Wesley's mat.phong.edge.jxs
Shader for for modifying image contrast by interpolation
and extrapolation
I personally am not a fan of the Orange Book. It obscures alot of
details about actual implementation issues of GLSL in current hardware
and gives the impression that things are easier and more flexible then
they really are. For instance, the guy talks about the GLSL noise and
derivative functions without mentioning that almost all current
hardware doesn't support them expect in software which will chunk your
shaders. I also have major beef with the lighting and shadow chapter.
It's all done with precomputed data which I think sucks. I use
shaders because of their power with dynamic meshes, not static stuff.
If you want to get into shaders, I would highly highly recommend the
GLSL spec over the orange book. It's more precise and as a bonus it's
free. The orange book is just a glorified regurgiation of it anyway.
Here's a link to the doc:
http://www.mat.ucsb.edu/~whsmith/GLSLangSpec.Full.1.10.59.pdf . The
one on the openGL site is for GLSL spec 1.20 which is only for OpenGL
2.1, so I cached the version for OpenGL 2.0 on my site.
Also, a very good book for shaders is the "Cg Tutorial" by Fernando
and Kilgard. When I first started using shaders, I didn't like Cg
that much, but I've been working with it for the past few months and
it has grown on me. Plus the book is very good. I can also recommend
"Advanced Game Development with Programmable Graphics Hardware" by
Watt and Policarpo. It's a nice full color book with full Cg source
code examples.
As for your shader, you didn't provide and XML tags
for the texture, so it didn't get bound to the shader by
jit.gl.shader.
wes
> ftp://ftp.research.microsoft.com/pub/tr/TR-2006-81.pdf
> which offers algorithm and has a sample glsl shader, but I
> haven't tested it yet, so I _hope_ it works...
ty nesa to point out that good paper. I read it, but I don't see how to apply it with jit.gl.shader.. This may be because I'm a newbie developer.
> My reccomendation would be to not do it and just work with
> opengl how it is for now. Although, I don't know what you're
> doing, so I can't say how critical it is.
I understand. Basically what I would do, is to simulate an atom/nebula of particles. once the model it's calculated (masses positions) I would render it "organically", and not just some "particles/spheres". I mean, not using spheres to visualize masses, but a more shaded objects, without defined borders, based on this mass of masses.. obtaining a soft form, with denser and lighter areas.
So these, let's say meshes/nurbs/volumes, will spin around and be seen from different angles. So I guess the problem of transparency is critical.
> If you are in to 3d graphics, definitely download the Jitter
> SDK if you know C and make some custom objects that do the
> drawing the way you want.
I am starting in 3D graphics, come from video making and tratement, but I really would merge this two aspects. I have some basic programming notions, and I'm not able to create custom objects. I thought that starting with shaders would be easier :)
Are there some workshops to be initiated in these practices? I read on vesa's site there are some organized by cycling, but I live in Paris.. IRCAM maybe?
Which compiler should I try to use to write/modify and check spelling of programs in GLSL or Cg?
> Alternatively, jit.gl.mesh might be your solution as you can
> draw orbitrary forms stored in matrices with it.
Yes but transparency will still be problematic. or not?
livio
ps I still can't visualize the JXS. How to see the forum in plain text?
ps2 Anyway it's really cool to have all this support from you :)
> vesa's
best,
weschua bentonstein
(i think i got most of us in this one)
> vade's
sorry i'm getting confused :)
livio
WONDER TWIN POWERS - ACTIVATE
FORM OF --- ??
v a d e //
www.vade.info
abstrakt.vade.info
>> vesa's
>
> best,
> weschua bentonstein
> (i think i got most of us in this one)
>
>
hello livio,
> more shaded objects, without defined borders, based on this mass of
> masses.. obtaining a soft form, with denser and lighter areas.
why not just generate 3d matrix with these forms, and visualise it with
jit.gl.volume?
please, check this modified jit.gl.volume patch:
hth,
nesa
On Nov 7, 2006, at 5:24 PM, Wesley Smith wrote:
>
> As for your shader, you didn't provide and XML tags
> for the texture, so it didn't get bound to the shader by
> jit.gl.shader.
But if i bind the shader to a jit.gl.gridshape, shouldn't the texture
pixels become available using the magic "texture2DRect(image,
texcoord)" function? That's worked for me in the past without
explicitly specifying a shader. But, even when I do that, I don't
see any image:
---- example patch ---
--- mat.phongtex.edge.jxs --------------
Shader for for modifying image contrast by interpolation
and extrapolation
--------- end shader-----------
After looking at your patch, I found the problem. Notice what the
name of your sampler is ... uniform sampler2DRect tex0; Then look at
your texture object in the patch. you have jit.gl.texture @rectangle
0. When making shaders, you really have to pay attention to what type
of texture you're using. This could be GL_TEXTURE_1D, GL_TEXTURE_2D,
GL_TEXTURE_RECT_ARB, GL_TEXTURE_3D, or GL_TEXTURE_CUBE_MAP. Each
texture type has its own sampler type and texture access function.
This is because shaders map very closely to the GPU hardware, so you
have to be very specific with your declarrations.
With jit.gl.texture @rectangle 0, you're create a GL_TEXTURE_2D which
is of type sampler2D and uses the texture2D function.
HTH,
wes
hey thanks for taking the time to look at my patch wes, i appreciate
it. this works now (i don't know why i added @rectangle 0 ...)
very good to know!
best
evan
On Nov 8, 2006, at 8:54 AM, Wesley Smith wrote:
> After looking at your patch, I found the problem. Notice what the
> name of your sampler is ... uniform sampler2DRect tex0; Then look at
> your texture object in the patch. you have jit.gl.texture @rectangle
> 0. When making shaders, you really have to pay attention to what type
> of texture you're using. This could be GL_TEXTURE_1D, GL_TEXTURE_2D,
> GL_TEXTURE_RECT_ARB, GL_TEXTURE_3D, or GL_TEXTURE_CUBE_MAP. Each
> texture type has its own sampler type and texture access function.
> This is because shaders map very closely to the GPU hardware, so you
> have to be very specific with your declarrations.
>
> With jit.gl.texture @rectangle 0, you're create a GL_TEXTURE_2D which
> is of type sampler2D and uses the texture2D function.
>
> HTH,
> wes
Hello
for the moment, I will use the jit.gl.volume method. Thank's for coming back to it, and for the example. It's rather the easiest way until I'll learn few basics in programming shaders, and eventually objects. Still, if you have any hints about workshops.. that would make the first steps easier.
best,
livio
nesa's patch is really nice - but here's a little "elaboration' on it
to make the result more spherical:
On Nov 9, 2006, at 2:58 AM, livio wrote:
>
> Hello
> for the moment, I will use the jit.gl.volume method. Thank's for
> coming back to it, and for the example. It's rather the easiest way
> until I'll learn few basics in programming shaders, and eventually
> objects. Still, if you have any hints about workshops.. that would
> make the first steps easier.
> best,
> livio
Hi Livio,
There's a technique for doing soft shapes that hasn't been mentioned
yet but which is IMHO much more flexible and straightforward than
depth peeling. It's called Volume Graphics. It treats data as a
participating medium in a world (meaning you model how the data
interacts with light). There are simple and complex models depending
on how fancy you want to get, but they all start with what's called
the Volume-Rendering Itegral. I just picked up a good book on this
called "Real-Time Volume Graphics" from A K Peters
(http://www.akpeters.com/product.asp?ProdCode=2663). It's a nice full
color book with Cg shader code listings which you can use directly in
Jitter via jit.gl.shader.
best,
wes
Hello,
I am trying to record a qtmovie from the result (in jit.pwindow) of
the help file jit.gl.plato...I am using jit.qt.record...but it does
not work-I do not know where to plug it in.. Is there an object for
recording the final window of the gl? I get error: jit.qt.record:
attempted to close track with no media. I was plugged at the end of
the jit.gl.render
Do feel free to point me to the tutorials.
cheers
Adina
Hi Adina,
there is a patch in the example folder called jit.gl-tomatrix
discribing 3 methods. If this is not enough search the archives with
words like openGL readback or similar.
good luck
Falk
Recording OpenGL in realtime as far as I know is not a solved problem
right now if you want high resolution and interactive framerates
(unless of course you have mucho bucks for some serious hardware).
The patch mentioned in the earlier post is the best way to go right
now.
wes
Thanks. I will have a look
Saludos
Adina
http://prof.usb.ve/aizarra
>
fraps.com is a program used to screen capture gaming videos with good
framerates.
windows only so not helpful for you i guess.
In the same vein: snapz pro for OS X should let you do it
v a d e //
www.vade.info
abstrakt.vade.info
Hello
to record live openGL rendered contex, if the PAL/NTSC resolution is enough for you, you can plug your second output of your graphic card on a DV camecorder.
You'll need a scan converter from VGA to composite, and a camcorder that take composite IN (analog video signal).
There are many scan converters, cheap and expensive ones. The cheapest solution I've found (that I actually use) is offered, surprisingly, by Apple. Search on the site apple "DVI to Video Adapter", 19$. If you don't have a camcorder with composite IN, ask your friends.
Otherwise you may want to consider the DVD recorder option. This is the way many VJ's record their lives, but it's quite an expensive solution.
Of course with this methods, your video pass through conversion and compression that might affect the quality on the pure GL render.
I tried with the glreadback options.. it's a smart method, and you may get the best result out of it (ie. more resolution, less compression, ..) if you have a very fast computer. Since it's a power consuming process, I'm not sure if you can reach much higher resolutions then PAL/NTSC, considering your process might already use resources.
best
livio
good tips livio
On 11/14/06, livio wrote:
>
>
> Hello
> to record live openGL rendered contex, if the PAL/NTSC resolution is
> enough for you, you can plug your second output of your graphic card on a DV
> camecorder.
> You'll need a scan converter from VGA to composite, and a camcorder that
> take composite IN (analog video signal).
> There are many scan converters, cheap and expensive ones. The cheapest
> solution I've found (that I actually use) is offered, surprisingly, by
> Apple. Search on the site apple "DVI to Video Adapter", 19$. If you don't
> have a camcorder with composite IN, ask your friends.
> Otherwise you may want to consider the DVD recorder option. This is the
> way many VJ's record their lives, but it's quite an expensive solution.
> Of course with this methods, your video pass through conversion and
> compression that might affect the quality on the pure GL render.
> I tried with the glreadback options.. it's a smart method, and you may get
> the best result out of it (ie. more resolution, less compression, ..) if you
> have a very fast computer. Since it's a power consuming process, I'm not
> sure if you can reach much higher resolutions then PAL/NTSC, considering
> your process might already use resources.
> best
> livio
>
hello Wes (and all of you gentle people)
it sounds very interesting! thanks!
is it a similar process then in jit.gl.volume?
I checked out some paper on the web (with fancy soft renders and some equations in it), but since I'm new in shader programming I really don't know where to start and I wonder if it's worth to buy the book, even if I'm sure it's a good one, it might be out of my range of action.
Aren't you tempted to update Jitter shaders in the next issue :) ? Or to disclose a pearl in this forum topic?
Anyway I'll try some bricolage..
I join a rudimentary patch to give you the feeling of what I'm working on.. but it's just a demonstrative sketch to point out some problematics.
cheers
livio
-----------
Hi Livio,
There's a technique for doing soft shapes that hasn't been mentioned yet but which is IMHO much more flexible and straightforward than depth peeling. It's called Volume Graphics. It treats data as a participating medium in a world (meaning you model how the data interacts with light). There are simple and complex models depending on how fancy you want to get, but they all start with what's called the Volume-Rendering Itegral. I just picked up a good book on this called "Real-Time Volume Graphics" from A K Peters (http://www.akpeters.com/product.asp?ProdCode=2663). It's a nice full color book with Cg shader code listings which you can use directly in Jitter via jit.gl.shader.
best,
wes
Another way, and even more expensive than DVD recorder, would be to use an
mxo box from Matrox. It takes DVI in an converts it realtime to HD or SD.
Then of course you'll need some way to record that output, like a computer
with an SDI card...
About livio's tips, if you don't have a camera that has composite in, a
solution would also be to use something like the canopus advc55 or advc110
to turn the output of your apple DVI to video adaptor into a digital
firewire signal.
b.
> good tips livio
>
> On 11/14/06, livio wrote:
>>
>>
>> Hello
>> to record live openGL rendered contex, if the PAL/NTSC resolution is
>> enough for you, you can plug your second output of your graphic card on
>> a DV
>> camecorder.
>> You'll need a scan converter from VGA to composite, and a camcorder that
>> take composite IN (analog video signal).
>> There are many scan converters, cheap and expensive ones. The cheapest
>> solution I've found (that I actually use) is offered, surprisingly, by
>> Apple. Search on the site apple "DVI to Video Adapter", 19$. If you
>> don't
>> have a camcorder with composite IN, ask your friends.
>> Otherwise you may want to consider the DVD recorder option. This is the
>> way many VJ's record their lives, but it's quite an expensive solution.
>> Of course with this methods, your video pass through conversion and
>> compression that might affect the quality on the pure GL render.
>> I tried with the glreadback options.. it's a smart method, and you may
>> get
>> the best result out of it (ie. more resolution, less compression, ..) if
>> you
>> have a very fast computer. Since it's a power consuming process, I'm not
>> sure if you can reach much higher resolutions then PAL/NTSC, considering
>> your process might already use resources.
>> best
>> livio
>>
>
found some links- pseudo code and theory.
A multi-sampling approach for smoke behavior in real-time graphics
http://www.ep.liu.se/ecp/019/ecp06019.pdf
Real-time Rendering of Accumulated Snow
http://www.ep.liu.se/ecp/013/007/ecp01307.pdf
its not really up my ally (or my league)
On 11/14/06, livio wrote:
>
>
> hello Wes (and all of you gentle people)
> it sounds very interesting! thanks!
> is it a similar process then in jit.gl.volume?
> I checked out some paper on the web (with fancy soft renders and some
> equations in it), but since I'm new in shader programming I really don't
> know where to start and I wonder if it's worth to buy the book, even if I'm
> sure it's a good one, it might be out of my range of action.
> Aren't you tempted to update Jitter shaders in the next issue :) ? Or to
> disclose a pearl in this forum topic?
> Anyway I'll try some bricolage..
> I join a rudimentary patch to give you the feeling of what I'm working
> on.. but it's just a demonstrative sketch to point out some problematics.
> cheers
> livio
>
> max v2;
> #N vpatcher 1029 44 1680 559;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 2;
> #P comment 258 36 121 196617 livio gioparte@gmail.com;
> #P window linecount 11;
> #P comment 357 317 215 196617 from the msd model , I obtain a set of
> particles position , that I would use to create the the "soft shape" ;
> using with the gl.volume with density values , means that I should
> calculate a very big matrix of densities to feed it , and I don't feel this
> is really optimised.. ; I even don't see how to calculate densities
> starting from particles positions. I'd need something like a jit.bfg with
> weights.. ;;
> #P window linecount 4;
> #P comment 259 194 259 196617 gives the idea of "atom" particles in 2D ;
> in the big patch this is done with msd library in 3D ; 40 particles
> spinning around a nucleus for three atoms ; this is modeled by a
> mass/spring simulator;
> #P window linecount 1;
> #P hidden message 95 72 14 196617 3;
> #P hidden message 76 72 20 196617 25;
> #P hidden newex 112 72 33 196617 s init;
> #P hidden message 25 72 14 196617 1;
> #P hidden message 40 72 20 196617 50;
> #P newex 25 54 48 196617 loadbang;
> #P newex 25 103 73 196617 s nucleus_dim;
> #P number 25 88 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname number[4];
> #N vpatcher 20 74 620 474;
> #P window setfont "Sans Serif" 9.;
> #P newex 237 106 33 196617 r init;
> #P outlet 60 174 15 0;
> #P inlet 60 33 15 0;
> #N vpatcher 21 74 621 474;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 308 248 73 196617 r nucleus_dim;
> #P outlet 160 355 15 0;
> #P inlet 185 27 15 0;
> #P number 308 267 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 0;
> #P newex 55 322 52 196617 value pos;
> #P newex 184 64 52 196617 value pos;
> #P newex 139 319 20 196617 t b;
> #P newex 154 281 27 196617 - 2;
> #P newex 183 281 27 196617 + 2;
> #P newex 165 252 27 196617 t i i;
> #P newex 222 282 27 196617 - 2;
> #P newex 251 282 27 196617 + 2;
> #P newex 233 253 27 196617 t i i;
> #P newex 55 293 48 196617 pack 0 0;
> #P message 286 132 39 196617 set $1;
> #P newex 269 111 27 196617 t b i;
> #P newex 269 162 71 196617 drunk 768 10;
> #P newex 183 84 58 196617 unpack 0 0;
> #P message 200 132 39 196617 set $1;
> #P newex 183 111 27 196617 t b i;
> #P newex 183 162 77 196617 drunk 1024 10;
> #P newex 163 319 199 196617 pack paintarc 0 0 0 0 0 360 255 255 255;
> #P connect 12 0 8 0;
> #P connect 8 0 17 0;
> #P connect 9 0 8 1;
> #P connect 14 0 15 0;
> #P connect 12 1 14 0;
> #P connect 0 0 20 0;
> #P connect 15 0 0 0;
> #P connect 1 0 12 0;
> #P connect 18 0 14 1;
> #P connect 16 0 4 0;
> #P connect 4 0 2 0;
> #P connect 2 0 1 0;
> #P connect 3 0 1 0;
> #P connect 12 1 13 0;
> #P connect 19 0 16 0;
> #P connect 14 0 0 1;
> #P connect 2 1 3 0;
> #P connect 18 0 13 1;
> #P connect 11 0 0 2;
> #P connect 9 1 11 0;
> #P connect 13 0 0 3;
> #P connect 5 0 9 0;
> #P connect 18 0 11 1;
> #P connect 10 0 0 4;
> #P connect 9 1 10 0;
> #P connect 18 0 10 1;
> #P connect 4 1 6 0;
> #P connect 6 0 5 0;
> #P connect 7 0 5 0;
> #P connect 6 1 7 0;
> #P connect 21 0 18 0;
> #P pop;
> #P newobj 80 123 57 196617 p new_pos;
> #P message 237 127 49 196617 512 384;
> #P newex 237 144 52 196617 value pos;
> #P newex 80 104 48 196617 t b clear;
> #P newex 60 60 30 196617 t b b;
> #P newex 80 85 50 196617 qlim 200;
> #P message 179 127 57 196617 brgb 0 0 0;
> #P newex 60 143 117 196617 jit.lcd 4 char 1024 768;
> #P objectname jit.lcd;
> #P connect 8 0 3 0;
> #P connect 4 1 0 0;
> #P connect 1 0 0 0;
> #P connect 7 0 0 0;
> #P connect 3 0 0 0;
> #P connect 0 0 9 0;
> #P connect 3 1 2 0;
> #P connect 2 0 4 0;
> #P connect 4 0 7 0;
> #P connect 10 0 1 0;
> #P connect 10 0 6 0;
> #P connect 6 0 5 0;
> #P pop;
> #P newobj 196 134 33 196617 p pos;
> #P newex 25 34 114 196617 autopattr @autoname 1;
> #X prestore flonum 1 0 1.;
> #X prestore number 1 0 50;
> #X prestore number[1] 1 0 50;
> #X prestore number[2] 1 0 25;
> #X prestore number[3] 1 0 3;
> #X prestore number[4] 1 0 50;
> #X prestore toggle 1 0 1;
> #P objectname u118000246;
> #P number 88 193 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname number[3];
> #P number 25 193 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname number[2];
> #P message 88 208 75 196617 slide_down $1;
> #P message 25 208 62 196617 slide_up $1;
> #P number 130 161 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname number[1];
> #P number 69 161 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname number;
> #P flonum 25 161 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname flonum;
> #P message 25 176 43 196617 prob $1;
> #P message 130 176 60 196617 y_range $1;
> #P message 69 176 60 196617 x_range $1;
> #P newex 196 192 58 196617 jit.sprinkle;
> #B color 5;
> #P objectname jit.sprinkle;
> #N vpatcher 655 207 1007 438;
> #P window setfont "Sans Serif" 9.;
> #P newex 157 96 33 196617 r init;
> #P outlet 20 160 15 0;
> #P message 157 124 49 196617 pos 2 45;
> #P message 20 124 49 196617 pos 2 45;
> #P message 71 124 70 196617 size 320 240;
> #P message 207 124 76 196617 size 1024 768;
> #P newex 20 96 41 196617 sel 1 0;
> #P toggle 20 73 15 0;
> #P newex 20 53 35 196617 sel 27;
> #P newex 20 32 40 196617 key;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P connect 2 0 3 0;
> #P connect 3 0 6 0;
> #P connect 7 0 8 0;
> #P connect 6 0 8 0;
> #P connect 5 0 8 0;
> #P connect 4 0 8 0;
> #P connect 3 0 5 0;
> #P connect 9 0 7 0;
> #P connect 3 1 7 0;
> #P connect 9 0 4 0;
> #P connect 3 1 4 0;
> #P pop;
> #P newobj 323 251 33 196617 p esc;
> #P toggle 196 90 15 0;
> #P objectname toggle;
> #P newex 196 111 51 196617 qmetro 2;
> #P newex 196 269 160 196617 jit.window rudimentary_example;
> #B color 5;
> #P objectname jit.window;
> #P newex 196 224 45 196617 jit.slide;
> #B color 5;
> #P objectname jit.slide;
> #P newex 197 316 156 196617 jit.matrix 1 char 1024 768 256;
> #P objectname jit.matrix;
> #P newex 197 338 86 196617 jit.gl.volume link;
> #B color 5;
> #P objectname jit.gl.volume;
> #P comment 81 56 76 196617 ESC toggle win;
> #P comment 259 135 121 196617 simulate "atom" position;
> #P hidden connect 24 0 26 0;
> #P hidden connect 25 0 22 0;
> #P connect 22 0 23 0;
> #P hidden connect 26 0 13 0;
> #P connect 13 0 12 0;
> #P hidden connect 28 0 18 0;
> #P connect 18 0 16 0;
> #P hidden connect 24 0 25 0;
> #P hidden connect 25 0 14 0;
> #P connect 14 0 10 0;
> #P hidden connect 24 0 28 0;
> #P hidden connect 29 0 19 0;
> #P connect 19 0 17 0;
> #P hidden connect 24 0 29 0;
> #P hidden connect 24 0 27 0;
> #P hidden connect 25 0 15 0;
> #P connect 15 0 11 0;
> #P connect 7 0 6 0;
> #P connect 6 0 21 0;
> #P connect 21 0 9 0;
> #P connect 10 0 9 0;
> #P connect 11 0 9 0;
> #P connect 12 0 9 0;
> #P connect 9 0 4 0;
> #P connect 17 0 4 0;
> #P connect 16 0 4 0;
> #P connect 4 0 5 0;
> #P connect 8 0 5 0;
> #P connect 3 0 2 0;
> #P pop;
>
>
> -----------
>
> Hi Livio,
> There's a technique for doing soft shapes that hasn't been mentioned yet
> but which is IMHO much more flexible and straightforward than depth peeling.
> It's called Volume Graphics. It treats data as a participating medium in a
> world (meaning you model how the data interacts with light). There are
> simple and complex models depending on how fancy you want to get, but they
> all start with what's called the Volume-Rendering Itegral. I just picked up
> a good book on this called "Real-Time Volume Graphics" from A K Peters (
> http://www.akpeters.com/product.asp?ProdCode=2663). It's a nice full color
> book with Cg shader code listings which you can use directly in Jitter via
> jit.gl.shader.
> best,
> wes
>