[02:06:17] <servus> Hi Coren.
[02:06:38] <servus> Do you have any idea how hard it is to find a lick of information on pixel shaders in OpenGL?
[02:13:40] <Coren_> It's actually fairly easy if you can read powerpoint presentations. Go fiddle on nVidia's developer site. They have lots of goodies, lots of it non nVidia-specific.
[02:15:05] <Coren_> I actually do a very nice pixel diffuse lighting right now with nothing more arcane than the dot3 combiner, and a single texture unit.
[02:15:20] <Coren_> And a 3d texture. :-)
[02:17:58] <Coren_> 'need two texture units to do colored lighting though.
[02:20:26] <servus> Are they vertex programs, even when they're pixel shaders?
[02:20:44] <servus> I can't seem to find anything but !!ARBvp1.x and !!vp1.x
[02:20:51] <Coren_> No vertex nor fragment program needed. :-)
[02:20:59] <servus> http://126.96.36.199/images/misc/ShadowMap11.jpg here's my new lighting engine
[02:21:28] <servus> For the rendering engine proper, I need to add 1) bumpmapping and 2) water reflections with a modified Fresnel term
[02:21:29] <Coren_> Looking good. Like the particle flame.
[02:21:36] <servus> Thanks, that was the easiest part:)
[02:22:00] <servus> I solved all the volume problems with some clever rewritings that eliminated the nede for hacks;)
[02:22:53] <servus> I also need to start [from scratch] a bones and IK engine... Urgha,
[02:22:59] <servus> How is yours going?
[02:25:24] <Coren_> http://tab.ctrl-alt-del.ca/~marc/foo.png
[02:25:49] <Coren_> To see my pixel shading. No textures yet, and ingnore the debugging black lines. :_)
[02:26:45] <servus> Pixel shading?
[02:26:46] <Coren_> But I'm very very proud of the code. *one* texture application, no GL lights, no vertex or fragment program.
[02:27:09] <servus> I plan on doing every single light in my scene with GL_LIGHT0...
[02:27:11] <Coren_> No normal maps are applied. It's debugging output. :-)
[02:27:27] <servus> Out of curiousity, can I see your pixel shader code?
[02:28:05] <servus> I have so much fun stuff to program for water!
[02:28:11] <Coren_> Doesn't build right now; I'm in the process of adding normal maps.
[02:28:23] <servus> I don't care if it builds, I just want to see something...:)
[02:28:56] <Coren_> Heh. Not going to be useful for you, methinks, because I cheat heavily. But lemme put it up and see if you can understand what I'm doing. :-)
[02:29:11] <servus> (Specifically, is the header for a pixel shader !!vp1.x, and does the code look like vertex shader code, or am I completely confused?)
[02:29:55] <Coren_> Oh, no... that's input for the nVidia shader preprocessor-- it is used to *build* the vertex program semiautomatically.
[02:30:17] <Coren_> If you want to know how to do fragment programs, you need to go read the actual extension spec.
[02:30:20] <servus> Oh, yes, I plan on doing it with the glGenProgramsARB function for now
[02:30:49] <Coren_> Be careful, though, only the very latest cards really do fragment programs.
[02:31:04] <servus> (Mine doesn't, so... they are out of the picture:)
[02:31:07] <Coren_> Which is why I spend so much time finding a way of doing proper diffuse without them.
[02:31:31] <Coren_> The screenshot you saw, every wall is /one/ polygon.
[02:31:40] <servus> I'm rather sure my card supports ps1.3 but I haven't found a single piece of sample ps code
[02:31:47] <servus> Ditto for my screenshot.
[02:32:22] <Coren_> Sample code is mostly impossible to find; people who do fragment programs tend to kepp 'em to themselves. It's still deep magic.
[02:33:39] <servus> I just need a quick runthrough...
[02:34:03] <Coren_> http://tab.ctrl-alt-del.ca/~marc/try.cc Look starting in the middle part of main for the texture setup and the ::render below for using it
[02:34:04] <servus> The way it stands, I'm going to puzzle it out with a little interpreter program I'll have to throw together...
[02:35:09] <Coren_> In ::render the glTranslated() is to set the light position, the scaled() is the light intensity. They are hardcoded in this snippet, but you should figure it out
[02:35:49] <servus> Though... I see no pixel shader code?:)
[02:35:54] <servus> I'll figure it out..
[02:37:01] <Coren_> You haven't been paying attention. :-) I was telling you exactly that: I managed to do (approximated) pixel diffuse lighting /without/ actual fragment programs so it works on older cards. :-)
[02:38:02] <servus> I have, honest! It is admirable indeed. I simply find myself wrapped up a bit in this Internet miasma I've been trying to get information from... *muck*muck*mucks around*
[02:38:40] <servus> It looks like a neat fallback pixel-shader-like hack, and though it's not what I'm looking for, I find it interesting. :)
[02:39:35] <Coren_> Well, if anyone else figured out that hack, they haven't been talking about it on the 'net. :-)
[02:40:32] <Coren_> And, with the proper texture matrix, you can do bump mapping with a second texture unit. :-)
[02:40:42] <servus> Isn't it like lightmapping?
[02:40:56] <servus> Software lightmapping, that is?
[02:41:26] <Coren_> Heh. The think you don't see is that the 3d texture has only *one* instance regardless of the number of lights or lit surfaces. :-)
[02:42:09] <Coren_> And because of what's /in/ the texture map, you won't be seeing any big light tiles either. :-)
[02:43:31] <servus> Ah okay I see, you created a new frame buffer.
[02:43:31] <Coren_> Hint: The texture map contains perpendicular vectors from the center of the map that are /not/ normal. When you dot3 them with the actual plane normal where the lit surface is, you end up with an illumination factor that does both distance and angle of incidence. :-)
[02:44:00] <servus> A sort of voxel fog which represents the light.
[02:44:01] <Coren_> "new frame buffer"?
[02:44:22] <Coren_> Yes, that's a good approximation, only the voxel "colors" are in fact vectors.
[02:44:28] <servus> A frame buffer, yes, which has the components RGB and Z?
[02:45:59] <Coren_> Aaah. Okay, I get you. Yes, except RGB are in fact XYZ of the vector.
[02:47:59] <servus> I know precisely how I'm going to do my water, I just need to know how to format the assembly! :)
[02:48:27] <Coren_> Goodie.
[02:48:31] <servus> First there's a simplistic form of the fresnel term, which only uses a dot product, which will correlate directly with pixel alpha, for a totally realistic Fresnel term with just 3 muls (!!!)
[02:49:05] <servus> Hmm, actually, 9 muls, but that's good and I may be able to improve!
[02:50:41] <Coren_> Yep; that's good. But careful around the edge of the water volume where you'll get degenerate vectors.
[02:50:47] <Coren_> Quake 1 had this problem.
[02:51:03] <servus> Let's see, the alpha for the pixel would be (lPos-pPos)*(pNorm*2*Dot( -(cPos-pPos), pNorm ) + (cPos-pPos))
[02:51:43] <servus> I don't sample pixels for this pass, so that won't be a problem.
[02:52:04] <servus> (That's a lot more muls than I thought, but no sqrts or cos or sin!)
[03:02:02] <servus> Hmm, vertex shader programs entirely handling bones?
[03:09:41] <Coren_> I heard it's possible.
[03:09:47] <servus> I have a demo of it here.
[03:09:53] <servus> I'll have to grok it later.
[03:10:08] <Coren_> And it'd make sense when you think about it-- vertex programs can transform recursively; exactly what you'd want.
[03:10:13] <Coren_> No IK this way, though.
[03:11:28] <servus> IK doesn't affect vertices, only bones.
[03:12:35] <Coren_> Hm. What card do you have?
[03:13:22] <Coren_> If you want to do ragdoll bodies you have to deduce the bones /from/ the vertices, don't you?
[03:14:31] <servus> No... Bones are parents and that is that. :)
[03:14:42] <servus> All the collision testing is done with the bones (They have an envelope)
[03:14:51] <Coren_> With normal maps, colored light need three texture units. So my code is going to do white lights when there is just one, colored lights at two, and colored+normal maps when more than two.
[03:15:31] <Coren_> My card has three.
[03:16:32] <Coren_> Err, four. Where did that three come from?
[03:18:02] <servus> My cat's breath smells like cat food.
[03:19:19] <Coren_> That doesn't sound entierly unreasonable. Unless you don't feed him cat food, in which case it's rather odd. :-)
[03:21:08] <servus> I think you're thinking too hard:)
[03:23:37] * servus groans... I'll do bumpmapping via software for now :(
[03:23:58] <servus> Same with fresnel terms... Yuck! I need documentation on pixel shaders!
[03:24:07] <Coren_> I'll prolly have my bumpmapping working in an hour or so with a little luck. :-)
[03:24:29] <servus> Well, I know precisely how to do it, but it'll be oh-so-slow if the CPU does it!
[03:24:39] <Coren_> I'd google "fragment program" which is the correct GL name for it.
[03:30:52] <servus> Ah, a neato PDF
[04:02:32] <servus> This is most disturbing... it'd appear that fragments don't have normals...
[04:04:19] <Coren_> That's normal (heh). Normally, you get the fragment's normal from some texture unit-- either as a (transformed) normal map or generated from the vertex info.
[04:05:26] <servus> I want polygonal normal information... I don't see a way to infer it through the surrounding vertices in the pixel shader specification, but I'll keep looking
[04:06:12] <servus> I can't use a normal map because this is based on polygonal information (for the Fresnel term, you see...)
[04:06:29] <servus> I could temporarily assume that all water has a normal of (0,0,1), but that is wickedly stupid. :)
[04:07:34] <Coren_> Actually, that sounds like a reasonable presumption to me if you have gravity. :-)
[04:07:34] <servus> The sample program in the ARB specification shows the polygonal normal passed in via a texel unit, and that is... gross! There must be a better way.
[04:07:50] <servus> Coren_: Who says that all water-like objects are water? [glass]. Also, water can flow.
[04:08:45] <Coren_> And no, the texture units /are/ by design the way you feed the fragment programs. It's not gross. :-)
[04:08:47] <servus> Can I call vertex program procedures in a fragment program, I wonder..?
[04:09:00] <servus> All I want is fragment.normal :)
[04:09:35] <Coren_> If your normal is going to stay constant (flat surface) then you can pass it as the primary color; or as constant color.
[04:10:40] <servus> Hmm...
[04:11:11] <Coren_> Which is, incidentally, what I do in my own hack; the plane normal is given as the primary color.
[04:11:26] <servus> If I were to create a normal map for, say, water, it'd be pletty boring, with a few ripples... I'd need a way to transform this normal map into world coordinates since it is in face-coordinates, but since I have access to the matrices in the fragment program, that should prove possible...
[04:11:29] <Coren_> So it's avaliable to the dot3 operator at every texel.
[04:12:06] <servus> Still, this does not allow for discrete changes in polygonal structure.
[04:12:31] <Coren_> You realize, of course, that your engine's hardware requirements are getting increasingly stringent?
[04:12:33] <servus> ...does it?
[04:12:46] <servus> Coren_: I'm not targetting voodoo2s.:)
[04:12:57] <servus> I'm targetting John Carmack. *Evil grin*
[04:13:15] <servus> I know how he did every feature of the Doom3 engine that I've heard about.
[04:13:23] <Coren_> Then forget fragment programs, buddy. You need an ATI or nVidia < 1.5 year old for that.
[04:13:33] <servus> I have that.
[04:13:47] <servus> I have an nv28.
[04:13:54] <Coren_> Oh, I misread you. You said *not* targetting voodoo2s. :-)
[04:13:58] * servus grins
[04:14:08] <Coren_> GeForce FX 5200/AGP/SSE2
[04:14:14] <Coren_> Which isn't shabby either.
[04:14:14] <servus> Poor you!
[04:14:28] <Coren_> Hey, it's enough to play Arx Fatalis. :-)
[04:14:30] <servus> How do you like it? I've heard nothing good about it
[04:14:51] <Coren_> Heh. It's damn fine, actually.
[04:15:14] <Coren_> It's got "only" a decent fill rate, but it does geometry mighty fine.
[04:16:33] <servus> Toms Hardware must be unduly mean towards it, then.
[04:16:41] <Coren_> I tend to take 3D card "reviews" with a grain of salt. When they aren't completely biased, they take only superficial details into account and tend to thikn poorly of cards that do "only" 350fps vs 370fps in random-game-of-the-moment.
[04:17:02] <servus> All the benchmarks I saw placed it below a GF2 =-O
[04:17:17] <Coren_> That's ridiculous!
[04:18:23] <Coren_> The only "bad" thing about the FX 5200 that I found is that, because of it's lower (compared to the current top-of-the-line) fill rate it is less forgiving to badly written renderes.
[04:18:54] <Coren_> If your renderer does little or no overpainting, then it screams like a banshee. :-)
[04:19:53] <Coren_> And it does vertex and fragment programs, which is nice for the latest games.
[04:21:02] <Coren_> Price/quality it was the best deal as of 3 months ago. I'm lucky enough to have a buddy at the local hardware place which lets me run arbitrary code on random hardware when I feel like an upgrade. :-)
[04:22:45] <Coren_> Ack. *please* don't tell me all the texture units share the same texture matrix!
[04:23:05] <Coren_> Ah, no. Bug in my program.
[04:23:09] <Coren_> *phew*
[04:27:35] <servus> My fragment program is done!
[04:27:53] <servus> I refuse to run it though, because I don't want to see it not work. :)
[04:30:48] <Coren_> LOL
[04:31:13] <Coren_> Well, then, just presume it works and stop working on it. :-)
[04:31:32] <servus> Yay! I have hypothetically saved the universe with my unproven fragment shader!
[04:31:50] <Coren_> Reminds me of a quote of Knuth for the Dragon Book. "Beware; this code may contain bugs-- I have only proven it correct not tested it."
[04:33:12] <servus> The marketing department heard that quote >.<
[04:33:34] <servus> It builds! Ship it!
[04:52:59] <-- servus has left IRC ()
[05:25:04] --> servus has joined #low
[07:07:26] <Coren_> Woot! Bumpmapping!
[07:07:55] <Coren_> http://tab.ctrl-alt-del.ca/~marc/foo.png
[07:08:49] <Coren_> Still without needing fragment programs. :-)
[07:11:57] <Coren_> And it's blindingly fast to boot. :-)
[09:56:53] <servus> My card doesn't support fragment shaders
[09:57:02] <servus> I'm sure it works though, *grin*
[09:57:37] <servus> How are you doing it in your method?
[12:20:05] <Coren_> Still with a single dot3. Only now I'm using a normal map instead of a constant normal for teh plane.
[12:21:10] <Coren_> My card does fragment programs, if you want me to test your code.
[13:21:41] <Coren_> Not too bad, really. One pass per light, only on surfaces actually lit.
[23:52:34] <Coren_> BBL
[23:54:16] <-- Coren_ has left #low ()