Minas Tirith Project || Part 2

#2161

My suggestions, taken in cosideration or not.

Issues:

1)Team members: find some members that are trustworthy and hang on to them. A concentrated smaller team is a lot more efficient that a big team that looks good only on the credit list. I found pretty easy to find people but hard to make them stay (i m sure this come to your notice too) so it s necesary to have a boost for them from time to time and that boost can mean anything from a smaller official update to a previz animation, or 360 turnarounds.

2)Modeling: i think at some point there was a talk about making a shared database with models that could be instanced. This data base is important and should be made.

3)Organisation: each new team member will be given at start point this xref archive, a desgin document with his section of Minas Tirith as long with the concepts available, the modeling guide and other small things that make sure the new guy has everything he needs to work in good conditions and have no reasons to be confused.

Deadlines are a must. The argument that everyone has a real life and is working on this project in their spare time is not a good one considering that they have joined the project.So make realistic deadlines (taking in consideration all the real life tasks…and a marge of error about 2 weeks) and try to stick to it. When someone comes to the team and sees how loose everything is and unorganised hi s start mood will end up loosing it s power.

For example: Project final deadline: July - 2009. (final real time version)
Top levels (level 5-6-7) deadline - august 2007 (including texturing)
Texture database: august 2007 (only diffuse)
and so on.

You might consider telling members (making it a rule for team members) that if they proove bad behaviour (missing deadlines, lack of skills bad communication skills etc etc) they will be kicked out of the project with no hard feelings. This will give a serious aspect for the project. I know what you will say…but we have to stick to what we have with our teeth…well it s not exacly like this.This will look harsh…but will make most of the new comers to stick to their work (that if they really like the project).
PS: for this tactic to work they need to see really serious people in the project leading board. Otherwise they will say…“heey…if they are not working and are missing deadlines why should i get punished when i stricke one”

Maybe an inside team ranking depending on the amount of work each one is doing will make people work harder to be ranked.

4)Texturing: i see this rather simple to resolve.One big database of diffuse textures with proper naming tags.
Example: Lev1_right_023_stone.
All the diffuse textures are clean textures( i mean no obvious dirt/cracks and with some special purpose). The dirt will be added ontop the walls as masks with opacity maps.This option has many advantages.The most important one is you have full control of were the dirt is and what dirt you want to use without needing to make houndreds of textures with many combinations.
So there will be a big data base with diffuse textures, dirt textures, plants, cracks, and all bunch of other details organised in an intelligent way.(i don t know if the viewer supports displacement,bumb,specular etc).

Each scene should use a multy sub object material.

I wonder if vertex color exporting is supported by the viewer. If so you might consider using vertex paint to fake the light. It s much less resource consumer and might even look much better.

Take it or leave it…

#2162

That’s very serious approach man :slight_smile:

1)Team members: find some members that are trustworthy and hang on to them. A concentrated smaller team is a lot more efficient that a big team that looks good only on the credit list. I found pretty easy to find people but hard to make them stay (i m sure this come to your notice too) so it s necesary to have a boost for them from time to time and that boost can mean anything from a smaller official update to a previz animation, or 360 turnarounds.

I think that being restrictive in accepting new members won’t help MT. The more people are involved the more fun is in sharing results of your work.

2)Modeling: i think at some point there was a talk about making a shared database with models that could be instanced. This data base is important and should be made.

You mean the building elements, right? Yeah, I agree on this with you only in case that there would be stil a lot of work on modeling and there would be a BIG TEAM that could really use these elements.

Deadlines are a must. The argument that everyone has a real life and is working on this project in their spare time is not a good one considering that they have joined the project.So make realistic deadlines (taking in consideration all the real life tasks…and a marge of error about 2 weeks) and try to stick to it. When someone comes to the team and sees how loose everything is and unorganised hi s start mood will end up loosing it s power.

Deadlines are something that people mostly don’t like but they help keeping projects going forward… Sometimes there’s no other way to finish what you’re developing.

4)Texturing: i see this rather simple to resolve.One big database of diffuse textures with proper naming tags.
Example: Lev1_right_023_stone.
All the diffuse textures are clean textures( i mean no obvious dirt/cracks and with some special purpose). The dirt will be added ontop the walls as masks with opacity maps.This option has many advantages.The most important one is you have full control of were the dirt is and what dirt you want to use without needing to make houndreds of textures with many combinations.
So there will be a big data base with diffuse textures, dirt textures, plants, cracks, and all bunch of other details organised in an intelligent way.(i don t know if the viewer supports displacement,bumb,specular etc).

Each scene should use a multy sub object material.

I wonder if vertex color exporting is supported by the viewer. If so you might consider using vertex paint to fake the light. It s much less resource consumer and might even look much better.

The idea of making two sets of textures (color and alpha for dirt) is nice but I don’t know if viewer could render it without a great reduction in performance (even with a sensed texture streamer). If I remember well viewer does support color,diffuse, bump, specular and alpha maps.

#2163

I think that being restrictive in accepting new members won’t help MT. The more people are involved the more fun is in sharing results of your work.

More people doesnt equal with lots of progress and fun unfortunatly.It s harder to keep track of a bigger team (from a team leader point of view)…and a much lazier one than a small and fresh one.

You mean the building elements, right? Yeah, I agree on this with you only in case that there would be stil a lot of work on modeling and there would be a BIG TEAM that could really use these elements.

A lot of modeling there will always be so you will get full of that.And tha big team fact is not an argument.

Deadlines are something that people mostly don’t like

Deadlines are something that every person that has a decent background will know to respect.

The idea of making two sets of textures (color and alpha for dirt) is nice but I don’t know if viewer could render it without a great reduction in performance

Using this method can reduce the size of the textures drastically so more resources will be available.

#2164

New overview renders:

Rendering is becoming rather painful, it takes 8 renders of 1000x1000 to get one full 2000x2000 render. I’ve got to render the lowest level seperately, because of the enormous memory consumption. And added to that, I’ve got to split the render into four sections, again because of memory issues.

[color=DarkOrange]New website:
[color=#fffffe]The ideas for the teammembers backend functions:
[/color][/color]
[ul]
[li]Edit personal profile.[/li][li]View other members full profile.[/li][li]Uploading and tagging renders.[/li][li]Viewing and downloading models from the models database.[/li][li]Uploading models to the models database.[/li][li]Changing building status for the map.[/li][/ul]Some notes to that list:
Personal profiles will include contact info, like email and MSN addresses, which are not visible on the front end of the website, but are visible to members.

The models database has long been a plan, but due to a lack of time, has never really made it. Now that we’re going to develop the new website we’ll have time to make it.
The idea is pretty simple. There will just be a bunch of models like different types of roofs, windows, pillars etcetera, available for download in different formats.

The projects host can be used by all members to upload their pictures to the website (and use it on forums), a bit like some of us use imageshack now. This will allows us to easily keep the website up to date.

The uploaded images will be tagged (how exactly is yet to be decided) so that the media database can be ‘linked’ to the map. For example, you’d get a little info box for each building on the map, and when you click it, you’re brought to the renders of that particular building. The infobox will also show the building status, which can be altered by the teammembers that are working on it.

#2165

Looks great ! :wip:
Was wondering how the renders were working with so much in there…this is the part that drives me nuts, spliting and layering …then you start to loose track, especially if you do it over more than a short span…when the textures get added it’s gonna be even tougher for your poor computer… :argh: :slight_smile:

#2166

New website:
Last thursday I’ve spoken with Emiel about our plans for the coming months. We’ve decided to combine a php project we’re going to do and the MT website.
We’re going to make a very dynamic CMS (content management system), which will allow us to quickly change it for any purpose. We are going to aim for 2 months development time for the backend, starting next week (including the teammember part).
The frontend is a bit of an unknown area though. We’ve got a design, made by Tim a while ago, but even though that’s looking pretty nice, we think that we’ve got to spice it up a little more. So that design has got to be tweaked, or perhaps even remade, depending on the ideas of the person who’s going to do it. Tim is currently having his internship, so it’s not clear if he can do this.
I’ll keep you updated about this.

[color=DarkOrange]@softdistortion: [color=#fffffe]It is indeed going to be very hard to render it once we’ve got everything fully textured, and I’m not really looking forward to it when it comes to that :stuck_out_tongue:
The compositing is very simply done now. I’m just rendering the thing once with only the first two level visible, and then another with all but the first level visible. After that I just lay them on top of each other and draw a mask in the top layer.
So this method wouldn’t be very useful for an animation of course. That would require some masking geometry I think.
Oh and I use max’ blowup settings to render four parts of the full picture. This saves some memory too, since you can render 1000x1000 in one frame, instead of a four times larger 2000x2000. The downside to it of course is the time it takes.
[/color][/color]

#2167

Minas Tirith viewer v12 :
Yesterday I received an update from Flavien, concerning MT v12.
Apart from some issues with objectnames (probably included the wrong position-data files, my bad), the development for v12 is going pretty prosperous.
So the release shouldn’t be too far away now.

[color=DarkOrange]New website (map) :
[color=#fffffe]Yesterday I’ve been working on the map of the city, for the website. I changed a lot of the code, going from ~300 to less than 30 lines for the building codes.
It’s now using a XML file (or php+mysql when running it online) for the information of each building. This will allow us to easily update it, without having to recompile the flash part.
For the backend, I’m going to make flash communicate with php, so that you don’t even need to worry about things like instancenames in the flash file.

[/color][/color]

#2168

New website (design) :
Another update concerning the new website :slight_smile:
I just spoke with Tim about the design for the new MT website. As Emiel and I will mainly work on the technical part of it all, we were in need of someone to do the graphical part. About a year ago, Tim had made a quite nice design, but we all agreed that it could use something more exciting, more slick, etcetera.
Tim is currently having his internship, so I actually didn’t expect him to have time to do redesigning for MT, but luckily, he does :slight_smile: So we’re all geared up to make something great for the website.
If all goes well, we can have a completely new website in about 8 to 12 weeks. (I’m not going to set a fixed date for it, as there’s still a lot of planning to do on this. And after all, we all know how things go with long-term deadlines on these kind of projects ;))

#2169

These are very good news. I’m waiting for both the new website and the new viewer. Great job guys :slight_smile:

#2170

Update week 10.[b]

New website:
[/b]This week Emiel and I have been planning and thinking about how to make all the features for the new website. We’ve got everything roughly worked out now, there don’t seem to be any more potentially ‘problematic’ areas.
The next step will probably be meeting with Tim to talk things through and make the final plans for the site.

[color=DarkOrange]b Tools:
[/b][color=#fffffe]I’ve been playing with maxscript a bit and I’m now developing a couple of tools for MT. One is a script that will make the rendering of regions (chopping one render up into multiple parts) much easier. Now you’ve got to change the max settings before rendering each region, and you’ve got to do the stitching by hand too. The script I’m now writing should avoid all that.
The other script I’m writing can be used to create the renders for a 3d flash viewer that I’m going to make later. It will become quite similar to the quicktime 3d viewer that David mentioned a bit back, but made in flash, so more flexible. What the maxscript will do is render out the object from a series of angles. These will then be put into one image file, like a sprite, using the same code as the region stitching. This sprite can then be loaded in the flash ‘3d’ viewer.
The advantage of this is that the created file can be uploaded easily and put directly on the website, without having to compile anything in flash.

A screenshot of the current UI:

Design document:
The work on the design document hasn’t started yet. I intend to get the development of this document starting next week.

Viewer v12:
Last but not least, the oncoming viewer. I haven’t found time to take a look at the problems with the object position files yet. I’ll try to do so this weekend. Once that’s done the release shouldn’t be far away.

[color=DarkOrange]Updates:
[color=#fffffe]I intend to continue with these much more frequent updates. I want to make a general update at least once a week, probably on Friday.
[/color][/color][/color][/color]

#2171

3D Viewer 3dsmax tool:
I’ve nearly finished the maxscript part of the 3D viewer tool for the new website.
The main functionality is completed, now it’s just a matter of making small tweaks and adding some minor features.

The script rotates the camera a certain amount for each render, resulting in a series of images showing the object from all the angles you specified. When the rendering is done, the images are automatically stitched into one large sprite.

The seperate images are stored in the default image directory of 3dsmax and are deleted once the stitching is done. You get a nice dialog when the stitched image is ready to be saved. This image can be used directly in the flash 3d viewer (well, that’s the plan :stuck_out_tongue: )

I’m going to make a region render tool using the stitching script too, to seriously speed up the workflow for overview renders.

#2172

I’ve prepared some material to work with for texture artists:

#2173

[b]Update week 11.

Design document:
[/b]Simon came up with the idea to make the design document in a wiki style. This will allow easy editing, referencing and searching. Yesterday I did the basic setup, so now we can move on to filling in the main subjects.
Softdistortion, whom you’ll probably know as the team leader of the shirowproject, joined us to help with the texturing part of the design document, and after that with the texturing process itself.

New website:
Next monday, I’m going to meet with Tim and Emiel to discuss the details for the new website. After that we can really start the production.

[color=DarkOrange]Viewer v12:
The positioning problems for v12 is taking a bit more time to sort out that I had thought. This is due to some changes in the filestructures and organisation of the instances.

3D To Sprite maxscript:[/color]
The maxscript part of the 3d model viewer is now completed.
What the script basically does, is render out a series of cameraviews and stitches them together in one large sprite.
The camera moves in a spherical motion around the target, so the output is basically a render of the object from all sides. This means that once you put it into flash to control which frame of the sprite you can see, it looks like you’ve got a 3d view of the model.
I’ve chosen to use one large image instead of seperate frames to make the uploading to the website easier. A sprite generated by the script will contain all required info (nr. of frames for example) in the filename, so all you’d have to do is upload the file to the server and the applications will take care of the rest.

The main window:

Rotation Settings

[ul]
[li]Active: Setting either the horizontal or vertical rotations to inactive will cause them to be omitted in the render. So if you only set horizontal active, there will only be horizontal motion available in the flash viewer.[/li][li]From Angle: This is the starting angle of the camera movement. 0 Degrees horizontal will mean that the camera stands at “12o’clock”, looking from the top. Increasing this value will make the camera move clockwise around the target. For the vertical rotation it goes from top to bottom.[/li][li]To Angle: This is the ending point for the rotations.[/li][li]Steps: The amount of steps the camera will take between the starting and ending angle. 10 steps will result in 11 frames (a starting frame plus 10 steps). More steps will obviously cause a larger amount of frames to be rendered, and thus a larger file.[/li][/ul] Render Settings
[ul]
[li]Camera: In this list you can select which camera should be used by the script. This should be a target camera (other cameras aren’t listed). Brazil cameras are supported, but you’ll have to make sure that it has a target.[/li][li]Output size: The size of one frame in pixels.[/li][li]Process Priority: The priority of the 3dsmax thread. You can select either normal or low. I’ve left out high because it can easily make your system to virtually lock up with heavy renders.[/li][li]Individual Frames Directory: This is the directory where temporary frames are stored before they are stitched together. Default is the image directory as set in 3dsmax.[/li][li]Delete individual frames: Settings this to enabled will cause the individual frames to be deleted automatically once the stitching process is completed.[/li][/ul] Resume previous render
[ul]
[li] Enabling this checkbox will load the settings of the previous render. This can be useful if you’ve cancelled the rendering process, or if max crashed. You can only resume rendering if you’ve loaded the same file as the previous time.[/li][/ul] Preview
[ul]
[li] This button will start the rendering process, but instead of rendering the frames, it makes a fast preview. This is done by grabbing a ‘screenshot’ of the viewport. This is a fast way to test your settings, camera setup etc.[/li][/ul] Render
[ul]
[li] This will open the render window and start the rendering process.[/li][/ul] The render window:

[ul]
[li]Last frame. This is the last rendered frame.[/li][li]Rendering Progress. Here you get a basic overview of the rendering progress, showing the amount of frames done, last frame time, elapsed time and the estimated remaining rendering time.[/li][li]Settings. Here you can see the render settings.[/li][/ul]To stop the rendering process, you can push the Esc key on your keyboard. When the rendering has been stopped, the button at the bottom will become active. Clicking it will resume the rendering process (the rendering of the frame that has been cancelled will restart).
After you’ve stopped the rendering, you can close the rendering window. Make sure not to do this before the rendering has stopped!

 [b]   The output:[/b]
    [[img]http://img148.imageshack.us/img148/2016/3dtospriterender1rg6.th.jpg[/img]](http://img148.imageshack.us/img148/2016/3dtospriterender1rg6.jpg) [[img]http://img147.imageshack.us/img147/3669/3dtospriterender2jq2.th.jpg[/img]](http://img147.imageshack.us/img147/3669/3dtospriterender2jq2.jpg) [[img]http://img147.imageshack.us/img147/8810/3dtospriterender3lk9.th.jpg[/img]](http://img147.imageshack.us/img147/8810/3dtospriterender3lk9.jpg)
    When the rendering and stitching are done, a 'save file' dialog will popup. This allows you to save the file where you want it and to give it a name. However, there will be a small addition to filename to pass a couple of variables (amount of frames for example) to flash. This addition will look something like "__10x9+5x3+f". Do not, I repeat DO NOT change or remove this. Doing so will most certainly give unwanted results in the flash viewer.
    As you will doubt see, the files can become quite large, especially when you render horizontal and vertical rotations at a rather high resolution (for example, 36x10 steps at 320x240 will result in a file of 11520x2640pixels). Because 3dsmax saves the file at a high quality (due to the crappy jpeg compression I set it like this) I strongly recommend that you compress the file in Photoshop. This can either be done by 'Save for web' or just the usual 'save as'. This will bring the filesize down by a considerable amount.
    
    
   [b] 3D To Sprite MEL script:[/b]
    Yesterday, Simon decided to start working on a Maya version of the 3dToSprite script. He is aiming on having it finished somewhere next week. If all goes well, the flash part of the 3d viewer will be done by then as well.
    
    [b]
    Region Renderer script:[/b]
  [[img]http://img80.imageshack.us/img80/2930/regionrenderuica1.th.jpg[/img]](http://img80.imageshack.us/img80/2930/regionrenderuica1.jpg)

Yesterday I began with the region render script. This script will make the rendering of large images much easier, by splitting it up into multiple small regions, and automatically stitching them together when the rendering is done. As you can see you can select multiple cameras to render from.
I can use a lot of code from the 3dToSprite script, so making it shouldn’t be too much work.

#2174

Region Renderer:
Today I’ve finished the region renderer script for 3dsmax:

The script allows you to render high resolution images which would otherwise cause crashes in 3dsmax. It just renders the whole image in parts, and after that stitches them together.
It also allows you to select multiple cameras, so that you can for instance let a couple of views render overnight, without having to start it all up each time.
Just like with the 3dToSprite script, it also has a ‘resume previous render’ function, in case the previous render was stopped before it was finished.

I will probably make the script publically available, since it can be useful to anyone who’d want to render high resolution images with large scenes. Perhaps a GPL kind of thing is an idea for it.

[color=DarkOrange]3D To Sprite maxscript:
[color=#fffffe]While working on the region renderer script I found out about a refined way of scaling images. I used to use a pretty straightforward method for the preview function, a ‘copy bitmap’ function which basically did nothing more than skipping every x pixel. The new method of resizing is based on texture rendering, and uses filtering. I’ve now inserted this into the 3d To Sprite script too, so that the output of the preview function will look a bit less rough.
It comes at a small cost though, the resizing wtih the filter method takes a second or so longer than the old one. So the time it will take to render a preview will double. Sounds dramatic, but it isn’t really, it goes from about one minute to two :wink:
[/color][/color]

#2175

I’ve prepared other material for texture artists…

#2176

Update week 12

[b]Viewer v12[/b]
Yesterday I've finally been able to spend some time to sort out the mess with the position files for v12. There were quite some problems with namechanges, wrong rotation controllers and other oddities. But I managed to get things sorted out and sent the files to Flavien so that he can continue his work on v12.
I am still thinking about different ways to do all the instancing and stuff, because the current method keeps bringing up problems. One thing I'll try, is writing a script that will check all objects for the correct rotation controller and replace them if necessary.


  [b]Website[/b]
Last monday I've had a meeting with Emiel and Tim to talk about the plans for the new website. It was very useful and fruitful and I'm confident that the new website will become very nice and useful.
For the front end the main goals are:

[ul]
[li]Giving the visitor a clear idea of what the project is about. This idea has to be clear quickly, so that visitors know what they’re looking at.[/li][li]Allowing returning visitors to see the last updates, which should be posted frequently. This should entice people to return to the website and keep following the projects progress.[/li][li]Showing the visitor the progress of the whole project with the media we’ve got. So as a sort of ‘photobook’ that shows the progress from the beginning to the end of the project.[/li][/ul]The main goals for the teammembers back end are:
[ul]
[li]Fast access to project date like documents, models, extensive teammember profiles (for contact data), scripts etcetera.[/li][li]Easy uploading of media related to the project. This hosting can be used for all media generated by teammembers, not that specifically for the website. The teammember can use the host to post his media on forums for example. A moderator can select which of the uploaded images can be placed on the website. Think of it like the service provided by imageshack, but then linked to the website. This is to encourage people to keep adding content to the website.[/li][li]Updating data for the website related to themselves or their work. This means editing your own profile, updating building statuses for the map etcetera.[/li][/ul]Other major features will be:
[ul]
[li]A weekly newsletter, sent by email to subscribed people. This newsletter will be generated automatically from the newsitems added that week, plus a possible piece made by an admin. This can be combined with the current weekly updates. This is once again to keep people up to date and to encourage them to keep following the projects’ progress.[/li][li]The admin(s) will be able to manage all the content on the website in a Content Management System. This will allow easy content generation and modification, which will result in more content (a tedious way of making content restrains people from doing it).[/li][li]A forum, integrated with the design of the website. If possible, team member accounts will be combined with forum accounts.[/li][/ul]All these features and goals will be taken into account in both the technical and creative (design) part of the website.

  [b]Hosting[/b]
At the moment, we've got a nice host in America. The provided traffic is very much sufficient. We've got about 2.7 TB to spend, so that's quite enough with an avarage daily usage of 600mb. In fact, the provided bandwidth is growing with 16 Gb per week. No idea why they do it, but you won't hear me complaining about it.
But, the host is somewhat slow for people outside the American continent. So it would be a good idea to get a server in Europe. I've been asking around and it looks like we'd need a dedicated server to provide enough bandwidth (somehow hosting in Europe comes with much less provided bandwidth than in the US). A dedicated server is of course rather expensive, at least more expensive than what my wallet can cover so to say (I'm paying about 90 euro per year for the current hosting and that's enough if you'd ask me).

    However, Wilco kindly offered a share of his dedicated server in Amsterdam. We can use 15gb per month for free. And perhaps we can arrange something with Emiel too once he's got his server (somewhere this summer).



 [b]3dToSprite[/b]
Last week I made a start with the flash part of the '3d' viewer. This came with an unpleasant surprise...a most unpleasant surprise I can safely say. It turned out that flash doesn't support images or movieclips wider or higher than 2880 pixels. This means that it can't load most of the output of the 3dToSprite script, or you'd set the frame size very low (80 pixels wide if you'd take 36 horizontal steps). It looks like I'll have to go back to seperate frames after all. No problem for the script of course, but it would be a problem for the ease of use when it comes to uploading it in the CMS for the website.

 So I've been searching around a bit for server-side zip unpacking possibilities in php. I found a very nice small script and program that does this. This allows you to easily upload 3d viewer data, by just uploading a zip file. For more info about the server-side unpacking of zip files: [m-zip](http://esurfers.com/m-zip/).
We might also want to use this for other media uploading on the website.

     The good thing about using seperate frames in a zip by the way, is that the addition to the filename like it happened before can be omitted and instead be put in a xml file.
The downside of using seperate frames is that 'recompression' of the data is a bit less easy. With just one file you can easily drag it through photoshop to make the file smaller. But with 400 seperate frames this is of course somewhat less easy. I think I'll just make a batch thing for this and include it with the maxscript. Perhaps it'd even be possible to have maxscript automatically start photoshop and the batch, but I'm not sure about the possibilities there.



    [b]Region Renderer Script[/b]
Last week I've been doing some tests with the region render script. It seems to work very nice, apart from one very annoying 'bug'. It turned out that when rendering a large scene, the script crashes when it starts stitching. I don't really know why this happens, but it seems to be a memory issue.
For more information (and possible help ;) ) check [this thread](http://forums.cgsociety.org/showthread.php?f=98&t=476735).
Luckily, the resume function is working nicely, so you can always continue after a crash:
[[img]http://img180.imageshack.us/img180/7596/mtcameraleftle5.th.jpg[/img]](http://img180.imageshack.us/img180/7596/mtcameraleftle5.jpg)

  
 

 
 That's all for this week. I hope that next  week will bring more progress on the viewer and design documents.
#2177

Looks like some major progress again. :thumbsup:

Nice textures Kope.

#2178

Good to see this project back alive :slight_smile: it is well worth the while :smiley:

the Region Renderer looks very interesting hehe I got a city that could use a script like that hehe.

Keep it going :slight_smile:
Looking forward to more

cheers
jozef

#2179

Thanks. I’m still making some minor adjustments to it as you’ve seen, but I do plan on making it publically available when it’s done.

#2180

Pjanssen- Let me know when you are getting close to ready for the texture part of the WIKI. I’d still like to get the texture budget and some info on the 3D engines texture abilities- layers/alphas etc.

Kope- Are those original textures?
If it’s ok with Pjanssen I’d like to get started on some tiling texture work if you are able and willing I would like to get your assitance…also Pjanssen’s/team’s input/ref links on the desired look for the final city.