#low@irc.freenode.net logs for 24 Aug 2005 (GMT)

Archive Today Yesterday Tomorrow
LoW homepage

[01:09:08] <servus> Coren_: What are you having problems with now?
[01:09:35] <servus> I ended up using the 3D "starburst" texture that I use for diffusing lighting, for my eye-to-fragment vector. That is why I'm an idiot - I was already doing the tangent space calculation! :)
[01:10:02] <Coren_> Heh. *that* texture. :-) Nice idea I had huh?
[01:10:27] <Coren_> But pointless now. I found the "right" way to do it with the vertex program. Very snappy and fast.
[01:10:30] <servus> Oh sure give yourself credit for MY working implementation *grin*
[01:10:47] <servus> Uhh, I've always done it with the vertex program ; o)
[01:11:15] <Coren_> Erm, I had a working implementation long before, you know. When we discussed it my implementation was working very fine thank you. :-)
[01:11:21] <servus> I use the vertex program to reorientate the 3D texture to match the S,T,R vectors for the current vertex.
[01:11:33] <Coren_> Funny, I do the opposite.
[01:11:34] <servus> What sections are you missing now?
[01:11:50] <servus> Yeah but you weren't using any vertex programs at all,r ight?
[01:11:57] <Coren_> None. I'm in the process of reworking the fragment program to use the new data coming off the vertex pipeline.
[01:12:09] <servus> I do believe that I am gaining close to full accuracy with my veretex programs.
[01:12:23] <Coren_> I was hoping to use the light coordinates to pass light info. Bad idea. Lost hours trying to figure out why things were all *@&# up.
[01:12:33] <servus> No, use the textuer coordinate :)
[01:12:44] <servus> All colours are clamped to [0,1].
[01:12:54] <Coren_> Yeah, so I found out
[01:12:55] <servus> Texture coordinates are the only unclamped interpolated values, AFAIK.
[01:13:05] <Coren_> I'm using the ProgramEnvParameters actually.
[01:13:07] <servus> Could've asked; I went through the same thing on my water transforms :)
[01:13:51] <servus> I'm using ProgramLocalParameter. I don't know the difference really between env and local
[01:14:07] <Coren_> Local values are kept between invocation of the fragment program.
[01:14:18] <servus> "kept"?
[01:14:23] <Coren_> pRESERVED.
[01:14:37] <servus> But the same fragment is never going to be drawn twice.
[01:14:39] <Coren_> Env are global to all programs.
[01:14:46] <servus> Oh, I see what you mean
[01:14:51] <servus> If you rebind another program
[01:14:53] <Coren_> Right.
[01:15:05] <Coren_> If you use the same program all the time, they are equivalent.
[01:15:07] <servus> Sounds to me like the performance difference is negligible, then.
[01:15:12] <Coren_> Should be.
[01:15:16] <servus> I use multiple frag and multiple vert program
[01:15:37] <Coren_> Well, the choice between env and local should be strictly a matter of convinience then.
[01:15:45] <servus> Ja
[01:15:58] <servus> So, did you put your ARB programs into text files that can be reloaded on the fly, yet?
[01:16:02] <servus> Makes debugging a breeze :)
[01:16:13] <servus> That 10ms recompilation time, *grin*
[01:16:28] <Coren_> It would, but I was too busy trying to figure out vertex programs. :-)
[01:16:45] <Coren_> Once I got 'em working I'll do that so that tweaking gets easier. :-)
[01:17:05] <servus> Well, I meant it's useful for massive "OMG it's BROKEN!" sort of situations, heh heh.
[01:17:29] <servus> I do all of my debugging graphically (like in the blue/red for water that you saw...) I even use Adobe Photoshop as my primary hex editor :)
[01:17:37] <Coren_> Heh.
[01:18:03] <Coren_> I found a good way to retain the accuracy I had with my fragment program while lightening its load considerably.
[01:18:08] <servus> Specular program just about worked on the first try though, and I wrote it all out beforehand; I'm happy about that :)
[01:18:23] <servus> I don't believe I'm suffering any accuracy at all from using vertex programs.
[01:18:50] <Coren_> I pass tangent-space coordinates of eye and light through texture coords; all I need to get direction vectors that are perfectly accurate is normalize them in the fragment program.
[01:19:07] <servus> How do you do specular lighting?
[01:19:11] <Coren_> I tried passing direction vectors, originally, but the interpolation makes a mess of 'em.
[01:19:16] <servus> I came up with my method entirely off the top of my head, and i think I did it funny :)
[01:19:48] <Coren_> I calculate the half vector in the fragment program; it's five instructions but it handles the normal map perfectly.
[01:20:14] <servus> What exactly do you mean by half vector? The incident to reflection?
[01:20:51] <servus> I meant, not "how" in the program, but how, algebraicly? Do you reflect the Incident vector against the normal and dot against the eye-to-fragment vector, as I do?
[01:21:12] <Coren_> The half vector is the difference between the normal and the light vector. Substract it twice (hence "half" vector) from the light vector and you get your reflection vector
[01:21:29] <Coren_> dot that with the eye vector and exponentiate. Voila!
[01:21:35] <servus> Hmm
[01:21:53] <servus> So you do standard reflection, but do part of it in the vertex program?
[01:22:12] <servus> By specular reflection code is 5 ops.
[01:22:42] <servus> s/By/My/
[01:22:55] <Coren_> Just the transformation to tangent space. I could calculate the half vector in the vertex program but then the normal map would be ignored (would only look right on smooth surface)
[01:23:04] <servus> OK so we are par then
[01:23:06] <Coren_> ... though admitedly most shiny surfaces are flat.
[01:23:26] <servus> I do transformation to tangent space for the light-to-fragment vector in vertex program
[01:23:38] <Coren_> But that would remove my purdy twisted-golden-braid-in-carpet effect. :-)
[01:23:55] <Coren_> I also do the eye-to-fragment transfor in the vertex program.
[01:24:09] <servus> Why?
[01:24:14] <servus> I keep my eye-to-fragment in world space.
[01:24:37] <Coren_> But your reflection angle will be in tangent space!
[01:24:57] <servus> Will it?
[01:25:17] <Coren_> Well, since it's derived from your normal and light vector, both of which are. :-)
[01:25:33] <servus> Meh
[01:25:39] * servus goes to investigate.
[01:26:31] <servus> Gosh those chips were good.
[01:26:35] <servus> MY MOUTH IS ON FIRE!
[01:26:39] <Coren_> lol
[01:26:44] <Coren_> Yep. Good chips. :-)
[01:27:20] <Coren_> Spicy stuff isn't good if you can feel your teeth fusing together. :-)
[01:27:30] <Coren_> s/can/can't/
[01:30:33] <servus> It was the salt, not the jalapeno, that did it... Laura Scudder's Stuffed Jalapeno potato chips.
[01:30:42] <servus> Golly!
[01:30:57] <servus> OK, so... Are we ready to port Ultima VII to our new engines?
[01:31:10] <servus> Oh gosh, you've been away so long, maybe you didn't see Exult 3D! *grin*
[01:31:32] <Coren_> I have. I didn't. :-)
[01:31:48] <servus> Didn't what? See it?
[01:31:53] <Coren_> Right.
[01:32:31] <servus> http://sammatthews.com/images/Exult3D/Exult3D-33.jpg http://sammatthews.com/images/Exult3D/Exult3D-37.jpg yada yada yada.
[01:32:59] <servus> OK, now to see if my tangents have gone off on a wild tangent :)
[01:33:28] <Coren_> Huhuh. Fun-ny. :-)
[01:33:57] <servus> I'm still looking for help to wrap up Exult3D.
[01:34:14] <Coren_> Oh, sure, I got sooooo much free time!
[01:34:19] * Coren_ smirks.
[01:35:02] <servus> With how much I work, it's amazing I did 300 models as it is, punko!
[01:35:14] <servus> http://sammatthews.com/images/Exult3D/AvatarWM.png :)
[01:35:14] <Coren_> Meh. I wish GL gave better error reporting than just a position. :-)
[01:35:34] <servus> What do you mean, 'error'?
[01:35:37] <servus> Compilation errors?
[01:35:57] <Coren_> In fragment programs. It's usually obvious typos, but not always. :-)
[01:36:03] <servus> My ARB compiler gives very explicit errors, like "matrix modifier not allowed on state.matrix.neo in line 15 column 30"
[01:36:32] <Coren_> Oddness. Mine gives me "byte 273"
[01:36:39] <servus> You poor thing! :)
[01:37:06] <servus> Want my compiler? Dunno where I snagged it from... One sec
[01:38:31] <Coren_> Meh. I'll cope. I'm not a fan; once I get my programs working right I'm probably not going to mess with them again.
[01:39:56] <servus> Fan of what? Here is the compiler I use: http://rafb.net/paste/results/DfvGHD61.html
[01:40:25] <servus> Wrote most of it myself, to fit the quirks of my program, of course, but yours should be a one-line fix to get an error string
[01:40:26] <Coren_> Of fragment and vertex programs. :-)
[01:40:43] <servus> They are fun when you have 1. descriptive errors and 2. no recompilation time :)
[01:41:42] <servus> Hmm, you're right.
[01:41:59] <servus> Specular highlight is perfect on the floor and ground, but has a peculiar mach band running through the walls :)
[01:42:02] <servus> Ughh.
[01:43:03] <Coren_> Not too bad. Doing the tangent transform gives me ~ 5x per fragment speed increase. I'm now mostly fillrate bound.
[01:43:27] <Coren_> s/form giv/form in the vertex program giv/
[01:43:30] <servus> You are getting less than 75fps on your 3 polygon world?
[01:43:55] * Coren_ slaps servus around with a trout.
[01:44:01] <servus> Sorry! Save the trout!
[01:45:04] <servus> Are you perhaps using fragment program emulation?
[01:45:26] <servus> Back when I had my GF TI4800, which didn't support ARB fragment programs, I used the NVidia fragment program emulator... Neat!.. but slow
[01:46:03] <Coren_> Nah, although I might sometimes run into a crossoverpoint. But the FX 5900 speaks fragment programs.
[01:46:27] <servus> Bizarre, then!
[01:46:27] <Coren_> I'm really fillrate bound now; the speed is comparable to no fragment program at all.
[01:46:40] <servus> How many triangles is your toy world?
[01:46:44] <Coren_> The FX 5900 has a good GPU, but sucky memory bandwidth.
[01:47:10] <servus> Well, relatively, but it's still better than the GF4-TI's, eh?
[01:48:12] <Coren_> It's not toy, it's the britain lev0. Ballpark 500 polygons in view where I test performance, and about 200 polygons for the shadow volumes.
[01:48:32] <Coren_> But I draw once per light, so that kills my fillrate.
[01:49:03] <servus> Still.
[01:49:14] <Coren_> Just for kicks, I subdivided my polygons in 16 and the framerate barely budged down.
[01:49:24] <servus> I was doing 4 dynamic lights in my UW1 with a GF-TI4800 with light volumes.
[01:49:42] <servus> Bizarre. Doing any non-graphics stuff in the background of the program?
[01:50:03] <servus> How efficient is your PVS and frustum culling?
[01:50:09] <Coren_> Nope. And framerate is almost exactly linear with the number of pixels in the viewport.
[01:50:19] <servus> Oh, and how are you casting your shadow volumes to infinity?
[01:50:39] <servus> I came upon a neato hack for casting them to a length of infinity for a substantial, substantial cost saving in bandwidth.
[01:50:49] <Coren_> No, I'm doing bound shadow volumes with effective light radius and depth fail.
[01:50:52] <servus> Are you just extruding the polygons out an arbitrary amount?
[01:51:01] <servus> Yes but how do you extrude the silhouette?
[01:51:08] <servus> Light radius./
[01:51:10] <servus> Ah, ok.
[01:51:25] <Coren_> So I cover as few pixel as is reasonably possible. That helps.
[01:51:54] <servus> I ended up doing it to infinity, and it was faster than extruding it manually, even a minor amount. I just set my homogenous vertex coordinates for the extruded end to 0 and clipped my frustum to include things that lay at the far clip
[01:52:07] <Coren_> I'm not sweating it, I know I'm hitting the memory bandwidth of my old card. Other recent 3D engines make me suffer the same way. :-)
[01:52:09] <servus> It doesn't seem like it would help, but the speed increase was tremendous
[01:52:25] <servus> Might wanna try it :)
[01:52:52] <servus> Are you always doing a ZFail or are ZPass/ZFail mixture?
[01:53:06] <Coren_> I might; but turning off shadows give me little speed increase actually. I pay a cost to draw them, but it's almost completely offset by not drawing the stenciled out fragments.
[01:53:16] <servus> I really don't see a difference between doing it brute force and doing the calculations to decide whether or not to do ZFail :)
[01:53:34] <Coren_> I do zfail always. It's actually faster that way for me.
[01:53:44] <Coren_> The cap isn't that expensive to draw.
[01:53:51] <servus> Yeah, I support both but I was so disappointed by the results :)
[01:54:09] <servus> Seriously though, try out my homogenous coordinate trick to extrude the volume to infinity!
[01:54:38] <Coren_> I will, once I'm convinced my fragment and vertex programs are bug-free. I don't like messing with two components at once. :-)
[01:55:05] <servus> Certainly, and you, Mr. Meanie, uncovered a bug in mine (I was doing tests on bumpy normal maps... silly me)
[01:55:35] <Coren_> I'm not sure it'd be a gain for distant lights with small radii, though. I got many of those and the actual size of the projection is small. Good performance then.
[01:56:29] <Coren_> Wheras extruding them to infinity would cover a lot of stencil space if there's an intervening obstacle.
[01:56:32] <servus> My performance while extruding the volumes to infinity was significantly faster than extruding for lights with a radius of 1.
[01:56:44] <Coren_> Even for distant lights?
[01:57:26] <servus> It didn't matter. I think that Doom 3 does it that way, so the drivers have a built-in speedway for a vector with a homogenous coordinate of 0.
[01:57:45] <Coren_> Aaah. Benchmark cheats. :-)
[01:57:57] <Coren_> Carmack has a lot of weight. :-)
[01:58:30] <Coren_> OpenGL is now replete with extensions saying "Carmack insisted on x" and "Carmack suggested y". :-)
[02:00:33] <servus> I don't care. It's _fast_ and looks the same to me :)
[02:01:29] <servus> Actually, the back of my video card box says that it has "special hypershadow engine blah blah that will enhance stencilled shadows in all games!"... I wondered how they could claim support for arbitrary games, but that might be it.
[02:01:45] <servus> I'd like to have an ATI test card.
[02:02:05] <Coren_> I wouldn't. ATI are the suzz0rz.
[02:02:15] <Coren_> suxx0rz even
[02:03:09] <Coren_> They are mindless minions of Microsoft and only pay lip service to OpenGL. And their drivers are nasty.
[02:04:26] <Coren_> If someone mails me about a problem with LoW (or anything else I do) and they have an ATI card, my knee jerk reaction is usually "Sucks to be you.". :-)
[02:04:57] <servus> How mean:)
[02:05:17] <Coren_> Serves 'em right for buying ATI hardware. :-)
[02:05:43] <servus> HL2 blows on NVidia.
[02:05:52] <Coren_> I'll change my mind the day they come out with a working, compliant GL 2.0 driver. :-)
[02:06:43] <Coren_> Note I've specified both "working" and "compliant". I'm not holding my breath.
[02:06:51] <servus> Hell with GL2 drivers, I want my GL2 windows headers!
[02:06:56] <Coren_> LOL
[02:07:10] <servus> Hmm, better that way I suppose
[02:07:20] <servus> Linux is really screwed up when it comes to drivers.
[02:07:20] <Coren_> value(ATI) ~= value(Microsoft)
[02:07:40] <servus> "Oh this was compiled for someone else's video card"... That sucks. The ICD is a good idea, but horribly implemented :)
[02:08:52] <Coren_> Bah. Not true. If other manufacturers would take the time and effort to do DRI with NVidia's quality, the universe would achieve perfect harmony or something.
[02:09:17] <servus> I should really work on my tangent space transformations *mumble*
[02:10:04] <Coren_> GLX is a known quantity, honed to perfection by SGI. With a solid X on top (x.org's) and a perfect DRI below (NVidia's) you get perfect OpenGL goodness.
[02:10:44] <Coren_> Which probably explains why Hollywood now has Linux renderfarms. :-)
[02:11:32] <servus> I... can't tell if my specular highlight is correct :)
[02:11:37] <Coren_> LOL
[02:11:45] <Coren_> Do it with perfectly flat surfaces.
[02:11:56] <Coren_> You should see nice oval highlights. :-)
[02:12:21] <servus> I am
[02:12:25] <servus> They were flat before.
[02:12:31] <servus> I mean oval before
[02:12:41] <servus> The oval is right, sure, but the position seems a bit wonky.
[02:13:08] <servus> If my eye is 5 units high, and the light is 5 units high, and I'm looking directly at the light, the highlight should be precisely between us on the ground, no?
[02:13:26] <servus> But it looks like the highlight on the ground is getting too close to my eye.
[02:13:37] <Coren_> The far focal point of the oval should.
[02:14:01] <Coren_> Which means the center /is/ in fact closer to your eye than to the light.
[02:14:18] <Coren_> But not by much unless you are both very very close and the angle is near 0
[02:14:57] <servus> But... 45 degrees down to the highlight, then 45 degrees back up, in simple terms. Hmmm. Looks wrong
[02:15:20] <Coren_> Put another way, the point of the oval that is brightest should be exactly between you and the light.
[02:16:22] <servus> In fact, it seems like the highlight is always centered around the camera... ugh.
[02:47:03] * servus kicks the fragment program.
[02:51:04] <Coren_> I just checked: if you are level with the light and look directly at it, the specular hightlight starts 'bout halfway visually and extends far towards the eye.
[02:51:39] <servus> Yeah. Mine is foobar'd.
[02:51:51] <Coren_> Wanna screenshot to compare to?
[02:52:29] <servus> Nah, I know how it is supposed to look :-p
[02:55:11] <servus> I think that it should be working is the wrong part; it means my calculations are off :)
[02:59:01] <servus> I'm trying to transform my eye-to-vertex coordinates to tangent space in the same way as I'm transforming the "starburst" texture coordinates. See anything wrong with that?
[02:59:53] <servus> I always forget some stupid component...
[03:00:42] <Coren_> No, that's how I did it when I was still using the starburst texture.
[03:00:54] * Coren_ rolls on the floor, laughing.
[03:01:03] <servus> You're not using it at all?
[03:01:09] <Coren_> Okay. Do *ont* bind the program every polygon.
[03:01:16] * Coren_ just doubled his framerate.
[03:01:23] <servus> Heh.
[03:01:25] <Coren_> Nope. No need for it anymore.
[03:01:35] <servus> But... I care about speed :)
[03:01:43] <servus> I'm positive I can make it work.
[03:02:02] <servus> Time to do more matrix analysis.
[03:02:02] <Coren_> So do I. The texture lookup is actually more expensive than the normalization and multiplication.
[03:03:08] <servus> Are you doing everything in world space, then?
[03:03:35] <servus> Every vertex receives full normal, tangent, and bitangent information. I suppose I could port to a full-worldspace solution simply enough
[03:03:36] <Coren_> In the vertex program, yes. But that one then passes everything to the fragment program in tangent space.
[03:03:45] <servus> Why?
[03:04:01] <Coren_> Because dealing with the normal map in tangent space is cheaper.
[03:04:07] <servus> How do you transform your eye-to-vertex to tangent space?
[03:04:27] <servus> I don't see why my matrix multiplication is not working as I expect.
[03:04:47] <servus> Oh no...
[03:04:57] <servus> I think I've been transforming in model space
[03:05:09] <Coren_> Basically, I multiply eye-point by the tangent space matrix per vertex
[03:05:59] <servus> Before the subtraction of vertex position and eye position?
[03:06:45] <Coren_> (eye-vertex)*T -> tc[0] (light-vertex)*T -> tc[1]
[03:07:02] <servus> That's what I'm doing...
[03:07:16] <Coren_> Odd. Should work then.
[03:07:51] <servus> I'm getting a "sheared" result, which looks like the sort of thing you get when you forget to transpose a matrix... but that's not it.
[03:09:02] <servus> Can I see your actual vertex program? http://rafb.net/paste/ I don't understand my results.
[03:10:24] <Coren_> pasted
[03:11:51] <Coren_> tct and tcs are just my lame-o texture generation for positioning the stencil and normal map. Pay not heed.
[03:14:52] <servus> Hmm, I have a much more fundamental error in my world-space coordinates.
[03:15:07] <Coren_> Meh. Lots of stuff in the ATTRIB and PARAMS are not used anymore.
[03:15:10] * Coren_ cleans up.
[03:15:36] <servus> That happens.
[03:17:32] <Coren_> Line 26 and 27 are duplicated by misaimed selection.
[03:19:10] <servus> OK, world coorinates are good... on a range of [0,1]... Next step... (Did I mention that the funnest part about doing fragment programs is when you can stop? :)
[03:19:39] <Coren_> I'm about to, it's working a-ok. :-)
[03:27:58] * servus grumbles.
[03:28:07] <servus> I should just restart the programs from scratch :)
[03:30:37] <servus> Think I found the problem
[03:30:47] <servus> The domain of my normals are all over the place.
[03:30:57] <servus> [-1,1], [0,1], [0.5,1]...
[03:34:32] <Coren_> http://aleph.uberbox.org/~marc/sd3.png
[03:34:39] <Coren_> Everything is glossy though. :-)
[03:34:59] <Coren_> Nevermind the FPS, I actually get around 16 now but I have debugging output out the wazoo. :-)
[03:36:08] <Coren_> I guess Lord British had Nanna go heavy on the wax. :-)
[03:36:08] <servus> Blah.
[03:36:13] <servus> Heh, looks great :)
[03:36:20] <servus> Gotta get mine working now!
[03:38:48] <servus> Back to where I started... specular highlight centered around the camera *rolls eyes*.
[03:40:40] <Coren_> I wonder if I can accelerate the fragment program by using an extra temporary so that the destination register is never one of the sources?
[03:41:20] <servus> AFAIK, using results as source operands is illegal:)
[03:41:28] <servus> OK, I'm rewriting my entire program now *blah*
[03:41:35] <Coren_> No, I mean, for instance:
[03:41:42] <Coren_> MUL foo, foo, bar
[03:41:55] <Coren_> Processors who do register aliasing don't like that
[03:42:13] <servus> Oh. I have no idea how it handles that. Time do to some benchmarking? :)
[03:43:05] <Coren_> I need to find a way to reduce my number of multiplies.
[03:43:23] <Coren_> color*light color*distance attenuation*cos of angle
[03:43:41] <servus> Broaden your use of ops, to use things like DST and LRP?
[03:45:27] <Coren_> The &@#^ thing is simple but lots of ops
[03:45:58] <servus> Hey, mine doesn't even do diffuse at the moment :-p
[03:46:33] <Coren_> (color*light color*distance attenuation*cos of angle)+(distance attenuation*specular*specular color)+(ambient*color)+emissive Arg
[03:47:11] <servus> Still sure texture lookups are slower? :)
[03:57:50] <servus> What's the difference between a PARAM and an ATTRIB?
[03:57:52] <servus> I forgot :)
[04:44:00] * servus dashes head against wall.
[04:44:05] <servus> This should be *so* simple!
[05:41:10] <servus> There. One specular highlight, well-baked.
[05:41:19] * servus dashes his brains out against the wall again just for good measure.
[06:13:58] <servus> http://sammatthews.com/images/The%20Abyss/Abyss13.jpg The new pipeline (Yes it's supposed to have such crazy specular highlights)
[07:27:11] --> Khelz has joined #low
[08:12:00] <servus> An outsider, hide!
[08:13:07] <servus> Coren_: http://sammatthews.com/images/The%20Abyss/Abyss14.jpg You should be pleased to know that my method of doing it is entirely backwards from yours. Faster, too. HA!
[08:35:41] --> Coren__ has joined #low
[08:44:26] <-- Coren_ has left IRC (Read error: 104 (Connection reset by peer))
[08:45:43] --> _Coren has joined #low
[09:01:13] <-- Coren__ has left IRC (Read error: 110 (Connection timed out))
[09:10:42] --> Coren__ has joined #low
[09:27:22] <-- _Coren has left IRC (Read error: 110 (Connection timed out))
[10:08:23] --> _Coren has joined #low
[10:21:45] <-- Coren__ has left IRC (Read error: 101 (Network is unreachable))
[12:33:36] --> Coren__ has joined #low
[12:50:19] <-- _Coren has left IRC (Read error: 110 (Connection timed out))
[13:18:02] <-- ChanServ has left IRC (Shutting Down)
[13:23:12] --> ChanServ has joined #low
[15:35:15] <-- servus has left IRC (Read error: 110 (Connection timed out))
[15:36:29] --> servus has joined #low
[18:46:05] <-- Khelz has left IRC ()
[21:34:01] --- Coren__ is now known as coren_
[21:34:05] --- ChanServ gives channel operator status to coren_