Hello!

I've been doing some basic testing in MAX before getting down to some more serious work in creating a level for a game prototype. I wanted to do something that I thought would be very simple - create a door that slides open. So far, I've not been successful. I'm going to list what I've done and what the results have been and I hope that someone where can help me to resolve my issues. I am certain a good bit of this is my own fault, but some of it may be MAX's? I just don't know, so any help would be appreciated.

My first step was to create a very, very basic door with a sliding open and sliding closed animation and get it into MAX. My modeler of choice is Blender 2.93.6.

I created a basic door and did an Apply All to set the scale, rotation, etc. of the model:



Then I created a simple keyframe animation with three actions - Open, Close, and NoAnim:



This simple animated model was then exported to MAX as an FBX file and named Door_9 (my 9th test with this) and then imported into MAX. In this case, the door comes into MAX with all animations present:



I check off Static Object Mode, set Collision to Box, ensure the animations are named Open, Close, and NoAnim and set NoAnim as the default by clicking it's check circle. Then I import by clicking the Import Object button, make the screen shot, and click to bring it into my empty scene.



After placing a player start position and running the game, I run into my first issue - the player can walk through the door. There is no collision detection. Selecting the door shows that Collision shape is set to Box. Physics is set to Physics on and Show at start of level is checked. So, why does my player walk through the door? Looking at other doors supplied with MAX, they all seem a bit different. Some are "Static Mode" and some are "Physics". Some have "Affected by gravity" as a check box and some do not. Now, my previous imports of my simple door had the "Affected by gravity" check box and this one does not. I have no idea why they sometimes do and sometimes don't. But when they do and that box is checked, the door normally either drops through the ground or falls over and bounces a bit. But in none of the cases does the door block my character.

Guess what? After adding in some of MAX's doors, the Affected by gravity check box suddenly has appeared for my door, too. It wasn't there before. Now my door falls through the grid floor when I run the game ... even if Affected by gravity is unchecked. Nice. Setting Physics to Physics off solves this, but then my player can just walk right through the door anyway.

The good news is the Door behavior works. It will open if "E" is pressed and close, too. But what good is that if I can just walk through it.

So, what am I doing wrong? How do I fix this? If I can import an animated door that will block my player and open with the Door behavior, then I feel I can actually start making something in MAX.

Any help would be appreciated.

Hello Argent_Arts,

I'll be glad if my comment could help you.

Collision needs vertices to effectively work.
If you didn't subdivide your mesh in Blender then there are no vertices to collide with inside your door.

Secondly you need to select the parameter "isImmobile" in the "Developer Mode" of the "Objects Tools" then your door will keep its position on the terrain.
Preferably place it on a flat surface ( use the dedicated tool of the terrain modeler for that purpose).

Thank you. That helped (if I wanted Physics on). Even so, my player can still walk through the door.



That simply should not be the case at all. It's not in other game engines. A player's collision hull does not need to encounter vertices in order to collide. It just needs to encounter whatever the collision is - a collision box, etc. It's more of a field. You should be able to have a large cube made of only six faces and still get collision with no issues. You should not have to sub-divide the cube at all. Doing so only adds unnecessary geometry that could potentially slow down the game, especially if you had dozens or hundreds of these objects scattered around your level.

I can bring in the same door, unanimated, as a static model and set the collision type to BOX and it will stop the player perfectly. So, the issue is not the geometry, though I do appreciate you trying to help.

As evidence, below is a quick video. It shows two models - the white one is the animated door and the red one is a non-animated door. Both have the same amount of geometry (the same number of vertices). The red door blocks the player while the white door does not. The difference is the red door can be set to static, it seems.

I've animated made doors before as fbx embedded with the collision model. both the door and collision have their pivot set at 0,0,0 and only the door is animated. The collision automatically follows the door.... am not sure about GGMAX as I don't have a copy yet, but if you can upload the custom collision made in blender try that... door should not be set to phys but static, you don't want the door to fall or move out of place with phys...

Hi Agustine - Thanks. I don't see how I can upload a collision mesh to MAX ... yet. I've requested this on GitHub. When I imported the animated model into MAX, I checked the Static box. Even so, the model is NOT coming in as static, which is the problem, I suspect. So, this is most likely a MAX issue.

Hello Argent_Arts, once I get a copy of GGMAX will investigate and post my findings... I hope you resolve the issue soon.... btw, does the door open and close ok in GGMAX?

Yep. It does. The script is looking for an "Open" and a "Close" animation name, so I've named them that way. Once I get close to the door, I get the "Press E to Open" message and pressing "E" opens the door. Pressing "E" again closes it. So, working as it should in that regard.

As far as the collision/static issue - I've reported it on GitHub.

Hello Argent_Arts, is there a way to see the collision in action while testing ingame? A toggle shortcut key to show collisions so you can see what's happening to the collision..

Animated entities should be set as dynamic not static (otherwise they can't run the script)

A door should also be set issimobile = yes so it stays where you put it.

Collision is controlled by the script, i.e. CollisionOn(e ) when shut and CollisionOff(e) when open.

I have this and collision set to box and my player passes right through the door.



When no behavior is attached to the door (i.e. no script is controlling the door), the player still passes through the door. When the Door behavior is attached to the door, the player still passes through the door.

What does the collisionmode setting in the .fpe say?

collisionmode = 0

Weird! Sounds like you are doing everything right.

I tried importing the model without ticking the "static" checkbox and I can still walk through the model.

Now, I have three animations with this model - Open, Close, and NoAnim. NoAnim is just the door sitting closed. That shouldn't affect anything, right? Especially since I tested this without any behavior/script attached to it, so it should just function like any other model in the scene.

Hello Argent_Arts, what are your blender export settings for the door? Did you try welding the verts before export?

Does the door work in Classic?

Not sure why I would weld the verts before export. All I did was create a cube and scale it to shape it like a door. Then I applied the scale when done. So, no need to weld any verts.



I don't currently have Classic installed.

Here are my FBX export settings that I use for GameGuru MAX:

EDIT - No answer on the Discord yet. Removed last comment as it turned out to not be correct.

Okay! I may have a solution. I will be testing more to see what's what and reporting back here.

I was using Blender Actions (I think they're called) to create and name the door animations. So, I would make one animation from 0 - 30 and name it "Open". Then I would press the New Action button and name that one Close and create another animation where the door closed, again from 0-30. These animations came into MAX and, to MAX's credit, it saw them as Open and Close and had everything set up for me. But, for some reason, the collision was not working when I did this.

I then created a simple animation that went from 0-60 with the door opening from 1-30 and closing from 31-60. When I imported this into MAX, I just created and named two animations channels (open and close). This door had collision and it worked correctly with the Door behavior supplied.

So, it seems that MAX does not like keyframed animations made with Actions, but is fine with them all strung out in a single row.

Okay, this is getting frustrating. I decided to repeat my steps to see if I had a sequence I could follow so I could start making some real doors for a real level. But guess what? The next three test doors I made all came into MAX with NO animations found. None. Zero. Zip. Even though I made all of them the same way as the one that worked correctly. Importing the FBX files back into Blender shows the animations are there. So, it looks to me like there's an issue with the MAX importer.

I've noticed something else, too - even though the animation I've created in Blender is 60 frames long, it comes into MAX as 76 frames long! Why is that? I'll have to look into some of the export settings to see if they alter things in some way ...

what script are you using ? if it's the same as the GG classic, it doesn't work well. I recall having to use the legacy door version.

I have found the issue with why sometimes animated models are coming into MAX without animation and sometimes with. I believe it's a bug and I'll report it on GitHub.

If you create a model in Blender and rename it to make sense, MAX will not associate the animation with the new name of the geometry. For example, let's say you create a cube in Blender. By default, Blender will call this Cube. If you look at the list to on the left side of Blender, it's named Cube. But let's say you want to make Cube into a door, so you rename Cube into Door. Then, after you've reshaped it to look like a door, you animate it and export it. Once you import that model into MAX, it will say that it has no animation. Why? Because it will find an animation for Cube, but not one for Door! I can actually bring the model back into Blender and change the name of Door back to Cube, re-export back out and import into MAX and it will suddenly find the animation. And in the animation track in the importer, it will read - Cube|NameOfAnimation (swap out NameOfAnimation with the actual name of the animation).

This is a problem because we may have several parts to an animated model, such as left_side_door, right_side_door, etc. We will want to name models to make sense. But currently the MAX importer is going to be looking for the default names for some reason.

This is in GameGuru MAX and I am using the Door behavior.

I found the solution:



It's not good enough to just rename the top level Blender gives you when you initially create a piece of geometry, like a cube. You have to twirl down and rename the actual geometry there. Once you do that, MAX will associate the geometry and the animation.

Okay! I've even got Blender animation Actions working in MAX, which means I can NAME all my animations in Blender and they import, already named, into MAX. I'll try to put together a tutorial on this later today ... after I've had some sleep ... (or at least later this week).

Solved the issue as to why my 60 frame animation was coming into MAX at 76 frames ... I needed to set the FPS in Blender to 30 before export. Now I get a perfect 60 frames in MAX.

Argent_Arts, I'm glad to read that your tenacity helped you to find the solution to correctly animate your doors in GG MAX.
About the collision, my conviction about the necessity to subdivide a mesh came from years of practice with clothes simulations (Marvelous Designer). The particle distance played an important role in the collision of clothes with other meshes.



Here is a screen capture showing the required setting to export your Blender's animations with a FPS compatible with GameGuru :



Have a nice day.

Collision in Blender, and collision in the game engine are two completely separate things, collision data from Blender does not carry over to GameGuru Max, GameGuru Max uses simple collider shapes (box, sphere, cylinder, concave hull, and polygon), this is assigned by the engine itself and currently we can't add our own, for example a box collider in GGM will be a simple invisible box that conforms to the size of the object, so the number of vertices and quantity of geometry makes no difference as GGM will still create an invisible box around the whole geometry for collision.

Because of the way that collision works in GameGuru Max, the engine cannot move (or animate) an object while it has collision, so how a door script works is the object is placed with a box collision on it, then when you activate the animation it disables the collision while it animates, then when it has completed the animation it re-enables the collision box.

Unless you are good at scripting the only way to open and close a door is via animation (you can do it using quaternians and rotations etc. but that's an AmenMoses level of skill to script), and while most animators can animation multiple object meshes without bones, for GameGuru Max (if it's the same as classic) it is best to include a bone based key framed animation because there are issues with how GameGuru Max detects proximity to an object based on the camera angle and the origin point of the object, this was more prevalent in third person in classic because of the way the camera worked so not such a big issue in Max.

Belidos, thank you very much for your clarification about the collision's process inside GameGuru MAX.
Importing assets in GameGuru Classic and assigning a collision's method to them was sometimes an uneasy task.
In GameGuru MAX it is now much easier and much faster even if the process is invisible behind the selection parameter.

Conclusion (for me) : I'll follow the advice of Argent_Arts to reduce the number of polygons in my imported assets.

I honestly hope that open/close doors with animations in GGMax, don't be that hard to do, but just as GG does or something similar.
Really not willing to make a master just to open/close a door.

It's actually very simple. Most of my issues were just that - my issues - end-user problems. I plan to create a tutorial on how to get a simple door animated into MAX and working with MAX's default Door behavior.



As Belidos has pointed out - what you're talking about here has nothing to do with collision in a game engine. Cloth sims and the like in a 3D modeling program are very different than what goes on in a real-time game engine. As I had said somewhere in this thread, vertices don't mater when it comes to collision and you want to keep your models as light as possible (while still maintaining their shape) to keep frame rates up. But Belidos covered all of that.

Yeah, there are two camps here, modelers and scripters. To be both would be bliss. You could have had this working in 10 seconds with a non-animated slab using a script. I would recommend that going forward doors and similar basic items become scripted to move rather than animated. Using the script method is faster when you don't have to insert animations or import through the MAX importer. Also the player can be more interactive with the object. Thirdly Collision is always active, even if the door is currently opening or closing-- you can't walk through it's collision box. I'm pretty sure from playing games like Fortnite, they probably use a physical movement method.

If you want to script your doors, you just (actually very important)-- you need to pre-plan the object to correspond to lateral/width north @ original angle...... for sliding doors, or edge point 'x=0' at hinge for rotating doors. Then it's pretty simple script nearly identical to the animation script, but with this method you have full control and aren't inhibited by model animations.
Quaternions are useful for flying stunt planes or driving Matt's OffRoad Recovery across mountains- (to feedback a civilized 3-axis behavior)

As an example of a *sliding door* script, it could be something almost as simple as this; (but this itself won't work) I went ahead and wrote a completed script you can request from me. Very similar in function to small_g's scripts and I think I did a very similar script when somebody wanted a cage to fall down on the player when they got near it.

if door_closed == true then
if mf < 100 then
MoveForward(e, 50); mf=mf+ 1
else
door_closed = false
end
elseif door_closed = false then
if mf > 1 then
MoveForward(e, -50); mf=mf- 1
end

It may be the case in Fortnite or other games, but in GGc (i haven't messed with Max much yet) that is not the case, in GGc running a door animation with the default door script will turn off collision while it is opening. Place a door and stand in front of it as it opens towards you and see, it will go through you.

I wrote before that it was because of moving while collision is on can break the animation, but i've just remembered that was something different, that was physically moving objects, which would apply to the scripted method of opening doors. With animated doors In GGc the actual reason i now remember that the door script turns off collision while animating is to stop the player being trapped on or behind the door.