3 replies to this topic

[Deft]

Hello everyone!

I'm very new to GameDev and programming with DirectX. But my experience in programming languages isn't low.
However, learning DirectX/HLSL programming is hard way for me.
At now I can draw box with texture on it (just follow DirectX samples). But storing scene data inside code is harmful idea. =)

So, next step for me is using files (such as .x/.dds/3ds max and etc.) for importing data about textures, coords, models and animation.
I has spent much time in searching for information for newbies (in result has about 35 opened tabs in browser >_<): what file format to use at startup and how to import data from external resources (such as files). All what I found is that .x files are deprecated, .dds files contains only texture info, no animation and bone kinematics, 3ds max files are large for startup - too many info will take all my time to import it into application at now. Also I hear about .obj files, that 3ds max can import into that format, but has DirectX built-in functions to read such files? Or I need to write custom importer?

I'll be very grateful if anyone give me some information about it. I'm not interested in auto-import tools, I want to do it on my own

Sorry, if such question already in beginner area and sorry for my English.

[darookie]

Since you are not interested in pre-existing solutions, here's a path that might be worth exploring.
First you'll want to export your model data in a format that is well defined and -supported by the digital content creation tool of your choice. In other words, try to stay away from the tool's proprietary format and save your assets as COLLADA files for example.

Next you need to identify the exact data that you need to render your scene and specify the exact memory layout that your renderer requires (e.g. index data width, vertex format, texture format, etc.) and convert the COLLADA files to a binary package that can be processed by your renderer without any further pre-processing.
Ideally, you'll structure the binary data in such a way that the parameters to your CreateVertexBuffer or CreateTexture2D calls are actually stored directly in the data file.
Using an intermediate format such as COLLADA has the advantage of allowing you to tweak your actual converter while leaving the actual asset unchanged and relieves you from the burden of writing custom exporters for your content creation tools, which in addition to the time required to get used to the SDK, is just another potential source of errors.

However, being new to GameDev I would strongly suggest to use existing libraries and tools first. Trying to roll your own tool chain for asset processing shifts your focus from actually creating a game to creating tools which, depending on your goals, might just be in the way of actually finishing a game. There's nothing wrong with using .X files and all rendering packages that I'm aware of have exporters available. You'll have plenty of opportunities to to create your own tools after you gained some experience in actually creating games, but YMMV.

HTH

[Deft]

Thx for your advices, they just prove my latest research on how to use external data. Yeap, I understand differences between text & binary information in that case, that binary representation is mostly effective and files are much less in size.
I agree that creating import-tool is not so better choice to be involved into gamedev, thank you for link to Collada - I didn't know about it.
And as I understood, we don't have internal DirectX tools to import external data apart from .x files with using D3D9 deprecated functions (or writing own parser implementation)? Or may I miss some API? >_<

With regards.

[darookie]

Unfortunately most of the utility functions for loading models has been removed from later versions of the DirectX-SDK. The main reason is that developers tend to use their own model formats that best fit the requirements of their gfx engines, frameworks or digital content tool chains.
Internal tools have therefore been dropped due to lack of developer interest and conflicting requirements. A scene format like Adobe FBX for example might be rather feature complete and efficient for complete scenes, but is unsuitable for streaming data (like in large open world type games). Streaming data formats on the other hand depend on the target medium (SSD server disks vs. slow optical media on consoles, and so on) and the clustering of the data.

In short, there are a bunch of libraries and SDKs (like FBX mentioned above) that provide fairly complete access to model and scene data, but loading these formats directly using the Direct3D API is often unavailable, because the process depends on the architecture and implementation details of your rendering system. Thus, most implementations provide an abstraction layer that lets you access all aspects of the serialised data, but leave the rest to you.