Finally I've made skinning!
http://www.youtube.com/watch?v=SwAIHFE64v0
This is a small video that shows the skinning with an FBX model! I'm satisfied for that, even if it costs me too much time due to the lack of documentation as of FBX...
But now I understood (with many trials and errors) the way to retrieve animation data, skeleton, meshes and material informations.
Next step it will be a big overall change of the engine in all its parts, because I've seen the current architecture is quite messy and it is not organized in a way I like.
This iteration of the engine, as already mentioned, is intended to cover all the aspect of an engine, and not only rendering (as my previous 2 engines).
Stay tuned for more informations!
Wednesday, February 17, 2010
Friday, February 12, 2010
Rendering design thoughts
I opened a really interesting discussion @ gamedev:
http://www.gamedev.net/community/forums/topic.asp?topic_id=561645
I'm brainstorming and sharing my thoughts about rendering, and the mentality behind the renderer I use in my engine.
Take a look!
http://www.gamedev.net/community/forums/topic.asp?topic_id=561645
I'm brainstorming and sharing my thoughts about rendering, and the mentality behind the renderer I use in my engine.
Take a look!
Monday, February 8, 2010
FBX, skinning and exploration
Finally I came up coding an importer that can give me the possibility to access data that include mesh, skeleton, animations and materials.
This is a HUGE step ahead in importing asset for the engine, and this lead me to other type of battles and thoughs.
I found FBX lacking of documentation, the only serious source code is made by a guy that created an FBX importer using DirectX10 and very kindly provided the source.
Still, I wanted to use FBX as an INTERMEDIATE format, that is translated in my own internal format, for speed purpose: I'm also using Collada as intermediate format,
but still I have problems in exporting in Max2010 (a beautiful CRASH).
Next days I hope I'll publish some pics (or maybe a video) showing the skinning.
The BIG improvement coming from the skinning integration is the focusing on the problem concerning the render of different kind of geometries...this is really fascinating, because
I know for sure I'll change all my rendering code very soon. Why that? Simply because I want to *explore* other way of rendering, I've always used direct rendering but now I want to change to other solution, and found in deferred rendering (not deferred light rendering, this with light-pre-pass was done on the previous iteration of Hydra) a new way of thinking: create a command buffer, one for each thread, and then add commands from every thread.
A final merge and the rendering, and you have deferred rendering.
I read some posts around the web, and also the emergent presentation about this, and I found really a good way of thinking the rendering as a multithreading process.
The other BIG improvement is the way of thinking "data oriented"...it is really amazing, basically it is a way of thinking based on data ACROSS objects, and not only objects...so objects became a set of properties and data, but not in a constraint way.
It is really 'holistic' way of thinking about the code, and I want to try very different way of doing the same thing.
Strange is the fact that coding is the process of transform informations, nothing more, nothing less. And we are experiencing a BIG process of letting all more complicated.
Multithreading is taking to the road of seeing programming with a different level of detail, no more safety and simple flow, but a more wider use of the machine and its power.
Speaking of exploration...I'm really sad about the announcement about Castlevania:Lord of Shadows. It will be another GodOfWar clone with no more exploration...
This is a HUGE step ahead in importing asset for the engine, and this lead me to other type of battles and thoughs.
I found FBX lacking of documentation, the only serious source code is made by a guy that created an FBX importer using DirectX10 and very kindly provided the source.
Still, I wanted to use FBX as an INTERMEDIATE format, that is translated in my own internal format, for speed purpose: I'm also using Collada as intermediate format,
but still I have problems in exporting in Max2010 (a beautiful CRASH).
Next days I hope I'll publish some pics (or maybe a video) showing the skinning.
The BIG improvement coming from the skinning integration is the focusing on the problem concerning the render of different kind of geometries...this is really fascinating, because
I know for sure I'll change all my rendering code very soon. Why that? Simply because I want to *explore* other way of rendering, I've always used direct rendering but now I want to change to other solution, and found in deferred rendering (not deferred light rendering, this with light-pre-pass was done on the previous iteration of Hydra) a new way of thinking: create a command buffer, one for each thread, and then add commands from every thread.
A final merge and the rendering, and you have deferred rendering.
I read some posts around the web, and also the emergent presentation about this, and I found really a good way of thinking the rendering as a multithreading process.
The other BIG improvement is the way of thinking "data oriented"...it is really amazing, basically it is a way of thinking based on data ACROSS objects, and not only objects...so objects became a set of properties and data, but not in a constraint way.
It is really 'holistic' way of thinking about the code, and I want to try very different way of doing the same thing.
Strange is the fact that coding is the process of transform informations, nothing more, nothing less. And we are experiencing a BIG process of letting all more complicated.
Multithreading is taking to the road of seeing programming with a different level of detail, no more safety and simple flow, but a more wider use of the machine and its power.
Speaking of exploration...I'm really sad about the announcement about Castlevania:Lord of Shadows. It will be another GodOfWar clone with no more exploration...
Thursday, January 14, 2010
Happy new year!
Finally...2010! Happy new year!
I feel very excited about the new year: it begans with many news, not all good, but changes are coming!
I'm rean completion of the base rendering system of the new engine, I'm working on multithreading and I fell in love with Data-Oriented Programming mentality!
Next days I'll have FBX model ready to draw with every shader again, deferred/forward/light-pre-pass easy to switch and already implemented, then I'll move to finalize the multithreading base and physics base.
I want to experiment with a multithreaded framework, to see how can I achieve good performance and stability and usability!
Stay tuned...new experiments awaits!
I feel very excited about the new year: it begans with many news, not all good, but changes are coming!
I'm rean completion of the base rendering system of the new engine, I'm working on multithreading and I fell in love with Data-Oriented Programming mentality!
Next days I'll have FBX model ready to draw with every shader again, deferred/forward/light-pre-pass easy to switch and already implemented, then I'll move to finalize the multithreading base and physics base.
I want to experiment with a multithreaded framework, to see how can I achieve good performance and stability and usability!
Stay tuned...new experiments awaits!
Friday, December 18, 2009
Math library; Core Engine development;
Even if I am not coding really fast, I'm studying different topics in which I find really different 'formae mentis': this is really fascinating!
Actually I written a non-template version of my math library, with some basic support for SSE/VMX code: premature optimization is the root of all evil.
So I'm moving forward to implement other core part of Hydra: camera, input and debug output!
Actually the camera is almost done, with all the code (like plane extraction, frustum vertex in world/view-space) working, the input is almost done and I'm writing the implementation of a directx9-based renderer, that will be used right now only for debug graphics to test that everything with maths works!
Also, I bumped in the Function Pointers World...really fascinating, with simple code that can make you skip some branch to choose what to do on different situations and have some performance gains...
I'll try to use them in the core part of the engine, to avoid virtual keyword and to skip some branches; this engine is not a commercial-one, so I am free to experiment everything keep my attention!
Actually I written a non-template version of my math library, with some basic support for SSE/VMX code: premature optimization is the root of all evil.
So I'm moving forward to implement other core part of Hydra: camera, input and debug output!
Actually the camera is almost done, with all the code (like plane extraction, frustum vertex in world/view-space) working, the input is almost done and I'm writing the implementation of a directx9-based renderer, that will be used right now only for debug graphics to test that everything with maths works!
Also, I bumped in the Function Pointers World...really fascinating, with simple code that can make you skip some branch to choose what to do on different situations and have some performance gains...
I'll try to use them in the core part of the engine, to avoid virtual keyword and to skip some branches; this engine is not a commercial-one, so I am free to experiment everything keep my attention!
Friday, December 11, 2009
Small snippets
There are small snippets that can be used very well...
One is a simple software interrupt:
__asm int 3;
The second is more evolved, but if used correctly can wield to know everything about your code:
#define Stringize( L ) #L
#define MakeString( M, L ) M(L)
#define $Line MakeString( Stringize, __LINE__ )
#define Reminder __FILE__ "(" $Line ") : Reminder: "
so if you use the #pragma comment (Reminder ": TODO/HACK/FIXME") under MSVC compilers you will see the message in the output window, and with a double-click on it, you'll be teleported on where the code is written, so you can keep track of all the stuff you have to change...during compilation time!
Really useful, small and smart ;)
P.S. A really simple profiler is born, now I'm writing my math library from scratch, so to see some eye-candy you have to wait some days!
Next steps include:
Stay tuned ;)
One is a simple software interrupt:
__asm int 3;
The second is more evolved, but if used correctly can wield to know everything about your code:
#define Stringize( L ) #L
#define MakeString( M, L ) M(L)
#define $Line MakeString( Stringize, __LINE__ )
#define Reminder __FILE__ "(" $Line ") : Reminder: "
so if you use the #pragma comment (Reminder ": TODO/HACK/FIXME") under MSVC compilers you will see the message in the output window, and with a double-click on it, you'll be teleported on where the code is written, so you can keep track of all the stuff you have to change...during compilation time!
Really useful, small and smart ;)
P.S. A really simple profiler is born, now I'm writing my math library from scratch, so to see some eye-candy you have to wait some days!
Next steps include:
- Basic math library (with future support for SSE)
- Input handling (mouse, keyboard)
- Camera and Frustum classes
- Debug draw (lines, spheres, cubes)
- System coherence tests (project/unproject, world/view/screen space tests)
Stay tuned ;)
Tuesday, December 8, 2009
Math-o-centric view
One of the thousands of changes I'm doing in the new Hydra is the math system: my math always based on a template math library without any SSE-kind optimization.
I went into a journey that highlighted the lack of centrality of math code and the lack of SSE.
Is it really necessary to use SSE?
The real advantage of SSE is the use of instructions that works on 128-bit registers, and that can contains, for example, a 4d vector.
The BIG advantage of SSE is to use the mentality used when writing shaders to reorganize data in
Structures Of Array and gain a near 4x speedup!
After some study, I've decided so far to eliminate the template aspect of the math library: floating points is the standard de-facto. The real twist is the centrality of math: to use SSE, it is better to create a place in which all math is done; this ensure the possibility to apply different kind of math calculations (better for multiplatform development) without changing code outside the math system.
I think THIS will be the real power of the new design: all math inside the proper system!
After that big change, SSE optimization is a matter of time.
For example, Frustum Culling: imagine a method that performs a Frustum-AABB intersection
int Camera::intersectAABB(const AxisAlignedBox3f* const aabb)
even if it can be cool to let the camera calculate the intersection (by information expert, it can be either the Camera or the AABB), it is smarter to move this method in the math system, like that:
int Math::FrustumAABBIntersection(const AxisAlignedBox3& aabb, const Frustum& frustum)
this assure that if you want to implement different math (SSE/VMX/SPU-like) you can do it using the preprocessor.
I'll try this different approach, and profile the changes from template-based-sparse to float-centric math, and also to float-centric-sse-math.
I am really CURIOUS about the results!
Stay tuned, next time I'll post some timing and talk about the Core of the Engine!
I went into a journey that highlighted the lack of centrality of math code and the lack of SSE.
Is it really necessary to use SSE?
The real advantage of SSE is the use of instructions that works on 128-bit registers, and that can contains, for example, a 4d vector.
The BIG advantage of SSE is to use the mentality used when writing shaders to reorganize data in
Structures Of Array and gain a near 4x speedup!
After some study, I've decided so far to eliminate the template aspect of the math library: floating points is the standard de-facto. The real twist is the centrality of math: to use SSE, it is better to create a place in which all math is done; this ensure the possibility to apply different kind of math calculations (better for multiplatform development) without changing code outside the math system.
I think THIS will be the real power of the new design: all math inside the proper system!
After that big change, SSE optimization is a matter of time.
For example, Frustum Culling: imagine a method that performs a Frustum-AABB intersection
int Camera::intersectAABB(const AxisAlignedBox3f* const aabb)
even if it can be cool to let the camera calculate the intersection (by information expert, it can be either the Camera or the AABB), it is smarter to move this method in the math system, like that:
int Math::FrustumAABBIntersection(const AxisAlignedBox3& aabb, const Frustum& frustum)
this assure that if you want to implement different math (SSE/VMX/SPU-like) you can do it using the preprocessor.
I'll try this different approach, and profile the changes from template-based-sparse to float-centric math, and also to float-centric-sse-math.
I am really CURIOUS about the results!
Stay tuned, next time I'll post some timing and talk about the Core of the Engine!
Subscribe to:
Posts (Atom)