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:

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:

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

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.

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.

Click to expand...

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?

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:

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!

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!

Click to expand...

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

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!

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.

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

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.

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.

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

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

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

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

Click to expand...

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

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.

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.

Click to expand...

Yes. It seem it can import animations. But they are corrupted as you say.

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.

Attached Files:

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?

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?

Click to expand...

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

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.

Click to expand...

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.

Click to expand...

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

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

Click to expand...

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.

Have been researching this and Esoteric has no plans for now to make the mesh 3D...

Click to expand...

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.

Click to expand...

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

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

Click to expand...

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!

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?

Click to expand...

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.

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.

Click to expand...

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.

Click to expand...

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.