If you’re a lighter in Maya, you might find this useful. I call it the Lighter’s Friend. Enjoy!
I’ve been building a handful of tools to use at work, and in the process I’ve been learning a lot about building UIs dynamically. With dynamic UIs and scriptjobs, I can tailor a tool’s visible functionality to what’s actually in your scene, or even what you currently have selected. Here’s an example, the Lighter’s Friend.
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.
The Sum of Parts project is officially back in action. As such, I’m going to be making a new, slimmed-down, narrower-focus KludgeCity. I already mentioned what I want to take away, but what am I going to add? Here’s the initial wishlist:
- kit-bashing: the ability to add arbitrary geometry and static meshes into the Kludge pipe
- arbitrary boundaries: the new Kludge will use a different method for footprints, allowing for arbitrarily-shaped polygonal boundaries… possibly NURBS?
- 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.
- 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.
- gargoyles: because they’re cool.
I’ve started designing the new overall feature-set for Kludge, based on the last year’s worth of experimentation. The purpose moving forward is to create a leaner, more robust, more useful tool in my production context.
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…
Kludgecity has always been a production-driven script — meaning, I started making it because I had a real use for it, and it was easier to make a versatile tool than to model out a city by hand. Then, the style and requirements for my short film changed, so I had to start the script over from scratch. So what happens when I abandon my short film for over a year? Well, I just don’t have any real incentive to keep working. But there is good news! I’m restarting the effort soon, and along with it, I’ll be finishing up Kludge as a production tool. Hopefully in July we’ll start seeing updates again!
The current version of Kludge uses a procedure I call “unitizeAndPlace” which divides up the window UVs into an 8×8 grid on the 0-1 UV space. It does this by iterating through all selected faces and assigning them to randomly-selected spots.
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.
Hey, if anyone wants me to email them a copy of kludge 2, bugs and all, just let me know. The project is officially “on-hiatus” while I finish up a couple projects this summer.
I’ve recently started a job with a studio here in Dallas, so I haven’t been able to do ANYTHING with Kludge for a couple of months. I still need to fix a handful of hiccups with Maya 2010 not working correctly, but more importantly, I’ve actually come up with a few really good ideas that I want to incorporate before I release version 2. I appreciate everyone’s patience… the end result should be a streamlined, production-friendly tool that actually works as advertised. In the meantime, check out the progress on http://sumofparts.wordpress.com — the short film that Kludge is ostensibly built for. We’re actually making assets! hooray!
By the way, if any of you are using Kludge to do anything interesting, send me a picture!
My 2010 Demo Reel has an example of KludgeCity in action:
The reel can be found here: http://vimeo.com/17833535
As part of a test, I ended up building a 200-story, fully-loaded KludgeCity building. It tips the scales at 1,800,000 triangles including exterior details and interior geometry. The actual building took about three minutes to generate without UVs. I included balconies, but I somehow doubt you’d want those on a building this size.
Finished the first step of the UV workflow — the “unitize and randomize UV” script from the first KludgeCity. Now all buildings have their windows and interior dividers UV’d based on a random 8 by 8 grid. Also, I’ve added a “color” rollout that allows you to define what colors you want to have on your building shaders before they’re generated. This allows you to set a refraction/reflection tint for windows, and also lets you create a “variation grid” that controls a random value shift on the glass color. Below is an example of the window variation, and with nightscape workflow enabled. Starting to see the light at the end of the tunnel on version 0.2, but I’ve still got a lot of elbow grease to put in.
working on balconies. Not exactly realistic right now, but I’m trying a couple different variations.
In case anyone’s curious, I thought I’d let you know sort of what my process is when I’m working on Kludge.
Most importantly, I keep my eyes open when I’m out and about. I live in Dallas, so we’ve got a fairly decent variety in our skyline. I take photos when I can, and look at pictures of interesting buildings online. There is sort of a vocabulary of city architecture — some buildings have alternating stripes of material (what I call “buffers” in the script), some buildings have windows that wrap around, some have blank walls without windows, some are monolithic and flat on their facades, and others have all kinds of details extruding out from their surfaces. My job is to take those basic architectural ideas, and make a system that is capable of creating them on the fly, for any mixture of features.
It doesn’t always work.
The first step is always to model out the structure by hand. Everything you do in Maya has a corresponding command in MEL. In theory, if you can do it manually, you can do it in a script. I’ll work out a list of steps that are involved in creating a particular bit of geometry, and write out a sort of “pseudo-code” that summarizes the process. Then I figure out what MEL commands will give me the desired result. Usually this involves a lot of guess-and-check and many trips to the technical documentation. MEL is good at a lot of things, but it can be incredibly difficult to find a scripted solution that mimics human creative judgment. “select the faces that are facing outward from the building” is great if you’re talking to a modeler, but translating that into code can be tricky.
At the core of Kludge there is the default building — the only building that is guaranteed to work perfectly every time. Whenever I add a new feature, I work with this default building at default settings until I make it work correctly. The “ideal test case” is something I come back to throughout the testing process — every time I make a major change, the first thing I check is to see whether the default setup still works as expected.
After that, I try out a handful of other configurations. If all goes well, then I proceed to do everything I can to break the system. Most of the time, this is not difficult. Usually, I try to “user-proof” the system to the best of my imagination, but the truth is, there are more ways to break Kludge than there is time for me to fix them. All I can really do is try to make the system as flexible as possible.
A lot of the functionality of Kludge will eventually involve randomization, and I really can’t ensure that every combination of features will look good, or even work at all. But I guess that’s really the power of working procedurally — if you don’t like the result, in a couple minutes, you can have an entirely different building. There’s no reason not to try a bunch of different things and only keep what works.
Is it possibly the nightscape workflow that I promised but never delivered on in the first version? I think it might be. Still leagues from perfect, but so far so good!
Added new feature — now you can generate a low poly proxy (152 quads, compared to 70,000 for the full mesh)
You will eventually be able to toggle between the visibility of the proxy and the high-poly version, so you can place your buildings before render time, add a command as a pre-render MEL script, and the system will switch all of them out for the render.
New feature — I’m dubbing them “verticals” — sort of exterior columns between the windows. They make for some fine, imposing structures.
Just added this — I’m calling them “rounders” – they fill in sharp angles with a semi-cylindrical mesh.
Just about broke myself today trying some new-fangled approach for smaller, non-skyscraper style buildings. It failed pretty miserably, but I’m going to try again. I think I’m onto a good idea, but translating it into something that MEL can work with… well, that’s not so easy. In the meantime, I’ve added in a bit of code for creating railings in the gaps between building tiers.
I’m sure everyone’s run into this problem before… Maya doesn’t really have a feature for creating “nice” extrusions the way many other packages do. There are a couple Python-based plugin solutions out there, but for KludgeCity, I had to figure out a pure MEL way to get the same kind of result. The “fixed” extrusion tool I’ve come up with is a bit slow, but it works for almost every situation I’ve needed it for so far. This will allow me to UV entire buildings at a time, instead of the piecemeal floor-by-floor approach I’ve been going with. For now, it’s got a pretty narrow scope of usefulness, but I’ll probably try to expand it so that it will be an all-purpose tool.
Testing the new tier system. You can now get a huge amount of variety from the same base footprint.
I occasionally get feedback from people who use Kludge, sometimes in the form of donations, sometimes just a friendly email. So I’d like to say a warm thank you to the following folks:
Sara in Angola
Raphael in South Africa
Ruslan in Karaganda, Kazakhstan
Sergey in Moscow, Russia
Ranaldo in Washington State, USA
Lee in Georgia, USA
Pamela in Colorado, USA
Jose in New York, USA
Paul in Michigan, USA
Brian in California, USA