PositionAttitudeTransform from OpenSceneGraph to VulkanSceneGraph

[josetxurro]

Hi,

I'm migrating some projects from OpenSceneGraph to VulkanSceneGraph and realized that there isn't a PositionAttitudeTransform class in VSG, which I need. So, I decided to implement the class myself. However, while refactoring the header and source files from the original OSG class to VSG, I noticed that the dirtyBound() function from osg::Node is not available in vsg::Node. I found a Data::dirty() function in the documentation, but it doesn't seem to have the same effect. Could someone help me? Thanks!

[robertosfield]

A PositionAttitudeTransform node is one I've hand in but hadn't got around to implementing it yet, so if you are able to open source I'd welcome a PR for it's addition.

The VulkanSceneGraph doesn't have bounding volumes assigned to all scene graph nodes like the OpenSceneGraph does, and there isn't a mechanism for propagating changes in bounding volumes either. This means there no Node dirtyBound() mechanism.

The Data::dirty() mechanism is for vertex arrays, uniforms and texture data and is used to inform the TransferTask when to copy changes to the associated GPU memory. This is quite different from changes to the internal nodes of a scene graph which are purely CPU based.

The fact that the VSG doesn't a have a general bounding volume assigned to all all scene graph nodes is decision I made to remove the performance overhead of storing a bounding sphere in all nodes, and doing checks for culling enabled and doing the culling itself on all nodes. This decision along with no node callbacks and masks is how the VSG keeps the vsg::Node size down to just 24 bytes vs the osg::Node 208 bytes.

This really helps reduced the memory bandwidth load and reduce cache misses when traversing the scene graph, and avoiding doing lots of node mask and culling checks on every node avoids tripping branch prediction and improves pre-fetch on the CPU so the VSG ends up being over 10x faster at traversals.

Culling and masks are still important for performance and usability of the scene graph, so there are fully supported, but just moved to dedicated culling nodes - vsg::CullGroup/CullNode/LOD/PagedLOD and dedicate mask handling with vsg::Switch. This means users need to place these nodes where they need them/judge them to be important for performance.

If you have a transform that is dynamically updated in the scene and you want to do culling on that subgraph it's generally best to place the culling node below the dynamically updated transform, this way it's bounds don't need to be updated dynamically as well.

If you have something like an animated character where there are lots of moving parts one would put a cull node with a static bounding volume for it which is big enough to encompass the local range of movement, so no matter the positions the culling will still work correctly.

These approach of using conservative bounding volumes might be a potential performance hit if the subgraph was really expensive to render, but for most scene graph applications and modern hardware the CPU and GPU throughput for many objects is much lower - especially as the CPU and GPU overhead of the VSG and Vulkan are much lower than OSG and OpenGL the gain from avoiding lowering CPU throughput is better than the gain you might achieve with slightly more culling.

[robertosfield]

One approach I've considered as a replacement for PositionAttitudeTransform is a CompositeTransform subclass from Transform where it has a list of TransformComponent objects, and each TransformComponent has a virtual transform method that can modify the modelview matrix.

One then would have TranslantionComponent, RotationComponent and ScaleComponent subclasses that can be put in any order to achieve the end result the user wants. As it depends upon virtual methods and multiple objects it'll have a high CPU overhead than a hardwired PositionAttitudeTransform but it'd be much more flexible, with the same level of flexibility of having a hierarchy of Transform nodes but with lower CPU overhead.

[josetxurro]

Thanks for your advice! That sounds much more efficient than simply refactoring the OSG class. Perhaps in CompositeTransform, there could be a method for adding components to a TransformComponent vector, followed by overriding the accept method to modify the modelview matrix.

[robertosfield]

My thought was a vsg::CompositeTransform would subclass from vsg::Transform and override the 'dmat4 transform(const dmat4& mv)' method, this method would then just walk through the vector<ref_ptr> call each ones transform(..) method.

The TransformComponent::transform(..) method could probably just use the same API and approach as Transform does, but wouldn't have children like Transform does, so wouldn't be a node in the scene graph. The purposes would be purely to provide transforms. I guess it could be nested class, called CompositeTransform::Component might be neater.

The downside of this flexibility is you'd need to iterate through the components to find the appropriate one to update, so wouldn't be as convenient to use as the hardwired PositionAttitudeTransform so I think this class still has value, much like the MatrixTransform has. Simplicity of API and implementation has it's own value.

[josetxurro]

Hi,

Today I tried to implement following your advice, but I think I am not getting the result that I was expecting.
This is my CompositeTransform class:
#include "CompositeTransform.h"
#include

namespace vsg {

// Método addComponent para añadir un TransformComponent
void CompositeTransform::addComponent(vsg::ref_ptr<TransformComponent> component)
{
    components.push_back(component); 
}

// Método transform sobreescrito de vsg::transform
vsg::dmat4 CompositeTransform::transform(const vsg::dmat4& mv) const
{
    vsg::dmat4 t = mv;

    // Iterar a través de los componentes para aplicar transformaciones
    for (const auto& component : components)
    {
        t = component->transform(t);  // Modifica 't' directamente por referencia
    }

    return t;
}

// método computeLocalToWorldMatrix
// Transforma coordenada local a coordenada global
bool CompositeTransform::computeLocalToWorldMatrix(vsg::dmat4& m)
{
    m = this->transform(m);  // Aplica la transformación
    return true;
}

// método computeWorldToLocalMatrix
// Transforma coordenada global a coordenada local
bool CompositeTransform::computeWorldToLocalMatrix(vsg::dmat4& m)
{
    m = inverse(this->transform(m));  // Aplica la transformación inversa
    return true;
}

}

And this is my TransformComponent class:
#include "TransformComponent.h"
#include

namespace vsg {
vsg::TranslationComponent::TranslationComponent(const vsg::dvec3& t) : translation(t) {}

vsg::dmat4 vsg::TranslationComponent::transform(const vsg::dmat4& mv) const
{
    return vsg::translate(translation) * mv;
}

vsg::RotationComponent::RotationComponent(const vsg::dquat& r) : rotation(r) {}

vsg::dmat4 vsg::RotationComponent::transform(const vsg::dmat4& mv) const
{
    return vsg::rotate(rotation) * mv;
}

vsg::ScaleComponent::ScaleComponent(const vsg::dvec3& s) : scale(s) {}

vsg::dmat4 vsg::ScaleComponent::transform(const vsg::dmat4& mv) const
{
    return vsg::scale(scale) * mv;
}

}

I also coded a test function to test the PAT implementation and see if I got the same matrixes:
vsg::dmat4 modelViewVSG = vsg::dmat4(1.0);
vsg::ref_ptrvsg::CompositeTransform compositeTransform = vsg::CompositeTransform::create();

auto translationComponent = vsg::ref_ptrvsg::TranslationComponent(new vsg::TranslationComponent(vsg::dvec3(1.0f, 2.0f, 3.0f)));
auto rotationComponent = vsg::ref_ptrvsg::RotationComponent(new vsg::RotationComponent(vsg::dquat(vsg::radians(90.0f), vsg::dvec3(0.0, 0.0, 1.0f))));
auto scaleComponent = vsg::ref_ptr vsg::ScaleComponent(new vsg::ScaleComponent(vsg::dvec3(1.0f, 2.0f, 3.0f)));

compositeTransform->addComponent(translationComponent);
compositeTransform->addComponent(rotationComponent);
compositeTransform->addComponent(scaleComponent);

compositeTransform->computeLocalToWorldMatrix(modelViewVSG);

cout << modelViewVSG << endl;

osg::Matrix modelViewOSG = osg::Matrix::identity();
osg::ref_ptrosg::NodeVisitor nv = new osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN);
osg::ref_ptrosg::PositionAttitudeTransform pat = new osg::PositionAttitudeTransform();
pat->setPosition(osg::Vec3d(1.0f, 2.0f, 3.0f));
pat->setAttitude(osg::Quat(osg::DegreesToRadians(90.0), osg::Vec3d(0.0, 0.0, 1.0)));
pat->setScale(osg::Vec3d(1.0f, 2.0f, 3.0f));

pat->computeLocalToWorldMatrix(modelViewOSG, nv);

for (int i = 0; i < 4; ++i)
{
for (int j = 0; j < 4; ++j)
{
cout << modelViewOSG(i, j) << " ";
}
cout << endl;
}

Do you have any idea what's the issue? Thanks!

[AnyOldName3]

I'd have thought that for most applications, there'd be one conventional preferred order for composite transforms, so having them be a template, and therefore bypassing the need for virtual function calls and permitting inlining, would be just as useful, but faster at runtime. Having a templatey composite transform class built into the VSG doesn't stop the few applications that'd want the ability to change the order at runtime from making their own class that can do that, but would stop applications that didn't need that from throwing away performance for features they don't need.

[josetxurro]

@robertosfield I followed your "instructions". Do you have any idea of what happened? I know that my implementation could be more efficient, but the issue has nothing to do with efficiency right now. Thanks and sorry to bother you!