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.