Yet Another Town Generator (3D)

[Steel General]

It's pretty darn cool already, good luck with it!

[mearrin69]

I had glanced at this before but just took the time to explore the site. This is something I'll play with for many hours when it's done! In the meantime it looks like you need building models? I don't have a lot of time at the moment and can't really commit to helping...but if you'd post specs (model format, poly limit, size, image map size, etc.) and a list of stuff you want I'd be willing to try to put a few together as I have time.
M

[danjr]

I spent a good deal of time looking at programming a GUI. I fear it'd be too hard for me to learn in time to be any use. Though I am trying to conceive of ideas of a gui layout to make it user friendly. What I may do is try a website with mouseover images that would serve as a reference for the program.


One other thing I thought of with this is the possibility of modern cities too. Allowing buildings to be upwards of 50+ stories tall. Though with the building modifier set as a 1 for the tall structures.

A couple of cool random generation features would be
Building upper stories limit, with an average structure height. This way it could generate a good spread. Couple that with the road "quality" The larger structures could congregate around those, giving it a real city feel. (Though I am a huge fantasy fan, the city gen would be an awesome additional feature.)

The road generation of the map could be a huge key on the "vegetation" "Quality" of roads would be an inverse ratio for adding in vegetation. Default for the "walls" would also prevent them from generating vegetation near them.


I hope you don't mind my brainstorming on this project, it is far more worthy of encouragement than many things I've seen.

[Crayons]

Thanks again for the encouragement !!! It is something that I think people will have fun with.

@mearrin69
Models are always welcome but at the moment getting the GUI up and running is the priority, and since I have someone willing to start that what I am looking for is someone who would like to continue or even take over that role. I don't think my current snake charmer will object to passing on the baton. For now though, the intention is that the beta version will have sufficient basic functionality to inspire a baton picker-upper to leap into the breach. (Mixed metaphors? me?)
As for models though, the requirement is that the model must be importable into POVRay, POVray is the core tool, the GUI just allows easy placement of objects by exporting POV code. if POVray can import the thing, it can usually scale it and shove it around for anything else. As for importing : POVRay is a bit like someone with type AB blood. It can accept (usually via third party converters) a number of model formats, but due to its seemingly unique code capabilities and focus on shape primitives is apparently not capable of exporting to any other format! I have successfully used Sketchup models (but textures may need tweaking) and meshes I've created in jpatch. A load of converters are out there for dxf and the like, I'd be happy to test any converted items people might like to send me!
One of the reasons I would never consider selling any of this stuff is its dependence on POVray . So, for example, you ask about image map size, and I can only say, "I don't know". At the moment I am using 200x200 pixel pngs as image maps for 2m x 2m wall sections. I'd prefer to use bigger maps , to enable whole sides of buildings to be textured, but I have had POVray "out of memory" errors - despite having lots of memory available. This could be/could have been a POVray bug that may be fixed.... Much depends on how big the town is and how many instances of "the thing" there are. As my streets are currently "the fill" there are a LOT of buildings. If you wanted to add one Cathedral, it probably wouldn't impact significantly???
If you want to create models, then work to what looks "right" for the scale of view you want to achieve, The stuff I've created assumes that this is for mapping and more distant views so anything under 0.1m is size is not modeled (but can be on image maps). For example - I would code a picket fence as solid and use an image map for the detail.
However, if someone wanted to create a ground level view of some street, they could create their own high detail foreground buildings (with or without picket fence!) and use 3dtg to "fill in" all the more distant stuff.

@danjr
I have a GUI layout of sorts as it is - nothing "amazing" - it doesn't need to be. The BIG headache with this concept was entering all the locations since POVray alone is text only. The current development of the GUI is based on an already written program which is free for modification and allows mouse placement. At the moment it looks like this.
3dtg.png
with the "Streets" tool only, now. Yes, the "new" button is too small, I'm gonna deal with that!
For any Python people out there? We are using pySketch by Erik Westra as the basis of the tool. I'll try to think of some way to thank him for putting that program out there for just this sort of thing!

On modern cities: sure! These things can be done. The idea behind 3dtg is that you will be able to write your own commands = street types in this case. How deeply those are coded into the GUI is up to debate but there will be a set of "generic" entry tools that will allow graphical insertion of "undefined things" that you then modify in the POV code afterward.
You can create new "tools"/"things" as POVray macros and only include the ones you want, like choosing your colour palette before painting. At the moment I'm concentrating on fantasy styles but anything "goes"!
The primary reason for choosing POVray is that (as far as I know) it is the only render tool that allows you to code "random". All the other (directly) GUI based tools are great for creating *A Thing* but not necessarily creating a whole bunch of random things based on an algorithm. My current street "tool" just needs a few parameters and it does all the rest itself.

As an insight to what you need. If I were to write a skyscraper street, I'd try to create a set of building type shapes, the basic "brick", the tiered "brick", the oval tube, the "pointy tower" and so on. I'd have a set of image_maps, brick, concrete, metal, tile, marble etc. I'd think up some algorithm for heights of buildings, perhaps linking some heights to some of the shapes. Write all that into a POV .INC file as a macro and Bob's your Uncle as we say. In many ways, it would be easier than my current "street" if it were city block based. Randomizing building placement on my street was/is complicated.

Needless to say, at the time of going to press on all this I will be creating Tutorials on a) Installing and Using the tool b) Modeling and creating macros in POVray.

The overall intent is not that I write all the tools! I'd rather enable people to "do their own thing". I doubt it will "take off" in a big way but if needed I might start a forum somewhere for people to share stuff and (if really necessary) try to control stuff??? My intent is that everything is FOSS.

[ravells]

It sounds really cool, crayons although I have to say that knowing nothing about programming means that I understand less than half about what you say. I have downloaded the trial version of city engine (but have not had the time to play with it as much as I would like)....does your city builder work on the same principles?

[danjr]

Love the GUI layout so far, simple and not overwhelming.

What about manual build up, or knock downs for buildings. How would that be done. Could it be a simple tool? Personally I think that would be the make or break feature.

So exciting.

[Crayons]

@ravs!
I get that a lot! Knowing nothing about programming. Well, apart from the very basics, neither do I really. POV "code" is a lot like writing a list of shapes, giving them positions, colour, and so forth. There's a bunch of "overhead" but it can be that simple. The "code" part is really only as complicated as ye olde BASIC was on early home computers. If, while, case statements and the like, written like that olde worlde BASIC. None of your "object oriented" whatevers here. If I look at something like Python my mind just sorta goes blank. Anyway, I've decided to bite the bullet and start a POVRay Basics Tutorial. POV 101 for Beginners, it's at about my level too.

@danjr
Erm, I'm don't understand what you mean about "manual build up" and "knock downs". Could you elucidate further?

[ravells]

Ah, BASIC, I can understand (well not sure how much i remember now)! Many Many moons ago I did an O level at computing, we worked on Commodore Pets and had write a programme as part of the course. Slight digression, I did a simple database to identify criminal suspects by height, colour build crime committed etc. One of the 'known criminals' on the database was the computer teacher. For some reason, whenever we queried it he always seemed to to be the chief suspect!

[danjr]

Ok lets say you randomly generate the city, it looks pretty decent but you want to edit things a bit.
By hovering over a structure you can add or remove floors one at a click or something along those lines. I think that would be the highest priority function for a novice user.

As a Novice user the things I'd like most to be able to do are.
#1 Increase/Decrease structure by clicking on it.
#2 Changing the structure type

As a more Capable user
#1 Change terrain elevation
#2 Move streets around. Maybe even add remove.


I think if those 4 functions were in the program, it would suit the needs of almost any GameMaster, of most systems.

Wishlist for Advanced would be coast and river editing, along with piers, docks and bridges. But the 4 I've mention before, would be more than enough for my selfish DM'ing needs.




On a separate discussion how would streets be editable, would they be like nodes of most art programs, where you could drag them around, along with add/remove?
That would really add an amazing editable ability for the users.

I hope I'm not overly bombarding you with stuff, like I said before this is probably the most useful program I've seen being developed.

[Crayons]

ravs
O'level Computer Studies eh? I did that too, back in around 1978/9? I wrote a Monopoly game in Algol that was so boring I called it "Monotonopoly". It was written on an Elliott 903 that I later became the owner of and have recently donated to The National Museum of Computing at Bletchley Park (where I am now a volunteer, restoring it!). My old school computer is now a museum piece! That's enough to age anyone!
My more recent programming experience has been VHDL - hardware, quite a lot different from software even if it looks similar!

danjr
OK, I understand now.
Hrm. Good ideas and I think the tool could have some of that functionality but I suspect not quite as interactively as you'd like?
The tool is also not trying to duplicate the work of other tools, that, I think, would be a waste of effort. All that is needed is that other tools can be used in conjunction with this one - or vice-versa probably more tactful!

The creative process is envisaged thus:

1)If required, generate a height_field image, for my test bench town, Bendford, I used Paintshop Pro and Wilbur.
2) Use the 3dtg GUI program to load up your height_field and place your objects on that in a top down only view.
3) Export your POV code to file(s). Save your GUI project file (currently PSK format)
4) Tinker around further with the POV code as you like.******
5) Choose your viewpoint and render settings and render your image in POVray.

***** It's important to understand that the main focus of results is on the POVRay element here. The GUI is mostly going to be there to simplify some of the more onerous parts of POVRay data entry, mainly inputting loads of coordinates! The GUI gives you the visual cues you need to place things in relation to your height_field.


It should be possible to go back to any point and reiterate from there.
However, I do not, for example, envisage the 3dtg GUI program providing height_field editing capabilities, that job is already excellently done with other programs.
However! I would be pre-empting the enthusiasm of any user willing to modify the code to do that by saying it would never happen. It just isn't planned for now. If you go back and edit your height_field with something like Wilbur, then load that instead of your original used in the GUI, then POVRay will adjust all the buildings to sit on that new height_field automatically.

At the moment we have the "street" tool working, it would seem. That is merely one of a set of tools which broadly fit into 3 categories based on how many coordinates they need.

Single coordinate tools planned are
Building
Tower
Gatehouse
Ship

Double coordinate tools
Street
Wall
Bridge

Multiple coordinate tools (up to 10 coordinates)
Fill Building Zone
Fill "Stuff" Zone
Urban Space Zone

then for each of these will be a "Generic" version
Generic Node
Generic Line
Generic Zone

The specific tools - like "Tower" bring up specific dialogue boxes to fill in that directly map to the POV macro call that is generated. Customised to the POV macro essentially.
The Generic tools will have (say) 10 text fields in the dialogue box to fill in that will appear in that order in the macro call. It's up to you to do some simple POVRay editing to customise it any further for the macro you are using it for. The basic benefit of using the GUI for this is the mouse entry of the node position(s).

Editing :
If you create a street using the Street Tool, you cannot edit individual buildings in that street. All you can do is ask it to generate a different street based on a different random sequence. That would likely be a direct POV task at the moment (but easy to do).
However, if you manually lay out a street by placing individual buildings one by one, yourself, then you can edit those individually.

As for "knocking down" and the like, this would not be by interactively clicking on a symbol on the image portion of the GUI like (say) "Populous" the game changing heights, you would have to select the item and edit the dialogue box variables. The current "Building" macro design does not have "Number of floors" as one of those variables, it is currently derived loosely from the building "Size". However, one could modify the Building macro and use the Generic Node tool to enter parameters for this as a non-standard tool - as it were. Building "type" likewise, I have a building type now, which reflects its building materials: wood, brick etc.

Ultimately, this is not targeted as a pure "Design Tool" where you need (and have) control of every aspect of the design. Aspects of this tool are designed, deliberately, to generate random "stuff" so things are, hopefully, quicker and more fun, perhaps.

Good news is, in the GUI all items are moveable, including street ends, and are removable/copyable.

Ultimately, the tools will all be available for you to tinker with, if you have the skills(!) and I would encourage that too. It does however represent a challenge as to whether or how far to control, say, a core code-set. All that will depend on "the community", if such there be, of users interested in collaborating on its future. If any!