Getting 3D Model data in my engine, Part 2

As told in part1 I’ve written an exporter based on the “Sample Content Exporter” from the DirectX March SDK.

The process of getting the 3D model data into my engine now works as following. My 3D Content gets created in any tool which supports exporting to  .fbx, .3ds, .obj or even .collada. Most tools support one or more formats of these. So the import site of the project is really great and supports major file formats supported by major tools.

The 3d data now gets imported into the “Sample Content Exporter”. This is using the Autodesk SDK. It was actually written for the FBX SDK 2009.1 but it’s working without any problems using the new 2010.0 version.
The intermediate format used is easy to export, most data is already in game ready form so it just has to be exported.

The export formats supported by the tool, as found in the DirectX SDK, just supports .xatg(used by the XBoxSDK samples) and .sdkmesh(this is used by the windows samples).
So all the infrastructure for exporting meshes is already in place and the code designed for exporting content.

So I started writing an exporter for my own model format, and it really work great. But it’s not perfect yet. The exporting of the actual mesh data is working currently but exporting of textures doesn’t work yet, but I’ll try to add this tomorrow. But as I’m the only one using this exporter in the moment this is not such an big problems. Because my format is designed to be easy editable by hand, so I can fix such problems really quick.

 

This is the test model I used for testing my exporter while developing it. As XNA developer you may noticed it already,  it’s the rocket from the XNA SpaceWar Starter kit. Content that worked in xna, which also uses the FBX SDK for importing, will also work and can be exported to my own custom format.

 

 

In the next post I ‘want to talk a little bit about how the “jenmodel” format is designed, what is supported currently and what makes it different from other formats, already existing.

New ConstantBuffer System

Since the last time I’ve done a lot of changes to my D3D11 Game Framework. I completely reworked my GraphicsSystem. The GraphicsCoreSystem is now gone,  this means not every call to the GraphicsSystem is a virtual method call, any longer.

I had implemented this CoreSystem to make it more platform independent. But I changed my mind, I don’t think that I will use this Framework on any different platform then Windows Vista or Windows 7. These OS both support D3D11 so I will not try to use this framework on XP or any other Platform.

I also switched the SDK Version from November to March, without the need for any changes in code. This also has changed since D3D9, fortunately:)
I also moved my Math Code from D3DX Math to XNA-Math, which was added in the November SDK.

 

But now to the new D3D11 Constant Buffer System, I implemented. The sample way(shown in the Samples of the D3D11 SDK) is to have one struct for each ConstantBuffer. This was also the way I had implemented it. But this doesn’t work when loading shaders dynamically, because at compile time we don’t know anything about the ConstantBuffers the Shaders will be using.

So I started to design a system, which I got working so far. I think it is a good starting point and new features can be implemented on top of it. So lets have a look how it works.

The System now is divided into 3 classes.

• ConstantBufferBuilder
• ConstantBuffer
• ConstantBufferElement

Before we start talking about the system, lets have a look at all the Code involved, as it’s easier to understand having seen the code.

GanbatteEngine::Graphics::ConstantBufferBuilder builder2(L"VSPerPassCB",L"PerPass");

builder2.Add<XMMATRIX>(L"View");

builder2.Add<XMMATRIX>(L"Projection");

graphicsDevice->CreateConstantBuffer(builder,&VSPerPassCB);

ConstantBufferElement* element = VSPerPassCB->GetElementByName(L"View");

element->SetDataSourcePtr(&view);

renderingContext->UpdateConstantBuffer(VSPerPassCB);

renderingContext->SetConstantBuffer(0,VSPerPassCB,VertexShaderStageBind | PixelShaderStageBind);

This is all the code necessary to create and use ConstantBuffers.

Firstly we create a ConstantBufferBuilder. Like the name says already it’s only purpose is to build ConstantBuffers. It takes the name of the ConstantBuffer and the frequency of updates for this buffer.

The creation of a ConstantBuffer was moved into the Builder because a ConstantBuffer is not allowed to change after it was created. To make it easier to create the ConstantBuffers at runtime dynamically the Builder was introduced.

To create a ConstantBuffer we just call “CreateConstantBuffer” and pass the builder into it.

After the ConstantBuffer is created we can get access to every element in the buffer by its name.

When we have the “ConstantBufferElement” we can just set the pointer on the data for this element. This currently is just working on void* pointers, so we are not typesafe in this place. Maybe I will change it at someday, to make it typesafe.

Now we have just 2 methods left, the first is “UpdateConstantBuffer” we just call it passing in the ConstantBuffer. This will copy the data of the ConstantBuffer into GPU memory.

And of course “SetConstantBuffer”, this will set the ConstantBuffer on the rendering context. We call the method with the input Slot(it will be set it on this slot), the ConstantBuffer to set and we define on which ShaderStage the ConstantBuffer will be set. Every ShaderShader Stage which is accessing the ConstantBuffer elements, needs the  ConstantBuffer bound to it.

As you can see the system is quite simple but also powerful. I really like it. So lets get on improving the other parts of the EffectFramework.

DirectX SDK March 2009

Mirosoft finally released a new DX SDK, the March 2009 version this time.March 2009 DirectX SDK

New stuff for D3D11:

The Multithreaded Rendering sample got an update and now shows something more interesting than the good old “tiny” in 3 mirrors: below you can see the updated sample.

SubD11 Sample was updated, the clown is gone as announced at the talk at the gamefest 2008.

But sadly there is no FX Framework for D3D11 in this release, so I can work on my own system without having to deal with the feeling that I’m reinventing the wheel:)

XNA Math

XNA Math was added to the SDK, this provides a cross-platform math solution for both XBox360 and PC taking advance of the underlying support for SIMD. This is supported for all platforms but also a fallback for platforms not supporting SIMD instruction is in the package.

The sample for XNA Math, contained in the SDK, shows XNAMath being used for Collision detection. It contains a lot of useful function.

XNA Math really looks great, especially it’s implemented in one header(xnamath.h) only and because of that we have full access to the source and it’s heavily inlining the operations. A big advantage over the D3DX math libraries which were closed and compiled into libs.

Samples Content Exporter

The Samples Content Exporter is really a cool tool which is new to this version of the SDK. It has the ability to import .fbx an other file formats, which are supported through the Autodesk FBX SDK, and export the scenes to .xatg(used for the XBox 360 Samples) or to .sdkmesh (used for the windows samples).

But a warning, this tool was developed for internal use, to help with the sample development. But because it could be interesting for other developer as well, it was released to the public. Therefore it’s not officially supported, in terms of new features or fixing of existing bugs.

But I think this is a great move to make it available. Especially using the Autodesk SDK it is using a great technology in the back for importing, this should it make a lot easier to load scenes into D3D. I will have a look at it tomorrow.

 

There are a lot of other changes and improvements I can’t talk about in this post. So have a look at the SDK on your own.

Something more

• Technical Previews of Direct2D, DirectWrite, and DXGI 1.1
• Introducing XNA Math
• Audio Improvements
• Improvements to PIX
• Updated Game Explorer Tools, Samples and Documentation
• New and Updated Samples

Ganbatte Engine Progress Report 2

Some more progress in the development of the GanabatteEngine. Since the last post I got Texturing and DepthBuffer support added into the engine.

The Core Layer gets more and more features, now it finally has all the features so I can start working on the next level of functionality. The next feature I will look start implementing is Model support. 

Before I will begin implementing the model class I will have a look at the different available Importers, especially into Assimp.
Assimp is short for Open Asset Import Library and the name describes it really well. It currently contains importers for 26 different Model Formats including Collada. I will especially look at the Collada support because it gets widely adopted by a lot of tools and I know how hard it is to write an importer for it (I’ve written one for use with an XNA application…).

So lets see how well it will play out.

Stay tuned.

Ganbatte Engine Progress Report 1

After a long time it’s finally time again to write about the great progress I made with the development of my Engine. As written in some post before I’m working on an Engine called Ganbatte Engine.

Ganbatte is an Japanese word and means something like “do your best”, that’s exactly what I’m trying with this really large, long-term project.

But now lets talk about the technical site of the project.

As you can see from the diagram above the project is quite complex right now.

The GanbatteEngine instance contains the PluginManager. It’s up to the Plugin Manager to load the implementation of the different system at runtime. The [..]CoreSystems define just the interfaces to use the functionality but doesn’t contains the actual functionality.

The Implementation gets loaded at runtime. Everything in the diagram shown in blue is the actual implementation of the CoreSystem it belongs to. Because of the way I choose to organize it’s easy to change the Implementation or add new System without the need to Recompile the engine which is just using the Interface which are defined in the [..]CoreSystem.

What is done?

That’s a good question and the most important.

Everything you can see in the diagram is actually implemented. Only the GraphicsSystem is in Progress in the moment.

The pluginSystem is the current core of the engine, because from the begging on my plan was to make the Engine less aware of the actual implementation of the systems.
In think this decision and the time I spend to implement the system and the abstraction will pay back at some point. Especially when developing a game based on the engine I always have the possibility to add different implementations for the UnitTests I’m doing. This makes it possible to use an empty GraphicsSystem so UnitTests can run actual game code without using GPU resources and the need to change any implementation code.

D3D11 Graphics System

As you can see from the picture below the GraphicsSystem is coming along quite nicely. The GraphicsSystem is implemented in D3D11, this means it’s running on TP (Technical Preview) software. D3D11 isn’t finally yet, because of this I have to implement a lot on my own, for example it not yet contains an Effect Framework, so I had to implement one on my own. This is the first time I have worked without the D3DX Effect Framework and now I know how great the Effect Framework is. It’s so much work to to write an Effect Framework. My system is quite simple because I only plan to use my effect framework until the D3DX Effect Framework for D3D11 gets released.

I currently doesn’t support the dynamic linkage feature of D3D11, sine this is dependent on the Hardware support and as we all now there is no D3D11 Hardware normal persons can buy. [at the moment]

Implemented are the following Features. I have support for the EffectFramework, Vertex- and Index- and Constant Buffers.

Win32 Window System

The Window System is complete and ready.

Input System

The Core part of the InputSystem is ready. As the System itself is divided in modules, every InputProvider. A InputProvider is responsible to query the States from the different InputDevices. Actually only one InputProvider is implemented, a DirectInput based Provider for Keyboard Input.

Log System

Currently only a very simple Log System is implemented. In some time I will replace it with a new threadsafe implementation but for the moment it’s enough.

ContentManager

The ContentManager Core System is implemented and two ContentLoaders are implemented. The ContentLoader are responsible for loading the file of a specific type. The decision which ContentLoader should be used is based on the file Extension. Every ContentLoader as to tell which extension it supports.

The implemented ContentLoaders are a FxLoader, it is responsible for loading Shaders from .fx files.
The DDSLoader task is to load DDS texture from the file.

Résumé

A lot is already done but much more is coming.
Some work has to go those “Low-Level” components before I can start implementing High-Level Components based on them. (SceneManager, Lightning-Systems, Shader-Management, Mesh-Support …. just to name some that have to deal with the Graphics portion of the engine)

Also missing is complete support for Audio which has to be added some time.

So a lot of work and time will be spend on this project in the future.