How much of a 3D engine will be included in the XNA Framework?

How much of a 3D engine will be included in the XNA Framework?

• Joe Kehnast

  The Beta will consist of the Framework, XNA Game Studio Express (which runs on top of Visual C# Express) and a couple of VS templates to get you started. The most interessting thing will be most likely the included starter kit, which gives you a full game with source code and lets you see how things work. In the future there will be more starter kits and samples.
  
  Torque obviously isn't included and there is also no typical 3d engine in XNA like in real games. It will provide you with a solid foundation and some helper functionality to manage your content and assets. But basically you have to write the same kind of DirectX code like before, it just gets easier (for example windows creation, content management or if you can utlilize the helper classes).
  
  I guess a full blown 3d engine would be way to complex and every game needs other things and might have different approaches to similar techniques (like GUI, drawing lines, doing effects). As always it will be best to write your own engine on top of XNA and then let your game use that :)
  
  
  

• LouisVanAlphen

  The content pipeline does not include any kind of level editor functionality. It basically handles everything after the original content has been created in some other tool, right up to your game runtime. You can think of it as very roughly occupying the same space that D3DX was used for, but with a very different (and I think much more powerful) architecture.
  
  A lot of the underlying work we have been doing is to build infrastructure and set policy that can apply to any kind of content:
  

  • A mechanism for plugging in importer and content processor components
  • Mechanisms for serializing content to XML and binary formats
  • A generic ingame content loader that reads the binary serialized format
  • Incremental rebuilds, so only modified content needs to be processed each time
  • User interface hooking all this up to Visual Studio

  But we've also used this infrastructure to implement some more specific content types that will be available out of the box:
  

  • Importers for .X, .FBX, .TGA, .BMP, .DDS, .JPG, .FX, etc
  • A DOM (document object model) designed for storing graphics data (meshes, textures, animations) in a easily editable format
  • Some standard processors that do useful things to that DOM (generate mipmaps, convert texture formats, calculate tangent frames, optimize vertex cache ordering)
  • Processors and serializers that convert DOM format objects into Direct3D textures, vertex buffers, and our new Framework Model class

  So all this gives you a couple of options.
  
  Out of the box, you can just drop .X or .FBX files into Visual Studio, use just a single line of code to load them into your game, and get back a Model instance that you can render.
  
  But if you want to go beyond that, there's a lot of (I think very cool) infrastructure that you can use to add your own new data types, importers, processing behaviors, and so on.
  
  
  

• Ted.

  Thanks for the information.

  That of course leads me to wonder more about the content pipeline.

  Are we talking the content pipeline in the more narrow sense like Effects files, shaders, maya x-file exporters etc Or are we talking in more general terms like some kind of simple level editor etc.

  It would be really helpful with information on the following areas:

  - Scene graphs (didn't I mention that already :)

  - Content guide lines (poly count, different kind of effects that can be applied detail textures etc. and their implementation)

  - Tutotrials taken one step further than the six that are generally used in the DX SDK

  - For those not very well versed in 3D math a tutorial toolbox where you can test and see all the effects of changing values in a matrix, length of vectors. Sort of a math toy box.

  I am sure I will come to think of more when I have posted this.

  
  

• leclerc9

  User content isn't something we've spent a lot of time thinking about yet, so this is all off the top of my head, but I don't see any immediate reason why that shouldn't be doable. You'd probably want to package up the build operation in some other way than using C# Express, to give more a user facing "get my content reader" interface as opposed to the developer focused experience we are putting together inside Visual Studio. But that's just a matter of writing UI. The underlying work is all done by an MSBuild task called BuildAssets, so it's pretty easy to access this functionality from your own build scripts, or even programatically using the MSBuild API.
  
  
  

• georgeskada

  Thanks for the information. It's about what can be expected and a very good start.

  Additional question:

  I have little knowledge in the difference between managed and unmanaged code. When the C++ version will be available how much work is it to convert a current engine like Irrlicht or Ogre to an equivalent Managed one that one could use for your projects

  Thanks

  Joachim

  
  

• aghoneim

  We're not providing a 3D engine as part of the framework, but we are providing several things that point in that direction:
  

  • A much nicer effect API, along with our new Model class, makes it considerably easier to get graphics onto the screen.

  • The Content Pipeline takes care of a lot of the data conversion and preparation that would previously have needed to be handled by an engine.

  • Our starter kits are of course going to include more complete engine infrastructures, and they are shipped as source so you use their code if it meets your needs.

  • And of course there will be full engines available from Torque, and I would imagine from some of you guys in the community!

  So we're concentrating on underlying things like the Content Pipeline that will make it easier to write any kind of engine, but not actually writing an engine ourselves.
  
  
  

• joeycalisay

  Shawn Hargreaves wrote:

  We don't have an out-of-the-box packaging system for version 1, but would appreciate feedback if this is something you would find useful in future. To roll your own, you'd need to do two things. Write a build task to create the packages. This would probably be an MSBuild task, since the Content Pipeline is implemented inside MSBuild. You would call your custom task after the regular Content Pipeline one, so it could zip up all the Content Pipeline output files. Then at runtime, you'll have to write some code to read from the packages. This is as simple as deriving your own type from ContentManager, and overloading the virtual OpenStream method.

  I must say, I'm really impressed with what you guys have done; the process you've just outlined is pretty much ideal. If that's really all it takes, I wouldn't worry about it unless you're looking for something to do.

  I'm also curious if the content pipeline can be extended to support outside content added by users at release time. The design I've used in the past (although in C++) is actually almost identical code-wise to the example's you've shown; in operation, it initially loads the default package of assets, and then depending on what mods are applied, loads additional packages, some of which override the assets from the initial package. I'd like to know if this will be possible, as it really makes it easy for end users (the packaging/encryption of the default assets is for a similar reason: to keep users from naively corrupting their install, and more importantly, swamping me with support emails :).

  
  

• Tony Valenti

  exal wrote:

  Will it also read the skinning information and animate that according to set parameters or changes sent to the object Or do I have to write my own animator for that

  
  
  The Content Pipeline will import animation and skinning data from both X and FBX formats into our standard Content DOM format.
  
  Our runtime Model class will then convert this skinning data from the Content DOM, giving you an object that is set up ready to be rendered using skinning.
  
  The core framework doesn't include any types for actually playing back the animation data (we are still investigating exactly what people want here and what this should look like) but we will be including an example of this functionality as source code in one of the samples.
  
  
  

• CetinBasoz

  From what's been posted by the team it sounds like there will be a sample project that sets up a skeleton game that you fill in. I can almost guarantee that there won't be a full 3D engine that's part of GS. If you want that, look into TorqueX. You can start using Torque Game Builder now and port it to TorqueX once it's released.
  
  

• asfsdf

  That's excellent!

  I guess I have to do some of the programming myself :).

  Some nice to haves:

  - It would be great with a white paper regarding scen graphs and other structural information to help out with the implementation

  - Ways to switch between different shader models (Can HLSL interpret any kind of code and make it into 1.4 -> 3.0 depending on level set )

  Is there any speed tests made to compare the "normal" Unmanaged C++ apps and The XNA framework

  
  

• TimStspry

  We don't have an out-of-the-box packaging system for version 1, but would appreciate feedback if this is something you would find useful in future.
  
  To roll your own, you'd need to do two things.
  
  Write a build task to create the packages. This would probably be an MSBuild task, since the Content Pipeline is implemented inside MSBuild. You would call your custom task after the regular Content Pipeline one, so it could zip up all the Content Pipeline output files.
  
  Then at runtime, you'll have to write some code to read from the packages. This is as simple as deriving your own type from ContentManager, and overloading the virtual OpenStream method.
  
  
  

• jturpin

  exal wrote:

  - It would be great with a white paper regarding scen graphs and other structural information to help out with the implementation

  We have plans for a lot of white papers, and will be continually adding more after launch. A lot of the XNA team are also very interested in posting this sort of more overview documentation on blogs (for instance mine is http://blogs.msdn.com/shawnhar/). Let me know any topics that would be of particular interest - I'm probably mostly going to be talking about the Content Pipeline, but would be happy to write about anything that people are interested in!
  

  exal wrote:

  - Ways to switch between different shader models (Can HLSL interpret any kind of code and make it into 1.4 -> 3.0 depending on level set )

  
  

  Yes it can. You can write a single HLSL program, then compile it several times for different target profiles. Although obviously the compile will fail if you write a complex HLSL program that depends on advanced features or uses too many instructions, then try to build it for 1.1.
  

  You can also use the Effects system to manage these variances. Write a single effect that includes several techniques, with just one copy of the actual shader HLSL, but each technique compiling it for a different profile. Then at runtime you can just change the active technique based on what shader profile you want to use.
  

  You will often find that you don't actually need to do this, though. If it is possible to implement a rendering technique in shader 1.1 or 2.0, you might as well just always use that version of shader even if you are running on a PC that supports 3.0. There is rarely anything to be gained by recompiling it as a 3.0 shader, unless you actually need the full 3.0 feature set for that effect.
  

  exal wrote:

  Is there any speed tests made to compare the "normal" Unmanaged C++ apps and The XNA framework

  
  

  We don't have things finished enough to be doing proper apples to apples comparisons yet, but from what the Garage Games guys were saying at Gamefest, they reckon the C# port of Marble Blast Ultra (which was originally native C++) ran "very very close" (I forget the exact words they used) to the native performance. Like us they said they were too early to have exact figures (and they were also running on a debug alpha build of the XNA bits) but they mentioned being surprised by just how close the performance turned out to be.
  
  
  

• yanyee

  Aha ok. Great!

  Additional question there for me who is pretty lazy. As long as the .X file is readble. Will it also read the skinning information and animate that according to set parameters or changes sent to the object Or do I have to write my own animator for that

  
  

• Hanel O

  With regards to the content pipeline, will it be possible to extend it to package (and possibly encrypt) content, and if so, to what degree; write a single class, or rewrite a dozen
  
• How much of a 3D engine will be included in the XNA Framework?