the UI is built based on the lights that are present in your scene, It seems like a no-brainer, but it’s a pain in the a$$ to get MEL to play nice.  Every controller has to have a unique name and connect up properly to their corresponding shape node.

I’m also working on a tool for generalists called “Context Kludge” that switches its interface automatically depending on what you have selected.  It’s a lot like the excellent “Ninja Speed Box”, but will not be based on shelves.  It’s currently focused on texturing and lighting workflows, but ultimately I want to convert the entire Kludge Tools toolset to a context-sensitive model.

I’m not sure how dynamic UIs and context-sensitivity will help KludgeCity yet, but it’s a good approach to have available.

1. kit-bashing: the ability to add arbitrary geometry and static meshes into the Kludge pipe
2. arbitrary boundaries: the new Kludge will use a different method for footprints, allowing for arbitrarily-shaped polygonal boundaries… possibly NURBS?
3. easier tiers: the new system is this — choose a height, choose a number of divisions, choose a “slide” or “weight” for placement, and Kludge will handle the rest.  And of course the randomizer will control all of these behind the scenes as well.
4. procedural shading system — because I don’t have UVs any more, I want to have a robust system for creating variation and surface shading with a minimum of fuss or hassle.
5. gargoyles: because they’re cool.

So first, to trim the fat:

• I’m removing all interior geometry.  I’ve never been happy with the way it worked, and I stumbled on a new approach to window rendering that I’m excited to try out.
• No more balconies.  They never looked very realistic, and I’m considering a non-procedural approach to these kinds of facade details
• I’m reducing the number of window options — my production focus now is on creating buildings that would feel comfortable in the 1940s, before the modern skyscraper’s glass-sheet style.  I may revisit this, but for now, focus on style is more important.
• Fewer custom options — In v2.5, almost everything will be based on ratios instead of absolute values.  The Randomizer will become the main value controller, and every building will be randomized to some degree.  Sorry folks, no presets.
• The new KludgeCity will use ONLY two shaders across all buildings… one for windows, and one for the building itself.  All other variation will be handled through some other means.  I’m working on this now, and I have some promising leads.
• per-face shading is out.  Windows and the building’s body will be seperate polygonal objects.  This can cause problems such as light bleed, but after a discovering a whole sh*tstorm of issues with component shading, this is a necessary evil.
• the UV variation grid is being reduced to 5*5 — 25 variations of textures and light intensity is more than enough.
• for now, I’m removing the “base floor” layer, until I can come up with a better method.
• KludgeCity will now NEVER provide UVs to anything but the windows — UVing complex geometry with MEL is beyond my ability — after three years of trying, I’ve decided this.  However, I will be working on a robust 3d procedural shader that I can use instead.

So, now I’ve figured out what I want to trim down, next, to figure out what I want to add…

This is very slow.  On a building with ten thousand windows, the uAP script has to run a loop to select the face, pick a random number, and move the UV shell ten thousand times.  Usually this takes a few minutes, but the larger the number of faces, the larger the performance hit.  A massive building with 60,000 windows will take more than an hour to UV.

The result of all this is that 1/64th of all the faces end up on each of the 64 possible UV grid spaces — which means there is a much better way to do this.  Instead of randomly placing 10,000 faces, instead, I’m now creating 64 groups of random faces and assigning them to each of the 64 spaces.  The randomization and selection process still takes some time, but I’m also using sets instead of arrays for the face lists, which should reduce the amount of time required writing and re-writing arrays.

I’ll post up the results whenever I run some stress tests.  I think this script could be useful for a variety of projects, not just Kludge.

By the way, if any of you are using Kludge to do anything interesting, send me a picture!

The reel can be found here: http://vimeo.com/17833535