pixelminerXNA:

It would be nice if someone from the development team could shed some light on this situation...

Stay tuned, I'm trying to find someone at Zepetto, who built this game for us, to get on to the forums to help answer some of these questions...

Okay.  Made a little bit of progress.  Take a look:

The oh so obviously broken model in the upper part of the screen was a fresh export from 3DS Max with bones recreated with character studio biped.  I can understand the overall scale difference since it may have changed when I first imported the FBX file in to Max but I'm not sure why body parts are floating separately like this.  It's in the animation maybe?  Or the parts are being scaled for some reason.  I donno... (BTW, I'm pretty sure the broken model above is smaller then the non-broken one because I made sure I walked right up to the non-broken one and the broken one came up a little bit above the waist line of the non-broken one.)

Anyway, I was able to get the newly exported FBX model in to the game without the "enum" calls that was giving me trouble last night by creating a new shader model processor and merging in some code from the ShipGame example to hook up the texture names from the material settings/slots which gets exported out in the FBX which the XNA FBX importer apparently parses correctly and passes useful information down the pipeline.  The trick was to strip the path in the material map slots in 3DS Max using the "Asset Tracking" window in 3DS Max so what gets passed is just the name of the texture.  I guess who ever worked on this didn't realize this and went out of their way to pass just the texture name in some funky way.  Although, since the geometry is mangled as is so I'm not 100% sure if the texture bindings are actually correct.  Eh...

I think what I'll try next is create a "blank" animation file with no transforms in the bones and replace all the .animation files with'em to see if that fixes anything.  Then, I may recreate the model in Max again by reimporting the original FBX but this time with matching scales.  Why can't we all just use centimeters, at least in 3D? :p

I fixed the part scaling issue!

The player model is still a little bit smaller for some reason but at least the pieces come in to scale now.  Maybe there is some scale factor that is inherent to the import/export process.

Anyway, fixing the piece scaling problem was actually rather simple.  It turns out 3DS Max's system units have to set to centimeters before importing the supplied FBX files and make sure the FBXs are exported in centimeters.  It seems as long as everything is centimeters to start with and stay that way to the end everything will be okay.  What tripped me up was that 3DS Max differentiates system units and display units I had to make sure to press the button at the top of the "Unit Setup" window.

But now there seems to be a different problem.  The model is very dark.  I suspect this may have something to do with specular maps so I'll have to play around with'em to see if I can get any response.  It also looks like the the back sides of the player characters which happen to be facing the player camera seems to be getting more lighting then the front side of the player model.  This is especially noticeable in the broken model because the front of it as seen in the second player view of the game is basically black.  I guess this means lighting on the player models are "fake" and have nothing to do with the level lighting.  I guess this makes sense since the shadow under the player model is obviously a textured plane.  LIghting on the player models don't change either when it's in shadow.

Just realized I was sort of wrong about the player model lighting.  Take a look at this image.

No, I didn't get four player working, although that would be awesome, and come to think of it, should be pretty straight forward.  Anyway, what you're seeing is basically two views of the two models, one on top is the one I just exported that's too dark.  You can see that in the pair of player views on the left the backs of the player models facing the camera are dark.  However, in the pair of player views on the right, the backs of the player model which is still facing us is brighter.  I basically turned the robot around 180 degrees and saw that the light changed as I turned in place.  My bad.

Alright!  I figured out why my model was so dark and fixed it.  Basically, the normal map and specular map wasn't getting hooked up during the build but I figured out how to hook them back up again.  Look!

The model in the first player view is the same model that was coming in very dark in my previous post.  You might think it's too bright now but if you look at the same model in the second player view you can tell the side opposite the bright side is actually dark.  Yeah! :)

The fix for this was so amazingly easy it's amazing that who ever created this in the first place went in circles to get the texture names out the way they did.  Basically, the reason why normal and specular textures weren't hooking up was because the material texture field names that gets spit out by the model processor wasn't jiving with their counterpart in the shader, in this case ShaderModelEffect.fx.

If you open up ShaderModelEffect.fx in a text editor, you'll see that it takes in "texture2D NormalMap" and "texture2D SpecularMap" before processing it as NormalMapSampler and SpecularMapSampler respectively.  Well, it turns out the material convert call at the end of ShaderModelProcessor is basically doing text matching so it's looking for texture2Ds with the same names as the ones in the .fx file, in this case "NormalMap" and "SpecularMap".  Unfortunately, it seems the XNA FBX importer has it's own way of labelling the different map slots in to the DOM which is correctly used in the shipgame model processor namely "Texture", "Bump0", "Specular0", and "Emissive0".  So, change "texture2D NormalMap" to"texture2D Bump0" and "texture2D SpecularMap" to"texture2D Specular0" in the .fx file and the material convertion call at the end of model processors will work properly without all this flipping ass over backwards to try and get the map slot names to match up with custom code and God knows what else the guy did in Max to get the text to come out...

Well, I guess it was a learning experience but man...  Really?  I swear, sometimes some people are too smart for their own good.  Anyway, now to move on to looking at the level geometry and going back to finishing the xml .animation file export script for 3DS Max.

I just finished writing an maxscript which exports out a custom animation I made with the model that was brought in to max in my previous posts.  The xml formatted .animation file seems to have gone through the pipe okay and even seems to apply to the model except this happens.

Yeah.  The player model here seems rotated 90 degrees in some funky order.  I suspect it may have something to do with whether my max file is Y-up or Z-up.  I usually work in Z-up so I guess now I'll switch to Y-up, re-rig the model and see if the animation exports out properly then.

Sure, I can spit out files that conforms to the .animation xml format which doesn't generate errors during compiles but as for running it properly, well...

It turns out XNA is Y-Up and 3DS Max is Z-Up so directly plugging in translation and rotation values from 3DS Max won't work.  And since there is no way to switch Max to Y-Up, I'm screwed.  I've tried some examples which supposedly translates from Y-Up coordinate space to Z-Up coordinate space but that didn't work either.  I think there is something fundamental about exporting bone animations I don't know about, makes sense since I've never done anything like this before, that is screwing things up on top of the Y-Up/Z-Up mismatch.  This does beg the question again about how the developers got their data over in to the game in the first place.  If they indeed used Max to create their content as all signs seem to point to then here is another head scratcher.  HOW DID THEY GET Z-UP ANIMATIONS IN TO A Y-UP GAME?!?!

I really don't want to b***h but I thought this thing was a starter kit.  Am I supposed to know the ins and outs of writing a 3D skeletal animation system in order to qualify as a beginner?!?

Anyway, I was planning on trying to get skinned models working in this kit at some point but it's looking like I should look in to it sooner then later.  It seems the skinned model example actually strips animations out of what the FBX importer puts in the DOM.  Maybe I'll learn something there which will allow me to fix the sad state of things now.

 

pixelminerXNA:

I really don't want to b***h but I thought this thing was a starter kit.  Am I supposed to know the ins and outs of writing a 3D skeletal animation system in order to qualify as a beginner?!?

Actually Robot Game was released as a mini-game, not a starter kit. We are trying to get the developers to answer questions for you but we haven't got that ready yet.

Jenkmeister:

Actually Robot Game was released as a mini-game, not a starter kit. We are trying to get the developers to answer questions for you but we haven't got that ready yet.

Oh, never mind then.

So, tried my hand at the skinning example and it was quite straight forward to get the animation into XNA as seen here:

It was almost too easy actually but the y-up vs z-up problems still persists as you can see the robot coming in laying down on its back.  At a glance it would seem it makes sense to rotate the model -90 in X inside XNA.  I'll have to look into it.

Oh, yeah.  I also noticed that who ever made the RobotGame may have scaled the model before it shows up in the game because when I first brought this model in to the skinning sample it was TINY.  I had to blow it up 1000% before it looked the way it does now.  And looking at the camera clipping planes for both the RobotGame and skinning sample, they seem to be the same so a model which is tiny in one should be tiny in the other unless one was messed with and the other was not.

I was being stupid by not having the root of my model's skeleton be at the root level of the scene in 3DS Max.  Anyway, I fixed it and the skinning example works fine now.

He's doing a little jumping jack type of motion hence the arms going up.  Now to try and get this to hook up in robot game!  I'll probably hit some other wall but oh,well...

While trying to figure out how I'm going to go about integrating the skinned model example to the RobotGame in general, I stumbled across an excellent set of tutorials which gave me a very good overview of XNA by building up an app from scratch!  Find them here:

http://www.thehazymind.com/category/xna/

You can also find the source code shown in the example here:

http://code.google.com/p/hmengine-xna/source/browse

Check it out!

...aka I got skinning sample rolled in to the engine I was able to write from the ground up by following the excellent tutorials I mentioned in my last post!

Granted, I could have copied and pasted the code from the tutorials, it's even available to check out via SVN, but I didn't.  I followed the 8 really concise tutorials and it let me wrap my head around how to do this XNA thing!  I think it's now time to go back to RobotGame and start figuring out how I can merge its functionality in to the engine I'm extending now which is really nicely structured.  Can't wait!

btw, the image's colors are inverted because the engine from the tutorials actually has a simple post processor built in to it which the latest tutorial actually shows you how to write.  Check it out!  I swear, the XNA team should get the guy who wrote the tutorials at http://www.thehazymind.com/ and get him to write tutorials for the official site!  He's awesome!

Jenkmeister:

There is nothing to be fixed. Premium content is a paid thing.

Well, there you have it, the official word.  Anyway, before this degenerates further in to a discussion which I'm frankly not interested in at all since I paid my $100, thank you very much... (NightMarez man, chill out.) [Mod: off topic discussion moved to another thread]

So while I was trying to decipher the animation code in RobotGame, I some how followed the web of classes, and the web is pretty thick btw, to the class that handles the game levels contained within "GameLevel.cs".  And while looking through the code I realized that who ever wrote it was doing something which doesn't quite make sense to me and I figured some of you more programmer types may be able to shed some light on it.  The situation goes like this.

First, a "GameLevelInfo" class object "levelInfo" is created inside the "GameLevel" class as a field as shown below.  (Notice, GameLevelInfo is not explicitly set to private)

Then, a public property for the field is created thusly.

That's all find and dandy but here is where it gets confusing for me.

See how he/she is using "levelInfo.WeaponInLevelList" in the if() statement but then uses "Info.GamePlayType" in the switch() statement?  Why?  Is there some reason why the field is looked at directly in one call but a public property is used to to look at a different member of what as far as I can tell is the same object?  Is this just a coding style thing?  Is it just because?  I mean, Info.GamePlayType should be the same as levelInfo.GamePlayType, right?

pixelminerXNA:

First, a "GameLevelInfo" class object "levelInfo" is created inside the "GameLevel" class as a field as shown below.  (Notice, GameLevelInfo is not explicitly set to private)

 Fields (member variables) in classes are automatically considered private in C#, C++, C, and other languages.  It's considered good public coding form to make that explicit by specifying the private modifier, but it's not a hard rule.  Most of our samples specify "private", but some do not.

 

pixelminerXNA:

Then, a public property for the field is created thusly.

This is a very common access pattern for C#, as properties can be referenced like fields by code that uses this object, and the property can take arbitrary action when retrieved or assigned to.  This creates a level of abstraction in case the internal implementation of retrieval and modification needs to change later. 

 

Public fields in a class allows others to take arbitrary action, which you usually don't want.  In this case, the accessor (get) is implemented, but the modifier (set) is not.  GameLevel code can set the value of levelInfo, and external code can retrieve that value, but it can't assign a new GameLevelInfo object into a GameLevel object.  This is such a common pattern, in fact, that Visual Studio 2005 (and 2008) have code snippets for you to write this quickly.  In the code editor, try typing "prop" (without the quotes) or "propg" and hit TAB.  You'll be automatically filling out a field-and-property pair.  :)

 

pixelminerXNA:

See how he/she is using "levelInfo.WeaponInLevelList" in the if() statement but then uses "Info.GamePlayType" in the switch() statement?  Why?  Is there some reason why the field is looked at directly in one call but a public property is used to to look at a different member of what as far as I can tell is the same object?  Is this just a coding style thing?  Is it just because?  I mean, Info.GamePlayType should be the same as levelInfo.GamePlayType, right?

Generally, internal class code should consume the same interface as external code, unless there's a good reason not to, typically performance or data access.  It's a public coding guideline, but it may not be caught everywhere. 

 

Note:  properties may not be inlined by the C# compiler, even simple ones like this, so it sometimes makes sense to avoid a property accessor inside a high-frequency loop (something that's called many times every frame), as the overhead can build up to something significant.  The code in the loop in this example is following this pattern somewhat, but it's not really necessary.  If I remember correctly, this is not a high-performance loop - it only runs on level load, not every frame.

 

GoDFaDDa:

Note:  properties may not be inlined by the C# compiler, even simple ones like this, so it sometimes makes sense to avoid a property accessor inside a high-frequency loop (something that's called many times every frame), as the overhead can build up to something significant.  The code in the loop in this example is following this pattern somewhat, but it's not really necessary.  If I remember correctly, this is not a high-performance loop - it only runs on level load, not every frame.

Thanks a lot GoDFaDDA!  I'll have to remember the bit about not using property accessors in high-frequency loops. :)

I got four player multiplayer working!

The code was a bit messy to wade through but it was totally worth it!  Notice the changed lighting and the background as well.  Good to go there.  The frame rate is a bit low but that's because the level model is totally over loaded with geometry I still haven't gotten around to deleting yet. (I was testing how many polys I can make the level out of before the game chokes.  Turns out it's possible to get 30+ fps out of a 360 with almost 100,000 polys in the level for a single player game.  One would never want to use that much though.)

Anyway, all in all this was a great learning experience.  Much thanks to the Microsoft team for putting up such an informative example.  I still have some more stuff to try and implement like custom weapons and such but I feel confindent that I can start thinking about a game of my own to submit to the community.  Who knows?  Maybe I'll make some lunch money after all! :D

I recently downloaded this minigame and then started reading this thread. I'm also looking for a good starting point for a game, and thought this might be it but then I noticed the animations were in separate files in a XML format. Looking at the developers website, I suspect they have some tool that does the stripping that they probably won't be able to share. However, we already have most (not all) of the information we need anyway.

 

If you notice, the AnimationSequence object is serializable (that's how they read it in). So I started writing a simple program to use the FBXImporter supplied by XNA to read in an FBX file and then I parsed the BoneContent node to pull out the data and move it into a game object, which I then serialized out in to a file. It results in a file that is in the correct format and it looks right, but something is missing. I was able to get the dude.fbx from the skinning example loaded in the game by deriving my own GameEnemy and pointing it to his assests (dude.fbx and WalkForward.Animation that I extracted with my program). He is in the game but he wasn't animating and he is also the relative size of a sky scraper in their world. :( I did step through the animation code and it is finding all of the keyframes, pulling out the bone transforms and applying them but the guy doesn't seem to move. I'm going to look at it further, but I wanted to pass along some of the things I found and maybe someone smarter than me (or at least with more time) can take this little bit of info and run with it.

 

Here is the code I wrote to move data from the fbx import to the game structure and then the simple serialzation chunk:

pixelminerXNA:

...aka I got skinning sample rolled in to the engine I was able to write from the ground up by following the excellent tutorials I mentioned in my last post!

So you have the same guy I was trying to get in the game working? I see your image, but it doesn't appear to be in the robot game so I'm curious if you're using the shader from the sample to animate the guy, or the animation system in the game.

McLovin, awesome work!  I was just getting ready to do something like this myself.  Thank you, thank you!

Yeah, so your guess about the shader is right.  Basically, the "skinning" example has a lot of misleading naming conventions where it fails to tell you that what it's calling "skinningData" isn't skinning data at all but actually bone data.  What does the skinning is actually in the SimpleSkinnedModel.fx file where blend indices and weight indices are passed in to the vertex shader, seemingly out of nowhere, and the "skinning" data passed into it is used as bones to transform the vertices.  At least that's how far I got last night before I decided I should get some z's.

I got that far last night because I was taking a second crack at getting skinned animations working and realized going through the "skinning" code that all the "skinningData" information was redoing the bone animation code that's already in RobotGame and for the worst.  RobotGame's bone system is able to blend between animations where as the one in the "skinning" example simply plays back animation clips which is no good for shooters.

My current theory is that simply placing a skinning enabled shader on a model which has blend and weight indices, which btw seems to be passed in by the FBX importer by default if they exist hence the "seemingly out of  nowhere" way they appear inside the .fx file.  I am going to test out this theory this morning and will be sure to post what I find out.  

McLovin,

btw, the reason why dude.fbx comes in HUGE is because he actually is huge in comparison to the models used in RobotGame by something like ten times.  Personally, I think it's the models in RobotGame that needs to be scaled up since they are something like 5cm tall if their FBX files are brought in to a modeling package.

So, if you're looking for a skinned model that'll look right inside RobotGame, you'll have to make one that's smaller or scale dude.fbx and re-export it out.

Still trying to get skinned models to show up but found something which might be a stumbling block for people just getting started on this.  Code follows:

The above is found in GameModels.cs.  Basically, unless a model has a custom rendering effect OR a BasicEffect placed on it, it won't render.  The confusion I ran in to with this was I replaced the shader on my player model with the skinning enabled effect then temporarily commented out the code attaching the normal maps stuff to players models because the custom effect call will try to pass arguments which does not exist in the skinning enabled effect causing an error.  The code to attach normal maps stuff is found in GamePlayer.cs as shown below:

If I comment the above lines out then my player model with skinning enabled effect won't render at all inside the game, all you see are two floating guns.  This is because at that point the player model has neither a custom effect nor a BasicEffect applied to it so it never gets drawn at all.  So, instead of commenting out the call to attach a custom rendering effect, I commented out what's inside the custom rendering effect temporarily so the player model will actually render inside the game.  Well, it renders but horribly broken so I won't upload that image just yet.  Soon, hopefully. :D

While I'm on the "mentioning what I found" kick, I should also mention that there is a small bug inside the weapon code which basically makes it possible for players to score multiple times by shooting an enemy player as their player models are going through its "dying" state.  I don't have the time to look for it now but it should be pretty obvious when you run in to it.  The trick of course is to simply encapsulate the offending code in an if statement which checks to see if the recepient of damage from the weapon is dead or not before passing it a message saying it's being hit.

I found a few bugs in the code I posted earlier. Basically the code is too rigid in where it expects to find animation data, but the concept of using the FBXImporter to load animations and serializing them out using their game classes is still sound. I actually figured this out while I was trying use a box I had animated that had no bones. The weird thing with the box is that it seemed to be shearing (it had translation and rotation), so I normalized the quaternion that was loaded and the shearing stopped and it almost looked like it was animated correctly. I don't think that is the right thing to do though, but I'm still looking into it.

Yup, still at it.

I did figure out it's possible to pass through bone information to a shader by expanding GameModel's RenderingCustomEffectEventArgs then adjusting calls to it accordingly.  However, I was still getting a "blank" model so, just to see if vertex information is being passed in, I commented out the skinning portion of the vertex shader.  That got the model to show up and even follow where the player model should be after I passed in the world matrix for the object but the model comes in face down on the ground instead of standing up on its feet.(Maybe I have rotation on the geometry inside 3DS Max?) 

Anyway, the guns, which are floating still, seems to be attached to where the hands would be and animated perfectly fine.  I guess something must be getting messed up in translation or maybe the "boneTransforms" I'm passing in has to be formatted in some way to make it work right with the skinning example shader.  If anybody has any ideas about why this might be I'd love to hear it...

pixelminerXNA:

That got the model to show up and even follow where the player model should be after I passed in the world matrix for the object but the model comes in face down on the ground instead of standing up on its feet.(Maybe I have rotation on the geometry inside 3DS Max?)

If you look in GameLevel.cs around line 945 in the function CreatePlayer, you will see:

            Matrix rot = Matrix.CreateRotationX(MathHelper.ToRadians(-90.0f));
            player.SetRootAxis(rot);

 
This is forcing the root orientation of the model to -90 degrees, which is probably affecting your model in a bad way. BTW, I'm actually not trying to override the player, but one I derived a new game enemy class and I'm replacing one of the spawned enemies. I noticed similar code for enemies in CreateSpawnEnemy that is rotating certain models in different directions. I actually put my own rotation values in for the UnitTypeId that I created so that my guy was oriented correctly.

I've also made a little more progress on exporting the animation files and getting a guy in the game that actually moves! I had an fbx from Maya and one from Max, and the Maya one doesn't want to work but the Max guy works... better. I'll have to check what got exported, but I see my guy (still 10 stories tall because I didn't get him scaled) and he is moving, but I see 2 meshes. One that is animating and one that is in the bind pose. I suspect it was just exported wrong, so I'll look at that tonight after work. I also noticed in the original files that they often optimize out keyframe data that doesn't change (that's what the fixedtranslation, fixedrotation stuff is for) and I don't do that yet. It shouldn't change the results, but it is data that is not needed and shouldn't be too difficult to optimize out. Once I get this thing working consistently, I'll post the code again.