Windows Warp3D - Beta Version Out Now!

Joe Ellis

Member

I've made a first person player object and laser projectiles with collision. Also cool oldskool sprites that always face the camera like on doom and things. I've done that with a special sprite shader that gets set at the end of the draw begin event after the 3d stuff is rendered, so the entire main draw event is reserved for instances with sprites and they can be drawn using the normal draw_sprite functions in their draw event like normal, the only extra thing that's needed is to set a uniform for the sprite's position eg.

shader_set_uniform_f(global.uid_sprite_pos, x, y, z)
draw_sprite(sprite_index, image_index, 0, 0)

Next week I'm gonna make some enemy ai, I've got it all planned out on paper
 

Joe Ellis

Member
I've created a saved game system, with files called Profiles.

Each profile is a node like all the other resources, and contains all the things needed for a saved game
eg. the current world, player variables like health ammo and armour, the inventory, and any global variables you wish to save.

The variables that a profile contains are fully customisable, and profiles can be edited in the editor,
they can also be created, saved and loaded in game, which is ideally what they're for,
eg. you can load and create them in the main menu and save them during gameplay, or at the end of a level.

The only thing you can't do with them yet is save the state of a level while your playing it, so every time you load a game you would have to start at the beginning of the level or at a certain checkpoint or save spot, which alot of games work like anyway, but I will eventually try to create a system for saving the state of a world, by making variable overrides for the instances and overriding whether each one is active or not, for if an enemy has been killed or an item has been collected.

I've also made a new resource type called a Preset, which is for saving instances, this is ideal for inventory items like weapons, cus they can all use the same object_index (obj_gun) but have different variables to make them the weapon they are.
You can spawn instances of presets during gameplay, which is ideal for projectiles, effects and any instances that are created dynamically during gameplay.

I've also improved the way collision is handled, by splitting it into 3 main parts\scripts:
collision_static, collision_dynamic and collision_precise.
Upon a collision, a second script is executed, which is a more specific script for that certain object_index. All of these scripts are easily defined in an instance's create event, or you can predefine them globally.

Collision_static is to check for instances that stay in the same place throughout gameplay,
like weapon pickups, health, ammo, triggers, teleporters and any static solid objects.
They get added to a grid when they are created, and any dynamic instances that need to check collision with them only have to check the current cell
they're in, so this ends up making them only need to check collision with 1 or 2 static instances at a time (if any), so this is a huge optimization
compared to every dynamic instance having to check every static instance in the level.

Collision_dynamic is to check collision with moving objects, like the player, enemies and moving platforms. These also get added to a grid but are updated dynamically ei. removed and added to\from grid cells every time they change cell.
This script is mainly used by dynamic instances to check collision with other ones, but is also used by projectiles and things that can harm characters, even though they aren't added to the grid themselves, cus characters shouldn't check for collision with projectiles cus there are potentially alot compared to the number of characters, so its much faster for the projectiles to check collision with characters in their current cell.

Collision_precise is the script I've already covered, for the polygon level collision.
It's mainly characters, projectiles and physical moving objects that use this.
For projectiles, they use a ray projection for triangles in their mask_radius.

I will have some footage of all these new things in action pretty soon.

Here's the current list of object indices, there may be a few more added but these cover almost every type of instance the template game needs.
And don't forget, they're designed to work with the preset system to make specific things, so these are very broad, general objects that are versatile.



And here's a picture of a blank inventory display:



I haven't yet finished the part where it renders the item's models, but that's next.
The inventory itself is just a 1d array, not a grid, so this makes it very versatile with whatever way you choose to draw the inventory,
there's not a set grid resolution so it can be displayed in any sized grid you want.
The inventory is designed to be a list of instance presets, which get created whenever an item is equipped.
A good thing about this is that when a preset is loaded ei. when the inventory is loaded at the start of the level,
it automatically loads the model it uses, so this stops any lag from loading models during gameplay when you spawn an instance of a preset.
 

Joe Ellis

Member
Here's some new stuff I've been working on this last month or so: (sorry no screenshots)
  • Made saving game during gameplay possible, saving exact states of levels
  • Improved dynamic light handling, allowing instances to emit light and made an automatic sorting system to deal with the max light limit
  • Improved variable handling, reduced cpu and ram usage
  • Reduced amount of node types, converted alot of them to instances instead
  • Made better way of calculating smooth vertex normals, using more of a median approach instead of mean, which illiminates bias from faces with the same normal and makes shading on quads and blocks look alot better.
  • Worked out how to do deferred rendering using the application surface alone (no extra surfaces)
  • Created a "pre depth pass" option, which writes the world's models to the depth buffer but not the pixels' rgba, then when rendering normally it eliminates overdraw and optimizes rendering a ton when using complex shaders.
  • Made a pathfinding algorithm, for using with navmeshes (points linked together)
  • Worked out how to build vertex buffers gradually while rendering them, which has made it possible to load models during gameplay without having to make instances that use it invisible while it's loading
  • Improved polygon-level collision method, roughly twice as fast as it was
 

JaimitoEs

Member
Everything looks great and tidy! I have seen that you make use of Constrained triangulation .
Have you implemented it in GML or is it a dll? You have done a great job with the Ui and the tools. The implementation of 3d models is great! I'm thinking of implementing something like that in my editor, it could do very well for a 3D sidescroller like Donkey Kong or Trine 1.
 

Joe Ellis

Member
Thanks :) It's all in gml. That sounds good, I'm sure you'll have no trouble implementing 3d models, the stuff that you've done so far is more complicated than that
 

JaimitoEs

Member
Thanks :) It's all in gml. That sounds good, I'm sure you'll have no trouble implementing 3d models, the stuff that you've done so far is more complicated than that
That's cool! For performance issues I decided to use the Ear Clipping technique, but I see your script very useful, especially for texture handling. Like your project I have decided to do everything in GML, I cannot resist the temptation to run the editor on a tablet and other compatible platforms. On the 3d, I put in the list to make a function to import models in Json format, it can be very good for the easy sending of information. Thank you very much for your comments, the same I say about your excellent work.
 

Joe Ellis

Member
I've finally worked out how to do the skeletal system I wanted to use, where rotations are applied in absolute space instead of being relative to the parent bone's rotation. They're applied directly to the bone's absolute rotation matrix and the relative matrix is then recalculated. (by multiplying the absolute rotation by the inverse of the parent's absolute rotation)

This means:
  • You can rotate the bones to be at any angle & orientation you want quickly and easily, without being restricted to only the x, y and z rotation values.
  • no more gimbal lock
  • no more having to wrap your head around how the bone rotates due to it being relative to the parent bone.

However, under the hood it still uses relative matrices, so it's still fully compatible with other model formats.

Here's a screenshot showing the bone heirarchy, which displays in the same tree like structure as the world editor:

Untitled12 3.png

When you click on or move the mouse over a bone(in either the heirarchy or in the 3d view), you can rotate it using the keyboard:

left\right: yaw
up\down: pitch
< >: twist

holding ctrl will switch it to "tilt" rotation:
(which uses the view angle as the axis (can be snapped to a certain amount eg. 90 degrees))

left\right: tilt sideways
up\down: tilt forwards\backwards

You can also hold alt and use the arrow keys to move the bones' positions in world space, and it recalculates the rotation matrices and bone length based on the change. This makes it really easy to construct a skeleton and the bind pose
However if you use this while animating, the lengths of the bones will likely change alot, so I've added a "preserve bone length" option, cus normally changing the length of bones in an animation will make the characters skin stretch quite unnaturally. But this might be a cool thing with cartoony characters which is why I've made it as an option.

I'll post a video soon showing this stuff in action, hopefully it'll show how much better this new setup is.
 

Joe Ellis

Member
I wanted to give abit of an update, although I've hardly got anything to show for the last few months work. I've been doing alot of deep engine level stuff that hasn't made anything look any different, but it's still alot of good stuff that I wanted to tell everyone.

One screenshot I've got is that I've added "smoothing edge threshold" as a setting for each mesh.
So it's able to have smooth shading and hard edges:

Cliff2.png

I've also merged the windows of each tool into the settings panel, so it just changes with what tool you're using. I think it's alot neater and more concise.

The rest of what I've done is technical engine things, that are getting it as good as possible.
The level editor is mostly complete, minus some functions for applying settings to all selected instances, and other handy things like that.
It now has infinite undo\redo. Although it doesn't work with deleted instances yet, you can't un-delete something, but I'll try to add that by keeping them in a "deleted items" list. There's also no undo\redo in the model editor yet, I'm starting to work out how I'm gonna do it though.

I've also started making an fbx importer from scratch in gml, so it won't need the dll anymore.
This will only work with the text\asci version, but I don't think this is a problem cus blender and most other model editors allow this.

Also with paths, created by joining points together, I've made it so you're able to make "flow" for each link between points (the direction you're supposed to move along it) which is essential for a game with cars and roads, consider police cars chasing you, every police car in the map is notified of your wearabouts and each has to plan a path along the roads to get to you. Without being able to know the direction you're supposed to drive along each road they'd end up crashing into all the other cars.
So now the pathfinding algorithm is able to [optionally] check that a link from point A to B is the right direction. By checking that point A is the 1st point in the link and B is the second, and if not, it will not consider this as a possible route and treat it as a dead end if there are no links that are in the right direction.

Also the final thing, (stop reading now if your not interested in files and data)

I've done a pretty huge optimization to the file format,
it used to work with strings for saving the type of each variable, it would save the name of the type as a string then interpret it when loading.
Now instead I've made every file save a "type list", with all the names of the types that file uses. When loading it, it creates a list of real type indices by interpreting each type name. So this has cut down the file size imensely and made it so there are only 20 or so strings that need interpreting, instead of 20 per instance.
Now all variable tables are saved with the name of each variable, and a single byte for the type index.
Also before, each instance would save it's variable table, with the name, type and value of each variable.
But the variable tables have identical var names & types per object, so only the values are unique to each instance.
So now I've made it save each table used by instances only once at the beginning of the file(the var names and types) and each instance now only saves the values of it's variables. So this has also cut the file size down alot, and made loading faster.

I've also added backwards compatibility measures, when each instance's variables are loaded from the file, it afterwards checks through the current variables table(not the one saved in the file, the one configured in the project) and checks that each variable exists,
if it doesn't it creates it and sets the default value from the table.
If it does exist, it checks the value is the correct type, eg. if it's a number it will return false if the value is a string or array.
If it's not the correct type it will set the default value instead.

So this has made all level files backwards compatible if you decide to change certain variables for objects after the file was made;
it will forget about ones no longer used that were saved in the file and add new ones that weren't saved in the file.
 

JaimitoEs

Member
Fantastic, I hope the world is aware of the unique value of the new tools that are yet to come for game maker. A need that many people were asking for is being met. Keep up the great work Joe !!
 

Joe Ellis

Member
I've improved the skeletal system even further, I've removed the need for relative rotations and a bind pose\set of inverted absolute rotations, and made it so the bind pose doesn't use any rotations in the first place, simply positions. Then when you're editing an animation you're directly editing the rotations that are passed into the shader, which are absolute. So when you adjust a bone's rotation you're simply adding extra rotation on to it, and it automatically applies this to all sub bones aswell.
I've also started using quaternions instead of matrices after realizing that you can lerp them and blend bone influences by multiplying each quaternion by it's weight and then add them together. With matrices I was weighting and adding the transformed vertex positions together and it wasn't a very accurate way of doing it.

Here's a video showing how easy it is to build a skeleton when you can just move the bones about, and I also got some very basic vertex rigging set up for the first time ever! I need to work on this part next and make tools\functions for assigning bones to vertices and adjusting the blending\weights.

 

z_bill

Member
I just learned about this and skimmed the posts...but this is going to work in GMS2?! Holy crap! Wow!

The version you released (and took down?) was the 1.4 version, right?

This looks so amazing and that it's gotthe level editor built right in is sorta blowing my mind!

Any suggestions on how I could prep a game, groundwork etc, to start using this (for GMS2) once it releases? Also, not to hound you, but have you set a loose timeframe for release?
 

Joe Ellis

Member
Thanks for the amazing feedback, stuff like this really motivates me and makes it feel more worthwhile :)

Yes, it will be for gms2. I'm going to port it once EVERYTHING is finished.
The porting probably won't take very long at all, as all the functions it uses are still in gms2 with the odd name being different.

I released it too early before, now I've decided to release it when it's completely finished, including a manual and tutorials. There's no actual date in mind, all I can say is that I'm trying to get it done as SOON as possible, while making sure everything is working as well as possible.

There are only 3 big hurdles left: the skeletal animation system, animation editor, and the lightmapper.
All of these are partly working, but need alot of finalization before they stand up along side the rest of the engine.. and I can't really just buckle down and finish them, cus I need to actually get my head around the things that are left to do.

Aside from those things, everything else just requires a few tweaks, bug fixes and extra handy functions here and there, and the progress with that is coming along really nicely and at a good pace at the moment.

I've also begun writing the manual, which I was struggling to do before, as a lot of things weren't finalized, so I couldn't really write about them in full.

And every day I'm making template\example objects (this is the fun part) All of which will be included in the release, and should provide examples of almost every type of thing in a game, whilst showing how objects need to be coded a bit differently in order to work with the engine.
All of this will be fully explained in the manual aswell, and together with the examples with commented code should provide a solid and easy to understand
starting point.

As for preparations for your game, it's hard to say, as so much of the game making process is done in gamemaker\gml along-side the Warp3D engine..
You could put together the skeleton of the project with objects with pseudo code of what they should do. Then when you have the engine it will be easier to put them into action. Also learning about vectors would make it easier to customize the collision scripts if you need to. Although it will be possible to just use the ones provided, there might be some situations where you want to slightly change what happens, and understanding what the maths is doing will help.
 

Joe Ellis

Member
More progress on the skeletal system:


Now I've got auto vertex rigging\weighting set up and working properly

I've also been experimenting with setting a bone's "capture radius"
To help stop parts of the model following the wrong bone (like the side torso following the arm bone if it's too close)
This'll make it easier to rig models without having to model them in a T pose.

On the video the rig starts off not looking right, but then I adjust the bones' radiuses and the amount of pinch around the joints and it ends up looking pretty good.
 

CMAllen

Member
More progress on the skeletal system:


Now I've got auto vertex rigging\weighting set up and working properly

I've also been experimenting with setting a bone's "capture radius"
To help stop parts of the model following the wrong bone (like the side torso following the arm bone if it's too close)
This'll make it easier to rig models without having to model them in a T pose.

On the video the rig starts off not looking right, but then I adjust the bones' radiuses and the amount of pinch around the joints and it ends up looking pretty good.
One of the methods of 'soft selection' used in most major 3d programs is topological-based -- the distance is calculated by following edges from the source point (or calculated backwards, from the end point, along edges to the vert nearest the source point) instead of just the distance between the source and end points. I mention this because it sounds like exactly what you're trying to achieve with smart-weighing bones.
 

Joe Ellis

Member
One of the methods of 'soft selection' used in most major 3d programs is topological-based -- the distance is calculated by following edges from the source point (or calculated backwards, from the end point, along edges to the vert nearest the source point) instead of just the distance between the source and end points. I mention this because it sounds like exactly what you're trying to achieve with smart-weighing bones.
Thanks, yeah it already does that, rather than measuring the distance from vertex to bone, each vertex gets the nearest point along each bone's vector from the parent to itself, basically a "nearest point on line" function.
The radius part is just used to stop certain bones from even being measured in the first place, like the elbow shouldn't affect the torso. So it first checks whether the vertex is in the bone's radius, then if it is, it gets the nearest point along it's vector, and gets the distance from that point to the vertex's position.
The nearest bone becomes the main bone, then it checks the bones connected to it, it's parent, and sub\child bones to find out which one is nearest. The nearest ends up being "bone_2" and then it divides the distance from bone 2 by the total to get the "blend ratio" between them.
 
Last edited:

Yal

šŸ§ *penguin noises*
GMC Elder
This looks really interesting, can't believe it's got under my nose this whole time! Gonna keep an eye on it for sure.
 

Joe Ellis

Member

I've made dynamic lights that use deferred rendering, which adds light & color over the top of the scene. I'm pretty happy with the result.
It's made it alot easier to handle dynamic lights, each one adds the light to the scene in it's draw end event.
I've done a similar thing to this for applying fog to the whole scene, and I'm planning on doing shadows like this aswell.
So now I don't have to make clones of shaders with\without fog, lights and shadows.

You might be wondering about performance. It's actually pretty good, it doesn't use any extra surfaces, it just needs to render the vertex buffers
several times, but there's plenty of room for more vertex buffers, and the batching system it uses is really efficient.
The lights can also be optimized by only rendering instances that are inside their radius, and using the collision grid it can get these instances really cheaply.
 

Joe Ellis

Member
I've done some stuff for the manual, the layout, page viewer, contents etc:



It's nothing special, but it's simple, straight to the point and has a nice oldskool vibe.

I spent ages trying find a good font to use, but couldn't find any that fit with the gui
so I ending up just using ms sans serif like everything else. Even though it's small it's actually really easy to read, so I think I'll just use that.

You click on a book to open it and see it's pages, and click on a page to view it.

For handling images on the pages, bullet points, titles\subtitles etc.
I've done an xml type thing where it reads special keywords in <brackets> and does a certain thing.
The actual page text files are like this:
Code:
<title>Bones
Bones are used to animate a model.
They are ordered hierarchially, starting at the root bone:
<img>Bones_Hierarchy 28 119
<goto> 28 298
Each bone has the following variables:
<bullet>X
<bullet>Y
<bullet>Z
<bullet>Yaw - Horizontal rotation
<bullet>Pitch - Vertical rotation
<bullet>Twist - Rotation around it's vector
<bullet>Length - The distance from it's parent bone
<bullet>Radius - (See <<Rigging>Rigging> for more details)
<title>Creating a Skeleton
To begin making the skeleton, you must first create the root bone in the model's hierarchy.
After that, you can right click on a bone to create other bones which stem off from it.
Use the arrow keys & pageup\dn to move it horizontally\vertically
Or double click on it to edit it's coordinates in the properties window

But are displayed like this:

 
Last edited:

Joe Ellis

Member
I've got some updates of really good stuff that I've done if anyone's interested, but I haven't got any screenshots cus I've been busy coding it all, but over the next couple of weeks I should have some cool stuff to show while testing the things.

The skeletal animation system is completely finished

All saving, loading, editing and handling playing animations in instances.
I've also made smooth transitions between animations when switching them,
like if you change an instance's animation from walking to attacking, it'll create a temp frame of the instance's current pose and set that as frame1, and frame2 is the first frame(or chosen frame) of the new animation.
Modifying bones during gameplay is possible aswell, like an enemies head turning to face you, aswell as attaching weapons and held object to hands.

I've made materials into global resources

Before you could only define materials in the model editor, which meant that if you wanted a model to have variations with different textures or materials you would have to make clones of the model with identical geometry but different materials.
Now you can just change the materials in the instance's properties, per mesh.
(models can have several meshes, meshes have a material assigned to them)
It's also way more efficient now cus meshes share the same global material, so less uniforms and textures need to be set.
You can also change instance's materials during gameplay

Examples of use:
  • Making blocks in the level editor and choosing what material each one has
  • Characters using the same model but different skin textures,
  • Switching textures as an instance gets damaged, like a car or a character having bloody wounds.
  • Applying a visual effect to a character, glowing when it collects a shield, turning into stone\ice, teleporting\disintegrating\fading away.

Instance presets are now fully working

Instances can be saved to a file, then spawned during gameplay or dragged and dropped into a level from the resource tree.
This lets you reduce the amount of objects needed in the game, if there are objects that all have the same variable names but with different values
you can just use one main object and create presets for each sub type that uses it.
This will be particularly useful for weapons, inventory items and enemies. Each thing can use one object like obj_gun, obj_melee, obj_item, obj_enemy_shooter, obj_enemy_melee and you can define the certain variable values each sub-type has.

Lists\Triggers

I've implemented a new type of node: "lists", which can be created in the level editor and sit in the hierarchy\scene graph like instances.
They can contain anything you want, instances, points, numbers, strings, and any resource type.
(You can simply drag & drop things from the resource tree and level hierarchy)

The idea is that they can be used by instances to deal with more than one thing at a time,
such as a trigger that when the player enters a certain area it will activate a list of instances in that area,
or a light switch that turns 4 lights on at a time and turns 3 off.

I've also made a new variable type for objects "var_any" which as you guessed can contain any type of value.
I did this to make triggers and switches more customizable.
eg. a switch has a variable "script", which is executed when the switch is used,
but it was quite limited with the arguments only being able to be one variable type,
I had to create different types of switches & triggers that do certain things,
eg. light_switch, activator_switch and they would just run 1 particular script, like instance_activate, and you would choose what instance or group of instances it would activate.

So now the arguments can be anything, it's opened up millions of new possibilities.
eg.
  • instance_set_model(instance, model)
  • instance_set_anim(instance, anim)
  • instance_set_variable(instance, var_name, value)
  • render_get_batch(list of instances)
  • material_set_texture(material, sampler_index\name, texture)
  • material_set_uniform(material, uniform_index\name, value)
You can make pretty much anything you want happen and set it all up in the level editor with a few main objects like obj_trigger_zone & obj_switch.

It's also made inventory handling really easy, you can just use one list, or two if you want items to have quantities
and loading\saving the inventory in saved games is completely automatic.. it just saves the list with the rest of the level.
I'm also gonna make a thing where the inventory is held on to during going to another level so that it doesn't start blank on the next level.

Here is a list of things I've thought of so far that the triggers, switches and lists can be used with that weren't possible, or awkward to do before:
  • Set any instance's variable to a certain value, using instance_set_variable(instance, var_name, value)
  • Render optimization (setting certain lists of instances to be rendered in certain areas (render_get_batch(list))
  • Activating\Deactivating groups\lists of instances
  • Animated textures: using an object called "obj_texture_animator" you choose the material it affects, the texture index, and a list of textures that it cycles through, and the speed\framerate
  • Random spawn points: instances can spawn at a list of points choosing one at random
  • Goto a random level on a list
  • Make a list of points for a patrol route of a character
  • A list of areas an enemy is allowed to walk in, or places where it searches for the player
  • Generate a certain effect or spawn a list of instances when an item is collected
  • Switches that make a block start moving or a door open
  • A trigger zone that when the player enters it, it goes to another level (world_load(name))

Also this is my to do list for the main things that need finishing:
  • Tooltips
  • Manual
  • Uv skin editor
  • Lightmapping (working but needs finalizing)
  • Mesh uv unwrapping (working but needs finalizing)
  • Manual bone weight painting
  • Drag texture onto world, creates a plane or billboard using it, or a quad if in the model editor
  • Precise line\ray collision for bullets
  • Non-uniform scaling (eg. for sizing blocks) (instance.scale needs to be a vec3)
  • Create model from level or selected instances
  • Checkpoints (save\load world state to\from buffer)
  • First person shooter example
  • 3rd person platformer\rpg example
  • 3d sidescroller example (where player and camera are fixed along 2 tracks\paths)
  • Make rom packing for finalizing a game (working but needs finalizing)
    (packs all game external files into roms: textures, models, materials, worlds)
After these are done I'll be starting to port it to gms2
 
Last edited:

JaimitoEs

Member
Definitely, here you have a buyer for your final version! I love seeing your progress, like TheSnidr, i can see in your effort the passion for your work. Come on! The goal is closer than you think! The documentation is somewhat heavy, maybe the part you like least to do, but this can evolve just like the engine, once you have the whole base of this and is ready in all its aspects to work on it, the updates do the rest. Otherwise, if you become obsessed with improving and improving, you never end up taking it out. Just a few small tips on things that have happened to me during my adventure .... If you feel like throwing in the towel, read this message again to fill you with energy. I will be a buyer.
 

Joe Ellis

Member
I've been getting the 1st person shooter template ready,
so far I've got basic movement, looking up & down, strafing and swimming.
I've made a quake style water effect aswell with fullscreen underwater effect
that turns on whenever the camera is under a water plane:


(The effects are fully adjustable in realtime aswell)

Next I've gotta get weapon handling sorted, health, ammo, armour etc.
and climbing up & down ladders. Then the 1st person template will be sorted.

I've also done a really good QOL improvement:

Meshes & instances can now use either materials or just single textures.
I did this mainly cus it was really annoying having to make a material for every single texture,
I made a shortcut, press M over a texture to make a material using it, but it was still awkward how there's a folder full of textures, and a folder full of materials which use those textures.

So now if you choose a texture instead of a material, it renders it using the default shader with the global directional light, sun color, ambient color and standard phong shading (smooth or flat depending on the mesh settings).
So this has made quick prototyping alot easier, instead of having to create a material for each texture that all use the same default shader
you can now just choose a texture and the engine is able to handle either in the same way.
Then later when you want more custom effects or multiple textures like normalmapping & specular masks you can make materials for those and swap them.

So now materials are optional, if your game doesn't need them, or you just wanna make the prototype without any fancy materials, you can.

Also here's a quick video a made earlier making a basic character model, it's only rough but I wanted to show what the model editor is like:


@JaimitoEs Thanks for the support! I agree with you totally, I'll be releasing it once my current to do list is done, I'm not gonna keep adding things to it now, cus they'll be extra things that could be released in an update.
 
Last edited:

JaimitoEs

Member
I've been getting the 1st person shooter template ready,
so far I've got basic movement, looking up & down, strafing and swimming.
I've made a quake style water effect aswell with fullscreen underwater effect
that turns on whenever the camera is under a water plane:


(The effects are fully adjustable in realtime aswell)

Next I've gotta get weapon handling sorted, health, ammo, armour etc.
and climbing up & down ladders. Then the 1st person template will be sorted.

I've also done a really good QOL improvement:

Meshes & instances can now use either materials or just single textures.
I did this mainly cus it was really annoying having to make a material for every single texture,
I made a shortcut, press M over a texture to make a material using it, but it was still awkward how there's a folder full of textures, and a folder full of materials which use those textures.

So now if you choose a texture instead of a material, it renders it using the default shader with the global directional light, sun color, ambient color and standard phong shading (smooth or flat depending on the mesh settings).
So this has made quick prototyping alot easier, instead of having to create a material for each texture that all use the same default shader
you can now just choose a texture and the engine is able to handle either in the same way.
Then later when you want more custom effects or multiple textures like normalmapping & specular masks you can make materials for those and swap them.

So now materials are optional, if your game doesn't need them, or you just wanna make the prototype without any fancy materials, you can.

@JaimitoEs Thanks for the support! I agree with you totally, I'll be releasing it once my current to do list is done, I'm not gonna keep adding things to it now, cus they'll be extra things that could be released in an update.
Very Cool! Your welcome man! ItĀ“s a very good project!! hand clapping emoticone!!:):):)
 

Joe Ellis

Member
Hi everyone, hope you're all staying safe

I've got some updates, first here's a video I made about 10 days ago, I wasn't gonna upload it and wait till I've got everything finished with the 1st person template but I wanted to keep you guys updated
There's a few cool things like bouncing projectiles and a "plasma" shader I made which is a cool oldskool effect where it blends between two colors in a swirly plasma-like way, using global.time which gets incremented every frame, you then multiply this by the uniform movement speed to affect how fast you want the material to move.
Also collecting things and screen messages saying what you collected (It was randomized on the video but now it's more customizable for each thing)


I've done a few other things since this video, mostly in code without actually testing and tweaking them though which is why I haven't got a new video yet:

Weapon handling, collecting new weapons, smooth switching between weapons, using different ammo and projectile types

Explosions

Destrucible objects (the crates) that drop collectibles (You can choose the collectible type and the quantity)

Hud displaying health, armour, ammo and the current weapon

View bobbing as you walk, and also floating up and down slightly when in water

Bullet & sight collision scripts,
Bullets can instantly hits walls and it returns the intersect point for making bullet holes and "poofs"
There's a similar script for sight checking, only it doesn't return the intersect, just true or false (useful for enemy ai)


Making the first person template has been a great way of testing the engine and I found & fixed quite a few bugs that I didn't know about.
Also it's made me realize that the engine itself and the editor are in a perfectly usable and releasable state, so I've decided I'm going to drop the few features that aren't finished for now and release them in an update.
Cus they're not essential features (mainly lightmapping, uv unwrapping and shadowmapping)
so people can start working on a game without these and they'll get them later with a free update if they need them

So once the 1st person template is finished, I think I'm gonna release it.

I want to make a 3rd person template aswell, for a platformer type game and an rpg, but I guess I can work on those
while the 1st version is released and people can get used to using the program for a few weeks, then those will be released in about the same time
 

Kentae

Member
That is just awesome ^^
I love the plasma effect! I can just see that used as a star in a spaceexploration game :)
Keep up the good work!
 

inertias

Member
Really cool update! I sadly have to wait for a port to gms 2, but I'm glad you're progressing well and are close to an initial release. Keep going! :D
 

FoxyOfJungle

Kazan Games
I'm really impressed with all of this! Few people create an initiative to do something new in 3D in the Game Maker Studio and it really looks promising! continues!
 

scorpafied

Member
not sure if your considering working on something like this. but i know some of the more modern tools for 3d have optimized things so it only renders whats in the players line of sight.

starts at about 1:40

thats a visual demo of what i mean. would help you optimize things to get a bit more performance. pretty incredible work so far btw. id love to mess around with that car demo u showed.
 

Yal

šŸ§ *penguin noises*
GMC Elder
not sure if your considering working on something like this. but i know some of the more modern tools for 3d have optimized things so it only renders whats in the players line of sight.
You basically get that for free in OpenGL... before you actually write to video memory, you transform the input coordinates using the world / view / projection matrices to get coordinates on the screen; if the screen coordinate is outside the visible region (e.g. negative z ---> it's in front of the screen), you can just stop there and not actually render anything. You find this result out really early on in the vertex step, before most of the heavy per-pixel computations are done in the fragment step.
 

TheSnidr

Heavy metal viking dentist
GMC Elder
You basically get that for free in OpenGL... before you actually write to video memory, you transform the input coordinates using the world / view / projection matrices to get coordinates on the screen; if the screen coordinate is outside the visible region (e.g. negative z ---> it's in front of the screen), you can just stop there and not actually render anything. You find this result out really early on in the vertex step, before most of the heavy per-pixel computations are done in the fragment step.
That's not the same though, the method in the video blocks out vertices that are obstructed even if they are in front of the camera.

That said, this will never be feasible in GM.
 

Yal

šŸ§ *penguin noises*
GMC Elder
That's not the same though, the method in the video blocks out vertices that are obstructed even if they are in front of the camera.
Ah, maybe I should've actually watched the video before assuming it was just vanilla optimization. Making research before I claim things isn't my style, though :p

Can't disagree with the conclusion, though. If anything is cutting-edge, GM most likely can't handle it (at a reasonable and stable framerate, at least). There's only so much throughput you can squeeze out of an interpreted scripting language, and anything visual tends to require a lot of repetitive heavy maths. Many AAA games have individual interfaces for different types of hardware to get that last little morsel of performance boosting, and GM just doesn't have that. (Running with GL ES 1.0 over a more modern version is just one of many places where it sacrifices power for maximal compatibility - after all, making one game and then basically just magically compiling it for every target you own with one click is one of its selling points)
 

Joe Ellis

Member
not sure if your considering working on something like this. but i know some of the more modern tools for 3d have optimized things so it only renders whats in the players line of sight.

starts at about 1:40

thats a visual demo of what i mean. would help you optimize things to get a bit more performance. pretty incredible work so far btw. id love to mess around with that car demo u showed.
Thanks for sharing the idea, but I think it's done entirely in the gpu, so it'd need a dll, and I've got hardly any experience in c++. Although, if it is possible, someone could write the dll and integrating it into a gm project would probably be really simple, just putting the dll call in the draw event. But it might only be possible with dx12
 
Last edited:

Joe Ellis

Member
Finally! the animation editor is working, it took me ages to work out all the gui side of it

Here it is, working with a rigged model, a sequence of frames, and playing and merging between frames correctly.
So it's safe to say that the animation system is set up and working :) (I'm so happy!!!)



@TheSnidr I just had an idea of making a model converter to convert to & from smf. and wondered if you would be ok it?
It's fine if not, but I thought it'd be good to make both tools cross compatible seeing as there aren't many 3d tools specifically for gm


In other news, I've got the rolling ball player object set up, and it's pretty darn fun

 

Micah_DS

Member
Wow! I haven't checked on the development progress for Warp3D for quite some time and I'm blown away! I'm excited about pretty much all of it, but I'm especially excited to see the animation side of things, and it looks fairly intuitive to use the animation editor, so that's awesome.

I have a few questions:
  • Will the editor be able to import GameMaker's vertex model files that were saved via the buffer_save function?
  • How does UV texture mapping work in your editor?
    If I wanted to maintain pixel density across an entire model and world, much like voxels, how easy/hard would that be to do?
  • Is the engine modular at all? For e.g., could I simply pop the animation system in to any game without using your entire engine?
  • Can this be used in HTML5?
-
I've improved the block tool to work in a minecraft voxel kind of way, but it has the advantage of not storing empty blocks and isn't confined to a grid, it just checks if a vertex exists at a position where its about to create one, and if it does it uses that vertex instead, so the blocks share the same vertices and get joined together, it also automatically deletes hidden faces, so the meshes end up hollow, which is most of the time what you want, -there is the option to disable this if you need the blocks to not be joined together.
Quoting a fairly old post here, but I forgot to mention way back that this is a feature I'd definitely use, since I have a project that needs a sort of tile-based 3D world.

-
BTW, up till now, I've been using Model Creator v5 (of course, I use a custom batch conversion program to convert ye olde D3D models into vertex models).
The reason I love MC5 so much is because you can work by creating and snapping all vertices to a grid. Even the UV mapping does it. The 3D art style I'm most passionate about is basically like pixel art, but in 3D, just like voxels, except without the limit of being blocky, allowing for angles, yet angled planes still conform to the grid. So that's what I'm hoping to be able to do with your editor.
 
Last edited:

Joe Ellis

Member
Thanks!

About importing vertex buffers, it can't currently but I was planning on adding it.
It should be quite easy to do cus I've already got a set of "vbuild" scripts for building vbuffers in every format combination, so I'd just have to make a matching set of "vb_load" scripts.
Then you'd just have to choose the correct format for it to load correctly.

I was planning on adding support for d3d models aswell incase its useful for some people, but I'll have to study the file format,
and the same with model creator's gmmod format, unless model creator has a d3d model export then I won't really need to.

If you have the code for the d3d to vbuffer tool and could share it that'd be really helpful cus I could make it alot faster that way.

About it being modular, I haven't really thought about this until you mentioned it, but I'll try to make the skeletal system modular.
You should in theory be able to just load the frame data and load a vbuffer from a file with the bone rigging\weights and bypass the node structure of the bones.
I'll try to make this possible, maybe by making an export script which exports the rigged vbuffer and frame data split per animation,
then an import script which sets it all up for an instance to use independently from the engine. It shouldn't be too hard to do.

About html 5 support, I have no idea to be honest, I've never used it and don't know anything about it.
I'll look into it once the first version is released, it might only require a few small changes,
although I'm doubting that it will be compatible cus of the engine using a dll to load textures from pngs.. But I'll def look into it.

About the modelling things

Vertices are automatically snapped to the grid res when created and movement is done in relation to the current grid res.
Rotation and scaling will mess this up, but there is a simple function "Snap to Grid" which snaps selected vertices to the current grid res.

The "Block Tool" (enabled by pressing B) should be fine for making voxel models,
a wireframe cube follows where the mouse is and can be offset vertically and horizontally using the arrow keys and pageup/dn, and you create blocks by clicking and dragging.
If "Voxel Blocks" is enabled in the geometry settings it will create one cube per grid cell
and vertices are automatically merged if a vertex exists where it's going to create one,
and also deletes faces that become hidden when the new cube is added.

It can't automatically create sloped pieces, but you can easily add them with the "Manual Polygon Tool".
To use that, you must be in vertex mode and press space on a vertex to begin the polygon,
then space again or click to add the next vertex.
If the mouse isn't over a vertex it will create one,
If it completes a full loop or you press enter, it finishes the polygon and triangulates it.

For uv mapping there are a few different options:

"Auto Cubic" mapping can be enabled for each mesh, (with adjustable scale) which is fast and always produces "acceptable" results.
This should be all you need if everything is made of cubes,
but there are also a few other more manual mapping functions:

"Planar" which uses the average normal of the selected faces and maps them in a flat contiguous section.
This is useful for bsp style mapping, and provides a better result with sloped faces than the auto cubic mapping.
There is also a combo function which sort all faces into sections and applies the mapping to each section.

"Affine" The most basic type, the stretched look of levels on ps1 games.
This generally works with quads, as the textures are square,
and you can apply this to one quad at a time by using quad selection mode and pressing Shift Q on the quad.
You can also use this with tilemaps, you're able to select the tile uvs by clicking on the texture square in the palette section
and then the quad is mapped with the chosen tile.
There is also a combo function which detects all quads and applies the mapping or tile to each one.

"Unwrapped" The most complex type, the result is similar to Planar but instead of using the average normal of the selection,
it generates planar uvs for each face individually and then rotates & glues them together,
so there is no stretching\irregularity in the texels.
This is the best result for character uv skins and lightmap uvs, and probably the best for everything unless you want the mapping to look one of the other ways on purpose.

You can also edit uvs manually by holding down shift. Shift is the key for anything to do with editing uvs.

Drag the mouse or use the arrow keys to offset the uvs by the chosen uv res in the "Snap" section in settings,
use the mouse wheel to scale them
and < > (, .) to rotate.

There are a few process type functions aswell, invert, flip, swap, normalize,
and I want to write one which detects overlapping sections and moves them so they're not, like lays them out on a sheet.

There is also a "Uv Viewer" which displays a wireframe of the uvs, which can help alot when creating & editing a uv skin or lightmap uvs.
 

Micah_DS

Member
About importing vertex buffers, it can't currently but I was planning on adding it.
It should be quite easy to do cus I've already got a set of "vbuild" scripts for building vbuffers in every format combination, so I'd just have to make a matching set of "vb_load" scripts.
Then you'd just have to choose the correct format for it to load correctly.
Awesome! I'm very happy to hear that.

I'll have to study the file format, and the same with model creator's gmmod format, unless model creator has a d3d model export then I won't really need to.
Interesting. I always assumed Model Creator just used d3d_model_save, but I just looked at the source (found here) and that's not the case.
That said, I'm still 99% sure it saves the exact same information as d3d_model_save does, because the info found in the models saved in Model Creator matches the info from here:
So it appears to be the same simple lines of text, whether saved via the d3d_model_save function or via Model Creator.

If you have the code for the d3d to vbuffer tool and could share it that'd be really helpful cus I could make it alot faster that way.
All you need is a script @xygthop3 made. It's the "vertex_buffer_d3d_model_all" script found within this asset project:
That one script will give you all the information you need to understand the d3d format (if the link above didn't already) and how to convert it to a vertex buffer. It's super easy to figure out, even for an average programmer like me, haha. I'd post the code from the project myself, but I'm unsure if that would be okay. Even though it's a free asset, I don't know if doing so is within the wishes of the author.

About it being modular, I haven't really thought about this until you mentioned it, but I'll try to make the skeletal system modular.
You should in theory be able to just load the frame data and load a vbuffer from a file with the bone rigging\weights and bypass the node structure of the bones.
I'll try to make this possible, maybe by making an export script which exports the rigged vbuffer and frame data split per animation,
then an import script which sets it all up for an instance to use independently from the engine. It shouldn't be too hard to do.
That would be absolutely fantastic. But - after reading your response to HTML5 support - I have another question on this topic:
Would a modular version of the skeletal system require any dlls, such as the dll to load textures from pngs, or is it all accomplished with GML and shader code?
I ask because the thing I could use more than anything for HTML5 is animation. even if the rest of the engine won't work in HTML5, I'd be more than happy with just being able to use the animation.

About the modelling things
(snip)

For uv mapping there are a few different options:
(snip)
Awesome. That sounds like something I could work with once I got used to it. It sounds like I could accomplish the same texturing style that I like to do in Model Creator, and more.
It's pretty hard to tell without using the program to get a feel of the tools and the workflow, but I'm thinking I might be able to move on from Model Creator to your editor, so that'd be neat.

-
I'm very grateful for your professional response. No matter what you end up able to do or not able to do regarding my requests, I can see myself using this engine, so I definitely plan to purchase it once it's released. :)
 
Last edited:
Top