I was thinking of building a correlation matrix for a collection of meshes which I wanna use in PCG. How should I go about
storing the matrix (data tables seem to a row based and not matrix)
propagating the matrix values from the level editor( there’s hundreds of meshes. let’s say I want to assign certain relationships between these meshes from the 3d space and editor itself using splines[connecting to other meshes] and zones/proximity). I’m thinking of creating a level for assigning these values and visualize the relationship on the go. much like an embedding.
Some things I’ve managed to understand so far.
I need a data structure which is one level higher, ie, on the folder and not the object. This data will be one big actor(?)/asset which applies to all the objects inside the folder/collection.
This could be done with a datatable, but I’m not too sure of the performance implications. I’m concerned that the data tables are row based, and we don’t have a way to navigate within it from both columns and rows. I could be wrong here.
Let’s say we’re going the datatable route. Then my first instinct is to create this data table using scripts(structs which are automatically populated), and update it without losing data as new objects are entered to the folder. To keep things compact, use a custom Struct for the data being stored.
Next step is to propagate the data table across half the table automatically or dynamically. Because a correlation matrix have same values across (x,y) and (y,x). The data is two sided.
And finally I have to figure out a way to optimize this representation. I’m not sure yet on the most efficient way to represent a correlation matrix. The representation and the retrieval, might need custom scripts/blueprints
As for authoring the actual data between each objects from the Viewport. I will definitely need to write some plugins and rely on FComponentVisualizer perhaps. I’m wondering if I could do it using geometry scripting as well.
P.S - I realize the title should have been “Data Assets:” and not “Data Tables:”
Some Updates.
I’ve found that the best way to store the data from a correlation matrix, is using data tables.
Think of a 3x3 matrix, the diagonal cells of (n,n) holds no value. and cell(x,y)=cell(y,x). So, we first subtract the number of diagonals, then halve the remain number of cells to find the relevant number of cells.
Hence, a correlation matrix have {(n²-n)/2} distinct cells.
Representing {(n²-n)/2} entries are much more elegant than having the number of properties scaled by the size of the matrix. We don’t have to worry about dynamically changing the Structure of the DataTable as more things get added. So instead of thinking we have to represent the matrix as a data table of n*n cells, we can simply represent this as a list of data for unordered pair of meshes. [UO Pair of Meshes][Attribute 1][Attribute 2].......[Attribute i]
But..
Then I realized working with indices are better than working with long strings of mesh path strings, so it’s ideal to use an unordered pair of indices instead of meshes. This will create some problems when the index of the meshes change, In order to solve this, we could simply use an external tool to convert the current data table to UO pair of indices(and use that for actual calculations) and keep track of indices, renames, deletions using registry of meshes(another data table for individual mesh’s data). In PCG/Blueprints, using indices allows for more complex operations and comparisons. we only need a minimal stringPath ↔ intIndex translation at the very end. Doing it this way makes the retrieval more efficient and solves the expected conflicts.
This takes me back to the real problem I should focus on solving; authoring the data intuitively.