Need some help with stubborn artists

(After having typed all this out… well… sorry for the wall of text.)

So, I used to work at a simulations company back in central Florida. I have friends who still do. I also have non-fond memories of dealing with the two environmental artists and their complete unwillingness to listen to reason.

Don’t get me wrong. They’re damned good at what they’re doing. They’re just not doing anyone any favors by the way they’re doing it.

Neither of these guys has ever worked in the games industry. The sum total of their experience seems to be having worked at this simulations company… probably going on 8 years now. At least one of them is technically minded enough to noodle with shaders in Unity. They work extremely well together and, therefore, have a habit of reinforcing eachother’s stubbornness.

Here’s the deal:

They bake all their lighting. This doesn’t sound so bad at first, but it gets there quickly.

They bake all their lighting in 3DStudio, and then discard all the dynamic lights. The lights never even make it to the game engine. They also have separate light baking passes for props and the interiors of buildings. The props see a lot of reuse and they each have their own lightmap, so the lightmaps have to be generic (eg. crate is made, textured, placed on a flat plane, then an AO pass is baked for it). They then use a vertex coloring script to tone the props to best fit the lighting where they are placed.

This means that the props have no lighting on them that is informed by the actual scene in which they are placed. Nothing looks like it belongs.

Then they use all the baked lighting to bake out their light probes. They slap the lightmaps into a self-illumination shader and scrap all the other textures. This means no colored bounce lighting gets into the light probes.

Everything in the scene looks flat. The character artist that got hired after I left complains that the bad lighting ruins all his sculpting and shader efforts, since the flat light-probes makes the character art also look flat.

And here’s what kills me. They literally spend weeks at 10-12 hours a day doing this. They map out the lightmap UVs by hand, packing the UVs in such a way as to not lose a single pixel of the lightmap textures. They utilize every pixel. Let that sink in. In order to not end up with light leaks, then then disable mip mapping on the lightmaps. This also means that, post baking, they have to go back in and touch up every UV edge to account for the fact that many edges from different parts accidentally shared a row of texels on the lightmap.

When I argued with them about this, they told me “a lot of games do this.” With what I know of rendering, I would assume that that statement is complete BS, but they clung to it like their lives depended on it. I even spent about three days taking one of their scenes, adding in proper lights, automapping UV2, and then rebaking everything to show them the improvements they would get (as well as the minimal cost it imposed in terms of performance). It only took 3 days because I had to figure out what they were doing so that I could undo it, and then start from scratch having never used Beast inside of Unity before. They looked at my results and dismissed them as “not having the lighting resolution that they can get.” I seriously wanted to scream, especially as the lighting pass (when I did it) took less than 5% of the time they put in to it and multiple people argued that my version looked better.

So, to wrap up this tale and avoid dredging up too much of the anger that still remains a year after having left that job, I request any time you guys might be willing to devote. My friends who still work there are still suffering under this tyranny.

If any of you would be so kind as to enumerate all the reasons why their approach is wrong (or if I am for some reason wrong to think they’re being dumb about this. I’m willing to have you guys tell me I’m an idiot), I will pass those arguments on to my friends still there. The environment artists wouldn’t listen to me because they knew me and had spent most of their careers with me (and because, technically, I was never a superb artist anyway. I was always a technical artist at heart). I think it might help if the explanation comes from a bunch of technical artists they don’t know who have a bit of history in the gaming world.

Help a guy help out his friends?

This is a classic TA problem.

There’s two levels to consider:

  1. A lot of artists get addicted to “perfection”. I’ve worked with a lot of artists over the years who go way, way past the point of diminishing returns in pursuit of making everything portfolio quality; I used to have a character artists at bungie who would stay up til 2 or 3 am waiting for Mental Ray AO bakes that took hours, instead of using the tool everybody else did that did almost the same job in minutes.

This is very frustrating for a TA - especially if you end up being asked to enable this addiction by providing tools or supporting workflows that are inherently wasteful. It is, however, the job of the art director or art manager to set the time/quality tradeoff for the studio and make people stick to it. It’s sad to watch people blow nights and weekends on things that only they can see, but you can’t stop people from wasting their lives that way. If people are refusing to budge on long, slow, and fragile processes that should be impacting the way their team regards them: being a working artist is not always about ‘doing the best work’ - it’s about doing the work that best fits the time, budget, and technical problems of your project.

  1. On the studio level, it’s a big mistake if decisions about things like in-game lighting are being driven by the emotions or personal preferences of the line artists. The studio needs to say ‘this is how we’re going to light our levels’ and then stick to it. A smart studio will take input from the folks on the production line, but ultimately somebody has to make that decision based on the time-budget-quality goals of the project and them make sure that everybody sticks to it. Making your own contribution look good at the expense of a teammates is unprofessional (to say the least).

So overall this sounds to me less like a tech problem and more like a management problem. If you’ve reasoned with these guys about it and they don’t listen, it’s kind of out of your hands unless you go over their heads - with all the politics and backlash that might entail.

On the purely technical level:

Lightmapping is always a hugely emotional thing for artists because it’s one of those techs where the hard realities of CG can’t be avoided.

On Halo3 / Reach, all the levels had a big 2k lighting atlas each. That was it - no matter what you did, the atlas was going to be 2k pixels. You could set a value on each triangle (doh!) which would raise or lower it’s importance in the atlassing process. But adding a single pixel of lightmap to that triangle inherently subtracted 1/4millionth of a pixel from evey other triangle in the level, and nothing you could do would change that. It was a fixed pool.

However, I found artists setting priority values between .01 and 40,000 in an effort to micromanage the lightmap res. People used to add a tiny invisible triangles to their favorite objects to make them physically larger so they got more lightmap space. People would grow objects in the game with a script in game so they got less lightmap (even though that did not help! The mapper was pretty good about keeping the low-freqency light triangles tiny no matter what). It was a huge waste of time and effort - the per-face values were always getting broken, they had to be rebuilt after topology changes, competing artists would constantly up their own values in a tit-for-tat bidding war to get more texels for their own work… It was awful.

So, I proposed a per-object setting with 5 settings from ‘low’ to ‘high’. You can just guess how that went over. I’d estimate that each project blew more than $100,000 on paying artists to sit around waiting for the results of pointless light bakes that contributed less to the final game than to the egos of their creators. Fixed-pie problems are hard. If you can’t solve them by growing the pie, it turns into bare-knuckles politics. Which is supposed to be what managers are paid to resolve - but they often don’t spot these things.

On the purely technical level these guys should not be making lighting decisions in isolation. That’s flushing money down the toilet, since any changes to level layout or design -which can come down the pike for all sorts of reasons - will break any baked-in compromises they’ve managed to come up with and send them back to the drawing board. Maybe as a last pass the week before the level is locked this pixel-painting hand crafted stuff is valid, but not before then.

[QUOTE=Theodox;25797]This is a classic TA problem.
On the purely technical level these guys should not be making lighting decisions in isolation. That’s flushing money down the toilet, since any changes to level layout or design -which can come down the pike for all sorts of reasons - will break any baked-in compromises they’ve managed to come up with and send them back to the drawing board. Maybe as a last pass the week before the level is locked this pixel-painting hand crafted stuff is valid, but not before then.[/QUOTE]

Fortunately, the majority of the “levels” are based on blueprints of existing structures or soon-to-be-built structures. Level design is easy for them.

One of the major issues I have is the disabling of the mip-mapping on the lightmaps. My understanding of the rendering pipeline is that you are then forcing a whole crap-load of extra work on the texture sampler in the shader when you disable mip-mapping, as well as increasing the potential for banding and moire patterning.

It’s renderer-dependent. In the case of lightmaps it’s likely to just mean sizzling and lower texture throughput. Whether it is ‘major’ or not depends on a lot of things - notably how big the final texels are on screen and the angle of incidence. I’d let the graphics programmers argue with that one.

You can however use the colored mip trick to show them how bogus those kinds of optimizations usually are. Make a texture with hand authored mips where the first mip is all red, second all blue, third all green and then run with it. Most artists are amazed at how rarely you actually see red in the game : they are so used to staring at things close up they don’t realize they are seeing a view that no player ever gets.

They’re actually not disabling mip-maps to keep things pretty. They’re doing it because they think their method of lightmap authoring is saving them huge numbers of draw calls. (I was the only artist technical enough to serve the roll of art-optimizer, but there’s nobody to manage that since I left.)

I mean, sure, they may be saving a couple more than if they just let the automatic mapping and light-baking tools in Unity to do what they’re there for, but it’s not really worth the cost in time, effort, and other potential issues.

Little late to the punch but I’m sure almost all TA’s and programmers have had to deal with this before.

I remember working on a team where 2 of the artists came from film, and would use unqine Geo for everything, have like 8 mat ids on each object, and use 2 to 4k textures for everything.

Than complain that ue3 is a slow piece of crap when it runs at 10fps.

After all of that they started to try and bake lights in Maya with MR as well.

Could not talk them out of there ways no matter what I did. Quit that job after every suggestion to make is answered with “its your job to make it work”

  1. Mip maps are orthogonal to draw calls. If they don’t know that they have no business making optimization decisions.
  2. If they aren’t atlassing their other textures, sharing a lightmap has no net effect on draw call count. It’s unique combination of material and geometry. If drawcalls are an issue, there should be some kind of level baking toolkit anyway, which seems like a natural unity tool.
  3. For the same size lightmap, you can put a precise price tag on the optimizations by looking at the number of pixels that are not set to whatever default color you’ve got. It’s total texels - unused texels. It’s pretty common for hand optimized UVs to be 10-15 % more efficient than auto-generated UVs using that count. There are subjective factors (there is always the one guy who swears that his layout is just ‘better’ even if it contains no more texels) but it should be possible to put pricetags on how much extra work it takes to do better. If somebody spends 2 hours to increase get 10% more texels out of a 2048 map, at low-end artist rates , you’re buying 400,000 pixels for $80 or about $.0002 per. If they spend two whole days its’ $640 / .0016. Multiply by number of levels x average number of revisions and you can get a real pricetag. It probably won’t be pretty.

Just to be clear, they know mip-maps have nothing to do with draw calls. They were packing their lightmaps super-densely and turning off mip-mapping to make sure it didn’t cause what looked like light leaks to show up all over the place. They’d then share materials across a lot of objects, hoping that Unity’s batching would reduce their draw call count.

Basically it was a tactic to maximize light map resolution and usage while minimizing actual VRAM usage and, at the same time, maximize Unity’s batching opportunities.

You comment on cost per texel still stands. Considering the long hours they’d put in and the number of times they’d re-bake lighting, tweak UV’s post-bake, and all the other shenanigans they engaged in, the cost per texel was getting way too high. Tack on the fact that this was all in lieu of using actual real-time lights to do things like, oh, I don’t know, light characters, and the flat, boring results are extra not worth it.

If they’re so smart, they should be hand-tuning their mips instead :slight_smile: