JmD

Jag har anmält mig som testpilot av Canons nya kamera EOS 550D. För den som är intresserad av att bli testpilot finns anmälan här: bli testpilot.

We decided to make the Dharma tool suite an integrated part of the BallistiX simulator framework. Up until now it has been developed as a stand-alone application.

The more developed Dharma gets, the more of the simulator functions it will need access to. Instead of re-creating the parts of the simulator functions needed, through integration we can use them directly.

The integration will make it easier and faster to edit and develop simulator asset and test them in the simulator. It will also make the overall development of both BallistiX and Dharma easier since they are now both part of the same solution in Visual Studio.

The integration will be done by using the MEF plug-in library.

Sorry – no translation

Children are human beings, just like adults. They lack experience but not intelligence. More often than not, they are still very open-minded. They need our love, and they need to be seen, considerably more than they need designer clothes and gadgets. They need limits and to be taught the connection between act and consequence. They should be allowed to be children and at the same time gradually learn responsibility. They have to be allowed to make mistakes and get hurt – both physically and mentally. Pain and the act of overcoming it is a part of life – do no try to protect them from it – then they will not learn how to deal with it. If they can not stumble and get hurt, they will not learn how to break the fall. Comfort them and help them when it happens – that is your duty as a parent.

Respect children for what they are – human beings with less experience – and put reasonable demands on them. The parents’ obligation is to be there for their children and to show their love for them. Children are the pups in the pack. Sometimes, they do need limits, but most of the time they need comfort in order to have the courage to face the world out there.

Children are the largest responsibility a human being can take on. If you can not take that responsibility – do not have kids. We see the right to have children as natural for every person – this is absurd. Being a parent is not a human right – it is a responsibility people should be obliged to prove they can handle before they are allowed to have children. We need to have a license in order to drive a car or carry a gun. But with children – the only demand is that we spread our legs. The consequences of a bad parenthood are far more devastating to a lot of people than, for example, the consequences of a bad traffic behavior.

To get 3D assets from content creating applications like 3DS Max to our simulator platform BallistiX we started by using the X-file format ( .X). This is a file format developed by Microsoft for DirectX. Since then we have however changed the tool chain to include Softimage XSI and Modo. These applications are not in all aspects as capable of exporting to the X-file format as 3DS Max. So we decided to use COLLADA as the main interchange format.

Dharma, our tool suite,  will be used for checking, manipulating and organizing assets for BallistiX. So Dharma will be the tool used for importing 3D assets from formats like X-files and COLLADA, and convert them to formats suitable for the simulator.

Both Dharma and BallistiX are coded in C#, so I started by looking for some open source library for parsing COLLADA files in C#. But I didn’t find anything suitable. There were a couple of “code-starters” and examples, but they all used the older XML-libraries of .Net. I wanted the parser to use the latest LINQ-based XML-library and so I decided to write my own parser. Not only does this give me full control of which parts of COLLADA get implemented, but it also gives me a good opportunity to get to know the COLLADA format better.

Dharma is a project we (my company Dynatech-2) started in the spring of 2009, right after we finished the first prototype of our hunting/shooting simulator BallistiX. The goal of Dharma was to make a level editor for BallistiX. Back then I based the GUI on Windows Forms and a bit of effort was put in to making custom controls to achieve the goals we had with the GUI functionality of Dharma.

We have been using 3D applications and tools for about 15 years, so we have quite a lot of experience from different approaches to the interface of such applications. Some of the  goals we set up for the GUI of Dharma were the following;

• Flexible and customizable GUI. Preset GUI layouts and the possibility to make your own.
• No limit on the number of simultaneous windows and viewports.
• The visual “framework” of the GUI should not be fixed if you don’t want that. All windows and viewports should be individually movable and resizeable. But they should also be dockable to each other so you can move and resize them all together as if there was just one main application window. This flexibility is very important for multi monitor setups.
• A window is just a window – it can show whatever information, tool, application or part of Dharma you want. There is no fixed content to a window. The layout presets are supplied so you don’t have to setup everything from scratch. There will be “traditional” setups like quad viewports, toolbars etc available to make it easy to get going.

Since then the project has been somewhat “asleep”. Now, with the new version of BallistiX beeing developed, the need for different tools is once again apparent. I have decided to develop those tools as parts of the Dharma Tool Suite. This time, however, I will base the GUI on WPF to utilize the latest technologies in that area. I will also use the techniques we are trying out in BallistiX, like CCR for parallelism and MEF for modularity. SlimDX will be used where I need a 3D API.

The final goal of Dharma is something I have decided not to try to define yet. I will let it develop sequentially as more tools get added. Whether it will be a level editor for BallistiX remains to be seen. The goals regarding the flexibility of the GUI is something i’ll keep to though.

The first tool I am developing is a little file viewer for x-files, a file format used by DirectX.

There are several techniques in the works nowadays to take advantage of the computing power of both CPUs and GPUs – TPL and CCR from Microsoft, Cuda from nVidia, Compute Shader (part of DirectX11), Stream from AMD, OpenCL from Khronos Group etc.

As I envision it there should be a library taking advantages of both CPU cores and GPU cores as they become available to the application. Of course there have to be some way of deciding what kind of processes get run on what kind of core (CPU or GPU) since they are fundamentally different in what they do most efficiently (the GPU being more effective in SIMD areas for example).

I think one possible future is that a computer comprises a core pool where many different types of cores reside – or maybe there are just a couple of basic core structures. In any case there are many cores, and they can be utilized by applications in a very flexible manner.

The CCR library (mentioned in the introductory part) seems like a very good choice for the parallel design of the simulator engine. I did a small test where I had a program update the rendering of a Direct3D scene on the OnPaint event of a WinForm (coding done in C# using Visual Studio). This process was in no way multithreaded and used around 50% (or one of my two cores) of my processor capacity.
Then I implemented the rendering update using a timer based posting of a message in CCR instead (using the DispatchQueue.EnqueTimer method). The functional and visual result was exactly the same as before. But this time the process used between 2 and 7 % of my processor capacity. This shows not only that multithreading is really needed if we don’t want to waste our processor resources on meaningless processes tying up threads. It also shows how easy multithreading and concurrency is implemented using the CCR, and how neglible the overhead of the library seems to be.

Microsoft has developed CCR, a library making life much easier for those developing multithreaded applications. Here are a number of links to sources of information about this amazing library.

• Microsofts user guide on MSDN.
• User forum on MSDN.
• Concurrent Affairs – article by Jeffrey Richter.
  
• Article on InfoQ.
• MSDN channel 9 videos.
• Questions about CCR on stackoverflow.
• PowerPoint Presentation by Igor Moochnick.
• PowerPoint Presentation by Andreas Ulbrich.

Me and my coworkers are developing a shooting simulator called BallistiX. It is developed in C#.

BallistiX is a plugin based simulator system. The framework will load the plugins available to the system and use them for the simulation. There will be plugins for user input (keyboard, mouse, laser tracking systems etc), plugins for output (3D graphics, sound etc) and plugins for simulator entities (animals, terrains, guns, ammunition etc). This architecture lets us develop the core relatively fast and then we can continuously develop the system by making new plugins without the need for the user to upgrade the core.

The focus of our development will be the following

• Flexibility and extensibility – this is achieved by the plugin architecture.
• Technical accuracy – great effort will be put in to the calculations of the bullet ballistics. We will use real world data for those calculations.
• Animal behavior – the AI of the animals will be very extensible and advanced. Initially the behavior model will be quite simple, but the framework for the AI lets us develop this to achieve extreme realism. Each animal has the ability to react to the environment and to the internal states of the animal. There are mental states like hunger, fear, fatigue, wakefulness, pain etc. There are also physical states like energy, tissue damage, mobility and so on. The mental and physical states are depending on each other to varying degrees. Environmental events also affect the states of the animal.
• Visual quality – we will utilize the latest shader technologies to achieve image quality in the realms of the more advanced game titles of today.

Technologies
We use SlimDX – a managed wrapper for DirectX – for the rendering of the 3D graphics. Currently we are using DX9, but eventually we will be looking into DX11.

The simulator engine will be a parallel design utilizing the multicore based CPUs of today. We looked at a number of technologies for concurrency and ended up choosing between TPL and CCR from Microsoft. For the moment CCR is the more appealing library since it gives us greater control over scheduling and management of the resource pools. The decision to go with a pre-fabricated library instead of developing our own was a no-brainer – development time will be greatly reduced by this.

More news will come as the development continues.