How to: change a skin mesh

Hi,

a common method to apply interchangeable cloths to character is to parent empties to bones and dynamically parent the several devices, weapons, cloths.

Unfortunately the new clothes are solid as steel an do not bend with the character.
This is perfect for weapons, armor and devices. Smooth clothes as pants, jackets, shirts can’t use this method as they should bend with the characters animation.

In-game there is currently no method to armature parent objects to armatures. (Or I simply do not know the right method).

But it is possible to change the mesh of an already armature parented object.

It is not necessarily a good idea to replace the skin mesh with pure cloth (except no skin is visible :wink: ).

But you can have multiple objects armature parented to the armature. E.g. skin mesh, boot mesh, pant mesh, shirt mesh, jacket mesh, hair mesh etc.

The idea is to add dummy meshes that can be replaced via replace mesh actuator.

Example:


Attachments

ManCandy 2.62_clothes.blend (1.59 MB)

Can’t you use two armatures, as following:
1] driving-armature (player controlled)
2] driven-armature (object (cloth) deforms by this armature)

Link the driven-armature to the driving-armature,
the driven-armature follows the driving-armature,
the driven-armature deforms the object (cloth)…

? (although your solution sounds like a solid solution)

Finally a solution for making a clothing system.

Does every clothing piece have to have the exact same topology and vertex count? Can a t-shirt be replaced by a jacket? Or a suit of armor?

Cool, thanks for share monster, this content is really awesome a lot of people usually wants to know how to do this, great!

No it follows the same rules as each other skin mesh:

  • vertex group names = action channel names

You do not even need a modifier at the object that holds the mesh. It uses the armature modifier applied to the original skin mesh (hook).
The hook does not need to have a vertex. It can be empty (but not an empty object).

The restriction on this method is: you can’t add new skin meshes. They have to be present already. With a little ahead planing this shouldn’t be a big deal.

The alternate way as crumpet suggests needs additional armatures. They have to play absolutely synchronous. And they eat twice as much processing power.

To make say… a shirt on a character. I would highlight the model/armature and Shift D dupilicate and enter. I slightly scale up the duplicated model. I go into edit mode on the new model and delete all vertices except for the shirt area. Then you scale it to fit perfect. And when you move your original armature in pose mode. The shirt moves perfectly with it. They both use the same armature. im not sure if this is what you are talking about though :D. I have an example of it, though im not so good at rigging :D. Apologies if im even talking about the wrong thing :smiley:

Superflip: this is a very good method to create cloths for a character. I used this method in the example.

The point is with the described method (post #1) you can exchange the shirt with another shirt during the game. This allows cloth customization.

Interesting. This might be useful for one of my BGE competition ideas.

why not just use the visibility actuator?

Because you would need ALL possible meshes present at once.
This is hard to manage when designing the character.
And it is very inefficient as all meshes needs to deform regardless if visible or not.

Thanks for this little pointer, Monster. I’m looking into customization for a project, and didn’t even think about using replaceMesh() (even though I used it before). That should work out nicely.

Is it still the case that if you replace the base mesh with another object (of a different shape) the collision hull remains that of the first, original mesh?

I believe so, but you can call reinstancePhysicsMesh() or the equivalent logic brick to fix it.

This method doesn’t seem to work using LibLoad. If I load an external mesh:

bge.logic.LibLoad(Path, 'Mesh')

and try using replaceMesh():

object.replaceMesh('LoadedMesh')

I get this:

warning: ReplaceMesh() new mesh is not used in an object from the current scene,
 you will get incorrect behavior

The new mesh loads. The old mesh is replaced by the new mesh. However the loaded mesh will not deform with the armature.

Perhaps this is what Monster meant when he said:

The restriction on this method is: you can’t add new skin meshes. They have to be present already. With a little ahead planing this shouldn’t be a big deal.

Yep, that’s exactly what Monster meant. So you’ll have to reload the scene to bring in new meshes. Or possibly you could load in an armature with the mesh you want on it, then delete the original armature tree. Haven’t tried it, but let me know if it helps if you would thanks.

Maybe load skin mesh in another scene and loading with this?

Or saving the skin mesh in a group in a .blend using append and any option to restart game?

I have a very bad solutions for use bpy functions in game engine.

-Use fuctions from bpy
-bpy.app.handlers.save_post (no to use save_pre)
-bge.logic.restartGame()

Example:
View My Video

My ragdoll_visible() function is

def ragdoll_visible():
    for i in range(len(enums)):  
        bpy.data.objects[enums[i]].hide_render = False

I don’t understand why this not work with my ragdoll_invisible() function. Code is:

def ragdoll_invisible():
    for i in range(len(enums)):  
        bpy.data.objects[enums[i]].hide_render = True

you can’t use bpy in game.

If you need dynamic loading you can use LibLoad :slight_smile:

Ok, I am testing but I have the next problem.

With libload in game engine the result is

In the original .blend into game engine see it

My code is

import bge
bge.logic.LibLoad('//modelos/VikingHelmet/VikingHelmet.blend', "Mesh")

bge.logic.getCurrentScene().objects["Head"].replaceMesh('VikingHelmet')

print(bge.logic.getCurrentScene().objects["Head"].scaling)

bge.logic.getCurrentScene().objects["Head"].scaling=[.65,.65,.65]

As a guess, you didn’t apply the Mirror modifier on your helmet. Also, ensure that the ‘destination’ blend file has the same shading as the helmet’s (GLSL, for example).