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