General game physics

[Shannon Poole]

This post may be a bit long winded so I apologize in advance.

 

So I am working an ammo.js plugin for Babylon. As I go, I am trying to do a certain amount of preemptive problem solving. I am focusing mainly on the workflow to go from asset creation (including rigid bodies) to actually using it in game.

 

I've looked at Blender and using the Babylon exporter. At first glance this seems great. Simple enough, just add a rigid body to the mesh in Blender and export. Ok, but that only gives us a handful of shapes and it’s basically impossible to really debug and tweak. Blender does some black magic to fit the shape to the mesh but doesn't really give you any feedback on what’s going on. You can’t even really see the hull shape. How does it determine what the capsule shape is fit to if you have a complex model? Just the bounding box? What about the axis, is it always straight up? And when is that applied, just when you first add it? It basically becomes trial and error. You have minor tweaks that you can do such as margin but again you can’t see any of it so it’s hard to use. So that’s the basic rigid bodies in Blender, the kind that the Babylon exporter actually pays attention to. And this is what I am trying to emulate when the models are loaded using the ammo.js plugin and Babylon impostors.

 

Then there is the Blender Game Engine mode you can go into and have a little better control of the physics. You can actually preview the result but without real debug drawing it can be hard to really tell whether a capsule behaves as a capsule and not just a sphere. So now we have more control but the Babylon exporter ignores all this and beyond that BGE doesn't seem all that useful to me. Is that really enough to make a game with? Just dropping in a few hulls and calling it a day? Blender may not even be a viable tool for game physics. I have no idea but the name would suggest so.

 

I read that some game engines rely on named meshes with prefixes like UCX_ and UBX_ to determine the hulls. This seems like a better approach to me since you have full control over the hull and can actually see it. However I am still a bit confused on what happens when you combine animation with the rigid bodies. I think this is more of a game engine design issue but I’d really like to know what kind of data structure would come out of this. Would something like Overgrowth (Partial Animation Blending) be the ideal result of something like this? And if that’s the case I don’t think Babylon’s approach of impostors would really work. It would need to be hull to bone binding instead of hull to mesh.

 

So I spent the last couple of weeks trying to find any good information to help me come up with a good workflow. I am more of programmer and less of designer but I do have a little experience working with game artists and providing them with tools to create assets for my games, but never 3d. I haven’t really worked with 3d physics engines but I have a basic understanding of the concepts and mechanics and Bullet seems straight forward enough. It's the combination of meshes and rigid bodies that gets me and the actual asset creation. I feel like there are some huge gaps in accessibility for this type of thing. What are some other tools that people are using? Is there some way to make Blender work?

 

I have more questions but I don’t want to sound like a crazy person so I’ll stop now. I am more than happy to dig into this stuff, I have just become frustrated with the lack of information and I don’t want to go down one road and realize later that it’s been solved already and that my approach was idiotic.

[GameMonetize]

Perhaps Gryff, our Blender master can help you:)

 

BTW why do you need to be linked to blender? For cannon.js I tried to used bounding boxes in babylon.js to deduce sphere and box shape. For capsules I think we can do the same right?

[Shannon Poole]

So there is nothing tying me to Blender other than trying to find a tool that will let me create assets. 

 

I did the same for the ammojs plugin for boxes and spheres, but capsules and cylinders also have an axis. So it's radius height and axis. Right now I am just doing z up. But this seems pretty inflexible. Imagine a character with outstretched arms. It should be horizontal. I thought about just determining the greatest difference in min and max on any axis but that seems wrong too. I really think it will need to be decided by the asset creator. Which led me down this whole rabbit hole of finding a tool that would actually let me do that. The Blender with exporter approach seems out, in that regard.

[GameMonetize]

Perhaps we can consider the axis is defined by the bigger dimension?

[Shannon Poole]

That's sort of what I meant about the biggest difference in min and max. You just said it in a clearer way. I think this might work for some cases but it really limits what we can do with any moderately complex character rigging. If we force every capsule hull to be fixed to a whole axis, right? The axis should be basically arbitrary. Otherwise the chararacter has to be rigged with 90 degree angles everywhere which would be pretty odd

[GameMonetize]

Worst case: Let's change babylon.js functions to allow users to define values if required

[Dad72]

This is exactly this a what I thought: to be able to define our values would be the best option

[Shannon Poole]

OK that seems easy enough through code but that brings me back to what tools will allow us to do that during asset creation.

So basically I guess my real question is there a standard way of doing this? I would think that there would be some basic data format for rigging up hulls to meshes. So that an exporter (from any tool, not just Blender) would be pretty straight forward.

I also think we should consider the hull to bone approach that would be used for any ragdoll like character rigging. And what that would look like in Babylon.

I mean people must be using some tools right? I remember using MilkShape ages ago and I might consider trying to work with that again, but I might be misremembering how easy it was

[Shannon Poole]

Thanks fluffrabbit

 

Have you been able to do any character rigging with physics in Blender? I imagine it requires a complex setup of multiple submeshes and rigid body constraints. Without visualization it must be pretty difficult.

 

I'm looking for some tools that allow me to do the following

• Edit geometry with standard modeling tools
• Character rigging, animation, skinning, bones, etc
• Define and visualize arbitrary rigid bodies
• Bind rigid bodies to meshes and preferably bones
• Export to some standard format
• Import into babylon.js with minimal(if any) extra boilerplate

I have no allegiances to any specific programs so I am open to any suggestions. It could even be multiple different programs.  

 

I think I have come to the conclusion that the impostor approach is just not flexible enough for what I'm looking for so I think the last bullet will just end up being a wrapper and manager that I write myself.

[Wingnut]

Hi gang.  Interesting topic!  I don't know if it applies but I thought I should point out Andy Beaulieu's work at...

 

http://www.andybeaulieu.com/Home/tabid/67/EntryID/238/Default.aspx

[Dad72]

You are reasons fluffrabbit . This is not a standard feature of Babylon. Physical Babylon with cannon.js is extremely limited. Game of bowling or billiards, but then it becomes very tedious to use, or even impossible with RPG scene.

 

I opened an issue as to attach an impostor directly on a mesh with parent. Which simplifies things. I do not understand how Andy Beaulieu has to attach the mesh impostors. His demo was too much code to understand how it works.

 

[Shannon Poole]

I had come across Andy Beaulieu's post early in my search. While great work, it only further illustrates my point about the limitations of the current workflow. To create the fairly simple character he has to create a main impostor and then use cannon directly to bind up the rest. Which is all well and good but I really think we can do better. His code would have to change drastically if he decides to use the ammo.js plugin. I want to avoid that. 

[GameMonetize]

As I already mentioned I'm fairly open to update the physics code to something more reliable

[Shannon Poole]

Thanks Deltakosh

 

I'd like to come to some consensus on a good baseline for a file format. I'm really leaning towards the prefixed mesh names for defining collision hulls for several reasons. 

1. The specific creation tool becomes less important since most 3d modeling tools can handle submeshes and mesh names.
2. Exporting is pretty straightforward
3. Rigging can be done as you would any other character rigging
4. Visualization during creation doesn't require any plugins
5. Debug drawing (of at least the hulls) in Babylon is straightforward

What we would need / want for Babylon

1. A modified loader to keep the prefixed meshes from rendering unless using debug draw
2. A parallel approach for physics plugins for where impostors are too limited
   1. Should support hull to mesh and hull to bone binding
3. An extended all-in-one loader to automatically bind rigid bodies (inferred from character rigging and prefixed mesh names)

What's missing

1. A way to actually define physics properties like friction, density, etc

It seems odd to use this approach and then rely on some form of BGE to define the physics properties. I haven't looked into it but I wonder if would be possible to use materials (or textures) to define them. Then you could have a set of predefined materials that you could tweak later without modifying the model. It's in interesting thought but, again, I haven't spent any time thinking about the implementation.

 

Unfortunately I haven't done any development using TypeScript so I'm a little slow on getting started.

[GameMonetize]

I absolutely agree: friction and restitution should be moved to materials and loaded from .babylon file

 

But I'm not ok for the prefixed names. I prefer having specific objects in the file format that could be linked to the mesh at loading time. I'm not against creating a hull object type (like I did for skeletons)

[Shannon Poole]

I get that. Is your concern that you just want it segregated or that you'd like a better format for the rigid bodies than standard meshes? I think it might make sense to just do the inference during the export. It would make the exporters more complicated but we could just pick up the prefixed meshes then and move them into a separate object with binding info. The prefixed names are mainly to allow us to use traditional modeling tools to create the hulls without plugins but after that it's less important.

 

I will spend some time tonight going through the current .bablyon format and see if I can come up with a decent structure.

[GameMonetize]

prefixes are risky because what does happen if I name my mesh with the prefixes? I'm more for a robust solution(especially for the web:))

[Shannon Poole]

I see what you mean but it's a pretty standard convention with the Unreal engine.

 

A mesh named Mesh1 would have a complimentary mesh named UCX_Mesh1 for the collision hull.

 

I am open to alternative solutions though. This just seemed the most flexible and easiest to implement. You could even have an option to specify the prefix during load but that would mean the inference would be done during load and not during export.

[Dad72]

The imposter system is good. But it misses others.

The problem is to attach an imposter on a moving mesh. But if "parent" is supported, It would solve the problem. Then add an impostor ellipsoid for the characters.

Then it would be good to adjusted the ellipsoid depending on the size of the character with the scaling and position.

 

Then, should the physic for hilly land. Would be perfect. This is what lack was Babylon.
 
The Engine Unity3D is like that with rigidBody and collider. Land, they automatically have a collider which follow the form of the meshes.

[Shannon Poole]

http://cgcookie.com/blender/lessons/1-creating-rig/

 

After watching this video I realized something. It seems you are supposed to create entire alternate meshes to turn into rigid bodies using the blender tools. This never occurred to me. If that's the case I suppose impostors would work after all since you would just assign them to the simpler meshes which makes inferring size and axis much easier. I think I get what you're saying now dad72. If you could just parent those alternate meshes to the true mesh or bones it should all work together. Is this not supported in babylon right now?

 

The capsule shape is straightforward after that. I should be able to use the triangle mesh shape from bullet to create the hills you are talking about but we might want to consider using the height field terrain shape since I imagine its much more performant.

 

I think the only other part is to export rigid body constraints from blender as well.

[Dad72]

Here's how it works, which is I think the best ways. This is a video that explains how it works. The video is very interesting to understand what I mean.

 

http://unity3d.com/learn/tutorials/modules/beginner/physics/colliders

 

And this. The impostor for character movement. (rigidBody)

 

[Shannon Poole]

Oh interesting. It looks like Unity has a collada exporter (sold separately $20) that supports physics. Does it make sense to just create a collada -> babylon converter that supports physics? You know, use collada for it's true purpose.

 

I like the controls and visualization of physics in Unity much better than Blender. BTW the free version of unity can open .blend files.

[Shannon Poole]

Oh I didn't realize that. :-/ hmm there's a lot to digest here.

[Dad72]

and export 3ds max also... 

 

I think it's fine to add the impostors with babylon, rather than with blender or 3ds max.

 

The ideal would be to make more robust the current physic system which is a very good start, but not enough.

 

[Shannon Poole]

Yea I agree with fluffrabbit. The asset creation should be completely separate from the engine. Having worked with asset creators in the past it becomes incredibly difficult to explain anything outside of the tools they are used to. They aren't developers. We shouldn't expect them to be. Their talents lie elsewhere. Unless you are developer and artist then I envy you. I can't do both. 

 

The artists also need a quick way to preview their work in game. This means straight export -> import with no boilerplate. Otherwise they can get bogged down on details and a ton of time is lost transitioning between developer and artist to iron those out.

 

I also agree that parenting solves a lot of the missing pieces. 

 

I am trying to work with the blender exporter plugin but I am having a difficult time debugging it. Does anyone know if there is an easier way to reload it without having to remove the plugin and add it again every time I make a change? It's quite time consuming.