Jump to content
  • Advertisement
Sign in to follow this  

Scene Graphs, skinning and attachment points

This topic is 4749 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, We have finished our mesh skinning functions. Our skinned mesh is a single mesh that is deformed on the fly. Mesh has subsets and each subset may have an attached visual effect. The mesh may have up to 32 subsets (and also 32 independent effects) for a nice and complex model. We may associate it into a scene graph node and move it. All fine. But now we would like to attach a torch located in the ground into his hand. The torch is in a scenegraph node. After we locate it in the hand we would like to add a particle emitter to the top (of course we have particle emmiters, thats not the problem here). So, the problem is to identify where to 'attach' the new node. I.E. In a torch, the grip of the torch is one side, but the particle emitter is located on the other side. A torch is a simple object and I may have a reference point in a separate script file that tells me 'particleemmiter al 1,0,0 from base'. But that is a simple case. In the case of a person holding the torch, I have to consider the position and direction of the torch in the hand. And that position adn directon should be transformed with the mesh. After looking for some info in this subject, we were considering to add a final dummy node in the objects with a position and a direction. This dummy node will have a specific name (like ATTACH0, ATTACH1, ATTACH2) so it can be identified by the mesh. No vertices will be assigned to these nodes they are just extra matrices. Those matrices are loaded with the mesh as additional bones, so they will be transformed with the mesh on each msec. Finally, on the SceneGraph, I may create a node for the character and add a child node but this node will have a reference to the attachment point. So when processing the scene for rendering, this child node must get its actual position from its parent but using the transformed mesh data. Something like: for each child node for the character { if this node is attachment point dependant { Compute attachment point transform (depending on this object time) Combine with transform of parent node Use this as this child transform } else { Compute this node relative transform Combine with transform of parent node Use this as this child transform } } I don't know if this is ok. Maybe you have another suggestion. Luck! Guimo

Share this post


Link to post
Share on other sites
Advertisement
I'm not an expert or anything, but I don't there's a specific way that a scene graphs works, also this is my suggestion.


intilizing
{
torch->SetAttachmentPoint("LHand")
}

calculatingTransformation
{
parent->GetAttachmentTransformation(myAttachmentPoint); //myAttachmentPoint = "LHand"
}




anyways attachment point transformations are easy, just transform the precalculated attachemnt point with the transformation of the hand, and then create a translation matrix with those points and multiply AttachTranslation * HandTransformation = TorchTransformation.

Hope that helps.

Share this post


Link to post
Share on other sites
Assuming you use a SceneGraph (more likely a Tree in fact), the 'standard' way, then you have each Node having a Single Parent (so it's a Tree), and the purpose of the SceneGraph/SceneTree is solely to provide hierarchical animation and uniform Entities access.

Then you have

void CEntity::update()
{
/* World Transform */
m_WorldTransform = m_pParent->getWorldTransform() * m_LocalTransform;

/* Hierarchical/Propagation */
size_t uiCount = m_SGChildren->size():
for ( size_t i = 0; i < uiCount; ++i )
m_SGChildren->at( i )->update();
}

m_LocalTransform allows you to animate the entity itself, and the WorldTransform to have it's World Coordinates.
After SceneGraphROOT->update() is called all of your Entities have correct World Space Transformations.

[edit]
Obviously update() is virtual and overrided in the ROOT Node to skip the 'Parent' part ^^ otherwise you'll get a nasty bug.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!