|
|
v002 updates Just a heads up - there are some updates to v002 plugins up at http://002.vade.info for Optical Flow, Film Effects, Blurs, and Screen Capture. Most fixes have to do with compatibility with some core image color manipulation patches (handle output colorspace conversions properly) as well as fixing issues with 3rd party apps, as well as fixes for some regressions. Enjoy. |
installed, ready & waiting to be deployed in pushing pixels :-).
Before I install... will this break any past connections in my compositions?
Also, nice that the problem with the render in image environment has been fixed. Boy that caused me a last minute headache when porting something from Leopard to SL. I thought I was totally up shit creek without a paddle. (Though, as we discussed, I was able to solve it by putting everything that involved the v002 Op Flow at the root of my comp.)
I would really like to see something like the Rutt or K3D heightfield be able to create a heightfield from an arbitrary input, instead of a plane. I think it might be more fitting for the K3D engine though.
So, what I would have in mind we to be able to create heightfield that pops out from arbitrary models/shapes, like a sphere, other models, a hull, whatever as opposed to the a plane.
Also, if one could have a "palindrome" heightfield (imagine another heightfield behind the front one, perfectly flipped so that it matches up with the front), where everything that is at 0 gets culled, then we could have the basis of a really cheap 3D liquid sim, as well as many other tricks, just by feeding in a particle system or something. I've mentioned this to anyone that will listen ;-)
Puh-leassssse, somebody!
No class names have changed. That was a one time only issue.
Also, as far as arbitrary output, this is what my vertex shader examples are for in the Rutt Etra download - there is an example that morphs from a sphere to a plane and back.
No, I don't mean arbitrary output, but arbitrary input. Right now, a heightfield bumps up from a plane/quad. One can put any render in a sphere glsl, or glsl torus, etc., but it doesn't actually make it a heightfield that is coming from a sphere.
So, with your example, if you put it in a trackball, or rotate, the backside is still "hollow" because of the fact that the heightfield is coming from a plane.
Imagine if instead of bumping out from a plane, one had in input that would allow you to bump out from different shapes (via a 3D model input), or even just standard GL shapes (not as cool, but better than now).
If something was bumping out from a sphere, if you rotated it, it would have heightfield coming out from every direction, no matter what. Similarly, if you input something like a single mesh model of a boulder, you could input a texture into the heightfield, and use that to mod the boulder vertices/normals.
Is this making sense?
Yes. Vertex shaders can morph a plane to a sphere, so from all directions it appears as though you are deforming a sphere. The same can be done for many shapes assuming there is a transformation from a plane to whatever shape you want and its reasonably good.
I forgot I did not use that example and changed it prior to release to build upon the earlier noise deformations examples I included, but its possible using the Rutt Etra right now.
I was referencing your earlier sphere morph example, so I know which one you were talking about.
With something like the Rutt, or any heightfield thing I've seen, it still does the extrusion from a plane, so the back side is still "hollow", even if you put it in any type of GLSL - the back won't "match" the front. I guess that's the only way I can explain the type of setting I'm looking for. That way, you could feed in text, for example, and end up with a perfect 3D looking representation from either back or front, among other things. Right now, if you turned something like that "around", you would see the letters dipping "in", not popping "out" like the front side. Something like the "blobber" qtz that I did with the K3D heightfield, would look more like blobs of liquid in space with that kind of option.
The earlier sphere morph example was never actually sphere morph, which is what I was saying - I did not re-name the macro when I published it and put it in the DMG. It only added noise to the Plane in XYZ. I chose to do that because it built on the earlier GLSL examples so could be a progression for folks to follow.
I don't believe I ever shared the one I was working on (an actual honest to goodness plane to sphere GLSL vertex shader) - but maybe I did?
Either way, I still have no idea why the text would only go in, rather than out or be any different from starting out as a sphere. This all depends on the direction you choose to extrude on and the direction you choose to 'wrap' the plane into a sphere - basically, its controllable form the vertex shader.
If you are saying that one side will be in, and the other out, then you are are not taking into account that the radius of your calculated sphere can be modulated by the absolute value of the original vertices Z value (ie, the luma displacement for that vertex), which would allow you to modulate the radius properly in or out around the circumference of the sphere sans any oddities.
Shit, I should just fucking try and dig that shit up - maybe I'm crazy.
if i understand what you are trying to say than its quite easy to achieve it with glsl. the only thing you have to do is, instead of displacing in a fixed direction (the z axis) you displace in the direction of the shapes normals.
with the plane it goes something like:
gl_Vertex+vec4(0,0,offset,0);
what you want is something like:
gl_Vertex+vec4(normal.xyz*offset,0);
is this what you mean? or is it like usual and im totally missing the point here:).
You can do that already with a simple levels or contrast patch before the displacement image. We do this in a shipping product based on a modified Rutt Etra code.
Ok, there is something getting lost in translation here.
I'm not talking of only 0 culling (which DOES happen in certain cases), but also, being able have the resulting look "close" at the seams at the 0 point. It is the combo of both that would be able to yield a bunch of soft liquidy orbs from a simply gaussian particle system, or a solid 3D block lettering that can be viewed from all sides and not look funky.
Also, it doesn't seem so simple to make sure that the 0 point culls all of the time.
I made an example pretty quickly here (I'm not going for perfect scale/size match between the string that is inside of the render in image, and the one outside, only so it's a little closer than what it would be by default).
For instance, culling doesn't happen whether a clear is black or alpha. It DOES happen with the image in string patch by default though.
So, what would one do to make it cull reliably? In addition, am I still correct in my point that there is no real way to make the extrusion "close up" and be seamless at the 0 point?
Define "0 Point"
The place that the plane is at when there is no extrusion.... if there is no extrusion happening, then the plane is located at 0.
Ok, sure - it always lines up there. Its just that in your example
1) Your image has little to no gradation between white and black - the extrusion is immediate - granted there is a small blur but the resolution in terms of vertices is very very small, this leads to jumps.
You can use a completely different image for your displacement amount, maybe vignette or use a dark "inner glow" at black so the pixels do not jump in your displacement. That plus increasing the resolution can help greatly.
2) the image has alpha, and the alpha in the same immediate transitions between white and black, leading one to believe the pixels not extruded (ie, black, which is alpha in your example) never meet one another. They do.
Check it :
I see what you're driving at, but you don't see the horrible visual quality of your png? I don't think your picture shows what I'm getting at. There are really nasty artifacts on the side, especially where they (arguably) "meet". I wouldn't call that "meeting" because it is transparent at 0.
I don't mean this as anything bad about the Rutt, because it's great. I'm just saying that it can't achieve the visual result that I'm trying to describe, which isn't traditionally an option with this sort of thing. If you had shown a picture that looked like a solid 3D model of text, then I'd be going "OK, you're totally right".
Hmmmmm.
some kind of cross between convolution and marching cubes?
This is because of how the texture mapping is happening. Its writing the coordinates linearly across the mesh, so two coordinates that are at the same x and y value, but that have a different z, have a different texture coord since that coordinate was originally "to the left or right" of the one previous. This is why its transparent 'during' the displacement, its interpolating the texture from non interpolated to interpolated. I suppose I could specify nearest.... just out of curiosity.
The visual quality is 'poor' because this is just about the worst way to do what you want to do, OpenGL wise :P
The Rutt was not really meant to do what you want to do, to be honest.
Yeah, I totally know that the Rutt wasn't meant to do that, it's not lost on me at all. It's just that in using it, as well as K3D, that there have been times where I've gotten results that look so "liquidy", that it's hard not to feel like it's one step away from being one of the fastest liquid simulators ever... if only I was able to actually navigate/rotate the scene or resulting "object".
This is why I've felt an idea like this needs to be a setting, not just placing two Rutts (or whatever) back to back.
OpenGL wise, it may be definitely crazy. From a user perspective, it is extremely desirable. The flipside, is that there really isn't any way to do what I want to do right now, which is to be able to take 2D images, and make slick 3D objects that are complete, front/back/sides, all on the fly.
With a technique like this, one could type 3D text objects in realtime, or again, do full on liquid simulation from a simple 2D image among other things...
Going back to the point about being able to distort from something other than a plane as the base (an arbitrary 3D model for example), it would be an amazing method of adding hair and skin looks to objects. One could contour the displacement image so that an area on top of a 3D object's head looked like it had hair, for example, and leave the face with a slight skin look.
I don't expect anyone to go "yeah, let me jump on this, what a great idea"... but it IS a great idea ;-)
Horrible hack that I discovered while wasting my time thinking about this, rather than my work issues (ha!) :
Use a v002 Erode on the displacement image. It effectively shunts the displacement 'in' so that the input texturing image (diffuse image if you will) maps slightly 'over' (its not larger bounds wise, its larger within the area of the image). This means the texture coords with some (lots) of manual massaging work out so it looks like you want.
This is a horrible hack, and I hate that I spent time thinking of this. The good news is it doesnt require any re-programming of the Rutt Etra, the bad news is this is a horrible hack and wont work all the time:
Note I also fiddled with the resolution of the string image and the resolution of the Rutt Etra, so your horizontal resolutions match - this is important for rendering the curves so they look decent. However, it wont really work great for all rendering modes. I admit the "Image Plane" is lacking. Due to work related stuff, I may or may not be able to help out.
hint: NI Rutt/Etra - in FX Factory 2.1.5 - has some other features you may want, works the same. You did not hear this here.
heres something
edit:
heh, looks like wasnt the only one preocupied with this:). i just used the pixel shader to make the threshold and avoid the interpolation problem.
The erode is an interesting idea, and it sure makes it look better. I've used some CI filters to tweak it in just about like this in the past. I like your Erode plugin very much, and am a sucker for morphology stuff.
However... vade- do NOT hate me for my persistence and constant needling on this! It still doesn't really close at 0, and while it is way better, at certain angles, the "plane" that the heightfield bumps up from is the same color as the clear, but it isn't really transparent - it will overlap on the renderer on the backside.
IMO, you shouldn't hate that you spent time thinking about this, because a plugin that made 3D liquid and text from 2D images would probably be a pretty sellable proposition. NI would probably be pretty happy about that!
( I admit I would probably rather see this kind of function as a K3D deformer, and a processor, not a renderer... no insult meant at all, it's just that it already makes sense in the context of K3D, since I'm also talking about what amounts to putting a heightfield on a 3D object as well, for full extrusion bliss).
Thanks for the head's up I don't know anything about ;)
Like I said it wont work for all rendering modes due to the lack of culling and blend modes being published as configurable. Try the thing I mentioned.
NO kidding! With GLSL too, good idea. Kudos to you fsk. Hmmm, nice. BTW, the alpha depth environment isn't needed on this one.
To be finicky, there is still a wee bit of that seam, and there isn't a methodology for making the "curve" look quite right if you're inputting something like a gaussian image... the GLSL doesn't let you get quite the same slope as the Rutt or K3D even when processing with blur and other smoothing filters, it juts out kind of straight (getting pretty good for text though, for sure).
Sure thing.
BTW, does anybody know of a good way to extract the contents of a package, to avoid using installers? The NI installer really whacked out my plugin folders awhile back and irritatingly made it so that many of my plugins that don't implicitly have an image icon look like folders. Not a huge deal, but it sure did freak me out for a few minutes. I also don't want to install "over" other versions of some things I have in there, in case other plugins have changed in ways that I don't desire.
the alpha depth environment is there because otherwise the invisible part of the grid will cover the other half if you use the z buffer.
heres another version. a bit softer. in the first one i forgot to remove the thresholding in the vertex shader :).
Hmm, if I rotate your first example every which way (when taken out of the GL Depth Buffer Alpha Threshold environment), I still can't "see" any of the GLSL plane. I may not be putting it at a rotation that makes it fail though. On my computer it sure doesn't seem to make a difference....weirdly, the actual orig depth buffer example doesn't look quite how I remember either. Maybe I need to vet that a bit more, and flip back to my Leopard partition, this partition I'm in isn't exactly standard.
FSK, you win! At least on text extrusion! Check out the pseudo liquid, it's not too bad either.
Those are both really nice. Awesome!
Ok, after a meal and some coffee, I have the GLSL extrusion shader deriving it's color from the texture input.
However... in letting color derive from the texture, I can no longer seem to void out the alpha parts of the image from rendering with the GLSL. All the same I'm posting it, because it's fairly cool to have extrusion like this that preserves the texture input color working in GLSL with no plugins.
If anyone can think of an approach for using the actual color from the texture, and getting the alpha (or any color) areas to cull, it would be great. I'm not bothering to post a "text back to back" example, since I'm getting black rendering around the areas that aren't text.
Hm. Looks like there may be a bug in how the blur handles intensity + alpha textures. Removing it and putting in a Core Image gaussian seems to work.
You took the words out of my typing hand!
I was just experimenting with that, and found that a number of the stock blur CI's are working fine. However... yours really smoothed those edges nicely. I'm having a bit of a time finding a blur that smooths that "seam", and also doesn't leave a tiny bit of black around the edges.
throw in a custom CIFilter, it will force an output to an RGB image before hitting v002 Blur, which will make it handle alpha correctly for that image type.
I'll experiment with proper Intensity8 image input support. Blargh!
This thread is getting ridiculously narrow...
a|x
Which is why BBulletin forums always look better than Drupal :-P
I think smokris likes the narrowing effect though!
D a r n !
Check the link for the first GLSL Extrude with Color From Texture.qtz. Seems to be the checkered shirt jpg link. Nice work in this topic, folks! Thanks!
Oh weird!
This was the first one..
Actually, this is a more useful tweaked in version that I had going late last night, where the v002 was replaced with the simple Gaussian so that the plane "dissapears". It also removed the GL Alpha Threshold (which I swear is making no dif for me), and has a Polygon Mode, so it can get Rutt type looks with the GLSL and GL Tools combo.
Stuff like sobel filters, edge filters, threshold stuff, etc., where giving some pretty cool effects when I was up laaaate, playing with this.
Still, the mythic thing for me is to be able to get the full on color, and still be able to "seal up" the edge a little better than any of those examples. FSK's example is excellent for that except that it has to remove the original colors as part of the process (which makes sense...).
Ok Kineme needs a new comment system.
Vertex Texture Fetch / Vertex Displacement is def a cool feature. If it had been around and working earlier I probably would not have written the Rutt Etra - however, you loose some of the nicer more scanline-esque looks, which is kind of a shame. I could probably write a pretty decent consumer plugin patch that does some plane rendering methods. Hm.
The new scanline type that you added in a version or so back ARE REALLY &&^%^* cool!!! No joke.
I started messing around with a plugin project last night to see if I could successfully get a few more render types going (eg., added another texture input so that the displacement can be different from the texture). Displacing on a sphere, or a model, works fine. I'm figuring I can just put a qtz in the nib and let it do the work. On that note, did you ever post the Rutt code anywhere? It would be nice to give it a look if possible (I can keep it private, or not distribute my resulting project if necessary, BTW).
Actually, what I would like to do is to code it as an Environment that leaves whatever is currently textured on an object in place, that way anyone can use whatever they want as the actual Render patch. I'm not sure this is possible at all/ possible in the Official API, to code what amounts to a deformer, into a Macro Environment. (Chris or Smokris, if you are lurking, give me a head's up, I'd like to fiddle with this in my spare time, and I know the SkankySDK has some major updates since the last time I used the project).
When you get subpatches with your plugins, you aren't using the Official API, are you? Are you using a the Official API Subpatch support from Kineme, or a variant?
All of the source code to all of my plugins is included in the dmg download, I think i've told you this like three times now :P
I was pondering making a version that just drew a few spheres rather than planar shapes at a point for each vertex, but that gets expensive fast.
Ok, ok, point taken! :-) For some reason, I keep looking in the main folder instead of the dmg; that's why I asked yet again! I usually just trash dmg's. Serves me right for doing so much of my emailing right before I go to bed/pass out, whichever happens first.
Yeah, drawing individual objects can be insanely expensive in that context (I've used OpenCL to generate displacement points, with which I have placed various objects... not the same as what you are describing, I'm sure, but maybe similar).
I placed an elephant model inside of the extrude GLSL and was distorting it with various textures... and even vid feed last night. It was pretty insane looking.
its been working for me since i got the first nvidia mbp. at least i think so.
i made something like that for exactly this purpuse:). http://kineme.net/forum/Discussion/Programming/staticgrid
it doesnt have all the rendering modes of rutt etra, it only has quads (looks nice in wireframe) and lines. the lines arent anti aliased (ill add the two lines of code on the next iteration:)). the version i posted seems to have a bug which i cant reproduce on my end (not the 0 thing, i fixed that). it doesnt use VBOs or anything fancy like that (im a GL noob) but a display list seems to do well. its actually quite a bit faster than the two other GLSL grid patches. at least on my macbook pro and QC3.
you can use two textures in GLSL. it used to be 8 max but i dunno how thats now.
now i just have to fix my example to show this:P.
here is the two texture example. i also changed the variable names to make more sense:).
btw, all my examples use the red channel for the displacement but you can easily change that in the vertex shader.
edit: forgot to mention something. i think the alpha threshold environment patch is only needed in QC3 (which is what i use). whenever i tried QC4 i just couldn't resist playing with CL but the crashes were so counterproductive i baned myself from using it:/. did 6.3 really fix this?
it doesnt really have to remove the colors. i just did that because it looked better than a solid color. the two texture example shows this. all it really has to do is make sure alpha is 0 where displacement <=0 (when using a plane). the "*vec4(1.,1.,1.,float(displacement>0.))" part does this.
One might as well use the GL Polygon mode to get line and points though (imo).
Yeah, I know it doesn't have to, but it did ;-) I was up till 4am last night fiddling with this, and we ended up with the same shader (albeit with different texture input port names). I hadn't posted it yet, because I'm still not 100% happy with the vertex smoothing.
Hmm, I thought you could use more than 8.... my impression was that it was limited by graphic card support (not talking about just QC here).
in line mode it doesnt draw a grid, its horizontal lines only like rutt etra.
True, but you're still deforming from what amounts to a plane. One thing I've found to be fun about this is that one can put an arbitrary model inside of the GLSL. This is another part of why I think the thing needs to be made into a macro environment plugin, so that various line/point modes can also apply to whatever is in the environment.
im kinda confused about where the deforming came from, but i can tell you that, there is no plane. there are just gl primitives.
but it can not. its not the same thing to draw a line or to draw a triangle with lines. vades rutt-etra and my static grid plugin both generate totally different geometries for the different rendering modes. where as the polygon mode patch just tells the graphics card to draw the same thing in a diferent manner. there is just no way (that i know of) a macro patch could redefine geometry like that. except maybe a geometry shader. but thats a whole different thing and to be honest i have no clue yet how those work so i cant say what could be done with them.
:)
When I say "plane", I mean "flat surface".
I guess I'm not expressing myself clearly. There are two things that, when I use GL Heightfield/Extrusion stuff, that I'm always wanting to achieve. The first is to have a nice seamless front to back. The other is to be able to have an actual object, or other shape have extrusion. I'm not trying to re-replicate a Rutt with GLSL, I'm trying to gain useful, and good looking, functionality that is past what is available with the Rutt, as being only a renderer, the K3D being a processor.
Doing this with a standard GLSL environment requires that people retexture objects that may already be textured easily, if they choose to place them inside a GLSL macro. I'm trying to convey that having that as a macro environment that didn't require having two texture inputs - one for deforming, and one for the image texture - would be more user friendly and straightforward for most people.
If there was a straightforward patch like that, that did the deforming inside of the environment, but preserved the texture image that was already input into the renderer, one could use any of the stock renderers or your grid, K3D objects, mesh, or whatever... AND they could also use a GL polygon mode macro in addition if they should so choose, if one wasn't using something like your grid, but wanted a wireframe pig that was jiggling to image input or something.
That's what I'm trying to get across. Doing the multi-texture thing is cool, but it would be nice for this to be built into a macro environment that didn't require someone retexturing their object, especially in the case of stuff like the dae mesh loader/render combo. Who wants to go through the pain in the ass of retexturing an object that is already correct, if all that a User (in this case, me), wants is to deform what is inside of the macro from an image input? The only way to be able to place all kind of different objects inside, is for it to still be an environment patch. I see it as a macro that one wouldn't necessarily place a scene in (but could if they wanted) but that one would place a single render patch in.
As far as my comment that you reference below this post, about your GLSL having to remove the color to get the look, I said that because of the issue with the v002 blur that was resulting in the black areas as soon as I referenced the colors from the single image input. If you take your original GLSL and rewrite it to reference the input color, with the same v002 blur you have in it, there are black parts that don't get culled. When I say "setup" I mean the whole shabang... all of the patches together. The way you did the shader that renders bluish greenish got around the edges resulted in the v002 blur thing being a non-issue, because the v002 blur issue didn't show up with the way the color was being established. If there had been a CI blur in there, I wouldn't have said that the setup had to do your original color change to work.
In addition, as a plugin macro environment, it would be slick to have a port that allowed you to change what color causes extrusion, much in the same way the K3D one works. IMO, that is better done with a custom plugin, and best as an environment.
Hey if my opinion sounds weird, it's weird, I just know that it would be useful to me, more so than any currently available method.
I get the following error upon opening test3.qtz
although the composition works AOK with almost any other blur, I did find that small gaussian blur would only give a GF Log error -
BTW, I've been playing around with OpenCL and text image as texture input into the Mesh Creator patch.
See attached - another iTunes viz :-), AuroraCyberoText, explicitly using Image as String as the texture input and another viz, QCTextDeformationVertexShader0, but working with straight audio input - OpenCL & GLSL that uses a deformation shader [spontz.org derived] - this one needs QCText.dae from http://developer.apple.com/mac/library/samplecode/OpenCL/Introduction/In...
The Aurora Cybero Text comp relies upon the Track Info and has been found to just produce blocks instead of mesh rendered text, ensure that the iTunes app is showing information too if you are running in QC.
Post Script
I have found that the AuroraCyberoText provokes a totally reproducible crash when deployed as a visualizer in iTunes - so do not deploy in iTunes and if you are wanting text, just get the string from the directory listing / XML structure you're reading the playlist from.
I have uploaded a copy of the QCText.dae for convenience, it needs to be at the same root level as the QCText composition.
Post Post Script
I have subsequently found that the introduction of any image input to that protocol setup produces the same iTunes crash.
Shall look into if smoothing the spectrum more assiduously might help, but kind of doubt it. [looked into it - still get a buffer crash - any type of texture]
Does not crash directly in QC, so long as it is not also running in iTunes.
Running Jelly in iTunes to check out the track info meshes in my comp will work AOK though.
I restarted, cleared the cache and the v002's are running beautifully, so I think it's something to do with the test3.qtz and in fact, now I come to think of it, the test2.qtz also gave the same error. [just checked and test2 do the same bad th-a-a-ang as test3]
so apologies for any anxiety caused by the correct as it then stood report & now we are stuck with the mystery of why the v002 fouls up within the test2 and test3 .qtzs and then that problem gets shared out to any other new comps calling upon those v002 Blur plugins within that same session, even in new compositions, until you quit , clear cache & restart QC.
Ah, CI Small Gaussian Blur! There's been a bit of discussion about that one (if you look back, I believe all initiated by me). The list populates the patch list, but the CI is non-existent as far as can be told. You can't even "get" Small Gaussian Blur to go onto the Editor.
I believe it's a Core Image bug (a dead listing is how I remember it being described to me...in the list of patches, but that the kernel is non-existent), not a QC bug, because of the fact you're loading private patches, so all Core Image filters that are listed get loaded into QC (including other non-applicable stuff, like color cube and it's virtual data input).
I've actually got some ideas on that. I don't think QC likes a plugin output image provider with a QCPluginPixelFormatI8 associated with the contexts colorspace, since the context is 3 component color space (ie, DisplayRGB, GenericRGB or GenericRGBLinear), but I need to supply a GenericGreyscale - but this means it wont color correct at all. I have a test build which fixes that - but its lame because i've yet to figure out a way to render using the same shaders for RGB to an Intensity texture, on both 10.5 and 10.6.
I do have a possible fix though.
What is lame is there are no example at all from Apple on handling all of the various types of image formats. In fact, there is no example of a GL image filter at all, so we are all flying in the dark. Its pretty lame.
But, importantly, is Intensity (Internal_I8) working to blurs and out now for you? Maybe I got the same hiccup and my workaround was a placebo?
Can you send me a demo patch showing how the built in Gaussian differs from the v002 Blur in a simple case. Im pretty sure I am rendering alpha and friends 100% correctly in all of my tests.
There are bugs with the GLSL patch where it does not properly pass gl_TexutreMatrix1 and greater. it works for 0. This is part of why I use custom patches, the GLSL environment seems wonky as fuck with images.
Also, as far as an earlier comment, VTF and VTD do not work on 10.5, wheras Rutt does. Oh well.
Do you mean by strapping in FBO Glitch & similar texture format wise?
Upon checking, pretty much everything else I work with is Display RGB, GenericRGB or GenericRGBLinear, sometimes GenericGreyscale [like the Image to String image].
This seems like the most pertinent thing I've been tinkering with today.
Love the way the FBO Glitch automatically reuslts in a kind of Fibonacci layout :-)
No no. I mean internally, GenericGreyscale is in OpenGL parlance "Intensity8" format. There are gotchas with that it seems in a custom QCPlugin - but I have more investigating to do.
I dont understand what your comp is supposed to be demonstrating?
Edit: to be clear, an image marked in QC as being GenericGreyScale is according to GL profiler an Intensity8 image.
No joy on the blur up from an Intensity8 image.
Same reproducible problem message wise.
Ah, good. Then my fix worked - I saw no issues and got no error message. I'll try and push an update soon. So much going on right now...
hi,
I'm using vade's movie player to play and stop a movie (thats all). I see the latest version of the patch doesn't have the Reset option. I'm playing a very short clip of a few seconds. To stop the clip I'm simply disabling the sprite in which the movie renders but what could be a solution if I want to restart the movie with the click of a button? perhaps returning the playhead to 0 ?
thanks for any comments,
juan
PS... the same question could apply to the Movie Importer patch since i'm not using all features in vade's patch. So... in Movie Importer... should I simply return the movie position to 0 ? (i'm not posting this to the dev list ;-)
Yes, returning the playhead to zero is like reseting. I do that all the time. :-)
nice. thank you.
I finally got around to putting out 10.6 / QC 4.0 compatible updates to the glitch plugins. Thanks to Noise Industries for OK'ing this public release with source (They have commercial rights to some of the source in this).
http://002.vade.info/?p=41
Expect Tom/bangnoise to have some new tricks soon, but since I got the go ahead I figured I'd package some fixes for 10.6 sooner rather than later. This release has no specific functionality updates, but working with 10.6 is nice. Included are some VDMX and CoGe patches.
Is there a version for lion? i am getting crashes with the latest beta. Thanks!
See v002.info for more information. [Basically , no]
http://v002.info/?page_id=13
http://forums.v002.info/topic.php?id=151