• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

About this blog

My recent work and projects

Entries in this blog

in the last months I wrote an importer for the OpenGEX-asset-format in the Asset-Importer-Library. At the moment it supports:
I started to work on a simple OpenDDL-parser. This will be used in the Asset-Importer-Library for the OpenGEX-importer, which I am currently working on. You can find it here:

Why I started to work on a separate parser and didn't used the reference implementation coming from Eric Lengyel?

  • When working on the OpenGEX-importer I saw that a OpenDDL-parser would be a really useful tool
  • I wanted to have it on github ( for issue tracking releases etc. ).
  • For reproducing issues I wanted to have a automated test suite
  • The reference implementation coming from here http://openddl.org/ is good for readability and understandability, but I wanted to play around with it on my own just for fun

    I pre-released it as Alpha.
I am happy to announce the Asset Importer Library 3.1.1. release. You can find the source on github: https://github.com/assimp/assimp/releases/tag/v3.1.1

You can find the pre-compiled binaries and the current release notes at sourceforge: https://sourceforge.net/projects/assimp/ .

And you can find our changes here: https://github.com/assimp/assimp/blob/master/CHANGES

Thanks for all supporters including all your nice feedback, bugreports, pullrequests and all the other stuff you helped us the last years.
And sorry for the name assimp, we just recocnized how bad it sounds in english :-).

Just if anyone is interested in: I moved the ZFXCE2-repository from SourceForge to Github. You can find it here: https://github.com/kimkulling/zfxce2

I did some progress in the rendering system:

  • Currently the whole transformations a re done via registered transformations groups.
  • I also introduces a base scene-graph. Currently no culling is done.
  • I fought a lot with the concept of a separate renderthread ( currently I am having only one Direct3D9 renderer finished ). What I now have is a simpe renderer for models imported with assimp.

    If my little daugther let me some time I am working on a simple space-shooter, which is using the ZFXCE2. But it takes a loooot of time.
Hi all,

I am very proud to announce our new 3.0 release of the Assimp Importer Library:

And here are the release notes:

  • New export interface similar to the import API. Supported export formats are Collada, Obj, Ply and stl.
  • New import formats are [font=arial, sans-serif]


  • A new experimental importer is also there M3
  • Vastly improved IFC support
  • A new API to query importer meta informations like supported format versions, full name, maintainer info etc.
  • A new post processing step is there: Debone.
  • The Ogre XML importer was reworked
  • Hundreds of bugfixes
  • Unified nameing and cleanup of the public headers
  • Improved Cmake-build system
  • Debian package supported

    You can download our SDK at http://sourceforge.net/projects/assimp/files/assimp-3.0/

    Thank for all the contributors, users and everyone, who gave us feedback for our work!
I am really glad to announce that the Asset-Importer-Library version 3.0 was released last week. Currently only a Source-Only package is available. The guy's from Debian asked for it and all the core-members of the assimp-team are currently really spare on time. But we will release the SDK as fast as possible.

You can find the source-package at Sourceforge: http://sourceforge.net/projects/assimp/files/assimp-3.0/

I wrote some interesting stuff abou the new features here: http://weblog.kimkulling.de/?p=45

I want to say "Thank you very very much!" to all the contributors who are helping us with bug reports, patches or just using us.
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]I finished the first approach to import assets in a separate loader task and I was able to see my first imported model. Currently any kind of texturing needs to be implemented. But how can you desribe the location of a resource like a texture or a shader in a elegant way? [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]So [/font][/font][font="arial, sans-serif"][size="2"]I added a class called Uri. This stands for unique resource identification ( see [/font]http://en.wikipedia....urce_Identifier[font="arial, sans-serif"][size="2"] to learn more about this ). This Uri is the new way to describe the place where you find your resources. For instance if you want to load a resource from your locale filesystem at[/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][font="arial, sans-serif"][/font][font="arial, sans-serif"][size="2"][source lang="cpp"][/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]filename = "c:\models\spider.obj"[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"][/source][/font][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]the URI format will be:[/font][/font]
[font="arial, sans-serif"] [/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"][source[/font][/font][font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"]lang="cpp"[/font][font="arial, sans-serif"][size="2"]][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]uri = "file://c:/models/spider.obj" ( on a windows xp system )[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"][/source][/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"]The interesting thing is the scheme of the URI ( here the attribute file:// ), which describes the type of filesystem we have to use to open this resource. I introduced a new class called IOServer, where you can get a filesystem instance to manage the requested file system. For instance if you have a URI like:[/font][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"][source lang="cpp"][/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]uri = "zip://texture.jpg";[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"][/source][/font][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]You can get the mounted filesystem and get a stream to access the resource as following:[/font][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"][source lang ="cpp"][/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]Stream *pZipStream = NULL;[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]IFileSystem *pFS = IOServer::instance()->getFileSystem( "zip" );[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"]if ( pFS )[/font][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"] pZipStream = pFS->open( uri, Stream::ReadAccess );[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"][size="2"][/source][/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"]Currently I only have mounted the locale filesystem as the default one. If you want to use this you have to mount the zip-filesystem before:[/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][/font]
[font="arial"][size="2"][font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"][source[/font][/font][font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"]lang="cpp"[/font][font="arial, sans-serif"][size="2"][size="2"]][/font]
[font="arial, sans-serif"][size="2"]// Mount the zip file system.[/font]
[font="arial, sans-serif"][size="2"]IOServer::instance()->mountFileSystem( "zip", new ZipFileSystem( "c:\\archive.zip" );[/font]
[font="arial, sans-serif"][size="2"]...[/font]
[font="arial, sans-serif"][size="2"]// get the file system[/font]
[font="arial, sans-serif"][size="2"][size="2"]IFileSystem *pFS = IOServer::instance()->getFileSystem( "zip" );[/font]
[font="arial, sans-serif"][size="2"][size="2"][/source][/font]
[font="arial, sans-serif"] [/font]
[font="arial, sans-serif"] [/font][font="arial, sans-serif"][size="2"][size="2"]I saw this approach first in the Nebula3 Device and I was amazed to see a really clean design for that kind of problems. Thanks guys![/font]
[font="arial, sans-serif"] [/font]
[font="arial, sans-serif"][size="2"][size="2"]But there is still some work to do. Currently you can only mount one Zip-Archive. If you want to switch to a different one you have to unmount the older one and remount the new. Here I want to be able to deal with multiple archives. But for a first proof of concept this should work. And I missed a simple search method as well. Currently you have to know where to look for your textures. And this is not comfortable in my eyes. [/font]
[font="arial, sans-serif"] [/font]

Assimp is part of Debian

just a short update from the Asset-Importer-Library. We are now part of the Debian-installation. Currently we are not part of the stable release, but hopefully we will get a lot of feedback from the linux front :-). And the last release of the Clan-Library will use our Collada-Loader. The old one used in older Clanlib-releases was replaced by Assimp. That are amazing developments we never planned at the beginning of Assimp.

And hopefully I will be able to deliver a M3-Loader ( the format of Starcraft2 ) in the next weeks as well.
I wans't able to update this user-jornal the last couple of weeks, sorry. Currently I am in educational holiday for three months and my daughter learned one thing at the beginning: moving. So I had to learn how to avoid bigger accidents like switching off the computer or destroy the house very vrey fast at first laugh.gif.

A first triangle will be rendered

I finished the basics of my Direct3D9-renderer. I was asked more than once why I started with D3D9, when D3D11 is the hot shit. The reason is pretty simple. I want to be able to try my demos on my devbox at my job as well and there I have to use a Windows-XP ^^. D3D11 is planned as well, but at first I want the basics running.
The Renderer runs in a separate render-task. To test the renderer itself I wrote a small render-test-app. This test runs in the main-thread. This makes debugging much simpler for me. I will add a screenshot-system to be able to automate the render-test if I have some time for it ( maybe the next decade ).

The Task-Manager
To be able to separate tasks into separate threads I have implement a class called TaskManager. This manager handles several task-instances ( creation, starting, stop them ). Each task can work in the main-thread or in a separate thread, which will be spawned for the task.
If you want to do something in a task you can send him an event. Events will be handled by EventHandlers. The user can implement this handler and attach them to a task. The event-handlers should be the hook for any user-specific stuff. So if you want to implement a task to handle some work you can use the task-manager to create a new task-instance. After that you can attach you own EventHandler and send user-specifc events to the task.

A first prototype for the Resource-Loading-System
The resource load procedure works, too. At this moment you can import models using the AssImp-Library in a separate thread. The ideas behind the resource system is really simple: resources are assigned to a unique resource-group-id. You can register a resource-factory and a resource-loader to this group id. Factories will create the resources, the loader will import the data. The resource-server will cache created resources to avoid redundat loadings.
If you want to create a new resource instance and load data into it the procedure is quite simple:
  • Get the Resource-Server instance.
  • Get the Factory and the Loader, which are assigned to the unique resource-group -d of your resource type
  • Create a new resource instance with the resource-factory. The factory gets the loader instance as a parameter. If you want to use a specific loader you can specify this here
  • No you can call Resource::onLoad to signal, that the resource loading should be started by the loader-task.
  • The resource-loading-request will be enqueued into the resource-loader-queue and handled as fast as possible.
    This works and now I can test this for other resource types like shaders or textures as well.

    Next steps
    Currently I am working on the render setup for the imported models. On issue I am thinking about is how to handle the ownership of the model-data. After finishing the loading the resource-data-ownership will be moved from the loader-task to the main task. The render-task will get this data by receiving an event and store it in vertex- and index-buffers. If you have some nices ideas feel free to share them with me ...

    The AssImp development
    I made some progress at the assimp-deveopment as well. The M3-Importer grows and grows. At this moment I am able to import faces, normals and vertices. But I will need some more time to understand how to deal with the bone-system of the m3-format. Understanding such things is a much harder task if you child tries to switch off your computer again and again...

    To be continued...
[font="arial, sans-serif"][size="2"]After getting a lot of questions about the [size="2"]Assimp-animation format offered Smasherprog wrote a simple Animation-controller and published the source. Hopefully this will help others to understand how to get the animations running. [/font]
[font="arial, sans-serif"][size="2"]You can find the blog-post with the example code here .[/font]
[font="arial, sans-serif"] [/font]
[font="arial, sans-serif"][size="2"]You can also look for real good explanations about the animation-format of assimp in our forum. Schrompf has written some really good explanations about that ( [/font]http://sourceforge.n...4/topic/4563379 for instance ).

In the last week I made some progress in the ZFXCE2 as well. Currently the render-driver model seems to work fine. So I concentrated my work on a render-test, which will implement a first reference-renderer using D3D9. I made good experiences with that approach in my projects at work, special if you want to offer more than one renderer for several platforms. Currently I am developing only for Windows ( 32- and 64-Bit ), but a good friend of mine asked for a Linux implementation as well. So an OpenGL implementation will come at least smile.gif. Hopefully I will be able to show some screens here in the next weeks.

And I will have some more time for my private projects in the next months. I will take education holiday for three months starting in August. Hopefully our daugther will give me some time for the Assimp- and the ZFXCE2-Library.
After having the first vacation with our little daugther in Stuttgart ( Germany ) I restarted my work on the ZFXCE2 render-subsystem. I tried to build at first a working render-thread, who gets signaled to refresh the render window from the render-interface. This interface is the front-end used by the user.
To get a simple feedback from the render-driver I just wrote a small logging entry like "Hey, I have an update!". The communication between the main-thread and the render-thread of the render-driver is done by sending events, which will be handled by a render-specific Event-Handler.
The render-thread itself is managed by a render-task. The user will only have to deal with this task. The thread-management-stuff like changing the priority or using the more threads ( or just the main thread ) will be done by the task-management. Hopefully this aproach will help to decrease the complexity, which the user has to deal with.

And then I learned a lot of "old" lectures again about not finished functionality:
  • Try to add a simple and workin logging mechanism ( even a simple printf is useful ). So you don't have to search why you cannot see any entries ( without writing anything you cannot see anything wink.gif ).
  • If you are building your own assert-test, don't be lazy. A minimum is a simple wrapper over the default-assert-implementation from the runtime. I had fixed many many assertion-failes in the existing code, because the ce_assert-macro was just empty...
  • Unittests can be very useful.
    So after fixing all these issues I saw the log-entry "UpdateFrame" and I feel motivated to implement a first model-viewer. I will use the AssImp-Loader for this task.

    And I opened a new website for the ZFXCE2. Currently it contains not really much stuff, but this will change hopefully: The ZFXCE2 homepage.

    And I learned in the last months: with a little child find some time for your hobby projects is the hardest task I was ever confronted with in my whole life laugh.gif...

    To be continued...
The team of the ZFXCE2-team ( me wink.gif ) mode soe progress:
  • I implemented a first initial version of the render-driver. The driver will run in a separate task, which spawn its own thread. The communication between the client like a game or a model viewer will be implemented by events. Currently the idea is that you can define your own event-handlers to a task. If you want to send any data or sync the client and the driver task you can do this by using a special event.
  • I integrated the old event-system from the first ZFXCE. The event declares only the type of the event, the data assigned to this is implemented by a special event-data class.
  • I added the first running unit-tests for my container and the event-queue-system.
  • I am still happy with the CMake-build.
    At this moment I haven't any render-application, but I will give my very best to change this as fast as possible.
I made the initial commit of the ZFX-Community-Engine version 2. It conatins the new basic architecture of the ZFXCE2. It is really simple and use the following layering:
  • Infrastructure
  • RenderSystem
  • ApplicationApplication depends on the RenderSystem, the RenderSystem depends on the Infrastructure.

    The Infrastructure layer:
    The core layer, which offers basic services like logging, IO, event-handling, operation-system relevant stuff like accessing a windows system, timers, threading. Currently a windows-specific implementation is supported.
    To offer an easy way to use the engine I will integrate a lua-interpreter at first.

    The RenderSystem layer:
    The layer which works with the graphic API. I am planning to use a rendering thread, which will be implemented by using the driver pattern. The user uses a render-client to define what should be rendered. The driver itself implements the access to the used render-api like OpenGL or D3Dx. I am not sure which communication-style between client and driver will work.
    At this moment I just plan to define a command buffer, which will be filled / modified by the client with the rendering commands. After finishing the current frame the command-buffer will be updated by the driver itself and the new frame will be rendered. On each frame only the dynamic stuff will be changed.
    I will also place here the scenegraph. Assets will be imported by using the asset-importer-library.

    The Application layer:
    This layer is the layer used by a user of the engine. It offers a base layer to configure, startupo and shotdown and accessing your assets and entities used for rendering.

    The initial commint contains a base version with the render window, which is currently empty with a black background. You can close it by pressing ESC or just closing the window by pressing the close-button. You see: The event-system works already. And I started my work on implementing a D3D9-renderer. Currently I am playing around how to implement the client / driver-concept for multithreaded rendering.

    I also added a first sample application called ModelViewer. It implements a first test of the architecture and it seems to work :-). You can find the code here: ZFXCE2 at SF .

ZFXCE restarted: ZFXCE2

After fighting against a lot of fatal design issues I made in the first version of the ZFX-Community-Engine I started the ZFXCE2-Project. This is just a relaunch of the ZFX-Community-Engine. I will try to reuse as much code as possible to be faster in developing something that work. So I will try to reuse the parts of the core-library and the already working AssImp-Importer.
My plan is to rewrite the complete rendering system and the scene-management. And I am thinking of a new threading-concept base on tasks as well: A task is a thread which will run a subsystem of the engine like the renderer or the IO-System.
To have not so much different dll's I created three layers: Infrastructure, Rendering-System and the Application-System. In the Infrastructure-layer you will find stuff like IO-access, the basics of the resource system or managing the several tasks. The Render-System will handle the whole rendering-stuff. I will also place the scene-management at this layer. The application layer will contain functionality to build applications. From the view of a engine-user this is the place to initialize and interact with the ZFX-Community-Engine.

You can find the new Sourceforge-site here: ZFXCE2

My first application to make some progress is a small Model-Viewer based on AssImp and a prototype OpenGL-renderer.

After writing the developer-weblog of the ZFX-Community-Engin at the sourceforge-website I descided to move it to Gamedev. Hopefully we will find some more readers for it.
The ZFX-Community-Engine is an open-source game-engine, which was started on a german game-developer-community : ZFX-Community ( german ) . I am working on it as a small learning project. I am also trying to build some small other projects with it.
You can find the project-page here: ZFX-Community-Engine projectpage .
And you can find my older posts here : The old ZFXCE developer weblog
Sign in to follow this  
Followers 0