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

Archive Today Yesterday Tomorrow
LoW homepage

[01:10:07] <coren_> I now declare my programs to be correct and complete.
[01:13:56] <servus> coren_: What was wrong about 'em before?
[01:14:02] <servus> Wanna compare number-of-ops?:)
[01:14:18] * coren_ chuckles
[01:14:35] <coren_> We'd first have to compare accuracy, wouldn't we? :-)
[01:14:58] <servus> Gamers don't give a crap about mild inaccuracy, only wild inaccuracy.
[01:15:27] <coren_> I don't give a crap about what gamers give a crap about, *I* give a crap about accuracy. :-)
[01:16:03] <coren_> But I don't expect my programs would satisfy a physicist anyways; they *look* good. :-)
[01:16:10] <coren_> Leseee.
[01:17:02] <coren_> Fragment: 2 tex, 23 ALU, 1 move. (For specular, ambient and diffuse with normal map)
[01:17:22] <coren_> Vertex: 9 ALU
[01:18:53] <coren_> Only significant restriction is that diffuse light color must == specular light color. Saves me two muls.
[01:19:22] <coren_> But then again, the only case I can think of where diffuse != specular would be the sun.
[01:19:45] <coren_> (because most of the blue component ends up in the ambient)
[01:21:12] * coren_ ponders
[01:21:41] <coren_> I guess you have to say that vertex has 13 ALU because I use ARB_position_invariant
[01:22:20] <coren_> How 'bout you?
[01:23:42] <coren_> But, at least, my primary requirement is met: it is not possible to detect seams between polygons from the lighting.
[01:25:43] <servus> coren_: Diffuse is not specular in all 3d Modelling programs :P
[01:26:47] <coren_> I know; but they are basically always set to the same color.
[01:27:13] <servus> 3 TEX, 18 ALU, no MOVs, and I think I can snip out 6 of those ALU ops
[01:27:38] <servus> I'm doing conversion of vector ranges all over the place *ugh*
[01:27:48] * coren_ raises an eyebrow.
[01:28:12] <servus> That is, a packed normal being in the range [0,1] where I really want it to be in the range [-1,1] is two ops to fix.
[01:28:19] <coren_> That's very low, if it's anywhere close to accurate.
[01:28:29] <coren_> No it's not. A packed normal is one op to fix.
[01:28:33] <servus> ?
[01:28:43] <servus> How?
[01:28:48] <coren_> PARAM fixit = { 2, 2, 2, 1 }
[01:28:51] <servus> -0.5 * 2 is what I do
[01:29:09] <coren_> MAD normal.xyz, normal, fixit, fixit.w;
[01:29:37] <coren_> err, -fixit.w
[01:29:40] <servus> Hm, I'd be interested to know about clock cycle differneces for ops... Thanks for that hack :P
[01:29:55] <coren_> MAD is (supposed) to be exactly the same as MUL
[01:30:14] <servus> You can use immediate vectors in ops you know? :)
[01:30:33] <servus> MOV resilt.color, { 1, 1, 0, 0 };
[01:30:47] <coren_> All it does it move the immedite to a param and use that. :-)
[01:31:06] <servus> How do you know for sure?
[01:31:24] <coren_> Because that's what the spec says it must be.
[01:31:52] <servus> Meh
[01:31:57] <coren_> (re: using an immediate op makes one less param avaliable.)
[01:32:16] <servus> Worst case scenario, sure :P
[01:32:42] <servus> Sounds implementation dependent to me
[01:32:53] <coren_> It'd also make no sense to implement it otherwise from an architectural standpoint. The added complexity cannot improve performance. :-)
[01:33:23] <servus> GPU architecture is a big state secret, so *shrug*
[01:33:30] <coren_> Means you'd need to have a data pipeline from the instruction stream, which is a CISC leftover.
[01:33:51] <servus> Yeah...
[01:34:37] <servus> Still, nicer for the programmer :P
[01:34:40] <coren_> No it's not. GPU architecture is well-defined and well-understood in academia. All of those problems were solved years ago. All that's left for the manufacturers is translate to silicon and manage thermal dissipation. :-)
[01:35:14] <coren_> Actually, I dislike immediate operands very much, myself. Wouldn't use them.
[01:35:55] <servus> I bet that NVidia and ATI programmable GPU cores have some fundamental differences.
[01:36:21] <coren_> In the details. I very much doubt the actual processing core has significant differences.
[01:36:50] <servus> On the other hand, it doesn't make a lick of differences
[01:37:02] <coren_> I remember reading my first paper on SIMD pipelines to process vector data for 3D about 20 years ago.
[01:37:49] <coren_> The only thing that has been invented in the past 10 years or so is nice tricks and hacks to circumvent the fact that the hardware has still to catch up with the math. :-)
[01:37:50] <servus> All sorts of processors have SIMD capabilities.
[01:38:11] <servus> SIMD capability doesn't say anything about underlying design principles
[01:39:25] <coren_> Actually, SIMD capability pretty much dictates the underlying design. Which is why it's such an ugly and inneficient hack on Intel CPUs; it's just a "real" SIMD core stitched and taped to the CPU. :-)
[01:40:29] <coren_> Knowing Intel, it's probably haywire and ducttape, too. :-)
[01:41:12] <servus> Well of course Intel is another story, pasting integer SIMD onto the FPUP :)
[01:42:35] <coren_> I still say that your FP has to butcher specular reflections to be that low in ops. :-)
[01:43:08] <servus> They look fine, buckaroo.
[01:43:17] <servus> This is what I ended up doing:
[01:43:57] <coren_> Lemme see a screenshort with some nice, smooth surfaces and some bumpy one. :-)
[01:44:10] <servus> http://sammatthews.com/images/The%20Abyss/Abyss14.jpg
[01:44:54] <servus> I was getting annoyed at the prospect of calculating a correct eye-to-fragment vector in tangent space, so I cheated. I was already using the 3D starburst to get the light-to-fragment vector in tangent space, so I simply retranslated that starburst in the vector program, reusing nearly all of my matrix multiply, and presto, a neat little eye-to-vertex vector in tangent space!
[01:45:22] <servus> Smooth and bumpy in one at that screenshot :)
[01:45:58] <servus> So I get my second tangent space vector for the price of translating a 4x4 matrix.
[01:47:00] <coren_> Doesn't look too obviously erroneous, discounting your odd scaling. Perspective looks... funny though.
[01:47:35] <servus> I like a sharp frustum
[01:47:54] <servus> 90'. What do you use? I think 60' is standard.
[01:49:01] <coren_> 60; 90 only looks good if you have your nose against the glass. :-)
[01:49:39] * servus investigates
[01:50:06] <servus> Wow, 60' makes me feel claustrophobic : o)
[01:50:28] <servus> I think HL2 actually changes your FoV dynamically, depending on your speed.
[01:52:12] <coren_> Mebbe.
[01:53:06] <coren_> Can you make a screenshot with no ambient lighting? That one looks like you're using xenon arc lighting in broad daylight and washes out detail. :-)
[01:53:34] <servus> Whaaa, you mean with real-game-conditions? :-p
[01:53:41] <servus> Pure specular, or diffuse too?
[01:53:54] <coren_> Diffuse too. It's how they look together that counts. :-)
[01:55:03] <servus> I can make the specular a different colour. My highlights still need a lot of tweaking.
[01:55:12] <servus> What bias do you use for specular falloff?
[01:56:28] <coren_> The usual. cos angle ** shiny. I usually use shiny=40
[01:56:31] <servus> And what op do you use to exponential :)
[01:56:38] <coren_> LIT
[01:56:46] <coren_> Does the clamping
[01:56:47] <servus> Oh, LIT? Hmm. I was just squaring
[01:56:59] <servus> I'll look into that before I make another shot
[01:57:17] <coren_> You can't just square. Specular is exponential. :-)
[01:57:55] <servus> Well, there are different lighting models, right? :P
[01:58:20] <servus> I didn't actually look any of it up, so I just guessed on everything.
[02:00:30] <coren_> Hm. I can't seem to make a reasonably interresting shot since I've turned on specular maps. Most of the stuff you find in a typical castle isn't that glossy. :-)
[02:00:45] * coren_ fiddles with the specular maps.
[02:00:56] <servus> Do the popcorn room just south of the fountain
[02:01:25] <coren_> That's a boring one. :-)
[02:01:38] <coren_> Lemme put a light or two in there then.
[02:04:51] <servus> Ethereal Void?
[02:05:01] <servus> Does your engine support rooms-over-rooms, yet?
[02:05:27] <coren_> Yes
[02:05:56] * coren_ tries to find the second light. Where did it go?
[02:06:35] <servus> Is your engine parsing UW conversations directly, or converting to Lua or something first, for extensibility?
[02:07:20] <coren_> Parsing directly.
[02:07:49] <servus> Ah.
[02:07:51] <coren_> Bah. The light was in a wall.
[02:07:55] <servus> Of course:)
[02:08:23] <servus> Are you thinking about game extensibility for your engine at all, or just a set-in-stone emulator for the original data?
[02:08:43] <servus> It'd be very cool to have a working RPG maker that let you build worlds as easily as placing tiles.
[02:08:58] <servus> Something like *that* would start a thriving mod community :)
[02:10:29] <servus> Maybe even a graphical conversation editor, and a simple scripter. What else is there to make a complete game, beside many some new graphics? :)
[02:11:16] <coren_> A good storyline? Those are rare enough.
[02:11:37] <coren_> http://aleph.uberbox.org/~marc/sd4.png
[02:12:03] <coren_> All surfaces are equally shiny, the "carpet" is perfectly flat, and so is one of the wall blocks.
[02:12:18] <coren_> The reddish light is close to the floor, the whiter one nearer the cieling.
[02:12:50] <coren_> And the viewpoint also generates light. You can see a reflection of it in the banner tile.
[02:13:41] <servus> Right. I disable specular highlights for my camera-light.
[02:14:35] <coren_> I don't: it gives very nice geometry cues for distant obstacles; catching a faint reflection in the distance is immersive. :-)
[02:14:51] <coren_> Want me to do roughly the same viewpoint with just specular?
[02:16:13] <servus> Sure. I'm still tweaking everything. I want really sharp highlights.
[02:17:30] <servus> Heh, I got sharp highlights with a SLT:)
[02:19:02] <coren_> http://aleph.uberbox.org/~marc/sd5.png
[02:20:00] <servus> Viewport looks a bit different
[02:20:11] <servus> Hrm... Tweak tweak tweak...
[02:20:25] <servus> At what range do your specular highlights fall off, based on diffuse attenuation?
[02:20:30] <coren_> Heh. I didn't note the exact coordinates the first time around, so I navigated by hand to "close enough"
[02:20:54] <coren_> Diffuse attenuation at the point of reflection. They don't fall of further.
[02:21:17] <coren_> I.e. distance from eye to point of reflection is not taken into account (and it shouldn't)
[02:22:28] <coren_> Hm. I was closer and looking more towards the floor in sd5. It's hard to position yourself if all you've got are specular reflections. :-)
[02:22:46] <servus> I was figuring you'd have a program-starts-here camera position :)
[02:22:56] <coren_> Yeah, but it doesn't start there. :-)
[02:23:20] <coren_> I had to walk from the Avatar's room.
[02:24:25] <servus> Put some lights in the avatar's fireplace:P
[02:24:56] <coren_> Well, actually, I moved my lights _from_ there because you wanted the hall! :-)
[02:25:50] <servus> Oh gosh.
[02:26:02] <servus> The first shot of the flute room is the most impressive.
[02:26:56] <servus> Can you normalize a vector in less than 3 ops?
[02:27:17] <coren_> No dice.
[02:27:58] <servus> No? I do a DP3, RSQ, MUL. What do you do ?
[02:27:59] <coren_> Oh, BTW, my 23 ops do include 4 for the fog.
[02:28:16] <coren_> DP3 lv, lightv, lightv;
[02:28:16] <coren_> RSQ lv.w, lv.x;
[02:28:16] <coren_> MUL lv.xyz, lightv, lv.w;
[02:28:28] <servus> Except same thing here, but with less swizzling o.O
[02:29:01] <coren_> Swizzles are free (I checked) and I needed to keep lv.w around for later.
[02:29:26] <servus> I didn't say it was a bad thing.
[02:29:54] <coren_> If you want to see the whole programs, just point me at that paste thing again
[02:31:07] <servus> http://rafb.net/paste/
[02:32:58] <coren_> C++ isn't true but they're there
[02:34:03] <coren_> Do your 18 ups include fog?
[02:34:07] <coren_> ops, even
[02:34:24] <servus> Well, by fog do you mean attenuation?
[02:34:47] <coren_> I mean fog. Fixed by distance so that the far plane fades away instead of just pop out. :-)
[02:35:37] <coren_> Like glFog. After all fragment color calculation.
[02:36:38] <coren_> For instance, I could remove those four ops without affecting the two previous screenshots since the far clip plan is nowhere in view.
[02:36:41] <servus> My far clipping plane is never visible, and I don't intend for it to be, so I don't have any plans to use fog right now.
[02:36:58] <coren_> You mean if the geometry allows, you can see arbitrarly far?
[02:37:10] <servus> Yep.
[02:37:28] <coren_> Ouch. That'll cost ya in large, open spaces.
[02:37:30] <servus> The map will never have a room that big though, and the PVS is pretty tight.
[02:37:48] <coren_> Ah, point, you're working on UW1 right? No big rooms there.
[02:38:28] <coren_> I needed to implement that for the really vast expanses of UW2; the far clip planes defaults 14 tiles away.
[02:38:49] <servus> Well, let's call it UW1 for the sake of argument :)
[02:39:11] <servus> I think you should rewrite your fragment program to use shades.dat *giggles*
[02:39:16] <coren_> And, frankly, at 14 tiles you barely see anything useful anyways-- your light is almost certain not to reach in the first place. But it's nice to be able to see distant lights from (relatively) afar
[02:39:43] <servus> Maybe you should just render the distant light, and not the geometry, except maybe the immediate geometry around the distant light?
[02:40:25] <coren_> That might work, I guess, but there are also emissive textures (lava, etc) to take into account. I'm not sure it'd be worth special casing all of that
[02:40:28] <servus> Honestly though, with each tile having 2 to 5 quads a piece, and usually 2-3, I don't think performance is such a huge matter; just disable shadows after an epsilon of, say, 3 tiles.
[02:41:53] <coren_> Maybe. But it'd be a pain, I precalculate the PVS for the whole levels (expensive operation) and beyond 14 tiles in some places the list becomes... unwieldy. :-)
[02:42:11] <servus> It's always cool to remove an op, do a live recompile, and see *no* change : o)
[02:42:50] <servus> Why should PVS be an expensive, unwieldy operation for 64 tiles!?
[02:43:03] <servus> Doing it super brute force, it wouldn't take more than a minute
[02:43:33] <coren_> *shrug* I have alternate programs to help performance selectable at runtime; like no specular and such.
[02:43:58] <servus> I should make a beach scene for my washed-out speculars here... That'd look superb.
[02:44:24] <coren_> I'm not saying calculating is any harder, but having a PVS that, basically, includes the whole level defeats the point. :-)
[02:44:49] <servus> Why?
[02:45:03] <coren_> Because then you have the overhead of the PVS with zero gain!
[02:45:09] <servus> Why zero gain?
[02:45:19] <servus> Right now, are you rendering all tiles within radius?
[02:45:21] <coren_> Because your PVS doesn't exclude anything!
[02:45:29] <servus> Mine certainly does, and yours should too.
[02:45:55] <servus> coren_: My world has several million polygons ; o)
[02:45:55] <coren_> No, only those that are in the intersection of the PVS and the vision wedge. Likewise, for lights, I intersect the light's PVS with the eye PVS and render only those.
[02:46:17] <servus> Right, that's what I use, with a fudge factor for shadows.
[02:47:08] <servus> When I render the camera-light, I do camera PVS, then when I render water, I render the union of the camera PVS with a specially created water reflection PVS. Rendering other lights, I render the union of the two PVS's. All pretty optimal, I think.
[02:47:35] <coren_> Yes, increasingly so if your PVS is small compared to the level.
[02:47:39] <servus> However, the cool part is that you don't really need a unique PVS for each light
[02:48:09] <servus> I only need a PVS for each BSP leaf, and each water plane. You only need a PVS for each tile. Whatever tile the light is in, uses that tile's PVS as its own.
[02:48:11] <coren_> I have a PVS per tile, simply enough. It's not as conservative as could be, but reasonably so
[02:48:26] <servus> Right, so I don't see what the big deal is.
[02:49:01] * coren_ checks stats.
[02:50:55] <coren_> At 14 distance, my average PVS includes 22 tiles, mode 14 and max 196. No cap on distance, avg is 39, mode 18 and max 819. Makes big rooms painful.
[02:51:17] <coren_> For very little gain in the typical case.
[02:51:26] <servus> Have you considered combining coplanar tile walls/floors/ceilings that share textures?
[02:51:33] <servus> I think that that is your #1 optimization priority.
[02:52:03] <servus> You can prevent things from getting out of control by only allowing coplanar tiles that happen to form a rectangle, to be combined.
[02:52:04] <coren_> Problem is, the world isn't static. The babl code can (and does) move geometry around.
[02:52:26] <servus> So make that a "can't-combine-this-tile" flag.
[02:52:42] <coren_> ... which is impossible to determine in advance.
[02:53:07] <coren_> babl code can change the geometry of arbitary tiles.
[02:53:14] <servus> Where does it?
[02:53:25] <servus> I can only think of certain tiles that change.
[02:53:50] <servus> Can't you scan the usecode to see what tiles are referenced, and mark them as noncombinable? I think it's worth it.
[02:54:41] <coren_> No, because in many cases the tile that gets referenced is calculated by the code itself. Some of the more interresting puzzles in Scintillus Academy come to mind.
[02:55:17] <coren_> I *could* play through the game and log all changes, I guess.
[02:55:58] <servus> That's no good.
[02:56:06] <servus> Won't work on new maps people might build :)
[02:56:15] <coren_> I may have to if performance demands it-- but that this point there is no gameplay hinderance by a max sight radius. In fact, the original also has a max visibility radius, and a much (much) smaller one at that
[02:56:20] <servus> Why can't you just break a coplanar tile in two when need be?
[02:57:19] <coren_> Screws up precalculated PVS. :-) Right now, the smallest unit of change is the resolution of my PVS, so fixes in runtime are adequate.
[02:57:51] <servus> Do walls ever get changed? I can only think of altitudes and floors.
[02:58:17] <servus> Oh, and will you be able to swim under water? :)
[02:58:35] <coren_> Walls too. Example: the big changes in the Ice Caves when you open the flood gates.
[02:58:51] <servus> Hmm
[02:59:07] <coren_> No. There's nothing under the water in the game data (so it's pointless) and some plot elements would break if you could.
[02:59:07] <servus> Well, I still don't see why game data from 1992 should be giving you trouble :)
[02:59:31] <coren_> It doesn't. Sight radius is a non-issue for me. I'm already doubling it. :-)
[02:59:49] <servus> OK.
[02:59:57] <servus> Well, I'm still tweaking my specular highlight o.O
[03:00:26] <coren_> I could always switch fragment programs on the fly depending on wheter you can/cannot see the far plane. :-)
[03:00:42] <servus> Why not disable fragment programs after a certain radius?
[03:00:57] <coren_> Actually, it's not a far plane per se, it's just the distance at which I don't bother rendering anymore. :-)
[03:01:17] <servus> You could see that if you deleted shades.dat in the original.
[03:02:15] <coren_> I might do that (disable fragment programs by distance). That sounds like a reasonable tweak-- not much point in bothering with per-pixel specular hightlights if the tile has 7 pixels drawn. :-)
[03:02:35] * coren_ ponders.
[03:02:36] <servus> But then again, that's only 7 invocations of the program :-)
[03:03:00] <servus> Enabling or disabling fragment programs does not seem to change my performance.
[03:03:11] <coren_> ... and I already draw tiles in distance order anyways, so no switching back and forth continually.
[03:03:55] <coren_> It does mine, but not by much. What kills me is fillrate. I have one pass per light (including eye).
[03:04:36] <servus> You need better PVS.
[03:05:10] <coren_> No. I have less than 5% tiles drawn which aren't seen in the worst case.
[03:05:34] <coren_> And in many cases, those actually fall just outside the view frustum and are just clipped away.
[03:05:35] <servus> How fast is your CPU? Your 5FPS still boggles me.
[03:05:57] <servus> Is part of your program in QBASIC?
[03:06:42] <coren_> I get 30-odd as 640x480. 50 something at 400x300. Memory bandwidth between GPU and video memory. I got a cheap video card, remember?
[03:08:04] <coren_> With fragment programs off, I get around 20% increase regardless of the resolution; so it's mostly dependent on the number of fragments pushed to the screen and not on how they are calculated.
[03:09:26] <servus> I still wouldn't consider the 5900 cheap, but I'll let it rest for now : o)
[03:09:28] <coren_> With only the eye light, I get decent frame rates in all resolutions.
[03:09:46] <coren_> Meh. The 5900 cost me $49 two years ago. It's cheap. :-)
[03:10:33] <coren_> You should see the framerate I get in WoW. It's make your cry. :-)
[03:10:44] <coren_> s/It's/It'd/
[03:10:45] <servus> I get 10.
[03:10:51] <servus> On a good day.
[03:10:58] <servus> ... With my GEForce6800. Go figure.
[03:11:22] <coren_> WoW is evil. :-) I can reach 10, if I move every tunable to 'low'.
[03:11:39] <servus> I'm _at_ low quality.
[03:12:04] <coren_> Surprisingly enough, turning on shaders doesn't degrade performance by much. Not unlike what I get with the LoW engine.
[03:12:39] <coren_> (MY CPU, BTW, is just 1.4Ghz, and the bus speed of my old clunker is just 300MHz)
[03:13:10] <coren_> *shrug*
[03:13:43] <servus> My GEForce 6800 is a piece of crap, and I am not impressed by it.
[03:15:54] <servus> I wonder what the mysterious epsilon is in the docs for LIT
[03:16:16] <servus> The word epsilon appears in 4 places in the entire whitepaper, and it's in that one snippet of pseudocode for LIT
[03:16:47] <coren_> epsilon represent the smallest representable value which is greater than zero.
[03:17:03] <servus> Is that what they mean? Epsilon can mean other things.
[03:17:07] <servus> Alright, seems reasonable.
[03:17:11] <coren_> That's what it means in math.
[03:17:37] <coren_> Epsilon is the smallest positive real number.
[03:18:00] <servus> Yeah, just sometimes it takes on values like 1.0 *grin*
[03:18:29] <coren_> Actually, that would be true for epsilon over N
[03:18:47] <coren_> (As opposed to epsilon over R, the traditional meaning)
[03:18:58] <servus> So LIT just clamps op0.z to [-128,128]? How useful : o/
[03:19:20] <coren_> No, actually, it clips it to ]-128,128[
[03:19:30] <coren_> Thus epsilon
[03:20:09] <coren_> And that's not particularly useful, but it's the clipping that the normal pipeline does so if you want to replicate behavior it's useful.
[03:20:48] <servus> Yeah...
[03:20:53] <servus> I don't think I'm going to use LIT
[03:20:57] <coren_> And, interrestingly enough, ]-128,128[ is the domain over which POW is defined. Small wonder. :-)
[03:21:39] <coren_> I do because it saves me the clipping to [0,1] and does the POW which you have to do anyways.
[03:21:49] <servus> What about SAT?
[03:22:01] <servus> The SAT modifier constraints to 0,1
[03:22:14] <coren_> It's not free on my card. MUL_SAT and SUB_SAT are twice as slow as MUL and SUB
[03:22:43] <servus> The specs here imply that LIT uses the underlying LG2 and EX2 functions
[03:23:11] <coren_> Exactly like POW does, for that matter. That's how you exponentiate with floating point. :-)
[03:24:19] <coren_> I checked, LIT is about twice as fast for my card as expanding the operations.
[03:25:02] <coren_> I expect that's because LIT has some hardware fastpath since it's part of the normal lighting pipeline.
[03:26:14] <servus> Your uncommented fragment code made me think "Meh, I'll just figure it out myself"
[03:26:47] <coren_> Chuckles. I'm about to go to bed, but the interresting part is 37-41
[03:28:03] <coren_> Line 38 takes normal*(normal dot light), multiplies it by two, and substract the product from the light vector.
[03:28:14] <coren_> ... == reflection angle.
[03:28:26] <coren_> 39 then dots that with the eye vector
[03:28:48] <coren_> 40 just moves the specular exponent into place for
[03:28:51] <coren_> 41 ... lit!
[03:29:08] <servus> Yeah... doesn't seem to give the results I want though
[03:29:14] <coren_> After that, all that's left is multiply the factors by the light color and texture color, and so on.
[03:29:21] <servus> I think I'm just going to take a saturated bias and exponentiate.
[03:29:44] <coren_> Then you don't want real specular highlights. :-)
[03:30:13] <coren_> That's the correct math.
[03:31:13] <coren_> If you just do a bias, your highlight will okay okay-ish on flat surfaces, but will light up far too much angles on bumpy ones.
[03:31:24] <coren_> s/okay okay/look okay/
[03:31:48] <coren_> You really need to dot the reflection angle with the eye vector and exponentiate that.
[03:32:23] <coren_> ... which implies you need the reflection angle. And light-2*normal*(normal dot light) is the right math to get it.
[03:32:24] <servus> I'm only going to use specular lights *very* sparingly.
[03:32:28] <servus> I want them to POP out at you
[03:32:42] <servus> I'm only going to gloss-map things like veins of gold in walls.
[03:32:55] <servus> I don't want to take the HL2 route and specular everything up just because I can.
[03:33:07] <servus> Just water and metal gets it, TYVM :)
[03:33:51] <coren_> Same here, except that i have many surfaces that must be shiny in UW2. Polished marble, blackrock, metals (there are vast rooms of brass around), many liquids
[03:33:55] <servus> I actually *want* it to wash out whenever I use it.
[03:34:07] <servus> Well Xen should look extraordinary, eh? :)
[03:34:13] <servus> I think Xen should be half washed out
[03:34:46] <coren_> Then it's not specular highlighting, it's directed diffuse. (That's also a real lighting effect you get with ordered surfaces like brushed metal)
[03:35:27] <coren_> But you get to simulate directed diffuse pretty well with specular and a low exponent (10ish).
[03:35:55] <coren_> Which is why you normally want your exponent to be per material. This way you can do brushed metal and rubber convincingly.
[03:36:23] <coren_> (black rubber: specular with an exponent around 5 looks wonderful)
[03:37:18] <coren_> Well, bedtime.
[03:37:21] * coren_ waves.
[03:37:36] <servus> Night!
[03:43:19] <servus> Yay, I'm happy with my specular now.
[04:19:12] <-- servus has left IRC (Read error: 110 (Connection timed out))
[04:20:12] --> servus has joined #low
[05:57:49] <-- servus has left IRC (Remote closed the connection)
[05:59:13] --> servus has joined #low
[06:02:27] <servus> How do you store your glossiness channel? I'm storing it in the alpha of my normal map, but it's a pain in the butt to make Photoshop do that, and I don't wanna open another texture file just for gloss. Is there an easier way to work with alpha in Photoshop without destroying the colour component?
[06:17:29] <servus> Gimp does the same thing. I don't get it; I know that Alpha has its own channel1
[06:58:18] --> Khelz has joined #low
[07:30:26] --> Coren__ has joined #low
[07:47:07] <-- coren_ has left IRC (Read error: 101 (Network is unreachable))
[12:33:58] --- Coren__ is now known as coren
[12:34:12] --- coren is now known as Coren_
[12:34:14] --- ChanServ gives channel operator status to Coren_
[20:17:07] <-- Khelz has left IRC (Read error: 104 (Connection reset by peer))
[23:31:33] <Coren_> YOu can draw simply enough with gimp on alpha; open the channel dialog and just mask out red, green and blue.
[23:31:45] <Coren_> I expect the technique is mostly the same on photoshop.
[23:32:40] <Coren_> It helps to create an opaque layer below your work layer so that you can see the alpha.