GameDevBlog

Unity Animator.Update Hogging CPU

While getting the framerate back up on my Mac I noticed something odd. Animator.Update was taking over 20 msec, which was weird since, like Tony Hawk, there's only one character in the whole game.

So I looked at it in some different scenes:

Turned out, the more complicated the scene, the more ms Animator.Update took. What?

Then I remembered - Unity by default (in fact, I can't figure out a way to stop it) attaches an Animator to imported meshes. I wrote a quick script to remove them ALL, added it back to the character, and now Animator.Update is back to taking almost no time at all. I'm going to have to go through and fix my prefabs, but it's a good start.

Here's the script, in case you want to do the same thing.

/*

This file is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or

distribute this software, either in source code form or as a compiled

binary, for any purpose, commercial or non-commercial, and by any

means.

 

In jurisdictions that recognize copyright laws, the author or authors

of this software dedicate any and all copyright interest in the

software to the public domain. We make this dedication for the benefit

of the public at large and to the detriment of our heirs and

successors. We intend this dedication to be an overt act of

relinquishment in perpetuity of all present and future rights to this

software under copyright law.

 

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR

OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,

ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR

OTHER DEALINGS IN THE SOFTWARE.

 

For more information, please refer to <http://unlicense.org/>

*/

 

using UnityEngine;

using UnityEditor; 

using System.Collections;

 

public class RemoveComponents : ScriptableWizard

{

 

[MenuItem("Custom/Remove Components")]

 

static void CreateWizard ()

{

 

ScriptableWizard .DisplayWizard <RemoveComponents> ("Remove Components", "RemoveComponents");

 

 

}

 

void OnWizardCreate ()

{

Animator[] components = GameObject.FindSceneObjectsOfType (typeof(Animator)) as Animator[];

foreach (var component in components) {

DestroyImmediate ( component );

}   

}

 

}

 

 

Unity 3D And Teamwork: Adventures In Source Control

You'd think with a name like "Unity" it would be easier to use on a team. I've heard people complain about Unity's source control capabilities before but always assumed they were solvable if we used something external that had binary file locking, like SVN or Perforce. (Or even SourceSafe, shudder.) 

Once I tried to synchronize work with Paul, though, I realized it's not so simple. Turns out that Unity doesn't respect the read-only flags on your files. So even if your source control package sets your binary files to read-only while someone else has them locked/checked-out ... Unity will let you go ahead and modify the files anyway.

The read-only flag is how I've made sure team members don't bash each other's changes ever since we first used SourceSafe with Die By The Sword at Treyarch in 1999. Unity is the first tool I've used that doesn't seem to respect the flag. 

Because of this, it seems like everyone I've talked to who uses Unity on a team has their own set of voodoo for dealing with this stuff, whether it's "whiteboard checkouts" or just living with the occasional collision.

So, after Googling and searching Unity forums and spaces for answers fruitlessly, I contacted them directly, and they sent me a plug-in. (EDIT: forgot to include the script. Here it is: RespectReadOnly.cs )

I haven't tried it with Unity Free but it partially works with Unity Pro. It's intended to be used with Unity Team, which is an additional $500 and out of my price range, where it will grey out things in the inspector you shouldn't be able to edit. But even without that, it won't write over readonly files and with a little modification (which I did) it will protect you.

So hopefully they'll work on this more and roll it out for those of us not using Team, because it seems weird to me that we should pay an additional $500 per seat for a single function. If you're using Unity with someone else, or plan to someday, please vote up the issue - I just used all my votes on it - so we can all work on a team easier sooner.

A System That More Or Less Works

In the interim, here's our source control policy and system. This is what we do, and you could do it too, or use it as a starting point. It took me a lot of trial and error to get here, so hopefully this will save other people some time.

I'm certain I spent more time working out our source control system than I actually would have spent redoing work after collisions between me and Paul. Whoops. But I've been a source control enthusiast ever since 1999; old habits die hard. By the sword.

Anyhow, my loss can be your gain.

So:

We use Unity Pro. (This is such a good deal. You get so much: static batching - i.e. much faster render times; postprocessing effects; and more, all for $1500 / person. Even if you're just a hobbyist it seems worth it - hobbyist photographers spend more on their camera equipment, yeah?)

We use Edit->Project Settings->Editor->Mode->Meta Files and Asset Serialization->Force Text. This means we don't have to lock our prefabs. Our experiments with simultaneously editing prefabs on separate machines turned out great. 

We put the RespectReadonly.cs file (below) in our Assets/Editor directory. That makes it go.

We use Unfuddle hosting and SVN. (We tried Assembla and Perforce, which was a tooth-grinding ordeal, and Assembla and SVN, which kept disconnecting in the middle of large checkins.) Under a gig Unfuddle is free, although we expect to hit that ceiling soon, and it almost never makes you have to think.

Because we've set External Source Control, we don't need to check in the Library directory. And none of the individual files (.sln, assemblies, etc) in the root directory need to be in source control - they get generated by Unity if needed. 

So it helps to figure out how to ignore files with SVN. It's kind of tricky with vanilla command-line SVN, but SmartSVN on the Mac and TortoiseSVN on Windows have some built in extra stuff that makes it easier. (On SmartSVN you can right click on a folder and go to Properties->Ignore Patterns and ignore things like LightMap*, Library and .DS_Store. TortoiseSVN has tsvn:needs-lock.) We also don't bother adding the LightMap files. These are things we'll generate on a more as needed basis, and don't want to use up the depot space with them. 

We set svn:needslock on our .Unity and binary files (.fbx, .dae, .jpg, etc). SmartSVN makes this easy - in Project->Settings->Locks set "needs lock" for binary files, and make Binary Files include *.Unity.

And then we could add and commit our files. (With SmartSVN, if you've forgotten to set "needs-lock", it's pretty easy to set a bunch of files en masse: set it to show files from subdirectories and filter on the extension you're looking for, select all, and set it.)

And once it was all in there, the hard part was over. We can now get the latest revision and work on things in Unity. If we're changing scene files and binary assets, we also Lock them so nobody else is working on them at the same time. 

Even if we both need to work in the same scene at the same time, it's doable as long as one of us is only changing prefabs.

Hope this helps other people, so they don't waste as much time as I do. Good luck! And if you have any questions I'm happy to answer.

Side Note: Why Not GIT or Mercurial?

You may ask, "Hey, Jamie, why not use the new hotness?" I used Mercurial for sixty second shooter, and appreciate it, but (so far) GIT and Mercurial are not intended for file-locking, and file-locking is the number one reason I want source control right now.

Having a history of changes is nice. Being able to make tinier commits to a local repository that I then push to the master server would be nice, but is pretty far down on my priority list. Preventing Paul and myself from accidentally working on the same scene file simultaneously is huge.

Screenshot Saturday: Am I Getting Too Old For This?

So Paul mades these new cranes.

They've got the highest vertex density of anything in the game by a long shot. The old-timer in me got scared when Unity complained about them being over 60K verts and split them up, but they fit into just 3 draw calls (maybe less, it's possible the static batching sews them right back up again) and the impact on framerate was unnoticeable. I wonder if that's a liability of being an old developer: I just don't realize what's truly possible anymore, while kids these days get to throw verts at the screen with reckless abandon. Anyhow, stoked about these!

Why Am I So Angry? Assembla And Perforce

I have a big problem with holding grudges. Particularly when it comes to companies. I never want to do business with Bank of America, Creative Labs, The Game Crafter, or HP again. (Of course, I probably own stock in BofA and HP thanks to mutual funds, etc. The irony.)

Turns out that holding grudges is an unhappiness habit. It's spelled out in detail in The How Of Happiness. And they have a trick for dealing with it - you write a letter of forgiveness. You don't send it, you just write it.

It mostly works. As a grudge resurfaces, sending waves out over the surface of my mind, I remember, "Hey, I already forgave them for that." And then I can move on and think of something else. (But as the years pass, I find I may need to write another letter ... if the grudge is buried deep.)

Well, I've been in a crap mood this afternoon after dealing with Assembla and their support team and what probably to most people seem like a few innocuous e-mails. So I guess it's time to write another letter.

 

Dear Ginger,

I forgive you. Although I honestly was just trying to provide helpful feedback on your company's services, maybe I came on too strong, maybe there was some miscommunication, or maybe you were having a bad day, so it's understandable that you wouldn't read my e-mails very carefully; it's understandable that you'd remind me that I'm not entitled to any support at all as a free user; it's understandable that you'd tell me 'we can’t spend any more time helping you at this point'; I can almost even understand why you'd close all my help tickets, the ones you previously asked me to open, and marked them as 'resolved' ... perhaps you think I'm just another entitled internet troll, trying to waste your company's time and money, for fun, inventing problems where there are none.

Again, I honestly was trying to be helpful by taking the time to write up those help ticket reports about problems that I'd already worked around, and was only bringing them to your attention so future customers wouldn't suffer as I had; and by taking the time to demonstrate my issues (with a screenshot, even!)

Still, nobody enjoys negative feedback, no matter how valuable it is. Even if you're just an employee of the company that's receiving the feedback, who likes to hear the company they work for devalued? That's loyalty, and I appreciate that. 

And I forgive the whole Assembla company, as well - although they claim to have 'Outstanding Support' and from my perspective that doesn't seem to be the case, it's possible that I just got unlucky in the interactions I had with them, landing on ones who were not helpful and liked to remind me that my problems could be 'user error'.

And I forgive the Assembla company for having bad documentation. I suspect you're not getting any clients for the service, and the ones you are getting are probably running up your server costs as fast as they're bringing in revenue - if they're bringing in revenue at all, and not freeloading like I hoped to do. I suppose I could argue that if you had good documentation and friendly customer support, then I might have been converted to a paying customer and had nice things to say on my blog about you, which might have gotten you more paying customers, but that's a lottery ticket, yeah? And with server costs being so high, you might not want those customers anyway.

So. It all makes sense, and I don't know why I'm dwelling on it. Maybe it's because I had to spend two days trying to get your service to work and I'm harboring resentment over that, but who knows.

Okay, so this sounds sarcastic, but I am trying to genuinely believe what I say here. Hopefully it'll work and I'll stop dwelling and move on. It really was a pretty innocuous series of e-mail exchanges. I am probably just overly sensitive. I forgive you. I forgive you. I will try to think no more on it.

Take care,

Jamie

Message from Perforce Visual Client - client 'yourclient' has no root usable from host 'yourhost'

Public service announcement!

Since Googling has helped me not at all with this one, I'll report on my findings. I think I know what it means. You get it if you log into Perforce, browse for a workspace, and then pick a workspace from a different machine than you're currently on. You might need to create your own workspace. And it's a good sign, because at least it means you've succesfully connected to the server. Much better than the 'partner exited unexpectedly' or 'unable to create workspace' messages, which probably mean you're not connected at all.

Migrating to Unity 4 Mecanim

Mecanim does some things I really like:

• Makes it scary easy to retarget animations to different models.
  With Unity 3, I did a lot of my work with the stock character Unity came with, and then when I wanted to use a new character, I had to use all new animations. With Mecanim that isn't a problem, you can simply retarget them. Even though Mixamo claimed their animations didn't work with Mecanim, I didn't have a problem - simply opened them up, selected Rig, targeted humanoid, Apply, done. (EDIT: the Mixamo animations I downloaded from the Asset Store as part of the Action Hero Motion Pack worked, but the ones I get from the Mixamo Store don't. :(  Good to know...and you can still get working ones from their website.)
• Lets you chop up your animations, set their loop and pivot points from inside the Unity editor.
  In Unity 3, I had to take my jump animation, note at what times in the animation the transitions I cared about happened (crouch to leap; going up to falling down; hitting the ground...), and hardcode that into the script. Plus now you can just click a button and moves the pivot to their feet - which is where I almost always want it.
  With Mecanim I just sliced it up into separate clips.
• And the demo has some nice smooth run and idle clips that I like better than the ones I was using. (There were some missing frames in my run. Did anybody notice?) I simply retargeted to my character and they're mine now.

What I don't like so much is the animation state machine I had to create.

Apparently, this will be fixed in a later update - you can't really use Any State as it stands right now, so I've got this mess of transitions of, well, just about any state to any other state, because it's easy to go from jumping to flying - to running (on a wall) - to crouch-running - but then you might stop and just be crouching - and so on.

AFAICT, you can't use mecanim clips in the legacy animation system. So I couldn't just take the new smooth retargeted clips and replace my old animations with them.

And there's still some bugs in my spaghetti system. Surprise. The joys of stateful programming - there's a state in the code representing the character's, well, state, and a state in the animation system, and communicating back and forth provides plenty of opportunities for screwups.

The code, in theory, can tell what state the animation is in with something like this:

if( swingAnim.IsInTransition(0))
{
    AnimatorStateInfo asi = swingAnim.GetNextAnimatorStateInfo(0);

    // do NOT forget the space in Base Layer. (I did.) 
    int jumpFlyHash = Animator.StringToHash( "Base Layer.JumpFly" );
    if( asi.nameHash == jumpFlyHash )
    {
        lastJumpUpTime = Time.time;
    }
}

But I was seeing mysterious delays when I used that method to trigger state changes that I never figured out.

One last plus, though - is being able to look at the state graph while the game is running is a pretty cool way to visually debug. You can't do that with Unity 3. Very cool.

Here's what I've done so far:

 

Unity Mecanim And You

Trying out Unity's new Mecanim animation system? Seeing an annoying jitter on your character, like they're flipping between two frames? Put your camera code in FixedUpdate instead of Update or LateUpdate. Took me all day to figure that out. If game development was like this every day I'd quit.

Unity Editor Script For Replacing Shaders

We're still casting about for a consistent look for Energy Hook - one that's inexpensive but cool. I've been leaning towards fairly flat-shaded on most things because flat-shaded has a "I meant to do that" sort of look to it - where if you texture then you can easily have inconsistent or insufficient texel density or inconsistent art styles on the different textures -  but it's probably too abstract. More surface detail looks like we're giving it more care and helps with the sensation of motion - when you're running along a flat-shaded floor it's kind of hard to tell how fast you're moving.

So here's some before and after from what I've done this weekend. These beige tiled buildings will probably go away soon anyway, but in the meantime...

Before.

After.

Which one do you like better?

Playing around with the look has meant changing shaders on a bunch of materials at the same time, and I made life easier on myself with this editor script, which takes all the shaders of a given name in the scene and changes them to another. 

/*
This file is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to 
*/
using UnityEngine;

using UnityEditor;

using System.Collections;

// ReplaceShader 

 

public class ReplaceShader : ScriptableWizard
{

	public Shader oldShader;
	public Shader newShader;
	
	[MenuItem("Custom/Replace Shader")]

	static void CreateWizard ()
	{

		ScriptableWizard .DisplayWizard  ("Replace Shader", "ReplaceShader");


	}

	void OnWizardCreate ()
	{

		//Transform[] Replaces;

		//Replaces = Replace.GetComponentsInChildren();
		Renderer[] renderers = GameObject.FindSceneObjectsOfType (typeof(Renderer)) as Renderer[];
		foreach (var renderer in renderers) {
			foreach (Material m in renderer.sharedMaterials) {
				if (m.shader == oldShader) {
					m.shader = newShader;
					Debug.Log (m.name);
				}
			}

		}
		  

	}

 

}

Call it "ReplaceShader.cs", put it in your \Assets\Editor folder, and use at your own risk - back up your stuff first. It'll mess up all your materials just like magic.

PlayStation Mobile Development Tip: How To Do Text

(I said I'd write fewer 'stupid programming tricks' articles, but that didn't mean I'd stop completely. )

I was asked about getting started with PlayStation Mobile. They've already beaten me to it at Games From Scratch, and I used some of their tutorials to get up-and-running. Nice work over there.

The biggest tip I could give right now - I've tried three different ways to render text on the Vita with PSM: UIComposer, emulating some of their demos, and using the FontMap stuff from their GameEngine2D. UIComposer was unusably slow - it may be fine for a front end but not an in-game HUD. Some of their demos render text - apparently on the CPU - to a texture, then render that texture to the screen. Better, because you can cache what you're doing, but still not great. The fastest result was the FontMap. Even if you weren't planning on using their 2D engine (I wasn't, since this is a port of sixty second shooter we're talking about) it's probably worth using it just as a quick way to get fonts in your game that run quite fast ... and some UI sprites.

You can use the 2D engine on top of the 3D easily, by setting it to update manually and setting the scene to not clear. There's some sample code here. I've ended up using the 2D engine for my entire UI.

The problem with FontMap right now seems to be the font is packed a little tightly in its bitmap, and depending on your choice of font size and rendering size you can see bleed from one glyph into the next. Messing with sizes let me work around that.

(Update 8/31/12:) Also - be sure to use the Label() class to draw your fonts, rather than the DrawTextWithFontMap, which currently can make the text appear squished. 

(Update 9/1/12:) Also - your font may appear fine on some resolution devices but on others show the glyph-bleed. Messing around with the FontMap size and width can fix that. Your font may appear fine with half the width - mine did.

 

Action Tweens - What do you think?

So I'm looking at Playstation Suite which has a 2D Game Engine high-level library which seems cool because it includes a particle system - and the samples seem fairly slick - which is a cousin of Cocos2d. I've never used Cocos2d, but looking at both of these libraries I'm leery. Maybe somebody can explain why Cocos2d is a good thing.

My main worry is with the Actions that help you tween your sprites. On the surface it seems really cool - "Hey, with one line of code I can make this thing move beautifully from point A to point B." But the FP fan in me is like, woah, that seems really stateful. Seems like you're taking one of my least favorite kinds of bugs, the curtain problem, and making it an idiom. I'm imagining the fairly complex logic that might be operating on my sprites and thinking that these fire-and-forget tweens are not a good way to try to describe it.

So maybe some of you have worked with Cocos2d and love the tweens and are like, "Nope, state issues have never been a problem, because..." Let me know.

(Another thing I'm not crazy about is the way it mixes game mechanical state with rendering state. It looks like you're expected to subclass your game objects from the rendering objects. I like to keep mechanics separate from rendering if I can, something I did with sixty second shooter and the Richard Garfield game that we never got funded - I like my games to have a sort of document-view model, partly to ease porting and partly because it's just pretty. But I know that's my own weird thing. And why do I want a scene graph for 2d?)

All that said, it still might be worth going this route for the free particle system. I don't *have* to use the tweens. Or can anybody recommend a free particle system?