It’s kind of neat, when you realise that your systems are generic enough that you don’t actually have to write much code to get interesting effects.
Previously, the “selected building” effect I was using was just to draw a simple wireframe box around it. But there were bugs which caused the box not to z-buffer correctly (that is, the box showed through the building). But I realised that with my procedural geometry, I’d already built all the tools I needed to draw glowing lines around the procedural shapes themselves; I’d written it for drawing region outlines that I was showing off months back.
Really, this probably also wants to have lines along the sharp corners, but that’s a little harder to work out; my procedural geometry is being worked out on a per-vertex basis, not a per-edge basis. Maybe I ought to switch to per-edge. That’d also let me cast shadows from these objects, which would be pretty cool.
But I’m not doing that until milestone 2! :)
I’ve been poking around a bit more with terrain/building authoring, most recently with an MMORPG Tycoon 1.1-style overhead view map, which you can zoom in and out.
Those who’ve been around for a while will remember that this was the original idea for how 2.0 would work; you’d have a 1.1-style vector graphic map, but when you zoomed in, you’d zoom straight in to the full 3D view.
As it turns out, though, it feels really weird to do that. For one thing, converting from a forward-view to a down-view interface actually feels really weird. And having the forced-downward vantage point while on the map also feels really weird. And finally, going to the solidly vector-graphic look from the current 3D view just seems to clash, from my point of view; the two styles don’t meld very well at all.
So I’m still playing with it a little, but it isn’t feeling nearly as promising as it sounded when I was originally considering it. Keeping terrain authoring and suchlike done exclusively via the FPS-style view may turn out to be the best way to go, after all.
Just thought I’d mention; I did the legwork today to get threaded comments working on blog posts here. It’s not the prettiest styling ever, but it basically works! And this revamp to the comment system means that gravatars are enabled, for those who use that system.
I’ve currently got threads capped at four replies deep, and we’ll see how that goes. Crossing fingers! 
Got annoyed today, and finally went searching to find the cause of the weird lighting glitch on these gazebo objects. You’ve seen this problem right from the beginning when these things were simple square-shapes, where part of the roof of one of these objects would have a weird hard edge, as you can see in the image on the left.
Basically what I’m doing here is figuring out which direction the surface is facing for each point on the model. On some bits of the model (such as the cylinders at the bottoms of the columns), the lighting is smooth across the whole shape. In other places on the model, there are a hard edges, or “creases” in the surface. The general approach is to look at every edge in the model and figure out how sharp a bend is occurring across it. By default, everything is creased. But if the bend over a vertex is shallow enough, then I remove the “crease”, and make the surface smooth.
As you can see here in the roof of this object, there’s a crease between the outer face of the gear-shaped roof, and the faces which connect them to the inner portion of the shape. The problem was that here we had two different basic smooth shapes being constructed; the wall of the roof, and the curving top part of the roof. At the bottom part of the roof, these two bits are different enough to cause a sharp crease between them. However, as we move up the roof, the difference between these two shapes lessens, and many vertices could legally be “uncreased” and merged into either one of those two shapes; the side or the top of the roof. What was happening before was that when it found a vertex that could be assigned to either, it would pick one or the other more or less at random.
My fix has been to change it to instead figure out which shapes a vertex can be merged onto, and then pick the best one, instead of picking one at random. With only a little bit of work to explain to the system how I define “the best one”, it seems to have made a big improvement!
It’s been a while since I posted a screenshot, so I figured that it was about time to do one again. You all probably remember that gazebo-style “starting area” that I set up to test the procedural building generation code.
Well, here’s that same pagoda building, except this time it’s not being built inside a square plot of land; instead, it’s being built inside a plot of land that’s shaped like a six-spoked gear.
I’m rather pleased at how well it’s coped with the strange, concave shape!
Still need to add some smarts to avoid having multiple overlapping pillars, though. Shouldn’t be too hard to do! (But not for milestone one; must keep focus!)
It’s kind of neat, when you realise that your systems are generic enough that you don’t actually have to write much code to get interesting effects.
