How to deal with transformation without scaling in CPACS & TiGL
#1070
-
|
Hey, just for brainstorming different implementation ideas: we typically use the CPACS For the new systems definition On the CPACS side, we should try to avoid scaling of system components at aircraft level. Components are predefined in their size, mass and center of gravity. If we allow scaling, it is not entirely clear whether this only refers to the geometry, or whether the mass and center of gravity are also changed, etc. It is therefore best for CPACS users to create a new predefined system element. Now to TiGL implementation. We could have a new cpacs type Should we adopt |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
Good question! I would probably need to experiment a bit to get a feel for the pros and cons. I wonder if it suffices to have a struct CPACSTransformationSE3
{
// an element of the special Euclidean group SE(3)
Vec3 translation;
Vec3 rotation;
};
// no inheritence, because of schema *(unless we inherit in the schema?)*
struct CPACSTransformation
{
double scale;
Vec3 translation;
Vec3 rotation;
};
// custom class
struct CCPACSTransformation : public CPACSTransformation
{
// implicit constructor from CPACSTransformationSE2
CCPACSTransformation(CPACSTransformationSE3 se3)
: CPACSTransformation{1., se3.translation, se3.rotation}
{}
};
struct CTiglRelativelyPositionedComponent
{
CCPACSTransformation trafo;
};
Note, that this discussion is related to #911. Here, the proposition is to remove |
Beta Was this translation helpful? Give feedback.
-
|
Renaming Experimental material is available in my |
Beta Was this translation helpful? Give feedback.
-
|
Ah I had a closer look and of course my code example is too simple, because of the following issues in the TiGL source code:
The easiest short-term solution is probably to have My current guess is that it might be a good idea to begin with refactoring // a CPACS element using a traditional CPACS transformation including scale
struct CPACSFoo
{
CCPACSTransformation trafo;
};
// a CPACS element using the new CPACSTransformationSE3 type
struct CPACSSystem
{
CCPACSTransformationSE3 trafo;
};
// TiGL source code
struct CTiglTransformation
{
explicit CTiglTransformation(CCPACSTransformation trafo) {}
explicit CTiglTransformation(CCPACSTransformationSE3 trafo) {}
};
struct CTiglRelativelyPositionedComponent
{
virtual ~CTiglRelativelyPositionedComponent() {}
virtual CTiglTransformation GetTransformationMatrix() const = 0;
};
struct CCPACSFoo : public CPACSFoo, public CTiglRelativelyPositionedComponent
{
CTiglTransformation GetTransformationMatrix() const override
{
return CTiglTransformation(trafo);
}
};
struct CCPACSSystem : public CPACSSystem, public CTiglRelativelyPositionedComponent
{
CTiglTransformation GetTransformationMatrix() const override
{
return CTiglTransformation(trafo);
}
};I do realize, that this is a somewhat painful refactor, because many classes access the |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks @joergbrech for your thoughts. I'm modifying Refactoring according to #911 would improve this implementation, but I leave that to the experts ;-) |
Beta Was this translation helpful? Give feedback.
Ah I had a closer look and of course my code example is too simple, because of the following issues in the TiGL source code:
CPACSTransformationofCCPACSTransformationif the parent uses the other transformation typeCCPACSTransformationSE3. The dependency should be inversed. Maybe something to fix at a later point 😁CTiglRelativelyPositionedComponentdoesn't store aCCPACSTransformationby value but by reference …