#low@irc.freenode.net logs for 18 Oct 2003 (GMT)

Archive Today Yesterday Tomorrow
LoW homepage

[02:55:09] <servus> See HL UW? :)
[03:16:35] <Coren_> Yep. Neat. :-)
[03:17:15] <Coren_> How are framerates? The way I generate the geometry is a bit naive and very suboptimal.
[03:17:33] <Coren_> I'd particularly ike you to go poke around the lake. Know how to get there?
[03:52:45] <servus> Very fast.
[03:52:55] <servus> *However*. I cannot load the entire map into HL.
[03:53:02] <Coren_> Oh?
[03:53:16] <servus> It seems to crash it... I've deleted varying parts of the map and the only thing I can come up with is that it's too large (it compiles fine, but crashes the actual game.)
[03:53:32] <Coren_> Well, probably hitting some silly static limits. The Q2 engine is funny that way (although Q2 itself handles my map)
[03:53:38] <servus> It seemed to work before I changed all the water textures to be swimmable.
[03:53:45] <Coren_> That's a non-concern for me since I'm not using the engine.
[03:54:02] <servus> I changed all the water textures to swimmable and it started crashing the game (I like how you made the artificial bottoms to lakes)
[03:54:11] <Coren_> I'm just pleased to see that the visgroups are small and correct; which is what I was hoping for all along.
[03:55:25] <servus> Well I noticed that you made a somewhat-effective attempt to combine large stretches of like walls into single planes.
[03:56:22] <Coren_> Yeah. The process is a bit naive because I didn't want to copy with the O(n3) complexity of real optimization, but it does a fair job most of the time.
[03:56:35] <servus> Oh, I fixed my shadows and it's all very fast now.
[03:56:47] <servus> I recompute barely anything.
[03:57:38] <servus> If there are 1,000 separate objects in a room, and a ball is bouncing around, I only have to recompute the single extension for the ball once for each light... How does your method handle large numbers of planes in a complex scene? My last method was horrid at such a thing
[03:57:47] <Coren_> Yeah, made the same tradeoff in my engine as well. I'm not yet sure how memory expensive this will get with a big map though.
[03:59:05] * servus is glad to have moved away from shadowmaps... I'm aiming for decent performance on lower end hardware... I just have a few odd kinks to work out.
[03:59:20] <servus> There's one odd problem that'll be murder to fix completely, still:
[03:59:26] <Coren_> Hm; well, since I cache light volumes I can actually tell which volumes are affected by which objects and only redo the relevant lightmaps. It's very quick, but at the cost of having to cache one lightmap per plane per light. Which isn't /too/ bad given that most lights actually hit only a limited number of surfaces in "real" cases.
[04:00:03] <Coren_> I consolidate coplanar surfaces, which helps.
[04:00:52] <servus> Imagine this if you will: The camera is inside the shadow volume of a single poly (it's the only poly in the scene casting a shadow, by the way, to be simple). All the extension faces of the shadow volume are facing inwards (they're all "carving"), so I need to overlay a single addition to my stencil to offset this, and this method mostly works. However, it's possible for half the camera to see inside the volume, and half the
[04:01:02] <servus> see outside the volume, which causes artifacts which are most indesirable indeed.
[04:01:17] * servus may have just come up with an answer, in his rambling.
[04:02:18] <Coren_> Hm; why not just clip the shadow volume with the near camera plane before you project it?
[04:03:21] <Coren_> And *my* rambling just gave me a flash of inspiration!
[04:03:24] <servus> That's not what I had in mind... I don't know how effciently I could do that, and it'd cause artifacting of its own if the far end of the shadow volume was not poking out the wall, maybe.
[04:03:34] <servus> Rambling is good. Watch the movie "Pi" to find out why. :)
[04:04:21] <Coren_> I project light volumes! I can dump all the math on GL if I render the scene *from the light's point of view*
[04:04:34] <servus> Actually, no, that is similar to what I was thinking of... Instead of simply pasting the entire screen with a stencil-adding quad, I'd shape that quad to match the most visible part of the side planes, somehow...
[04:04:45] <servus> Duh, that's what I did for my lightmaps :)
[04:05:04] <Coren_> But then you don't /need/ lightmaps at all!
[04:05:27] <servus> 1. Orientate camera to lights position 2. Multiply the projection and modelview matrices with a bias matrix, and store this matrix. Now, before projecting your light volume, simply project with this stored matrix.
[04:06:08] <Coren_> Well, right now I project the volume on the plane, and simply rasterise the resulting polygon to a lightmap. Straightforward and /mostly/ efficient.
[04:07:04] <servus> That was my first generation method.
[04:08:27] <Coren_> How did you fix the aliasing? Or did you just rely on interpolation and the fact that, with a texture, it's not obvious?
[04:11:46] <servus> With that method? In my second generation, I "fixed" the aliasing by doing some weird GL-accelerated affine map tricks to "unfold" the polygon into the right triangle needed for the texture map. It wasn't entirely succesful, but as you can see, my shadowmaps look good. :)
[04:12:48] <Coren_> I just wish I could rely on some GL extensions. HP_OCCLUSION_TEST and EXT_FRAGMENT_PROGRAM would solve _all_ my problems.
[04:13:18] <servus> I'm on my fourth generation now. My third generation was the final shadowmap version and the prettiest of them all. What I did was render a series of shots from the spotlight's point of view, looping through shapes. For each shot, I made all objects black, and the active shape white. I stored this single shadowmap for each object. While rendering, I did the following: render everything as pure bright, then turn on blending, st
[04:13:41] <servus> with the spotlight's stored projection*bias*modelview matrix, and use each stored shadowmap and render each object again.
[04:13:48] <servus> None of my methods use any extensions.
[04:14:35] <Coren_> Yeah, but the method you just described needs the Fillrate from Hell.
[04:15:19] <servus> And it is also extraordinarily wasteful in texturespace. (It tended to use 5% of the allocated texture memory)
[04:15:33] <servus> It's purty, though. *grin*
[04:21:49] <Coren_> Erm. Beddy bye time.
[04:22:25] * servus relishes the ability to scare people off with matrix math. >:)
[04:22:32] * Coren_ chuckles.
[04:22:37] <Coren_> Not I, certainly. :-)
[04:23:27] * Coren_ is away: Sleepness.
[05:22:02] <-- Coren_ has left IRC (capek.freenode.net irc.freenode.net)
[05:22:02] <-- servus has left IRC (capek.freenode.net irc.freenode.net)
[05:32:01] --> Coren_ has joined #low
[05:32:01] --> servus has joined #low
[13:16:37] <-- Coren_ has left IRC (Read error: 110 (Connection timed out))
[15:45:42] --> Coren_ has joined #low
[15:45:42] --- ChanServ gives channel operator status to Coren_
[20:17:30] <-- Coren_ has left IRC ("using sirc version 2.211+KSIRC/1.2.4")
[20:22:33] --> Coren_ has joined #low
[20:22:33] --- ChanServ gives channel operator status to Coren_
[22:54:37] <-- Coren_ has left #low ()