BZW Generator

I’m about a week behind schedule, but I’d never expected graph implementation to be so hard. As far as a simple graph goes, all is easy. The problem arises if you want to keep the graph planar, and keep track of the graph faces.

Yesterday I finally managed to get rid of those stupid coordinates in my generation Zones. Now a Zone can take any shape from a graph and generate itself from it. What that means for BZWGen is that I finally got the door open to a non-axis aligned world. Unfortunately, despite the fact that the PlanarGraph class works and is used by the existing grid generator, it’s still incomplete in terms of properly “growing” it, and there is no non-axis-aligned generator yet. I hope to get at least that finished before the7th July deadline.

As a positive sidenote however, riggin the zones into the planar graphs made the code more clean then ever. I removed a lot of obsolete code, cleaned up the rest and added doxygen comments to all the affected headers. A few more headers to comment, and this will be the best commented piece of BZFlag code :P.

As anyone visiting this site probably knows, BZWGen is going to be enhanced as a part of GSOC 2008. Technical plans, and formal stuff will go to the BZFlag BZWGen revisited project entry ( at http://my.bzflag.org/w/BZWGen_revisited ), progress reports and rambling will go into this blog.

Since the beginning of the program I managed to achieve two more important goals — I cleaned up the codebase severly (it pains me how lousy of a C++ programmer I was then -_-), and made BZWGen work as a plugin for BZFS.

Currently I’m working on one of the things that mostly made BZWGen city maps worse-looking than other city generators I’ve seen — removing the constraints imposed by the axis aligned grid. After a lot of research I decided to do that by implementing a planar graph structure. Once that is done I think I’ll rig the structure to be generated by a L-like-sytem, probably even rigging it to the existing grammar.

Next progress report post soon.

Um, yeah, there was no posts lately, my fault. Work ather the end of GSoC has of course deccelerated, but not stopped. Apart from invisible changes, most notable the reduction of all the subdivision and partitioning rules to the more powerful split and repeat, as well as finally giving bzwgen the ability to define it’s own textures instead of relying on precoded ones.

Yet, some visuals still have been added. I added some textures, changed many rules, and added roof dingbats. See for yourself:

Now however work on visuals will be accelerated — bzwgen is going to be the topic of my Master Thesis! Expect to be able to download the Thesis from this page before the month ends! (in english :D)

It as been quite some time since the last update, but my!, I’ve been busy. Took two days to implemented but finally I have the basics running — multifaces, made with boolean operations!

I didn’t have much time to make use of them, so only a sample demonstration is available. I did however manage to combine them with ngons. There is still plenty to do, and plenty bugs to be fixed, but the basics have been done and (surprisingly!) work!

Now if only I could finally get myself to work on the Thesis… but working on bzwgen is so… addictive xP.

Little less dev-time today than usual, and I have to start working on my master thesis. Yet, except fixing a couple of bugs and style issues, I managed to implement one important feature - NGon based buildings! This is the first step towards non-quad based buildings. The following screenshot is from the testing grammar (ngons were not yet fully placed well, and a lot too many :P):

As a bonus, I implemented counting of faces, so now I can tell you that as for today, an average bzwgen map is made out of 60,000 vertices, 50,000 faces, and 2,000 texcoords (the last value because of texcoord reusage system I implemented).

It all started when I prepared two door images, really. The first problem was that the default face covering was 1/4 of the texture, so I implemented a operation to set the texcoords so the texture covers exactly the face. And then I implemented the whole rest of texturing, along with snap grids and all. Snap grids made me also implement snap-aware subdivision and partitioning. Now all texture problems should be solved.

It’s hard to see it on such a small screen shot though. Why not give it a try on Constitution’s server?

Well, this is my first post as a OS developer. At least a unpaid one :). I’m unsure whether I’ll keep updating this blog on a regular basis, but at least until I finish my Master Thesis (which is about BZWGen) I’ll try to.

Today I finally moved all the building generation into the grammar (as usually extending it a bit), done a lot of clean up in the code, and fixed some bugs with ugly looking buildings. I also added some “dingbat” rules.  Not enough visuals though to warrant a screenshot though.

GSoC coding time has ended, but the BZWGen project is still alive ;]. Although today was a day of mostly cleaning up the code before the big submission, also many project related changes have been made. Most importantly a lot more power has been given to expressions, including basic math operations and boolean comparison for the new “assert” recursion guard. Also as a bonus is the ability to read current face attributes. That allows the controlled creation of things such as doors or implementation in the language of partitioning.

I also started to work on the language manual finally. It came out stronger than I expected.

On the sidebar are almost current Windows binaries. If on linux, then just checkout the source, it should compile without problems. Note however that in both cases you’ll need a HEAD bzfs to run those maps! Ask me if you need a Windows one.

Next awaits the hard topic of non-quad shapes that I’ve been putting away for a long time now…

Duh, I thought that I will work on more visual stuff today, but instead I focused on stuff needing attention before the deadline. Several “must be” features were fixed/implemented. Most of all the whole zone placement system was rewritten to provide a more comprehensive and extensible code (instead of a blob of spaghetti). The zone reader (the thing that reads the 2D grid map into zones) now reads any map that is based on rectangles, and the subdivision system (the one that divides the map into lots) has been completely rewritten to accommodate that, and provide truly random subdivision.

Looks like SimCity, eh? Anyway, I also implemented other much needed things - the program now takes command line parameters for almost every variable of the generator (thanks to JeffM for the command line parsing module) and also there’s an option to finally provide CTF play with the creation of bases.

Out of the fun things I added some grammar for the roofs :P.

I want to still be able to escape that SimCity look. Tomorrow I plan to tackle the issue of shapes. This is a biggie, but if it works, it’ll make the visuals MUCH better. Also planned is a scatter map, but I’m unsure whether I’ll be able to make it before the deadline.

Per aspera ad astra! :P

Today was also a day full of hardcore coding. I managed to implement a *lot* of things, mainly around the grammar - including but not limited to materials, attributes, chamfer algorithm, and most important - multimesh support — now both zones, as well as grammar rules can divide their work into separate meshes.

Although the grammar is now enough powerful to build all the existing algorithms and basically render them unnecessary, some buildings are still in the code and not in the grammar. I’ll probably move them out of there tomorrow.

Sidewalks are a nice side-effect of today’s coding, as is shape chamfering. Some green land in a city wont hurt anyone :).