Multi-Pass GLSL Shader Patch

No idea if this is possible as a QC patch, but it would be incredibly cool to have support for multi-pass GLSL shaders in QC, so that the the geometry of one shader could be passed to another.

It would also be great to be able to run multiple GLSL patches at the same time (in an Iterator, for example), and have the geometry from all the instances combined into a single 3D scene (it's currently only possible to run multiple GLSL patches if you place each inside a Render In Image patch, and then of course, they're effectively all 2D images, rather than 3D objects, so can't be drawn convincingly together). This is possible in VVVV on the PC, and I've seen multi-pass GLSL shaders working in RenderMonkey, so I know it's theoretically possible, at least in OpenGL on Windows.

Cheers,

alx http://machinesdontcare.wordpress.com

cwright's picture
multipass

I was about 2 seconds away from saying "silly alx, vertex shaders go straight to the rasterizer! lawlz!11" when I remembered something: There are feedback buffers in opengl that might be able to capture vertex shader output (to pass through another vertex shader, for example). I've never seen this done, and I don't know if it's possible in GLSL (I left my opengl bluebook at home this week :/), but I found this promising post for HLSL/xna: http://forums.xna.com/thread/41256.aspx

I'm still not certain whether it's possible, but this new avenue is definitely territory I'd like to explore in the near future.

multi-pass fragment shaders should be possible a bit more easily. Sadly, you've poisoned google so it's a bit more difficult to search for stuff like this :) (Way to go on SEO though ;) -- I'd like to check this out too (especially the difference between 2d and 3d fragment shaders, as you've mentioned... I was under the impression that they're the same thing, but I have no personal experience with it to back up that impression.)

How do you reckon we'll be able to control such a monstrously complex patch? QC doesn't have any vertex/fragment shader ports to pass such things around (though that would be pretty rad, as you could just plug-n-play with shaders... man that idea makes me smile:)

toneburst's picture
Interesting...

Hiya!

Apologies for posting this here, after I'd already posted an Enhancement Request to Apple. Just thought maybe there was another method... and it turns out maybe there is :)

Just read that post, and it actually chimes with something I was thinking of about Display lists. I was also wondering if the vertex list could be somehow buffered, then multiple buffers combined together before rasterisation, which is exactly what the post suggests (albeit in HLSL/PC land). This seems to be the way VVVV works, as far as I can work out.

In terms of how a multipass shader patch would work... good question.

Two things come to mind:

  1. It would be really great to be able to just stick a GLSL patch inside an Iterator, and have the vertices from all Iterations automatically collated together. Maybe some kind of Macro '3D accumulator' patch that you'd nest the Iterator inside would be a goer.

  2. Alternatively (or ideally additionally), a variation on the GLSL patch itself, with a Vertex output, and input, and a seperate GLSL renderer for the accumulated 3D objects?

These are initial thoughts only, and I've really no idea if any of this is possible, but as you say, it would be VERY cool if it was!!

Re. the Google thing- entirely unintended. Just a side-effect of me asking lots of silly questions on forums across the Web. It's that unfortunate combination of enthusiasm, not matched by knowledge ;)

Incidentally, I've been experimenting with iterated GLSL patches today. The snag is each iteration has to be rendered to an image with a Render In Image patch, so it runs like a dog. Looks nice though... http://machinesdontcare.wordpress.com/2008/02/27/pseudospreads/

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
invariance

In GLSL, there's the invariant keyword, which you use to keep vertices in the same place when doing multi-pass fragment shaders. Doing this shouldn't be difficult at all (however, QC doesn't provide a way to supply multiple fragment shaders, so a lot of UI code would need to be written to allow the user to add multiple fragment shaders).

Does anybody honestly use DL's anymore? From the recent (past 5 years) opengl stuff I've checked out, you either use immediate mode (massive geometry, or very simple geometry), or VBO's/VBA's (shockingly fast, for more than a few vertices, and less than several million vertices). I'm often mistaken on this stuff though.

I'm going to build some tests this weekend to see what I can figure out; this question is starting to drive me crazy :)

Don't worry about the google stuff :) I've done the same thing (asking about various QC-related things), so I just thought it interesting :)

We've discussed a vertex accumulator for Kineme3D actually, that sounds similar to your suggestion with QC Objects. I'm not sure of all the details for that yet, but I'll think about it some more and see what I can reason out.

Rad pictures, by the way :)

toneburst's picture
:)

You're probably right on the Display List thing (certainly far more likely to be right than I am, anyway ;) ). VBOs sound like the way to go, from my VERY limited knowledge. I think some of the OpenGL documents I've been looking at might be quite old...

I'm really excited about this now! Can't wait to see what you come up with!!

Thanks for the comments re. the pics, by the way. I'm really just playing catchup with the VVVV guys. Still, sometimes you get interesting results from working around limitations.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
gl extension!

Ok, I think I've found it: Vertex shader output requires the "EXT_transform_feedback" extension. This can be used to put the output of a vertex shader into a VBO for reprocessing. I've not tried it, but it's supported on my hardware (gma950), so I'm guessing it's pretty much everywhere by now. I'll try to do some tests with this for kicks this weekend :)

If this works as expected, it'll be way less hacky that I was imagining.... It'll completely change the way I think about vertex processing. shudders

[By the way, if this works, Kineme3D's deformers could all be rewritten in GLSL... lots of work, and some internal changes would be necessary, but it would Scream on machines with Hardware T&L (i.e. not mine :( )]

Mad props to toneburst for continuing to bring this up even after I had considered it impossible. :)

toneburst's picture
AHA...!!!! That sounds

AHA...!!!! That sounds coolcoolcool.....

Would this also make it possible to 'accumulate' meshes from multiple GLSL shaders running inside an Iterator? That would be the icing on the cake, I think.

I don't deserve any credit for this one- I just planted the seed of the idea ;)

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
Any luck with this

Any luck with this one?

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
delayed

Some projects have come up, and I got a bit distracted (girls ...), so I didn't get to it. I'm sorry.

franz's picture
ha ha ! don't apologize you

ha ha ! don't apologize you fool ! what's more important than grrrrls ? (don't say money !)

toneburst's picture
girlS

GirlS plural? You lucky man, you.... ;)

No problem. I've just managed to get a simplified version of tonfilm, gregsn and sanch's VVVV Superformula shader working in QC, and I'm quite pleased :D Course, I have no idea how it works, but it looks nice, which is the main thing! Now to get lighting to work...

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
indecision

only plural because I suck at making decisions :)

I saw some of the supershape stuff (not sure if superformula is related to it) -- I don't envy you having to write normal-calculation stuff (for complex surfaces, there's usually a bit of calculus... that sometimes makes my brain turn off.)

toneburst's picture
Heehee. Decisions,

Heehee. Decisions, decisions... Not a strong point of mine, either, sadly.

The supershape stuff is related. It uses a 2D version of the Superformula/Supershape algorithm originally developed by Johan Gielis. I took the code from Paul Bourke's site ( http://ozviz.wasp.uwa.edu.au/~pbourke/surfaces_curves/supershape3d/ ), and worked out a simple CIFilter implementation of it

I'm nowhere near being able to work out normals myself. Also, sadly, disappointingly far even from being able to work out how to convert the chunk of HLSL code where tonfilm, gregsn and sanch work out the normals, into something QC can understand.

I'm planning to try and enlist my brother, who's a maths graduate in that side of things.

Having said that, this post has some potentially useful stuff on normals, actually http://tonfilm.blogspot.com/2007/01/calculate-normals-in-shader.html in relation to mathematically-defined surfaces, at least. Not sure how this works in terms of things like Vertex-Displacement-Mapped meshes though. I have a horrible feeling it's horrendously hard to do....

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
displacement normals

Franz and I have fought with displacement-mapped normals off and on for a bit. It's basically impossible to get right without a lot of tweaking, since calculating normals properly requires knowing a lot more data than vertex shader's typically have access to (either all the vertices of a face instead of just one vertex, or knowing the formula used to displace by so derivatives can be calculated).

If you maths brother makes any discoveries, please make them public :)

toneburst's picture
Will do!

I will do!

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

psonice's picture
Faking it

Ah, so its not just me that gets stumped by calculating the normals after displacing the vertices then. That's quite a relief :D I got around it with some nasty faking (basically using the vertex displacement formula on the normals with an offset for faked directional lighting)

toneburst's picture
Talking of Normals...

This is a little OT, as it's basic GLSL stuff really, but maybe one of you will be give me some pointers as to where I might be going wrong. It's probably something really obvious...

I'm messing with stuff I don't understand, as usual. This time it's a GLSL/QC conversion of the VVVV Superformula shader (screenshots on my blog, if you're interested). I've got the geometry stuff to work, but I just can't get the lighting to play ball. I'm pretty sure it's a normals issue.

The vertex-displacment code returns vec3s for the Tangent and BiTangent of each vertex (in un-transformed Object Space). I'm trying to calculate the Normal using

normal = normalize(gl_NormalMatrix * cross(Tan,Bi));

but it doesn't seem to work.

If I use

normal = normalize(gl_NormalMatrix * gl_Normal);

I get some lighting (weird lighting, as the normals of the original mesh are completely wrong for the distorted mesh), so I know it's a normal problem.

Any ideas where I'm going wrong?

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

PS feel free to tell me this is not the right forum for this kind of question...

yanomano's picture
Normal Calculation

Don't now if this help but have you seen this link ?

Normal calculation in shader :

http://tonfilm.blogspot.com/2007/01/calculate-normals-in-shader.html

toneburst's picture
Going back to the original question...

Given that it's theoretically possible (though inadvisable) to create a QC patch to allow the execution of arbitrary OpenGL instructions, would it therefore be possible to create a patch that would allow you to run a GLSL shader program (or more than one shader program) directly, bypassing the existing GLSL Shader patch?

To replicate the functionality of the current GLSL patch, you'd need to create a text-editor with code colouring etc. and some kind of error-checking. You could perhaps do without this, though, and just have the patch read a text file containing the vertex and fragment programs off disk, run the shader code, and stick the result in some sort of accumulation buffer, where it can be joined by the results of other shader programs.

Initially, perhaps, the shader could act on a simple hard-coded grid primitive (with selectable number of vertices), but you could later add the ability to have it work on other primitives.

You'd need some way to have the patch dynamically create input ports as necessary. Don't know if this could be done, but if it could, you could improve on the way the existing GLSL patch does it. It's really annoying the way uniforms don't currently appear as input ports until they're referenced in the main shader loop.

As usual, I have no idea if this could be done, so just thinking aloud, really...

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
scalability

Possible to run a shader program: yes; there's a patch in kineme3d that does this.

text editor et. al.: possible, but much more difficult that it sounds -- by "much more" I mean a ridiculous amount of code. Loading from file is easy, but to me that feels hacky, and wouldn't last more than a few versions. Careful using the term "accumulation buffer", as that's a 2d buffer in opengl (similar to the depth buffer, but for a different purpose). QC's default gl context does not have an accumulation buffer, and it doesn't seem easily possible to create one after initialization. You weren't talking about this buffer though, so that's not a problem.

grid: why not make it a macro patch, so it'll operate on whatever you put inside? Caveat: the transform feedback stuff enforces a limit on the number of vertices. It may be really huge, and thus not a problem, but if not it may do the wrong thing unexpectedly.

dynamic port creation: trivial. wiimote control does this, as do many other patches. Adding ports based off of the input GLSL shouldn't be a problem either, opengl allows you to inspect glsl programs quite easily.

toneburst's picture
:)

Cool!

Re. Text Editor: I didn't think the text editor thing would be a goer, actually (unless there are some prebuilt libraries that you can drop in to handle that kind of thing). That's not so much of a problem from my point of view, anyway. I'd probably test the shader first using a standard GLSL Shader patch. The text editor of the current GLSL Patch isn't the best, anyway. I often find myself writing shaders in TextWrangler, so I can use find-and-replace tools, then pasting them in to QC, or copy-pasting between the two apps.

How do you envisage getting the shader program to run? I mean in terms of the GUI to specify the shader code? Maybe the shader program could be piped in from a JavaScript patch as a big string, which would open up possibilities for changing the code on-the-fly, or swapping between different shaders, at least...

Re. Accumulation Buffer: I'm aware there's an Accumulation buffer in the OpenGL fixed functionality pipeline. I should have been more precise in my language though ;) Actually, is this not used by the CoreImage Accumulator patch (or the Render In Image patch, with the feedback option enabled)?

Re. grid: If it can be made a Macro, then that would be cool, and would open the way to sticking proper 3D models in there, with a 3D mesh import patch. Just thought it might initially be easier to have a hard-coded mesh.

Re. dynamic port creation Glad this is easy :)

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
thoughts

There's not much in the way of pre-built text editor libraries. It's actually not too difficult, except for fast syntax highlighting, now that I think about it. I had a simple one for the (unfinished) python demo, and a better one for the (even less discussed) javavm patch. Going over the top with a fancy editor is definitely overkill though; that's what separate apps are for :)

I'm personally all in favor of abstracting shaders (even separating vertex and fragment shaders, and perhaps geometry shaders(?) once I'm able to afford a mac with a real video card) so that you can combine them in various ways on the fly -- writing one FixedFunction replacement fragment shader, and then being able to use that in combination with lots of different vertex shaders would be way handy, imo. I like the idea of creating shaders from arbitrary strings too... I'm not sure how expensive compiling shader programs is, but making them on the fly would be cool. Error handling would be a pain -- still thinking about how to do this. Also: I'm not sure how to properly handle inputs when the shaders change. For example, let's say you have a shader with 1 float input, and then you switch to a shader with 5 vec4 inputs. The patches in QC could change to reflect this change, but there's no (official) way to make connections within a composition without the editor. For parametric inputs like that, I think a structure would be a fair abstraction (I wish structure tools were more developed to make this simpler). Thoughts on this?

Render In Image uses a separate context's color buffer, no accumulation. I believe the Core Image accumulator just uses textures, not the accumulation buffer (the accum buffer in opengl is single-channel as far as I remember.. I've not worked with it since it's not in QC and I don't feel like writing GLUT code to tinker with it).

macros are trivial; I'll plan on that, since that's the way to go.

[edit: my comments keep getting longer and longer... I should write a book ;) ]

toneburst's picture
Ponderings on Thoughts

Re. Text Editing: The code-colouring in the existing GLSL patch isn't that great, anyway. Maybe they'll improve it in a later version.

Re. Abstraction: The ability to separate Vertex and Fragment shaders I agree, would be very cool. You'd have to be careful about varyings though, I think. You'd need to ensure that Vertex and Fragment shaders had matching varying variables, or just used the builtin GLSL varyings (gl_FrontColor, gl_Normal, gl_Vertex etc.).

Re. Changing Ports: I know what you mean about the problems of changing port configurations with different shaders. This had occurred to me also. You could have a standard number of ports created by the patch, and hook these up to different things internally, maybe with some special code in the shader. VVVV and Jitter already do this kind of thing. You loose flexibility and readability this way though, and potentially end up with a very loooooonnnnnnng patch in the QC GUI.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
varyings

Good point on pairing the varyings.. I had completely skipped over this, but it would be a major problem.

It's possible to inspect each shader object (fragment or vertex, independently) to make sure they match before doing anything. Perhaps an error output to help the developer know when there's a mistake? It can be handled gracefully, so I don't think exploding or denying flexibility would be a good idea overall. Sticking with the built-in ones is too boring, in my opinion :)

Standard number of ports is another tricky problem: when you have a float input, GLSL actually makes it a vec4 behind the scenes. modern cards have a limit of something like 16 vec4 inputs, but they can be configured in a bunch of different ways (64 floats, 16 vec4's, 32 vec2's, matN's, etc.). There doesn't appear to be a "Right Way" to expose this in QC's port model. The only feasible way I've seen to pass around arbitrary data in varying configurations is with a structure. :/ This puts the consistency burden on the QC developer, and isn't very intuitive either :( yanomano briefly discussed making a graph modifier patch some time ago (create patches, delete patches, connect ports, etc) -- perhaps its time has come? :) (only half serious - that causes a number of additional problems to deal with...)

toneburst's picture
Varyings

Ah... hope this isn't insurmountable... I agree, it would be really nice to be able to pass arbitrary data between VS and FS programs. This would give you the flexibility to implement fancy lighting effects etc.

I guess it shouldn't be too tricky to check for matching varyings, and flag-up and errors before execution of the code.

Are you thinking you could pass in a struct containing the shader code itself, and any I/O ports it needs?

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
should be ok

it's not insurmountable, as long as you remember to watch out for it. Not any different from trying to run JavaScript with syntax errors, really.

I'm thinking there'll be a few patches: One that takes a string for input, with a dropdown for Vertex/Fragment shader, and outputs a "Shader" object -- we could even make distinct vertex/fragment shader ports, to make it less ambiguous. Error output for parse errors.

Then, there'll be a "Shader Program Linker" which will take a fragment and vertex shader object for input, and output a Shader Program (combined fragment and vertex shaders) that you can feed into a Super-GLSL Shader macro patch or something. This will have an error output also, for link errors (mismatched varyings, etc).

the super-glsl shader macro patch will have a Shader Program input (obviously ;), and an arguments structure input, which will have name/value pairs to feed to the shader program. If the structure omits an input, the patch will just set the input to 0. if the structure defines values that the shader program doesn't look for, they'll get safely ignored. I'm still unsure of how to handle texture inputs in this model -- they can go in structures just like everything else, so maybe it's fine as is?

Eventually, we'll add a Multi-Pass GLSL Shader patch, that takes a set of GLSL shader programs, and runs its internal patches with each of these activated in sequence. I'm not sure of the specifics with this (i.e. how to use the color buffer, which is normally a destination, as a source, since I think some multi-pass algorithms do this?), but it should grant the functionality that you're looking for, more or less.

Make sense? Am I omitting anything obvious? Feel like commissioning this project? ;)

toneburst's picture
Aha!

OK, this all sounds good.

How does my idea of Iteratable shader objects fit in to this though? Would it be possible to feed this Super-GLSL patch a structure containing multiple shader/control input blocks, and have it create multiple shaded objects?

This is the way shaders work in VVVV- you feed them a 'Spread' of say, 10 values, and it runs the shader code 10 times, with these values as inputs.

Alternatively, I could live without this ability, and stick the patch inside an Iterator, as long as all iterations end up in the same 3D space (ie each shader's output ends up in a common buffer).

I'd definitely be interested in a plugin giving this functionality. Not to say that the other options you outlined don't also sound exciting.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
Commissioning

I'd really love to see this project see the light of day, so... if commissioning it would help that happen, I'll definitely consider it. No idea how that might work though...

I just think it would open up so many cool possibilities...

Have you had a chance to think about the above post? As I say, I'm really looking initially for a subset of the possibilities you outlined, but if all the other stuff comes as part of the package, that's fine by me.

EDIT:

If you can get Vertex Displacement Mapping (ie Sampler2D input to the Vertex Shader) working at the same time, I'm DEFINITELY interested!

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
In terms of commissioning,

In terms of commissioning, I'm not a company, just an enthusiastic amateur, so I'm sadly not in a position to push loads of dollars in your direction. Particularly as I've just got around to replacing my ageing G5 with a shiny new MacPro, so feeling a bit tender in the bank account at the moment....

On the other hand... I'd really like to see functionality I talked about above in QC. I think it would be very cool. And you're doing great work here, generally.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
Writing a Book

Just paste them all together- voila, a book!

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
EXT_transform_feedback

According to http://developer.apple.com/graphicsimaging/opengl/capabilities/ looks like this extension is only supported on GeForce 8600 GPUs- which limits its usefulness somewhat, sadly. Having said that, the list is a little out of date, so it may be supported on newer hardware, like the GeForce 8800 on the MacPro I've just ordered (yippee..!). Won't work on MacBook Pro's though...

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

cwright's picture
I'm pretty much the most annoying nerd ever

Spotlight -> "OpenGL Driver Monitor" Click "Monitors" on the menu bar, "Renderer Info", expand your video card (not Apple Software Renderer), expand OpenGL Extensions.

Even the unspeakably lame Intel GMA950 has this extension, I'd be impressed (in a bad way) if every other card didn't support this extension by now.

I've found Apple tech docs to be wildly inaccurate when they start to enumerate features of various pieces of hardware. shrugs

[EDIT: smokris' ATI X1600 (X1000?) also has this extension; though his macbook pro is a few months newer than my macbook]

PreviewAttachmentSize
EXT_transform_feedback.jpg
EXT_transform_feedback.jpg145.51 KB

toneburst's picture
I stand corrected

my 1st-gen MacBook Pro's X1600 has it also. This is Good News. Sooooo.......

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
Geometry Shader

Have you looked intro Geometry shaders, by any chance? There doesn't seem to be much info around about them, but what I have read seems interesting. Not sure they have any relevance to this issue, but sounds like they have potential for interesting stuff.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

psonice's picture
Geometry shader patch?

I'm very much interested in geometry shaders too, I get the impression that there's a lot you can do with them that would be really useful. My card supports it too, despite the apple opengl info saying it doesn't! (radeon 2600)

For it to be really useful in QC though, we need a third 'geometry shader' tab in the GLSL patch window. I guess that's one best left to apple.

cwright's picture
listing...

should be indicated under GL_EXT_geometry_shader4

it's listed for Apple's software renderer, but not my video card. Not sure for other video cards. probably driver-related.

they look good for generating lots of geometry; very different from vertex and fragment shaders.

You're right, I'm not going to touch this one :)

franz's picture
geom / vertex shader

can't you generate geometry from the vertex shader directly ?

cwright's picture
not quite

Geometry shaders can emit multiple primitives for each input (you feed it one triangle, it can generate more than 1 triangle, etc). A vertex shader, in contrast, only outputs one vertex per vertex, no more, no less.

toneburst's picture
Did you

get my email, incidentally?

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

psonice's picture
Not listed, definitely supported

The apple open gl docs say it's only supported for geforce 8600 and software renderers. OpenGL driver monitor says my card supports the extension though, so I'd guess all GF8xxx cards and all radeon 2xxx cards support it. I think older cards only support SM3.0, and won't do it, but I may be wrong there.

cwright's picture
pioneer

NVIDIA pioneered the extension (the docs are all written by nvidia engineers), so at the time the apple doc was written, that was probably true.

Again, don't even bother reading apple docs when it comes to hardware specs; use the driver monitor. They don't spend much time (if any) updating stale docs like that.

One that they Do seem to keep updated is the capabilities matrix: http://developer.apple.com/graphicsimaging/opengl/capabilities/ -- I use this often.

[edit: maybe you're looking at the confusingly similar GL_EXT_gpu_shader4 extension? This one's only on the software renderer and the 8600...]

psonice's picture
Ah, you're right

Yes, I was looking at that document, and mixing gpu shader 4 and geometry shader 4. There are others that are definitely supported but not listed though, like arb_fragment_program_shadow, so I still wouldn't trust that document too far :)

cwright's picture
oh, interesting

Good to know that that's not accurate either... sucks. I went down the list and compared a few other cards, and noticed some other weird omissions that don't make much sense (comparing the gma950 to the gma 1300, for example). So I think you're right, this one's not trustworthy either. :(

I usually use it for shader instruction limits and texture size limits, where it seems to be accurate from the limited testing I've done. But extensions.. I guess not.

toneburst's picture
Hi yanomano. Funnily enough,

Hi yanomano.

Funnily enough, I linked to that exact page on Desaxismundi's blog in an earlier post to this thread. Spooky..... :)

The code I've been using already calculates the BiTangent and Tangent vectors. It's just that I'm having problems getting a usable result from those numbers. It's not impossible that they're not being calculated properly, of course, or that somewhere in the HLSL>GLSL conversion process, something has gone AWOL.....

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

yanomano's picture
Supeformula's way ...

With the introduction of the superformula 2D/3D in QC you have open a Big vertex in the exploration land. So now there are crossroads in our ways...:)

yanomano.

toneburst's picture
Props

The credit should go to the geniuses who wrote the original code though. So, BIG props to gregsn, sanch and tonfilm for their amazing HLSL work! Also of course to Johan Gielis for the Superformula itself, in all it's amazing beauty...

As you can see, I'm a very long way from understanding how it all actually works.

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
Any progress on the vertex

Any progress on the vertex accumulator thing? :)

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net

toneburst's picture
Hmm...

This one seems to have dropped off the bottom of the list. :( Shame, because it would be really cool....

alx

Quartz Composer Blog: http://machinesdontcare.wordpress.com

Music Site: http://www.toneburst.net