Well there's 2 main editors, the map editor which is like a 3d replacement for the room editor, and the model editor, which is completely optional whether you wanna use it or just use blender etc.
You can import a model and add the shader effects after you've imported it, the editor has full control of all the uniforms and samplers in each shader (It basically reads the shader file and interprets it, finding each uniform)
You can import the materials from the fbx, however this only imports each material, the attributes and the values, and the outcome of how they look all depends on the shader and which uniforms the values are mapped to. So this option could be useful in some cases if you've set up a very complex and precise \ fine tuned material, but in most cases you may aswell just import the model and set the shader up inside the editor, as you can see exactly how it's gonna look in the game with the particular shader you've chosen.
--side note, you can also import a model split into meshes if you need several different materials.
The shader settings can also be altered per object, rather than per model, meaning each object using the model can have different settings for the uniforms & textures, and also work per vertex buffer, if the model has several.
The game's levels need to be made in the map editor, and consist of 8 main object types:
- Entities - which use a standard gamemaker object with a 3d model, shader settings and a list of variables (which can be set in the map editor)
- Points - Simple coordinates that are built into the map and can be accessed any time by name or index, useful for spawn points or places a character should walk to. They can also contain rotation and scaling values for instance making a character face a certain direction when it's spawned.
- Areas - basically a cuboid (that can be irregular) that entities get logged into when they enter it, (not all entities, you get to choose which ones are checked) this can be used for activating events when an entity enters a certain place, like a trigger.
- Tracks - these are basically 3d paths, I would've used the word path but gamemaker already has loads of functions for this so track was the next best thing lol
- Cameras - these are optional, you can use an entity to do the same thing, but most of the time, you want a camera to just have one function and follow the player in some way, so with these you can set the step event, make them follow a track, and also which "render_state" they use.
- Render States - this is basically a list of stuff that gets rendered in the draw event, render states allow you to choose exactly what you want to be rendered at what time, so they make stuff like ignoring invisible places really easy, and rendering only the current place the player is in, which I don't need to say is gonna be so much better for performance. They're also incredibly quick to switch between, as they're all pre-compiled during the map loading process.
- Render Targets - this is a fancy word for rendering to a surface, they automatically set the surface up for you, allow you to assign a camera to render to it, and also allow you to set it as a texture in a model. Many juicy things are possible with these, deferred rendering, render to texture like cctv cameras, water refraction \ reflection, mirrors, shadows, the light shaft thing, ambient occlusion, sub surface scattering, you name it
- Lights - these just contain lighting properties for the light, direction, radius, color, brightness, and get compiled into a uniform array, which can then be read in a particular shader, there are several different formats, revolving around the shaders that read the arrays, but I've(or will) write all these shaders and indicate which format each shader uses.
All of the objects' actual ai and stuff is meant to be coded in gml as you normally would do, and you simply assign the object to the "entity", just the same as you assign a model.
I'm gonna include alot of starter scripts and templates like a 3d platformer, first person, topdown, vehicles and lots of rendering examples.
Most of the 3d model handling and rendering side of things is automatically handled within the engine, so you don't actually need to code any of that, you just use the ui and menus to define everything.
There are a few functions which are intended to be used in "game code" that control things like switching animations, models, shader uniforms, aswell as collision scripts which all revolve around the system I've built for "collision meshes" which are attatched to each model.
These include:
- Spherical collisions, where an entity is the sphere, colliding with the mesh, very precise and can return the angle \ normal of the collision, the surface normal and the up vector which can be used for making the entity bounce at a realistic angle or slide along it.
- Lines intersecting triangles, useful for vehicles, and things that are rectangular \ rigid, there'll be a few combo methods with this, for say a rectangle or cuboid consisting of several lines.
- Getting points on a triangle, for instance the place an object would land on the floor, or the triangle it's facing.
- And several others that work primarily in 2d, but use the z axis \ coord, as there are several situations where this is all that's needed, and is alot quicker than the full 3d methods
All the collision meshes are split into cells, which makes the checking process fast as it only needs to check a few triangles at a time.
Shader uniforms can also be controlled in realtime by entities, by linking a uniform to an entity's variable, this makes animated uniforms possible, like switching colors, flashing lights and animated textures.
I think I've covered every possibility with the system I've built, allowing multiple materials per model or object, the only thing that is restricted is using more than one shader per object, for that you'd need to make 2 objects that render in the same place, but this is pretty easy to do and that rare that its ok to have to do that now and again. It just didn't make sense to have this as a standard feature as the whole system would've had to be built differently and would be less efficient when rendering objects without multiple shaders per model.
Wow, that was alot of information, just wanted to be thorough and here's some pics of the actual gui: