search

DLR-SL / CPACS

CPACS - Common Parametric Aircraft Configuration Schema
http://dlr-sl.github.io/CPACS/
Apache License 2.0
79 stars 38 forks source link

Introduce a library node for external geometry #717

Closed jnwalther closed 3 years ago

jnwalther commented 3 years ago

As discussed in yesterday’s stakeholder meeting, there might be a need for a higher level library node for external geometry (CAD/mesh) files.

Currently, the only way to add external geometry is via the genericGeometryComponents node at aircraft level. As pointed out by @sdeinert, the contents of this node will be added automatically in TiGL. However, in the deck definition proposed in #674, the idea is for the geometry (e.g. seat models) to be merely referenced within the deckElements node (which is placed at vehicles level, analogously to structuralElements), and be placed later by a deck instance. Using the existing infrastructure of genericGeometryComponents will therefore cause unwanted models to appear in TiGL.

A quick mitigation is to move the reference to the external file to the deckElements node. However, maybe it would also be a good idea to create a library node for external geometry at vehicles level, which could be referenced by both the deckElements (for cabin component models) and the genericGeometryComponents (for TiGL visualization) to keep external model references in one place.

@rainman110, would adding this be an issue from TiGL side?

MarAlder commented 3 years ago

I see two options here, which are shown in the figure below using seatElements as an example (as proposed in #674):

decks

rainman110 commented 3 years ago

I think option 1 is preferrable: Lets stay at seats. We just define 1 seat as a generic component, but you probably like to have many seats, each of them at a different location, right?

jnwalther commented 3 years ago

Thanks for your comments! @rainman110, yes, the idea is to establish the link to the external component once in the seatElement, and then do the actual placement using the decks node in the fuselage. From what I heard from you and @sdeinert I guess the genericGeometryComponent is implemented differently. Either way, I'm ok with using option one, which means we can close this issue.