A Simple Discrete-Event Simulation: Part 80

I was working on other things today so the only thing I added to this project was the grid. It’s at a y-elevation of zero. More interestingly, it’s generation is automated, with the relevant code being shown below. Because floating-point numbers can be notoriously touchy after numerous operations I added in the smidge factor to ensure that end lines are always drawn and that the center lines can be found reliably. The center lines can be drawn in a different color if the number of divisions across the total width or length of the grid is even, meaning there will be an odd number of lines.

The grid fits to the layout so well because I make use of the fact that I had the boundary locations available since they’d been calculated to identify the center about which the camera flies and at which it looks. I extended the grid exactly one block in each direction. I wanted the blocks to be (roughly) square so I created more of them in the z-direction than in the x-direction. Last but not least the function can and should be parameterized instead of hard-coded like I’ve done here, but that’s a trivial matter.

I put the following scene together as part of preparations for a presentation. The code for generating the grid is a bit more primitive but this exercise drove me to learn how to modify the endpoints of existing lines as well as their color. In define3DLine we specify the endpoints as a pair of vector objects pushed into an array called vertices. If we want to modify those endpoints we simply dereference them in the other direction. The trick in this case is knowing you need to set the flag which lets the framework know the change needs to be processed internally. Some operation are straightforward — you just change and value and it takes effect (the line’s color works this way as we’ve already seen). In other cases you have to set the flag because the framework has to do something extra in response to the changes that wouldn’t happen naturally.

Always be on the lookout for such gotchas if the first thing you try doesn’t work the way you think it should. As it happens I found the verticesNeedUpdate property when I was using the Firefox debugger to inspect the line I was trying to change. A quick search in the documentation told me that my hunch was correct. You know what they say: RTFM.

You can see the results here, in the lines showing where the camera is located as it orbits the scene. The camera does the same thing in the simulation code demos up to this point as well.