News
04/11/09 Fédia rules update (french only)
The new rules are there, they are now rather well tested, except for magic.
There are exactly two notes, one about the magic system, another about the newly introduced Art of War skill.
Another french only update about the world to come a bit later.
29/10/09 Fédia update ("shortly" online, french only though)
I've been working on my RPG rules, they are inspired by Legend of the Five Rings (L5R) and Qin, and are not yet completely tested.
The elementalists magic system remains to be tested, and the Druids/Shamans magic system is a work in progress, but that's not a problem to have fun games already :)
I've had around 8 games sofar, which only lead to small changes, mostly making things simpler, and slightly enhancing the battle system with a one more option.
I also spent some time on the setting of the world. Nothing new, I have two notepads (A4, 192 pages and 288 pages), full of descriptions : kingdoms, characters, orders of chivalry, places...
05/10/09 A couple of changes
I've updated my CV to reflect some of my past work.
I spent time improving my role playing games rules. The players are rather happy with them, very few glitches in 11 hours of play.
I found very little time to work on FlExtEngine those days, it's still on my mind and I write a couple of notes now and then...
23/08/09 Progress update
I've been busy on a number of things lately.
Like most programmers I paid close attention to papers released for SIGGRAPH. I also watched Carmack's speech at QuakeCon, was nice. :)
As an avid player, I also paid attention to GC and BlizzCon. Guild Wars 2 trailer caught my eye, I got all Guild Wars games sofar, I'm really curious about the new game.
I worked some more on my engine, but I also did some web programming (been a while since I was in the industry), with PHP/MySQL, usual stuff I guess.
My engine progressed slowly due to both doing other things (web programming, helping a little on some MMORTS code), and having been a bit too enthusiastic with some changes that had more impact on the architecture than I first anticipated.
Things are clearing up though, and the engine should be well multi-threaded, with nice tasks being black boxes with no side effects. (Like shaders on GPU really.)
30/06/09 FlExtEngine 0.2
I've started numbering it ! ;)
There's a good reason why I gave it a number, as usual with me, every tenth version is a major change from the previous.
Here the changes include :
-new Model and Mesh design, deleted Skeleton class, embbeded Bones inside the Model class. (As it once was ^^)
-modified LoD mechanism, now LoD is stored in the Model class except for Index Buffer LoD (using Offset and Count in the same IB) stored in the IndexResource.
-slightly modified Animation Mixer, and changes in Animation State storage.
-streamlined Model, Mesh & Bone class, also moved into their own namespace Model to make naming more concise (use of namespaces in headers isn't that nice though ^^)
-simplified Resource classes which I did (wrongly) copy from OctoPort
-started replacing (work in progress) the updating & rendering processes to make them both simpler and more batching friendly (batchs being memory access, hence cache & multi-thread friendly)
That's about it, not everything is finished yet, but it's gonna make everything simpler, and K.I.S.S. rules ! ;)
18/05/09 News
I've been working on my animation system and the "resource" manager, which is more like a buffer manager.
The animation system is mostly done, even though I didn't solve the transition problem, I'd need additional data to know when I can have transition between different animations.
Unreal's huge animation tree is of little appeal to me, I'll see what I can come with.
The buffer manager isn't finished either, I've been studying memory allocators and cache algorithms in order to find out a good solution for that problem, I think I came up with something good, I'll have to test it when it's up and running.
On another note, I got a cold a little more than a week ago, and it did slow me down considerably :(
(Maybe playing Warhammer 40k : Dawn of War II in ladder matchs is for something in my slow down too, but I think I play it only when I'm too tired to code...) ^^;
Once I'm done with the buffer manager algorithm, I'll have to finish implementing buffer updating through STAGING resources.
Next big task will be to rework the Effect framework, which is connected to the Renderer.
The latter isn't a big deal, as I already had a D3D10/D3D9/OpenGL Renderer before I joined Cyanide Studio a couple of years ago.
BTW, the 3rd part of my series about "The technology of a 3D Engine" has been published (at last ;p) at Beyond3D, you can find it here!
Someone told me that he didn't like the fact that it was more wishful thinking rather than notes about what I did implement, but I thought it was fine when I wrote it (in 2007), to have 3 parts : what I did, what I'm doing, what I'm up to, and a fourth about a couple of other things I needed along the way.
Comments are welcome :)
19/02/09 "Deferred Animation"
There are a number of things that the engine should perform to speed-up rendering:
-Geometry Level of Detail (Multi Resolution Meshs in Intel's wording), reduces memory & vertex processing load.
-Skeleton Level of Detail, reduces the CPU animation load.
-Animation State sharing, reduces the CPU animation load, only valuable when a lot of objects are on screen, otherwise it might be too obvious.
-Occlusion (using software rasterizer, this solution seems to get popular these days.), reduces GPU processing.
-Shader Level of Detail, reduces shader aliasing/load. (Any/All stages.)
I'm not a fan of ShaderLoD, I recognize its usefulness in aliasing reduction, however I don't think the reduction in fragment shading load is that valuable.
An object with reduced LoD is already having less vertices, and also covers a smaller screen area (ie fewer samples), so I doubt implementing Shader LoD to reduce that load further is worth it. (Means more shaders and so more shader switch.)
(I'll test it though, but only after the first version is done.)
The FlExtEngine performs the following steps to render the scene:
1) Scene updating
2) Spatial culling
3) Rendering
This raises a problem with animation (computed during updating usually), since it needs be evaluated before an object is known to be culled.
Spending time animating something that doesn't contribute to the frame is obviously wasteful, and so must be prevented.
Skipping animation altogether is not possible though, as some meshs might be linked to any bone which means that their location isn't known until animating. (A sword or shield in a character's hand, for example.)
However, only nodes with such a dependency require animation during updating to guarantee the correctness of the culling step therafter...
That introduces both the concept of minimal updating, which consists of only updating the subset of nodes that will guarantee the correct execution of the culling step,
and the idea of deferred animation, since the animation is (mostly) computed after both the updating and culling steps.
06/02/09 FlExtEngine multi-threading "Take 4"!
The "Take 4!" is a reference to the best PC game of all time (according to me) : Outcast
It had a Voxel terrain, making it very different from most games at the time (back in 1999/2000), all NPC were dubbed, and you could ask them about places and people, they would tell you where to go !
Water had ripples, was reflecting the sky, the sky was beautiful, as was the landscape (at the time), the hero was dubbed by Bruce Willis voice actor in France, so it was really nice.
Great memories. :)
Anyway the "Outcast TAKES" were small videos made by the Appeal team with the in-game engine as-if Outcast was a movie, so they were supposed to be takes cut from the final product, and were really funny. :)
Back on topic, it's just a small note to say that I found a bug in the code generating the stats of my multi-threading test :(
The good news about it, though, is that according to the (supposedly correct now) stats, I get a Ts/Tp ratio of 1.9 with my naïve Threading Building Block implementation, on a Core 2 Duo E6600 !
It means my code is parallel a lot ! :) (94.7% parallel, keep in mind it's a synthetic test, so final code will be different.)
OpenMP gets a Ts/Tp ratio of 1.472, naive native threads implementation gets 1.467, TBB parallel_for gets 1.732, TBB naive tasks get 1.902, and TBB tasks with reuse get 1.760.
Clearly OpenMP has a high overhead (as Dean Calver told me), and the lack of (smart) scheduler doesn't help the naive native thread implementation.
04/02/09 FlExtEngine multi-threading 3
Well, there are a number of obvious things I'm multi-threading (or about to since writing code takes time ;) ), but I figured I could write about them anyway.
When I talked about Scene Updating, that included both Skeletal & Shape (Morphing) Animation, although the second can be done on GPU, I'll rather do it on the CPU side because it would likely be more interesting on consoles (especially PS3).
Particles are another thing I'll also keep CPU side for the same reasons. (I'll probably not resist writing a GPU version, but not in the first version)
In both cases I will be using SSE, since they are ideal candidates for SIMD.
While talking about SSE, I'm using SSE2 intrinsics (widely supported), and also taking advantage of it when streaming data from RAM to VRAM to keep the CPU cache clean.
On a last note, Beyond3D is going to have dev blogs again !
So I expect to move there at some point in the future. :)
02/02/09 FlExtEngine multi-threading 2
OctoPort (my previous engine) was already multi-threaded, but to a much lesser extent that FlExtEngine is going to be (and starting to be).
In OctoPort, the I/O access through the IOManager, was spawning threads which would write to a locked slot.
The system was simple and efficient. I went using a Thread instead of Async loads so as to make the code much easier to write (adding PlugIn needed be straightforward), and because the Thread is also inflating data along the way.
So the FlExtEngine is getting the following "process" multi-threaded:
-RAM resource loading (from Disk like OctoPort had)
-Scene Updating (I have two different algos competing atm.)
-Spatial Culling
-Rendering (In fact OctoPort was already building command buffers at some point, it's just a matter of digging it back ;) Of course being client side, they can't be as optimised as server side, like in D3D11.)
-VRAM resource loading (from RAM, it happens that D3D9/10/OpenGL aren't thread safe when it comes to locking/mapping. DX11 will be a nice improvement.)
I'm using Intel's Threading Building Blocks (licence might be an issue at some point, but there's a commercial version also), because it's nice to have a Scheduler generating as many threads as the system as active cores, and not only load balancing but also taking the cache into account :)
01/02/09 FlExtEngine multi-threading
I've been working on multi-threading the update(...) process of the FlExtEngine, I tried a number implementations (OpenMP, Native, pthreads, Intel's Threading Building Blocks, JobSwarm from gdalgo mailing list) and recorded the results on my Core 2 Duo E6600.
The various implementations are working rather fine, with a Ts/Tp ratio close to 1.5 (implementation dependant), except for JobSwarm which is much lower. (Lack of Scheduler most likely.)
I did chat a little about it with Dean Calver and read a number of papers to see what I could improve, but it seems there's not much to improve right now, but as soon as I finish the animation mixer and add more node types, I'll try it again.
BTW, thanks to Ryszard Sommefedlt (Beyond3D editor-in-chief) who ran the initial tests on his quad core, it scaled. (Ts/Tp = 2.5) He also told me he plans on getting the 3rd article of my series published next week at last ;p (I wrote it in Autumn 07.)
08/01/09 News
First one, I've been quoted by Wolfgang Engel, and that's nice :). You can see it there.
Second, I've resumed my work on my brand new engine from scratch, the FlExtEngine ! :) It's slowly taking a rather nice shape, no clue when I'll get it up and running, so I'll only say "when it's done" ;)
07/01/09 Happy New Year !
I wish a happy new year and good health to everyone reading this page ;)
