- This topic has 5 replies, 2 voices, and was last updated 10 years, 6 months ago by
.
-
Posts
-
So, I think I’ve asked this, but I forgot the answer, and can’t find it…
Is it possible to discuss your forays into Geometry Shaders in QC? More than anything, I’m curious if you have any thoughts about extension of GLSL in QC to handle fur/grass shader stuff…. which as far as I know, is GLSL Geometry Shader territory (?).
That said, I’ve been wondering if there is some kind of way to get that going with OpenCL via a deformer… if for four verts one could average the distance between, creating a “fifth vert” so to speak, and then pushed that point out, it would basically look like a spiky hair thing. Then, if we could apply perlin noise to the final x/y/z of the implied 5th vert, it would basically be very hair/grass like.
Just thinking aloud. This is something I’ve had in the back of my mind, but it hasn’t really been 100% clear how to plow into it, so I’m throwing it out there.
Well, where to begin.
I use Geometry shaders in some QC plugins (for work), and you can only do it in a Plugin due to some specifics of how you have to init, specify number of output vertices, and specify in and out geometry primitives for the shader, and of course because the built in GLSL patch does not support it*. But its 100% doable in QC in a plugin if you are sure to reset and not leak OpenGL State (something very very important in 3rd party plugins). Another important note is that although some Geometry Shaders are supported under 10.6, most run in software fallback for vertex/geom processing (not fragment).
As far as OpenCL, I have limited experience with only because support is so all over the place and its so finicky right now. But my understanding is you can do arbitrary tessellation and output of new primitives because you have full control over the pipeline. It basically is a programmable pipeline where the concept of ‘stages’ is fully removed (OpenGL has various fixed function, and programmable stages for how it handles lighting, rasterization etc).
What you are talking about is tessellation, and its 100% doable in GLSL/GL_GEOMETRY_SHADER_4 and OpenCL, however you have to be incredibly careful in the ordering of your output primitives and the indices you output that describe the render order. OpenGL is very sensitive to these things, and getting it right makes all the difference.
Another issue for how this works in QC, esp with regard to meshes, is the order and primitive you are sending to the plugin (or the OpenCL patch). You don’t always have a lot of say in that area, which could throw some wrenches in a plan to make it globally usable (I think).
*on the topic of the built in GLSL patch – I avoid it like the plague. I’ve had too many odd issues with it, plus texture matrices / coordinates are not always what you want, when you ask for anything in a unit higher than 1. Also, In one shader, you don’t have to have a vertex program to have a fragment program, and vice versa (although you do need a vertex program if you want a geometry program). Apples GLSL patch forces some unnecessary requirements on you, coupled with oddities in their handling of image texture matrices and coordinates, makes me *always* use a custom plugin. Plus, near as I can tell, its faster.
(You know what though… I was doing some tests recently on HD material and an extrusion shader I wrote smokes the Rutt by about 2x speed or more.)
The Rutt Etra emulator is written to emulate the Rutt Etra, not just do extrusion, so it does some things for quality (especially if you pre process). A straight vertex shader extrusion will trounce it, but I bet look and feel different. Did you post it somewhere?
Well here’s the thing –
I’ve tried a few routes, all of which, on my nVidia 9400/9600 combo are non-trivially faster.
First off, I am always using a gaussian blur, for the smoothing of vertices effect, ala the way that you’ve traditionally done with Rutt. Interestingly, if I sub in v002 blurs, I get a trivial hit in performance (2~4fps), as opposed to using CI Blur with image dimensions/crop.
If I use a GL Polygon mode for my “wireframe”/”point” stuff, I’m seeing a hit of maybe 2fps. Totally negligible.
However, that doesn’t give all of the nifty scan line type options.
So, in adding in Lattice type of GLSL effects to the extrusion shader so that I can get horizontal or vertical scanlines, as well as “square” wireframe look (and other looks that aren’t available with rutt), I am still getting faster fps.
If I put the shader around the David Langford’s weighted grid generator instead of the normal GLSL grid (again, for scanline type effects)… again, way faster.
Bumping up resolution on the GLSL Grid/Shader combo to 256 produces almost no hit. On the Rutt, there is more disparity with resolution and fps.
My tests resulted in something like 12~15fps on HD material with Rutt, vs. an easy 30fps+ with GLSL.
No, I haven’t posted it anywhere, I’m working on it for a project.
- You must be logged in to reply to this topic.