MD5 Loader
@devsh: That's strange, cause vsync is definiteley turned off. I just checked it. In former times this was a windows bug (at least on my machines) i couldn't turn opengl vsync off in window mode (perhaps i have just been to dumb to do that ^^).
Today i smoothed the animations, it's now interpolating between the frames, but just linearly. This resulted in a small performance hit of ~100fps on my machine from 1700 down to 1600.
The next thing on my list is: clean up and make an alpha release, so we can have a more open discussion and especially test it on linux.
Version3
Today i smoothed the animations, it's now interpolating between the frames, but just linearly. This resulted in a small performance hit of ~100fps on my machine from 1700 down to 1600.
The next thing on my list is: clean up and make an alpha release, so we can have a more open discussion and especially test it on linux.
Version3
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Yep, there is definiteley still an error with one of the axis, i just had a short look into it, it's not very high on my priority list at the moment, but i will fix this during beta phase.
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Ok here is the first sourcecode release of my MD5loader. Instructions how to use it can be found inside the readme. It's still in a very early alpha stage as you can see. We still have a long way to go. We have to especially look at the AnimatedMeshSceneNode and the current SkinnedMesh and decide whether the SkinnedMeshMD5 and the SkinnedMesh should (or can) be fused or not. Also further speed improvements are definiteley needed.
An example how the SkinnedMeshMD5 currently works can be found inside the readme. There is not much you can do currently (apart from the basic SceneNode functions), just load meshes, load animations and set animations. Setting the animation to -1 turns off the animation and sets the model into bindpose.
It only loads the first mesh it can find in a .md5mesh file.
You can find it here
Now it's your turn, suggestions, critics and feedback is needed.
An example how the SkinnedMeshMD5 currently works can be found inside the readme. There is not much you can do currently (apart from the basic SceneNode functions), just load meshes, load animations and set animations. Setting the animation to -1 turns off the animation and sets the model into bindpose.
It only loads the first mesh it can find in a .md5mesh file.
You can find it here
Now it's your turn, suggestions, critics and feedback is needed.
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Hello r2d2,
I have been following this development for a while, and when trying to implement the MD5 Loader into the Irrlicht Source code, (following the readme text word for word), upon compilation I get a lot of errors;
This is just the beginning of the huge list of errors, which I can see has been caused somewhere in the CMD5MeshFileLoader.cpp to cause everything else to register as invalid.
Note: This only seems to happen when compiling in Debug.. Release however seems to allow the process to complete... Though even in Release, the following warnings register;
Is this a known issue? If so, is there a solution at hand?
Thank you,
Michael
P.S: I am using Visual Studio Professional (9.0), and Irrlicht 1.5.1
I have been following this development for a while, and when trying to implement the MD5 Loader into the Irrlicht Source code, (following the readme text word for word), upon compilation I get a lot of errors;
Code: Select all
1>------ Build started: Project: Irrlicht, Configuration: Debug Win32 ------
1>Compiling...
1>CMD5MeshFileLoader.cpp
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : warning C4229: anachronism used : modifiers on data are ignored
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2365: 'operator new' : redefinition; previous definition was 'function'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2078: too many initializers
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2440: 'initializing' : cannot convert from 'int' to 'void *'
1> Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2143: syntax error : missing ';' before '('
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2226: syntax error : unexpected type 'size_t'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(33) : error C2059: syntax error : ')'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : warning C4229: anachronism used : modifiers on data are ignored
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : error C2365: 'operator new' : redefinition; previous definition was 'function'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : error C2078: too many initializers
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : error C2440: 'initializing' : cannot convert from 'int' to 'void *'
1> Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : error C2143: syntax error : missing ';' before '['
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : error C3409: empty attribute block is not allowed
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(36) : error C2226: syntax error : unexpected type 'size_t'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(143) : error C2059: syntax error : 'constant'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(144) : error C2091: function returns function
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(144) : error C2802: static member 'operator new' has no formal parameters
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(144) : error C2333: 'std::locale::facet::operator new' : error in function declaration; skipping function body
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(149) : error C2059: syntax error : 'constant'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(151) : error C2091: function returns function
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(151) : error C2556: 'void *(__cdecl *std::locale::facet::operator new(void))(size_t,const std::_DebugHeapTag_t &,char *,int)' : overloaded function differs only by return type from 'void *(__cdecl *std::locale::facet::operator new(void))(size_t)'
1> C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(143) : see declaration of 'std::locale::facet::operator new'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(152) : error C2059: syntax error : 'return'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(152) : error C2238: unexpected token(s) preceding ';'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(155) : error C2628: 'std::locale::facet' followed by 'void' is illegal (did you forget a ';'?)
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(157) : error C2817: return type for 'operator delete' must be 'void'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(157) : error C2333: 'std::locale::operator delete' : error in function declaration; skipping function body
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(169) : error C2523: 'std::locale::~facet' : destructor tag mismatch
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(174) : error C2590: 'facet' : only a constructor can have a base/member initializer list
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(186) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(186) : warning C4183: 'facet': missing return type; assumed to be a member function returning 'int'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(187) : error C2143: syntax error : missing ';' before '&'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(187) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(187) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(187) : error C2143: syntax error : missing ',' before '&'
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(187) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(119) : error C2327: 'std::locale::_Refs' : is not a type name, static, or enumerator
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(119) : error C2065: '_Refs' : undeclared identifier
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(120) : error C2327: 'std::locale::_Refs' : is not a type name, static, or enumerator
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(120) : error C2065: '_Refs' : undeclared identifier
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(127) : error C2327: 'std::locale::_Refs' : is not a type name, static, or enumerator
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(127) : error C2065: '_Refs' : undeclared identifier
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(127) : error C2327: 'std::locale::_Refs' : is not a type name, static, or enumerator
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(127) : error C2065: '_Refs' : undeclared identifier
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(128) : error C2327: 'std::locale::_Refs' : is not a type name, static, or enumerator
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(128) : error C2065: '_Refs' : undeclared identifier
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(129) : error C2327: 'std::locale::_Refs' : is not a type name, static, or enumerator
This is just the beginning of the huge list of errors, which I can see has been caused somewhere in the CMD5MeshFileLoader.cpp to cause everything else to register as invalid.
Note: This only seems to happen when compiling in Debug.. Release however seems to allow the process to complete... Though even in Release, the following warnings register;
Code: Select all
C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(342) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
1>.\CSkinnedMeshMD5.cpp(48) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(53) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(58) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(63) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(77) : warning C4244: 'argument' : conversion from 'irr::u32' to 'irr::f32', possible loss of data
1>.\CSkinnedMeshMD5.cpp(120) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(122) : warning C4244: 'initializing' : conversion from 'irr::s32' to 'irr::f32', possible loss of data
1>.\CSkinnedMeshMD5.cpp(123) : warning C4244: 'initializing' : conversion from 'irr::s32' to 'irr::f32', possible loss of data
1>.\CSkinnedMeshMD5.cpp(132) : warning C4244: 'argument' : conversion from 'irr::f32' to 'irr::u32', possible loss of data
1>.\CSkinnedMeshMD5.cpp(133) : warning C4244: 'argument' : conversion from 'irr::f32' to 'irr::u32', possible loss of data
1>.\CSkinnedMeshMD5.cpp(135) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(143) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(161) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(181) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(192) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(388) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(397) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(403) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(600) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(627) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(639) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(647) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(662) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(677) : warning C4018: '<' : signed/unsigned mismatch
1>.\CSkinnedMeshMD5.cpp(704) : warning C4018: '<' : signed/unsigned mismatch
...
C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xlocale(342) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
1>.\CMD5MeshFileLoader.cpp(96) : warning C4101: 'animhierarchy' : unreferenced local variable
1>.\CMD5MeshFileLoader.cpp(97) : warning C4101: 'frames' : unreferenced local variable
1>.\CMD5MeshFileLoader.cpp(95) : warning C4101: 'animheader' : unreferenced local variable
1>.\CMD5MeshFileLoader.cpp(102) : warning C4101: 'version' : unreferenced local variable
1>.\CMD5MeshFileLoader.cpp(167) : warning C4101: 'version' : unreferenced local variable
1>.\CMD5MeshFileLoader.cpp(294) : warning C4244: 'initializing' : conversion from 'double' to 'irr::f32', possible loss of data
1>.\CMD5MeshFileLoader.cpp(465) : warning C4244: 'initializing' : conversion from 'double' to 'irr::f32', possible loss of data
1>.\CMD5MeshFileLoader.cpp(527) : warning C4244: 'initializing' : conversion from 'double' to 'irr::f32', possible loss of data
Is this a known issue? If so, is there a solution at hand?
Thank you,
Michael
P.S: I am using Visual Studio Professional (9.0), and Irrlicht 1.5.1
Yeah, totally forgot to mention, this is a known problem i am also encountering this problem, not yet sure why. I don't think that i will ever fix this problem. After toying around with Irrlicht again i noticed that the animation system Irrlicht currently uses doesn't fit my needs, so i will start writing my own engine from scratch, based on C# and slimdx.
greetz
r2
greetz
r2
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Well, i need an animation system, which primarily focuses on bone animation. The one Irrlicht currently uses definitely doesn't focus on bone animation, it still sticks to keyframe animations. Sure there are structures to use bone animation, but they are not very good. I think that one would have to totally break the current Irrlicht animation system, structures and interfaces to make the animation system fit to bone animations (and since Irrlicht wants to support keyframe animations, this task is definiteley not simple, you can't simply combine keyframe and bone animations in one interface without creating tons of overhead or spending much, too much time on it).
I thought about extending Irrlicht and implementing a new animation system, but i would have to break far too much interfaces to implement it the way i would like to see it. We would have to discuss all these interfacebreaking changes and i think that the discussion may even take more time then the actual implementation (especially because of the keyframe animation support).
I allready worked on a C# and OpenGL based engine, but never released it, cause it was in no way complete, but it worked. I don't want it to support many different filetypes or many different ways of scene management, i will keep stuff very basic to fit my needs (a nice, lightweight and clean bone animation system [attaching nodes to a bone, efficient reuse of skelletons, blending of animations, using different animations for feet, eyes, etc, animation of the skelletons taking place in a different thread (but this one is optional i'm not sure whether i will work on that)]).
My main point on writing a complete new engine is that it will take me less time than writing a new Irrlicht animation system. First of all, i would have to break many interfaces and assure that everything fits into Irrlicht flawlessly (so i would also have to study all the internal Irrlicht details, to be able to change the MeshLoaders, add AnimationLoaders, think about different file formats, etc), then i would have to take care of the keyframe animation support which i don't need and i have to discuss all these changes with the Irrlicht team, which is the most time consuming task.
I could also create an Irrlicht spin-off, a engine based on Irrlicht but managed by myself, until the Irrlicht team decides whether it wants to include the changes i made or not or perhaps modify it even more. But i am not sure if this would help the Irrlicht community much.
Other ideas are as allways, welcome
greetz
r2
I thought about extending Irrlicht and implementing a new animation system, but i would have to break far too much interfaces to implement it the way i would like to see it. We would have to discuss all these interfacebreaking changes and i think that the discussion may even take more time then the actual implementation (especially because of the keyframe animation support).
I allready worked on a C# and OpenGL based engine, but never released it, cause it was in no way complete, but it worked. I don't want it to support many different filetypes or many different ways of scene management, i will keep stuff very basic to fit my needs (a nice, lightweight and clean bone animation system [attaching nodes to a bone, efficient reuse of skelletons, blending of animations, using different animations for feet, eyes, etc, animation of the skelletons taking place in a different thread (but this one is optional i'm not sure whether i will work on that)]).
My main point on writing a complete new engine is that it will take me less time than writing a new Irrlicht animation system. First of all, i would have to break many interfaces and assure that everything fits into Irrlicht flawlessly (so i would also have to study all the internal Irrlicht details, to be able to change the MeshLoaders, add AnimationLoaders, think about different file formats, etc), then i would have to take care of the keyframe animation support which i don't need and i have to discuss all these changes with the Irrlicht team, which is the most time consuming task.
I could also create an Irrlicht spin-off, a engine based on Irrlicht but managed by myself, until the Irrlicht team decides whether it wants to include the changes i made or not or perhaps modify it even more. But i am not sure if this would help the Irrlicht community much.
Other ideas are as allways, welcome
greetz
r2
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Which parts fo the SkinnedMesh are focused on keyframe animation? Yes, bone values use key frames in order to get the values in a finite number of steps instead of using functions to describe the values. But that's how most if not all file formats also do it.
You simply store the joints and bone weights in the mesh, and add keyframe values for the translation/rotation/scale.
You simply store the joints and bone weights in the mesh, and add keyframe values for the translation/rotation/scale.
My own Doom3 model loading code was written almost three years ago, when Irrlicht didn't have any core skinning implementation IIRC. I'm pretty sure I didn't have to rewrite the engine in order to get it to work.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
First of all: i misused the word keyframe animations, what i was talking about was vertex animation. So please replace the word keyframe animation everytime i used it with vertex animation.
I never said that one would have to rewrite the engine in order to get Doom 3 models to work (i haven't rewritten the engine and my doom3 model loader works ). I just don't like the way animations are handled. The current way you have to handle bone animations is, that you have to load them into a mesh and hand the mesh over to the other mesh which should use that animation.
I think animations should be completely separate from meshes (if you use bone based animations). If you want to make the animations editable you would have to extend the SkinnedMesh class far to much, it would become huge.
But separating animations from meshes is quite hard (perhaps even impossible if you want it to be clean and more or less performant ) if you want to keep support for vertex animations. This is especially the point which i think would take much more time than rewriting my old OpenGL C# Engine and porting it to SlimDX (it also should be completely shader driven). But if you have any suggestions how one could do that (keeping support for vertex animations and seperating bone animations from the corresponding bone animated meshes) then let me know
The easiest way would be to use the Irrlicht engine and remove every support for vertex based animation and to create a spin-off (perhaps a completely shader driven spin-off, but that idea (the shader driven spin-off) just came across my mind while writing this post so i haven't thought about it much yet).
Any other suggestions (how we could separate bone based animations from the meshes) are welcome
Sorry for everything beeing so confuse
I never said that one would have to rewrite the engine in order to get Doom 3 models to work (i haven't rewritten the engine and my doom3 model loader works ). I just don't like the way animations are handled. The current way you have to handle bone animations is, that you have to load them into a mesh and hand the mesh over to the other mesh which should use that animation.
I think animations should be completely separate from meshes (if you use bone based animations). If you want to make the animations editable you would have to extend the SkinnedMesh class far to much, it would become huge.
But separating animations from meshes is quite hard (perhaps even impossible if you want it to be clean and more or less performant ) if you want to keep support for vertex animations. This is especially the point which i think would take much more time than rewriting my old OpenGL C# Engine and porting it to SlimDX (it also should be completely shader driven). But if you have any suggestions how one could do that (keeping support for vertex animations and seperating bone animations from the corresponding bone animated meshes) then let me know
The easiest way would be to use the Irrlicht engine and remove every support for vertex based animation and to create a spin-off (perhaps a completely shader driven spin-off, but that idea (the shader driven spin-off) just came across my mind while writing this post so i haven't thought about it much yet).
Any other suggestions (how we could separate bone based animations from the meshes) are welcome
Sorry for everything beeing so confuse
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Ok guys i just thought: "why the hell should i start my own project? That's crazy and not really the spirit of open source." I could slap myself for thinking of movin' back to my old abandoned project.
Ok here 's the plan. I will sit down and work out some possibilities how we could handle that animation stuff and separate bone and vertex animation interfaces from each other. And we will discuss it on IRC and in the Dev Discussion forum.
Ok here 's the plan. I will sit down and work out some possibilities how we could handle that animation stuff and separate bone and vertex animation interfaces from each other. And we will discuss it on IRC and in the Dev Discussion forum.
R2D2's Irrlicht Mods
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Messed up with my database so the page is not working at the moment -.-
CPU: Core 2 Quad Q6700RAM: 4096 mb Graphics: Radeon 4850 512mb Sound: on board InternetConnection: DSL
Hi,
I'm very interested in this loader which prevents me from recoding mine to fit irrlicht's architecture. I've tried downloading it and made some adaptations to make it "1.6 compatible" without problem but I have a problem at linking process.
||=== Irrlicht, Win32 - Release - accurate math - dll ===|
..\obj\win32-gcc-release-dll\source\Irrlicht\CMD5MeshFileLoader.o:CMD5MeshFileLoader.cpp:(.text+0x747f)||undefined reference to `irr::scene::CSkinnedMeshMD5::CSkinnedMeshMD5()'|
||=== Build finished: 1 errors, 0 warnings ===|
btw I wonder if ( and when ) this loader could be integrated into the main trunk ?
great job you did here btw.
I'm very interested in this loader which prevents me from recoding mine to fit irrlicht's architecture. I've tried downloading it and made some adaptations to make it "1.6 compatible" without problem but I have a problem at linking process.
||=== Irrlicht, Win32 - Release - accurate math - dll ===|
..\obj\win32-gcc-release-dll\source\Irrlicht\CMD5MeshFileLoader.o:CMD5MeshFileLoader.cpp:(.text+0x747f)||undefined reference to `irr::scene::CSkinnedMeshMD5::CSkinnedMeshMD5()'|
||=== Build finished: 1 errors, 0 warnings ===|
btw I wonder if ( and when ) this loader could be integrated into the main trunk ?
great job you did here btw.