SMF - 3D skeletal animation - Now with a custom Blender exporter!

TheSnidr

Heavy metal viking dentist
GMC Elder
Because of the limited uniforms, I've opted to resubmitting the vertex buffer for each emitter. I've made a logging system for keeping track of previous positions of moving buffers, but this only supports changes to the coordinates - meaning that if the emitter changes orientation, all the particles that have already been spawned also change the orientation of their starting positions, which in turn affects their current positions. This is visible in the cube emitter GIF I posted up there, notice how the trail of smoke looks like it's rotating along with the cube! So it is in fact an artifact, but in my opinion it's an acceptable artifact, at least in some cases.

So yes, indeed, the particles are completely deterministic, decided only by the emitter's time alive and the index of the particle, which is set in the vertex buffer. Their positions are calculated like this:
Code:
vec3 startPos = u_emitterPos[emitterInd].xyz;
float startScale = mix(u_partScale[0], u_partScale[1], gold_noise(partStartTime));
float startSpeed = mix(u_partSpeed[0], u_partSpeed[1], gold_noise(partStartTime));
float startAngle = mix(u_partAngle[0], u_partAngle[1], gold_noise(partStartTime));

vec3 currentPos = startPos;
currentPos += startDir * (startSpeed * partTimeAlive + u_partSpeed[2] * partTimeAlive * partTimeAlive); //Speed
currentPos += u_partGravAmount * u_partGravVec * partTimeAlive * partTimeAlive; //Gravity
float currentScale = startScale * (1.0 + partTimeAlive * partTimeAlive * u_partScale[2]);
float currentAngle = startAngle + partTimeAlive * u_partAngle[2];
Also, the vertex buffer is cut down to the absolute minimum:
Code:
var mBuff = buffer_create(partSystem[| SMF_partSys.ParticlesPerBatch] * 12, buffer_fixed, 1);
for (i = 0; i < partSystem[| SMF_partSys.ParticlesPerBatch]; i ++)
{
    for (var j = 0; j < 3; j ++)
    {
        buffer_write(mBuff, buffer_u8, i mod 256);
        buffer_write(mBuff, buffer_u8, i div 256);
        buffer_write(mBuff, buffer_u8, i div (256 * 256));
        buffer_write(mBuff, buffer_u8, j);
    }
}
 

TheSnidr

Heavy metal viking dentist
GMC Elder
Particle trails!

The effect in the gif requires a total of two draw calls

EDIT:
Made the trails persistent :D


EDIT2:
And a little stress test for y'all:
 
Last edited:

GMWolf

aka fel666
I think by double buffering the data on textures you could achieve much better performance. (Read position and velocity from one texture, write to other texture, swap buffers every frame)
 

TheSnidr

Heavy metal viking dentist
GMC Elder
Not sure I see what you mean, I don't use textures for storing data. I believe I'm squeezing as much performance out of this as possible, since the limiting factor now is the fragment shader. If I zoom out so that the particles cover less of the screen, the framerate increases drastically. Like we discussed, I don't think there's a viable solution to this problem in GM.

Edit:
I think I understand what you mean, but I don't see how it'll be possible in GLSL when I can't read from textures in the vertex shader.

Edit2:
Added the possibility to spawn particles upon death:


Edit3:
I made an emitter that spawns 100.000 particles a second that each spawn 30 smoke particles a second, and another 100 explosion particles when they die. The result is friggin thirty-two million particles on screen:




 
Last edited:

GMWolf

aka fel666
I think I understand what you mean, but I don't see how it'll be possible in GLSL when I can't read from textures in the vertex shader.
Damn, I always forget what you can / cant do with GM textures.
I have used textures in vertex shaders before, though I'm not sure it was with GM.
Would be nice if GM would update to newer standards...

That being said the performance is really good! More than enough for most uses!
Great work!
 

kagamma

Member
Hi Snidr! I am testing your model tool (v0.94) and I got this error randomly when I tried to add/modify bones on a skinned model.
Code:
############################################################################################
FATAL ERROR in
action number 1
of  Step Event0
for object oRigSystem:

trying to index a variable which is not an array
at gml_Script_smf_dualquat_multiply
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_smf_dualquat_multiply (line -1)
gml_Script_rig_save_smf
gml_Script_undo_save_animation
gml_Script_perform_actions
gml_Object_oRigSystem_Step_0
I also got this error when I try to add another bone right after undo without selecting a bone first:
Code:
FATAL ERROR in
action number 1
of  Step Event0
for object oRigSystem:

trying to index a variable which is not an array
at gml_Script_smf_dualquat_get_translation
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_smf_dualquat_get_translation (line -1)
gml_Script_perform_actions
gml_Object_oRigSystem_Step_0
 
M

Misty

Guest
Does 8.6 run on both studio 2 and 1.4 or just 1.4?

I prefer working in Studio 1.4, because Gm studio 2 lags for me no matter what computer i use.

Also, does this come with a speed test? About how many animated characters can you get before it drops below 60 fps?
 

TheSnidr

Heavy metal viking dentist
GMC Elder
8.6 works both in 1.4 and in GMS2. It is however a very old and outdated version, and the more recent versions for GMS2 are ridiculously optimized compared to 8.6. I haven't done any proper speed tests with the 8.6 version, but it doesn't take many fully rigged characters before the fps tanks. The latest version, however, can display several orders of magnitude more characters at the same time.

I don't use 1.4 anymore, so I haven't bothered keeping it updated.
 
M

Misty

Guest
8.6 works both in 1.4 and in GMS2. It is however a very old and outdated version, and the more recent versions for GMS2 are ridiculously optimized compared to 8.6. I haven't done any proper speed tests with the 8.6 version, but it doesn't take many fully rigged characters before the fps tanks. The latest version, however, can display several orders of magnitude more characters at the same time.

I don't use 1.4 anymore, so I haven't bothered keeping it updated.
It's just that gm studio 2 has unbearable lag for me, and it's IDE and sprite editor is hard to use, so I just import my projects from 1.4

I guess what I have to ask is, if I make a project using 8.6, it is easy to simply convert it to the latest update?
 
L

Lu9

Guest
This is pretty amazing stuff!
One suggestion I'd make is to be able to import already rigged/animated models from model formats like .ms3d (Milkshape 3D), .mm3d (Misfit Model 3D), .md2 (Quake) or .blend (Blender)
only one of these would be already good enough, as converting between (most of) them is easy.

Also is documentation for the scripts planned? It would be useful for beginners to know about, for instance, the terms used ("sample", "up", etc) and it would also be useful to make the variables "built-in" (there are variables used within the project file of course, but not if you want to start things entirely from scratch) variables such as the animation index, maybe even the x/y/z speed and gravity... but still, a few "premade" variables for some basic functions would be interesting.

Lastly I'd like to report an issue I had (which could be on my end, or not...) which is when trying to move bones for animating in your tool, I would get this error:
yAslZ3k.png
Is there anything I can do, or is it a bug?

Anyways, good luck with this project!
 

TheSnidr

Heavy metal viking dentist
GMC Elder
Thank you for the feedback, @Lu9! You bring up some important points that I intend to do something about. An FBX importer is in the works, and actually partly works already - it can import rigged and skinned models, but I haven't been able to import the animations yet. The limited FBX importer is in the latest version, so you can test it yourself.
Documentation is next on my to-do list! It is long overdue, but is a necessity at this point.
The error you're getting looks like an error on my part. Which tool does that? I'm on vacation atm, but will fix it as soon as I get home!

Edit:
I'll be back home aug 8th
 
Last edited:
L

Lu9

Guest
Thank you for the feedback, @Lu9! You bring up some important points that I intend to do something about. An FBX importer is in the works, and actually partly works already - it can import rigged and skinned models, but I haven't been able to import the animations yet. The limited FBX importer is in the latest version, so you can test it yourself.
Documentation is next on my to-do list! It is long overdue, but is a necessity at this point.
The error you're getting looks like an error on my part. Which tool does that? I'm on vacation atm, but will fix it as soon as I get home!
The model tool, in the animation tab. Simply moving any bone with the tool selected by default (Bone pitch, I think) will cause the error to happen
 
L

Lu9

Guest
the same error is still happening... although i was able to move some of the bones this time around.
 

TheSnidr

Heavy metal viking dentist
GMC Elder
Urgh, sorry about that. It's the remains of an old variable naming convention I used to use. Renaming ingrained variables is a bad idea!
Here's a hotfix for that error:
Download
Thank you so much for reporting it!
 

Morendral

Member
Can I make another humble request? Could you please add the 3rd person shooter back into the demo mix? I've been trying to re-incorporate it back from many versions ago, but much has changed since then.
 

The-any-Key

Member
I have been browsing for some mocap equipment that use fbx export. I found what I needed and was just interested on how the fbx importer is going for SMF? Not that I am eager or something. No noo.
 

TheSnidr

Heavy metal viking dentist
GMC Elder
@Morendral I will do that! I've been moving lately and only got internet in my new apartment today, hopefully I'll be able to be more active from now on :D

@The-any-Key No change on the FBX importer front I'm afraid :( It still only imports Model, rig and skinning, no animation support yet.

Here's what I've been working on inbetween everything for the past month:

It's a fully 3D A* pathfinding algorithm that automatically analyzes a level model and generates a traversable node grid. I plan to incorporate this into the SMF system.

Also, the particle system is now its own separate thing from the SMF system!
Here's the topic for the sPart system
I plan to make a "design particle effect" tool within the SMF model tool, but you will need the sPart system to actually use it in a game.
 
C

Cow

Guest
Nice work TheSnidr! Your examples have always been both edifying and inspiring to me. I'd love to play around with this a bit, hoping for documentation at this point (even open sourcing those might be a good idea). I haven't dug too deep yet, but the quirks of the collisions in the examples bother me a little -- is there the ability for low-level control of the collisions, or an implementation of sliding based on the collision normal?
 

sylvain_l

Member
@TheSnidr just figured a thing; the red dot are blocking node.
That means in it actual state the pathfinding only handle basic walking.

Any chance for developing more feature, like handling jumping/flying/swimming ? Even if it throught manual editing.
(a unit capable of jumping could fall from the bridge, or go up the smallest part of the slope at the start of it)
 

The-any-Key

Member
no animation support yet
Just let me know if I could contribute with funds to allow you to develop it. Even if it's for public use, I would really like to have this feature in the SMF engine. I know many of us often can't put time into some areas because we need to keep busy with other projects that accumulate money or make our long term project go forward.
 

matharoo

manualman
GameMaker Dev.
Thanks for making this program!

Importing an .obj from Blender, it doesn't keep the colors. Everything is white.

upload_2018-10-11_22-29-39.png

upload_2018-10-11_22-29-50.png

How could I fix this?
 

TheSnidr

Heavy metal viking dentist
GMC Elder
Oh, it should! Though I may have removed that functionality because some models got messed up... I recommend using textures instead of vertex colours, but I will re-include this functionality for the next version ;)
 

FoxyOfJungle

Kazan Games
It's a perfect engine! but,
I think you did not see my comment, so I had asked if there is any possibility of putting water with reflections, the "Shadertoy" contains many shaders.
I could even pay for your engine if you do it.
 

matharoo

manualman
GameMaker Dev.
Oh, it should! Though I may have removed that functionality because some models got messed up... I recommend using textures instead of vertex colours, but I will re-include this functionality for the next version ;)
Thanks for the quick reply! Any idea when the update will be out? :)
 

TheSnidr

Heavy metal viking dentist
GMC Elder
@Cow: Thank you! What specifically irks you? There are two types of collision scripts, those that simply avoid the model in the direction of the triangle normals, and those that compensate for the triangle normal to avoid sliding down small slopes. Is there something else you'd like?

@sylvain_l: My plan is to allow for many methods of movement. I also want to create some kind of visibility lookup map so that enemies can even look for cover :D

@Amon: Yes, there are scripts for shadowmaps in there! The demo that showcased this had to be removed to be able to upload to the Marketplace, but if you open the .yyz in the zip in the first post, you can use demo 6 for reference.

@FoxyOfJungle: Actual reflections are not supported at the moment, but the system allows for cheap reflection-like effects like sphere maps and equirectangular maps. Play around with the effects in the model tool ^.^

@matharoo: Perhaps after the weekend!


That said, I'm playing with the idea of splitting up the SMF system into smaller modules that are easier to understand, that can be used either individually or together. Any thoughts on this?
 

matharoo

manualman
GameMaker Dev.
That said, I'm playing with the idea of splitting up the SMF system into smaller modules that are easier to understand, that can be used either individually or together. Any thoughts on this?
Sounds good to me too. Makes it less confusing.

But yeah please get to the colors things first :p
 

Micah_DS

Member
That said, I'm playing with the idea of splitting up the SMF system into smaller modules that are easier to understand, that can be used either individually or together. Any thoughts on this?
I really love this idea. +1
It's nice to be able to pick only what is needed, giving a less cluttered project, avoiding needless bloat, etc.
 
L

Lu9

Guest
Just a heads up, but apparently the w.i.p. FBX importer does in fact also import animation. I imported an FBX model and the animation came together with it... although the model was in a completely wrong position, the animation still worked.
(I still keep my suggestion of supporting formats like md2, ms3d or mm3d, maybe they could be easier to implement, and in the case of mm3d it supports multiple animations)

This is also something I was concerned about, and it might already be in the engine, but I'll suggest it anyway: that we can simply execute the scripts that actually render the 3D, even if we don't have a -lot- of knowledge about how it works, so that we can focus more on the game logic, than on making the 3D itself work properly, it would be something more user friendly, but it's alright if that isn't viable...
 

The-any-Key

Member
that we can simply execute the scripts that actually render the 3D, even if we don't have a -lot- of knowledge about how it works, so that we can focus more on the game logic, than on making the 3D itself work properly, it would be something more user friendly, but it's alright if that isn't viable...
I am building a wrapper around the SMF engine. So I can do things with just some script calls. Ex this:
Code:
switch (state)
{
    case "init":
        // Init
        show_debug_overlay(true);
        // Create 3D engine
        instance_create_depth(0,0,0,obj_3D_engine);
        // Load models
        scr_3D_model_load("Own/World.smf","World",false);  
        scr_3D_model_load("Own/BackWheel.smf","BackWheel",false);  
        scr_3D_model_load("Own/FrontWheel.smf","FrontWheel",false);
        scr_3D_model_load("Own/FrontWheelRight.smf","FrontWheelRight",false);
        scr_3D_model_load("Own/Car001.smf","Car001",false);
        // Wait for models to get loaded
        state="wait for loading models";
        break;
    case "wait for loading models":
        if obj_3D_engine.loading_models=false
        {
            state="create camera and light";  
        }
        break;
    case "create camera and light":
        scr_3D_camera_create(0,0,20,0,0,-1,0,-1,0,0,0,1);
        state="create models in demo";
        break;
    case "create models in demo":
        test_model=scr_3D_model_create(0,0,0,"Car001");
        // Set model physics
        scr_3D_model_init_physics(test_model,70,30);
        // Make camera follow model
        scr_3D_camera_follow_model_set(test_model,30,15,5,3/game_get_speed(gamespeed_fps));
      
        scr_3D_model_create(0,0,0,"World");
        // Load nodes in model
        scr_3D_model_load_node_data(test_model,scr_3D_model_handle_car_data_TEMPLATE);      

        // Prepare vars
        rotate_value=0;
        state="move";
        break;
    case "move":
        // Save diff from last matrix
        //scr_3D_model_save_diff_from_previous_step(test_model,0);
      
        if keyboard_check(ord("W"))
        {
            scr_3D_model_ph_increase_to_speed(test_model,true);              
        }
        if keyboard_check(ord("S"))
        {
            scr_3D_model_ph_increase_to_speed(test_model,false);              
        }
      
        // Apply current physics
        scr_3D_model_ph_apply_to_speed(test_model,1);      
      
        // Rotate object
        if keyboard_check(ord("D"))
        {
            scr_3D_model_ps_turn_to_basis(test_model,70,60,false);
        }
        if keyboard_check(ord("A"))
        {
            scr_3D_model_ps_turn_to_basis(test_model,80,70,true);
        }
      
        break;
}
Creates a simple car movement with delta time that the camera follow:
simplecarmovement.gif

But you still need to know how 3D works (basis, matrix, object space, world space...).
The problem is to unify stuff. This will be for a future car game. So this wrapper will lack any stuff that is needed for ex a walking character game. Or a flight game...
 

IGameArt

Member
@TheSnidr How much work would it be to allow users to define their own vertex formats, and assign the various extra values from within your tool on a per vertex or a per goup of vertexes/polygons basis? My thoughts are using the tool to determine with rooms in my map will have different density and color fog values.
 

The-any-Key

Member
Just a heads up, but apparently the w.i.p. FBX importer does in fact also import animation. I imported an FBX model and the animation came together with it... although the model was in a completely wrong position, the animation still worked.
Yes. It seem it can import animations. But they are corrupted as you say.

[LEFT: Walk animation from iClone to FBX] [RIGHT: Import to SMF model tool]
Animation01.gif Animation02.gif

I tested different FBX targets. And Unity3D and Cinema 4D will have the rig inside the model. The other targets (3ds max, Unreal, Maya, Motion builder, blender) need to spin rig around X to put it in the correct position.

Export with 60fps also removes animation glitches [see above right image].

The funny this that there is a strange walking red guy in the "front" window that actually look better.
Animation3.gif
 

Attachments

TheSnidr

Heavy metal viking dentist
GMC Elder
Haha, that's some debugging stuff I used while trying to import animations! I forgot to remove it for the latest version of the Model Tool :p
I'm still around btw, sorry for not being so active in this topic. I've spent the last few weeks completely rewriting the model tool. I'm not done yet, but here's a small teaser:
 
Last edited:

The-any-Key

Member
I was about to send a PM and ask if you where still working on this. I am working on a 3D game and SMF has been invaluable.

Looks very promising with the weight paint.

The rewrite thing is about the modular system you where talking about before? So the Model tool can have a kind of plug-in system. I will truly support the FBX importer when you come to it. Is that is planned as a module/plug-in or in the main system?
 
Hello,
I have been trying to mess around with this tool, but keep on getting this error:
___________________________________________
############################################################################################
FATAL ERROR in
action number 1
of Step Event0
for object oRigSystem:
global variable name 'editorModelName' index (100202) not set before reading it.
at gml_Script_press_buttons
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_press_buttons (line -1)
gml_Object_oRigSystem_Step_0

All I am doing is click on "add model" and then trying to export it as .smf
Am I doing something wrong?
 

TheSnidr

Heavy metal viking dentist
GMC Elder
I was about to send a PM and ask if you where still working on this. I am working on a 3D game and SMF has been invaluable.

Looks very promising with the weight paint.

The rewrite thing is about the modular system you where talking about before? So the Model tool can have a kind of plug-in system. I will truly support the FBX importer when you come to it. Is that is planned as a module/plug-in or in the main system?
Yep, this is part of the process of turning the system modular! The collision system, for example, will function perfectly well without the rest of the SMF system - and it will even function without the Model Tool. The Model Tool will also be entirely open source. This is part of the reason for the rewrite - the old codebase was way too messy, I kept building new stuff on top of the old with no planning. This time I've rewritten pretty much all editor functions, and I've made pretty much all model manipulation part of the SMF system. So now you can generate normals and tangents, you can merge models, you can tesselate your models, create collision buffers, turn them into wireframe, and even rig and skin them through code.
You will also have full control over the material system, you can create and modify materials on the fly. The old version of the SMF system included a lot of shaders, and they all had to be included in the final game for the system to work. I'm going for a different approach this time - I've created a "default" shader that contains everything the SMF system can make use of, but it's all deactivated using preprocessors by default. This means that even though the shader contains all functionality, only the parts that are activated are actually compiled. To make use of, say, rim lighting and normal maps in one material, you duplicate the default shader and enable rim lighting and normal maps. I will write a proper tutorial for this.
The SMF system will no longer handle textures for you. Textures can still be included in the SMF model format, but this will not be encouraged. Instead, the model loading script will look through the internal sprites and see if the texture is already a part of the project. So in order to use internal sprites as textures, you only have to give them the same name as the texture you've defined in the model tool.
I plan to rewrite the level editor as well, but I will release the model tool before that is finished, meaning the level editor will not be included in the next release.

In short, I'm making the SMF system less invasive, giving the control to the user. I want it to be a powerful tool in the process of generating 3D games in GM, rather than a game engine in itself. Even though I'm adding lots of functionality to it, I'm also making it easier to understand and use for people who are not familiar with it.

As for the FBX format, I used a dll, but I couldn't make sense of the animation curves it gave me. Believe me, I spent MUCH time trying to figure it out, but I just couldn't do it. So if I give it a new attempt, I will prolly try to parse the fbx file myself. Before that though, I'm considering adding MD5 support, the format that Doom 3 uses. It seems like a simple task!

@NoobsWeStand - That's a bug with the "add model" button, it seems! The model name is based on the name of the model you load when pressing the "Load model" button. If you only press "Add model", that variable is never defined, which is why the error appears. It's unnecessarily convoluted systems like this I'm trying to avoid with the rewrite! For now, I recommend using the "Load model" button instead of "Add model".
 
Last edited:

DBenji

Member
Wow, amazing... I wish I had discovered it sooner!
In short, I'm making the SMF system less invasive, giving the control to the user. I want it to be a powerful tool in the process of generating 3D games in GM, rather than a game engine in itself. Even though I'm adding lots of functionality to it, I'm also making it easier to understand and use for people who are not familiar with it.
So does that mean we will have much more efficient ways of setting/resetting bone transforms during runtime? Think an almost unlimited number of bones for things like procedural animation/entirely scripted movement.

Generating a new sample entails two dual quaternion multiplications and a dq normalization per bone, so it's doomed to be slow.
...will this still be an issue in the new system? Is there any possible way around it that isn't performance heavy?

Also, (#grainofsalt) what would be nice is a way to combine 3d meshes/vertex buffers with Spine's skeletal bone system. Spine has some very performant and easy to setup bone constraints (ik, transform, and path constraints) that can be reset during gms2 runtime at very little cost. On the other hand, Spine's skinned mesh system is just so tedious to work with. (I'm thinking about this from the perspective of a 2.5d sidescroller type game. The z position of vertices wouldn't matter much as long as the character can only move along the x/y axis.)
 

The-any-Key

Member
Also, (#grainofsalt) what would be nice is a way to combine 3d meshes/vertex buffers with Spine's skeletal bone system. Spine has some very performant and easy to setup bone constraints (ik, transform, and path constraints) that can be reset during gms2 runtime at very little cost. On the other hand, Spine's skinned mesh system is just so tedious to work with. (I'm thinking about this from the perspective of a 2.5d sidescroller type game. The z position of vertices wouldn't matter much as long as the character can only move along the x/y axis.)
Have been researching this and Esoteric has no plans for now to make the mesh 3D. Currently it is only 2D mesh in Spine. So even if you get it to work. It will not look good. Because overlapping faces have no idea on what Y (z is up) they should be.
 

DBenji

Member
Have been researching this and Esoteric has no plans for now to make the mesh 3D...
Really? That's a real shame. The majority of their twitter posts show off the 2.5D capabilities of Spine's mesh system. I personally feel like it's a huge missed opportunity. No idea why Esoteric Software don't develop it further.

...So even if you get it to work. It will not look good. Because overlapping faces have no idea on what Y (z is up) they should be.
... I never said that I was trying to make a 3d mesh in Spine - although some people have tried and succeeded to a limited degree. The above problem you mentioned was the main issue, although there are ways to re-order the mesh vertices by assigning them to different weights in the hierarchy - but it's a highly involved and tedious process.
 

TheSnidr

Heavy metal viking dentist
GMC Elder
I will see if I can help out with the fbx parser. You was thinking of trying to parse it inside gm itself?
I will at least look at the possibility. I found the python script Blender uses to import fbx, it's a mastodon of a script! Are you familiar with the format from before?

Wow, amazing... I wish I had discovered it sooner!

So does that mean we will have much more efficient ways of setting/resetting bone transforms during runtime? Think an almost unlimited number of bones for things like procedural animation/entirely scripted movement.

...will this still be an issue in the new system? Is there any possible way around it that isn't performance heavy?

Also, (#grainofsalt) what would be nice is a way to combine 3d meshes/vertex buffers with Spine's skeletal bone system. Spine has some very performant and easy to setup bone constraints (ik, transform, and path constraints) that can be reset during gms2 runtime at very little cost. On the other hand, Spine's skinned mesh system is just so tedious to work with. (I'm thinking about this from the perspective of a 2.5d sidescroller type game. The z position of vertices wouldn't matter much as long as the character can only move along the x/y axis.)
There still is a maximum limit of bones! It's currently set to 32 bones, keeping it low in order to allow for other uniforms. We only have access to a limited number of uniforms, so budgeting them is important. I've been thinking of a way to potentially use unlimited numbers of bones though - by splitting up the model so that each part of the model only uses a small number of bones (say, 16, to make it more likely to work on mobile), and only the relevant bones are sent to the shader. It will take more computation, since each submodel will require its own unique sample, but it will work for an unlimited number of bones.
Generating a sample by interpolating between keyframes still requires several dual quaternion operations per bone, so for real-time animations, I haven't found any way to optimize it further. For non-real time animations though, you can precompute a bunch of samples and linearly interpolate between them, which is a super fast process. A game typically only needs real-time animations for the player, and static animations for enemies. You can also modify the sample for basic things like head turning and the like, but changing one bone in the sample will not affect the bones later in the hierarchy.

I haven't tried Spine actually, so I don't know if it's possible to get info about the rig in real time. Will have to look at it later!
 

The-any-Key

Member
I will at least look at the possibility. I found the python script Blender uses to import fbx, it's a mastodon of a script! Are you familiar with the format from before?
Not worked on this level with the FBX format before. But the parser is soon ready. The script will return a nested map with lists of all elements with their properties and data list and children/sub elements. It can use the JSON encode. The parser will however only work with binary FBX format. Not ASCII.
 

DBenji

Member
There still is a maximum limit of bones! It's currently set to 32 bones, keeping it low in order to allow for other uniforms. We only have access to a limited number of uniforms, so budgeting them is important. I've been thinking of a way to potentially use unlimited numbers of bones though - by splitting up the model so that each part of the model only uses a small number of bones (say, 16, to make it more likely to work on mobile), and only the relevant bones are sent to the shader. It will take more computation, since each submodel will require its own unique sample, but it will work for an unlimited number of bones.
Well, I didn't know there is currently a bone limit, but to clarify, I'm not interested in unlimited bones for models actually... I wouldn't want you to get focused on something that most of us might not need. I'm interested in being able to adjust many bone positions/rotations during runtime or produce realtime samples for things like procedural animation.

...You can also modify the sample for basic things like head turning and the like, but changing one bone in the sample will not affect the bones later in the hierarchy.
I'm perfectly fine with it not affecting other bones in the hierarchy. As long as you can reset the bone transform during runtime and it comes at cheap cost - and by cheap I mean you can have many bones doing this and it can run on most PCs. But if it's something that's simply not possible or difficult to achieve there's no problem.

Also, sorry if I didn't get the memo, but what's the current state of being able to import pre-made animations from Blender in this engine? If this isn't currently a feature, I would like to add to the voices of anyone requesting it.

I got to briefly try out the SMF tool. It's very impressive! It will definitely help many users who are new to 3d overcome/bypass the frustrations of having to learn to rig/skin/animate in 3d software like Blender and Maya.
A suggestion: being able to select where you place the next keyframe instead of having it appear halfway between two frames.
 
Top