Skinning solutions and body animation

[Ingemar]

I am looking for advice on methods, code and model formats suitable to do body animations with skinning.

I know how skinning works, and I could implement it from scratch (I have even authored a student lab on skinning), but time is limited so I would like to avoid detours on not-so-good formats, and if there is good (modern) code around then it would be wise not to miss it. I fear that what I know is aging and I want to be updated.

Let's say, what is the current state on the subject? How do you work on body animation?

[User137]

My game engine is actually not that far yet to do bone based animation, but i know little about formats:
OBJ: Does support multiple objects and textures but no frames or bones.
MS3D(Milkshape3D): Propably supports it all but the format itself is weird. There is binary and ASCII versions, and i suppose different versions for the binary.
3DS: One of the most popular ones to support all. If you find a good model reader for this you can do alot.

Then there is also formats from other games like HalfLife 1 and 2, and Quake, was it MD2 and MD3 which had i guess compact bone animation format for gaming. I'm not sure how much Unreal-engines format is used, but graphics and models in their games are outstanding.

[Ingemar]

AFAIK MD2 and MD3 are a bit too old-fashioned these days. OBJ is nice for rigid objects but no animation data.

3DS is popular, no doubt about that. How about Collada, B3D? Any nice loaders/renderers around?

[AirPas]

xproger wrote an excellent tutorial about that http://xproger.mentalx.org/old/?id=1&page=2&doc=anim3d

you will find also a source code + 3DS max exporter

i personally used it

[Stoney]

While I never wrote my own model loader, when I used Unity3D and Horde3D I generally used Collada (and sometimes FBX in Unity) and I was really satisfied with it.
Collada shouldn't be too difficult to parse, since it's just a big XML file. But I don't think there are any Collada loader written in Pascal though.
There is also Restless (http://texelviews.delphigl.com/index.php?nav=3&theme=peach#restless), a model loader and format written in Pascal with a Blender exporter and it should support everything you for looking for. Unfortunately I haven't been able to get it working properly on Mac OS X as of yet. (Compiling the dynamic library works with some added compiler defines, but somehow it crashes in the example application.)

[Ingemar]

Collada shouldn't be too difficult to parse, since it's just a big XML file. But I don't think there are any Collada loader written in Pascal though.
On the negative side, I understand that Collada is a very complex format so writing that loader might take a lot of time.


There is also Restless (http://texelviews.delphigl.com/index.php?nav=3&theme=peach#restless), a model loader and format written in Pascal with a Blender exporter and it should support everything you for looking for. Unfortunately I haven't been able to get it working properly on Mac OS X as of yet. (Compiling the dynamic library works with some added compiler defines, but somehow it crashes in the example application.)
As you say, the library compiles with a few tweaks (Delphi mode + replacing dglOpenGL by GL + GLext), which is a very good sign. Most packages I find that are written for Delphi tend to be littered with dependencies and Win32 calls, so I am happy that that wasn't the case here.

So now I can try a demo though the debugger and see what happens.

[mobilus]

The longer I use GLScene, the longer I wonder why it was created, and since it was established why it is not used. You have the best format there - MD5 (I tried all) - just a few lines of code:


With TGLActor.CreateAsChild(GLScene.Objects) do
begin
Name:= 'Actor1';
LoadFromFile('actormesh.md5mesh');
MeshObjects.BuildTangentSpace(True, True);
StructureChanged;
TransformationChanged;
AddDataFromFile('actoranim.md5anim');
SwitchToAnimation('actoranim');
AnimationMode:= aamLoop;
end;

[Ingemar]

As you say, the library compiles with a few tweaks (Delphi mode + replacing dglOpenGL by GL + GLext), which is a very good sign. Most packages I find that are written for Delphi tend to be littered with dependencies and Win32 calls, so I am happy that that wasn't the case here.

So now I can try a demo though the debugger and see what happens.

It finds the file, but crashes in CreateVBO. Something is nil, and it looks like it is the current object. Or I am not allowed to take the address of a variable in the TRLS object. It is the @FVBO parameter to glGenBuffersARB that breaks.

glGenBuffersARB, BTW. Isn't it well overdue to drop ARB from glGenBuffers? Not that I have cleaned up every code snippet I have but in a library like this I think I would. But it shouldn't matter, of course.

[Ingemar]

Now I think I was all wrong; the problem must be that I don't initialize OpenGL properly.

I can't seem to use dglOpenGL, it doesn't compile, and the error "Generating PIC, but reference is not PIC-safe" is not understandable to me. But dglOpenGL shouldn't be needed anyway.

So I'll have to figure out how to initialize OpenGL in a way that enables glGenBuffersARB. Should be trivial.

PS: And it was: load_GL_ARB_vertex_buffer_object

So my current status is that is compiles, finds the files, runs... but doesn't draw anything.

Stoney, how far did you get? Where did it crash for you?

[Stoney]

Using Mac OS X Lion and FreePascal 2.7.1 I get this error while compiling and linking one of the examples:


Assertion failed: (_dependentDylibs.size() != 0), function File, file /SourceCache/ld64/ld64-123.2.1/src/ld/parsers/macho_dylib_file.cpp, line 391.
0 0x102efd71c __assert_rtn + 76
1 0x102f562c1 mach_o::dylib::File<x86>::File(unsigned char const*, unsigned long long, char const*, long, unsigned int, bool, bool, bool, ld::MacVersionMin, ld::IPhoneVersionMin, bool) + 2721
2 0x102f4abe2 mach_o::dylib::parse(unsigned char const*, unsigned long long, char const*, long, Options const&, unsigned int, bool) + 706
3 0x102f5c0a5 ld::tool::InputFiles::makeFile(Options::FileInfo const&) + 709
4 0x102f5d6f9 ld::tool::InputFiles::InputFiles(Options&, char const**) + 665
5 0x102efd947 main + 311


I used dglOpenGL to build the library, but integrated those changes (https://gist.github.com/1044116) in dglOpenGL to get it working properly on Mac OS X.


I'm pretty sure I was able to compile it on Mac OS Snow Leopard, but it crashed when I tried to execute one of the examples.

[Ingemar]

Then the question is where to continue, from your build (using dglOpenGL) or mine (using the built-in OpenGL). Yours crashes, mine runs but shows nothing. Not very easy to work from there I'm afraid.

[Ingemar]

Using Mac OS X Lion and FreePascal 2.7.1 I get this error while compiling and linking one of the examples:


Assertion failed: (_dependentDylibs.size() != 0), function File, file /SourceCache/ld64/ld64-123.2.1/src/ld/parsers/macho_dylib_file.cpp, line 391.
0 0x102efd71c __assert_rtn + 76
1 0x102f562c1 mach_o::dylib::File<x86>::File(unsigned char const*, unsigned long long, char const*, long, unsigned int, bool, bool, bool, ld::MacVersionMin, ld::IPhoneVersionMin, bool) + 2721
2 0x102f4abe2 mach_o::dylib::parse(unsigned char const*, unsigned long long, char const*, long, Options const&, unsigned int, bool) + 706
3 0x102f5c0a5 ld::tool::InputFiles::makeFile(Options::FileInfo const&) + 709
4 0x102f5d6f9 ld::tool::InputFiles::InputFiles(Options&, char const**) + 665
5 0x102efd947 main + 311


I used dglOpenGL to build the library, but integrated those changes (https://gist.github.com/1044116) in dglOpenGL to get it working properly on Mac OS X.

I'm pretty sure I was able to compile it on Mac OS Snow Leopard, but it crashed when I tried to execute one of the examples.
I just got curious: Is dglOpenGL better than the built-in OpenGL interfaces in some way? I want to use the best headers, obviously.

[Stoney]

I just got curious: Is dglOpenGL better than the built-in OpenGL interfaces in some way? I want to use the best headers, obviously.
The difference I've heard of is that dglOpenGL supports OpenGL 3 and higher while the FreePascal standard GL header doesn't. But that may just be misinformation on my part, because I've heard since that the FPC GL header supports up to OpenGL 4 as well. I've never tried it though.
On Mac OS X, it doesn't really make a difference, as Apple only has a complete implementation of OpenGL 2.1 in their drivers and everything newer is just partially supported. dglOpenGL has pretty fast updates, once a new specification has been releaved. (But they still don't officially support Mac OS X and each time they release a new header, you have to apply the patch I posted and in a few cases they patch didn't work and dglOpenGL was unusable on the Mac.)

[User137]

I think the major bonus is that you can use dglOpenGL header with both Lazarus and Delphi. It might be incredibly difficult to transfer fpc header to Delphi, and Delphi has its propably outdated header of its own.