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

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 :)

abi at 2007-8-30 >

• 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.

ShawnHargreaves at 2007-8-30 >

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?

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.

ShawnHargreaves at 2007-8-30 >

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.

ShawnHargreaves at 2007-8-30 >

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.

ShawnHargreaves at 2007-8-30 >

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.

ShawnHargreaves at 2007-8-30 >

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.

ShawnHargreaves at 2007-8-30 >