SMF - 3D collisions, animation, materials and level editor - Now works in HTML5!

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);
    }
}

 

Particle trails!

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

EDIT:
Made the trails persistent


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

 

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)

 

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:

 

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!

 

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

 

Thank you for the error report! I managed to replicate the error, and I believe I fixed it. Here's a hotfix for the issue:
Download v0.9.75

 

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?

 

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?

 

You could add water with reflection and refraction, would be perfect!

 

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:

Spoiler: Error

Is there anything I can do, or is it a bug?

Anyways, good luck with this project!

 

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

 

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

 

Shout-out to anyone using 3D this is sick lol!

 

Here you goooo, bug fix your you, very special

 

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

Spoiler

 

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!

 

Works correctly now!

 

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.

 

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.

 

@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

@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.

 

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?

 

@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)

 

Are shadows for objects possible? Great work by the way.

 

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.

 

Thanks for making this program!

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





How could I fix this?

 

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

 

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.

 

Thanks for the quick reply! Any idea when the update will be out?

 

@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

@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?

 

Sound good.

 

Sounds good to me too. Makes it less confusing.

But yeah please get to the colors things first

 

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.

 

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...

 

I am building a wrapper around the SMF engine. So I can do things with just some script calls. Ex this:

Spoiler

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:


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...

 

@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.

 

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]


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.

 

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
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:

 

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:

Spoiler

___________________________________________
############################################################################################
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?

 

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".

 

I will see if I can help out with the fbx parser. You was thinking of trying to parse it inside gm itself?

 

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.)

 

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.

 

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.

... 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.

 

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?

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!

 

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.

 

Oh really! Fantastic

 

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.

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.