Multimaterial Mesh question

[AlexSilverman]

Hi voxel,

Thanks for taking a look, and I'm glad it makes sense.

• All good points, and my mistake throughout. I somehow got out of the habit of using btMaterial objects at all, but I've changed both the btMultimaterialTriangleMeshShape and the demo file to include them more thoroughly. I also split the btMaterial definition into its own file. Take a look and let me know what you think.
• Currently, I am using the material index method you describe. The btMultimaterialTriangleMeshShape contains a list of the materials (m_materialList), and a list of indices (m_triangleMaterials). If you look at the implementation for btMultimaterialTriangleMeshShape::getMaterialProperties, the last three lines of code (1) obtain the index into the list of indices by using the partID and triIndex arguments, (2) obtain the pointer to the material data in the material list, and (3) return it. If you wanted to trim it down even more though, the scheme could be altered to make use of the partID. This is something Erwin suggested earlier in this thread, but I never got around to doing. Currently, the list of indices into the material array is on a per triangle basis, but this could be changed to be on a per part basis. The mesh could be divided by which parts based on which triangle use which materials. The mesh shape could be created, then part 1 (which uses material 1) could be added, followed by part 2 (which uses material 2) and so on. That way, rather than each triangle holding an index into the material array, each part would. This would have presented some additional problems for the project for which this package was written, just in the way we're representing our mesh data, but it's definitely something I'd like to come back to when/if time allows.

I've attached the entire package again, just so downloads are easier.

- Alex

[voxel]

[*]Currently, I am using the material index method you describe. The btMultimaterialTriangleMeshShape contains a list of the materials (m_materialList), and a list of indices (m_triangleMaterials). If you look at the implementation for btMultimaterialTriangleMeshShape::getMaterialProperties, the last three lines of code (1) obtain the index into the list of indices by using the partID and triIndex arguments,

I looked at the code, but wow... completely missed that!

I think there will be 3 ways developers will store their materials:

1) Per-triangle - raw data (i.e UV mapping -> texture(s))
2) Per-triangle - indexed material
3) Per-part - indexed material

(1) and (2) are similar in implementation.

For (3) I'd add a isMaterialPerTriangle()/isMaterialPerPart() method and create a new getMaterialProperties(int partID) while keeping the old method.

[Erwin Coumans]

It looks like the userpointer in the triangle can always be a btCollisionShape isn't it?

A more general solution, that also could be re-used for btCompoundShapes (so each part of a compound can have its own material) could store the root collision shape in the btManifoldResult.

[edit] this would require an API change, which is better to avoid, so let's go for Alex' solution for now.

Thanks,
Erwin

[AlexSilverman]

@voxel
I think another option would be to only change the creation of the shape, and keep the rest hidden, using the same getMaterialProperties method, and just ignore the triIndex argument if the shape was created with per part material data. I'm going to be away for a while coming up, but I'll look at getting this implemented as soon as I can.

@Erwin
I decided against using the the userPointer to store the root mesh location because in the collision algorithm, when the triangle is created, the triangle userPointer is set to the root mesh userPointer, so whatever data might be there could be propogated to the ContactAddedCallback. I also thought about using the userPointer anyway, since one would still have access to the root mesh userPointer (albeit a bit more indirectly), but I figured it wasn't my place to introduce something that might break existing user code.

- Alex

[Erwin Coumans]

After looking at it again, adding an additional API call to btCollisionObject seems preferable. It doesn't change existing API, and it supports compound shapes automatically.

Here is the new proposal:

Code: Select all

	void	setCollisionShape(btCollisionShape* collisionShape)
	{
		m_collisionShape = collisionShape;
		m_rootCollisionShape = collisionShape;
	}

	SIMD_FORCE_INLINE const btCollisionShape*	getCollisionShape() const
	{
		return m_collisionShape;
	}

	SIMD_FORCE_INLINE btCollisionShape*	getCollisionShape()
	{
		return m_collisionShape;
	}

	SIMD_FORCE_INLINE const btCollisionShape*	getRootCollisionShape() const
	{
		return m_rootCollisionShape;
	}

	SIMD_FORCE_INLINE btCollisionShape*	getRootCollisionShape()
	{
		return m_rootCollisionShape;
	}

	///Avoid using this internal API call
	///internalSetTemporaryCollisionShape is used to temporary replace the actual collision shape by a child collision shape.
	void	internalSetTemporaryCollisionShape(btCollisionShape* collisionShape)
	{
		m_collisionShape = collisionShape;
	}

The btConvexConcaveCollisionAlgorithm.cpp and btCompoundCollisionAlgorithm can use this 'internalSetTemporaryCollisionShape' API.

Hope this helps,
Erwin

[AlexSilverman]

Erwin,

This looks like a good solution. Adding materials to compound objects would be neat as well.

Thanks.
- Alex

[Erwin Coumans]

The patch has been applied, and the new demo is renamed to MultimaterialDemo:

http://code.google.com/p/bullet/source/detail?r=1199

Thanks for the contribution!
Erwin

[AlexSilverman]

Great. Thanks for including it Erwin

- Alex