Transformation Component

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Transformation Component

      In Physics VSyncVisibleScene function(Physics.cpp:469), in seems to me that sending the last event is unnecessary? please correct me if I'm wrong.

      Source Code

      1. pGameActor = g_pApp->m_pGame->VGetActor(id);
      2. pTransformComponent = pGameActor->GetComponent<TransformComponent>(TransformComponent::g_Name);
      3. pTransformComponent->SetTransform(actorMotionState->m_worldToPositionTransform);
      4. shared_ptr<EvtData_Move_Actor> pEvent(GCC_NEW EvtData_Move_Actor(id, actorMotionState->m_worldToPositionTransform));
      5. IEventManager::Get()->VQueueEvent(pEvent);


      So we have an actor, we get it's transformation component and we set it to the matrix of the physics actor, cool. Next we send out an event with the same matrix of the physics object to move the actor.
      The event is picked up by the Scene, which updates the scene node that is linked to the same actor and the same transformation component.

      Source Code

      1. pCastEventData = static_pointer_cast<EvtData_Move_Actor>(pEventData);
      2. id = pCastEventData->GetId();
      3. transform = pCastEventData->GetMatrix();
      4. pNode = FindActor(id);
      5. pNode->VSetTransform(&transform);


      Did it need to do it?
      Even if the event was sent in case of awareness of change to the component, there is the PreRender function in the scene node that gets it's actor's transformation component and applies it to the current matrix.

      Source Code

      1. pTc = pActor->GetComponent<TransformComponent>(TransformComponent::g_Name);
      2. m_Props.m_ToWorld = pTc->GetTransform();


      What's the point of sending this event? Shouldn't the transformation component be responsible for all transformations done to an actor, and scene nodes simply refer to it and obey it. Am I missing something here?

      And many thanks for a fantastic book, almost done reading it :P
    • Yeah that definitely seems redundant, one of Rez's side notes in the book mentions how an engineer on a project he worked on solved this by only having one transform for everything ie. a transform component, I'm not sure if it would work with a 3rd party physics library though as it has it's own internal transforms.

      The way I handle things is having the transform component automatically send an event when it is modified, this way, whatever system changes the transform, synchronizes the rest of the systems as well, without the need to send an even from outside the transform class.

      One design flaw I have not got to yet, is that I do this for EVERY modification, what I should have done is have a 'dirty' variable that marks the transform whenever it is modified, than on the update call for the transform component, it will check if it is dirty, and than send one single combined update event.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • mholley519 wrote:

      one of Rez's side notes in the book mentions how an engineer on a project he worked on solved this by only having one transform for everything


      It's a note in the "Data Sharing" paragraph, in chapter 6, and I have a question about it.
      The note mentions that actors had 3 transforms: render, logic and physics. What I'm not sure about, is whether these 3 transforms were copies of one another and the sync was simply a matter of copying the data around, or if they were possibly different data, and the sync was to keep them "coherent".
      Anyone?
    • berry wrote:

      mholley519 wrote:

      one of Rez's side notes in the book mentions how an engineer on a project he worked on solved this by only having one transform for everything


      It's a note in the "Data Sharing" paragraph, in chapter 6, and I have a question about it.
      The note mentions that actors had 3 transforms: render, logic and physics. What I'm not sure about, is whether these 3 transforms were copies of one another and the sync was simply a matter of copying the data around, or if they were possibly different data, and the sync was to keep them "coherent".
      Anyone?


      Oh man, I honestly don't remember anymore. This was nearly a decade ago. I think the data was represented slightly differently in each component, but I could be wrong. It was kept in sync whenever it got updated and that inevitably failed on occasion.

      This type of issue crops up all the time and is called data denormalization. The idea is that you want to speed up reading the data, so you cache it somewhere. The advantage is a performance boost, but the disadvantage is that you have to keep the cache updated. Many bugs on The Sims 4 can be traced back to caches not getting refreshed. We actually ended up writing a generic caching system that everyone had to use for data caching which allowed us a lot of control. We even had a cheat to turn off all caching in the game so you could check to see if it was a caching bug or not.

      My general rule of thumb is to never denormalize data unless there is a real, measurable performance gain that I can see in a profiler. Sometimes you have to do it, but you're almost always going to have bugs with it.

      -Rez