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.

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.

Explicit Run-Time Linking Library

As I’m continue to work on my long time project. The Ganbatte Engine. This engine is developed by me for my personal projects to get more experience with all the technology popular in the gaming industry that is freely available for personal use.

The Graphics System is actually powered by D3D10 but will change after the release of D3D11 to D3D11. Since D3D11 is based on the D3D10 API it will be very easy to switch, D3D11 will also run on D3D10 hardware.

To make all the different components of the engine more independent I choose to go the way of Explicit run-time linking. So I can change the implementation of a System without having to recompile the application using it.

To make the process a little bit more streamlined and object-orientated(.Net really makes you an object beast ) I developed the small ExplicitRunTimeLinkingLibrary. The library is only one class actually.

As you can see this class is really simple.
Just 5 methods + con- /deconstructor.

The constructor takes just the name of the dll we want to get the function pointer from.

Load()
Loads the dll, returns false if something failed.

Unload()

Unloads the dll, returns false if something failed

GetFunction<T>(string functionName, T* function)
This method is most important function of the class. This method takes a name containing the name of the function we want to get the pointer to.
T* is a pointer to an object of the function signature described through a typedef.
Returns false if something failed.

GetErrorStack()
Returns an std:stack<wstring> data structure containing all the errors.
As you can see the function doesn’t return any information about what failed this information is available here.

Example:

typedef bool (*importGraphicsDeviceFunction)(IGraphicsDevice** device);

DllReflector graphicsDll(L"D3D10GraphicsSystem.dll");

graphicsDll.Load();

graphicsDll.GetFunction<importGraphicsDeviceFunction>("CreateDevice",&createGraphicsDevice);

 

As you can see very easy and straightforward.

download

ExplicitRunTimeLinkingLibrary by Jendrik Illner is licensed under a Creative Commons Attribution 3.0 United States License.