T w e n t y S i d e d

In the last entry I hacked together a solution that let me draw my scene without using a framebuffer object. But now I’m realizing that even though I got lighting working, I still don’t have the features I need to make this work.

The Loss of Framebuffer Effects

One of my goals at the start of this project was to mess around with goofy color reduction and dithering effects. I don’t know why, really. It was just something I wanted to see in action.

The idea I had for dithering would squash the image down to just 16 colors, which would produce something like this:

With lots of colored lighting, stark shadows, and the right surface textures, that might look really interesting. Like pixel art in motion? The other idea was to simply reduce the resolution of the individual color channels to make something like this:

Again, there might be some combination of lighting, shadows, bloom FX, and surface textures that would make something unique. (As opposed to just “pixelated”.)

I really enjoy this sort of crazy mixing of technology levels. Like, “What would it look like if you were doing modern-day 3D rendering on the EGA displays of the late 1980s?” Maybe it would yield a distinctive look, or maybe it would just result in something confusing and dull. The only way to be sure would be to do the experiment and see how it looks.

Sadly, I have to abandon this idea. These effects require the use of a framebuffer. You need to be able to render the entire screen into a framebuffer, and then copy it into the viewport using some sort of special effects shader. No framebuffer means no full-screen effects.

This also means no bloom lighting, which is another thing I wanted to experiment with. I wondered what it would look like if you only applied bloom to certain color channels. Like, blue light blooms, but red light doesn’t. It might look something like this:

I know this is somehow possible in Unity, because Nightdive Studios did something like this in the System Shock Remake demo, and that was written in Unity:

I’m guessing the “dreamy” look of this image comes from bloom lighting with the blue channel boosted, and I really wanted to try that out on my city.

But to do all this I’d need to figure out how to gain access to framebuffer effects in Unity, and:

1) The documentation on this rendering path is so sketchy it borders on classified.
2) What little I can find out about it indicates it’s built around rendering the scene with normal maps, with the assumption that you’re going for modern-day rendering conventions. So even if I did gather enough information on how to use Unity’s deferred render path, I’d still need to perform extensive modifications to adopt it to my gonzo rendering style. (And it might not even be possible to do so.)

Using Unity is really odd. Sometimes huge, complex tasks can be automated in just a couple of lines of code, and sometimes seemly-obvious things become unreasonably complex. For the last five days I’ve been saying, “Everything in Unity is either trivial or impossible!” That’s not really true, but it feels true.

Enough whining. Let’s get back to work.

Streets

In previous entries you might have spotted some streets with traffic lines and proper intersections. In this write-up I’m listing features in order and talking about them in isolation because that makes it easier to follow, but the truth is that I bounced around and worked on a lot of different things. If I got stuck on one thing, I’d switch over to another task until I got an idea of how to solve the first problem.

So let’s go back and talk about how I made those streets, because I ran into an amusing situation.

Like I said in part 1, I scribbled some random lines down to use as streets. That would form something like this:

Then I just need to see where the lines cross each other. I can split them at those points and insert intersections. That will leave me with something like this:

Okay, so I just need to take two arbitrary line segments and derive their intersection point. (Assuming they have one.) To do that I’ll need to…

Um.

This Should Be Easy, Right?

Hang on. Why can’t I figure this out? I really expected this would be easy, but now that I’m about to type the code I suddenly realize I have no idea how to do this. And it seems like it should be simple, right? “Where do two lines intersect?” That sounds like a simple operation. It certainly seems simple compared to fancy stuff like surface normals and reflection vectors and transformation matricies.

Oh right, I can look at the point and see how far it is from the ends and that will tell me…

No, that will tell me if the point falls within the line, but first I need to find the point.

(Moments of confusion and embarrassment pass. I feel like some kid who’s been asked to write a word on the chalkboard, and it’s not until I’m holding the chalk in my hand that I realize I no longer speak English. Why am I having so much trouble?)

This is silly. I can do this. What if…

Okay, what if I connect two of the endpoints? This will form two of the corners of a triangle. It should be easy to get the inside angles of those two corners, and I can use those to somehow derive…

Huh. I actually have no idea how to do this. I guess this is the sort of predicament you find yourself in when you’re self-taught. I’m not surprised I have gaps like this in my knowledge, but I am surprised I didn’t know that I didn’t know this until I tried to do it. That’s funny.

Anyway, I search around and I find a code snippet that does the job for me. I have to convert it into C#, but it works:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

public bool Intersects (LineSegment other, ref Vector2 intersection_position) 
{
	//First let's try to avoid the heavy math with simple bounding checks.
	Bbox2	box1 = new Bbox2();
	Bbox2   box2 = new Bbox2();
 
	box1.Contain (start);
	box1.Contain (end);
	box2.Contain (other.start);
	box2.Contain (other.end);
	if (!box1.Intersect (box2))
		return false;
 
	float		a1 = end.y - start.y;
	float		b1 = start.x - end.x;
	float		c1 = a1 * start.x + b1 * start.y;
 
	float		a2 = other.end.y - other.start.y;
	float		b2 = other.start.x - other.end.x;
	float		c2 = a2 * other.start.x + b2 * other.start.y;
 
	float det = a1*b2 - a2*b1;
	if (det == 0)
		return false;
	intersection_position.x = (b2*c1 - b1*c2) / det;
	intersection_position.y = (a1 * c2 - a2*c1) / det;
	//The above checks can figure out WHERE the intersection takes place, but that 
	//point might only be reachable by continuing one of the segments.
	//Now make sure this point falls WITHIN the segments.
	float	to_intersection;
	float	my_length = Length ();
	float	other_length = other.Length ();
	to_intersection = (start - intersection_position).magnitude;
	if (to_intersection > my_length)
		return false;
	to_intersection = (end - intersection_position).magnitude;
	if (to_intersection > my_length)
		return false;
	to_intersection = (other.start - intersection_position).magnitude;
	if (to_intersection > other_length)
		return false;
	to_intersection = (other.end - intersection_position).magnitude;
	if (to_intersection > other_length)
		return false;
	//All tests pass. The point must be good.
	return true;
}

It works, so whatever.

Getting Rid of a Bad Idea

Remember in part one I put down all these little “sidewalk marker” objects? At the time, I was envisioning this system where sidewalks would be very organic. Roads would crisscross and form little traffic islands and such. Stuff like this:

But now that I’m working on this, I’m not really interested in messing around with organically-grown traffic islands. They’re interesting, but they’re not the kind of feature you need. The scene won’t look incomplete without them.

Also, having the program chew through thousands of these stupid sidewalk points is slow to the point of annoyance. If I’m not using them to do anything sophisticated, then there’s no reason to have a sophisticated system.

Highlight code. Press delete.

Now we can build blocks a much simpler way.

We take all our streets, cut them up where they intersect, and put intersection objects at the split location. This intersection will mediate the connections between all the roads that feed into it.

Once all the streets are plugged into their respective intersections, we go around and look for hanging dead-end streets. We throw these away.

The block builder will grab one side of the street and just keep making right turns until it gets back to where it started. When it’s done, it’s formed a block.

This is still a very primitive system. I’ll need to add a way to have streets of varying widths, and maybe more variation in the spacing. But I plan on adding a “region” system later where different parts of the city will have different streets / buildings. Until then, I think this is good enough.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.