(Engl/D) ConstructionScript: let build building procedual - BUT T: How to build several indep meshes out of different components AND

(Engl/D) ConstructionScript: let build building procedual - BUT: How to build several meshes out of different components AND theese meshes should be rotatabe and moveable independend of each other. UE4.27.2

Ungelöstes Problem: Mittels Constructionscript komplexes Gebäude errichten.
Unsolved problem: How to build a complex building in Constructionscript? LookToComment

Was problemlos funktioniert/what is not the problem:

  • (D) In einer Reihe/Ebene diverse Bauelemente (als Mesh bzw. Component) anordnen.
  • (Engl) To build Elements (Parts/Component of Meshes) in a row/column or an plain.

You can see in my video:
Hier kann man das sehen:

Problem:

  • (D) Gebäudeteile in verschiedene Richtungen bauen - rechtwinklig zueinander oder gar in anderen Winkeln einander ausgerichtet. Man müsste mathematische Gleichungen aufstellen, die von allen Komponenten die Drehungen und die dadurch verursachten Ortsverlagerungen ermitteln lassen. Das ist möglich aber mühselig und wohl auch nicht effizient. Besonders wenn Gebäudeteile versetzt sind, werden entsprechende Berechnungen kompliziert.
  • (Engl) Build Parts of the building in different directions - maybe 90° oder other angles. Complicated mathematical Equations are needed to let to calculate the new position and rotation of every single component. Of course, this is possible, but it is laborius and arduous and i guess, it is not efficient - especially, when there are parts of the building which have an offset.

Lösungsideen/Ideas of solution

  • (D) Man könnte durch das Constructionscript verschiedene Actors erzeugen lassen. Z.B. für die vier Seiten des Gebäudes könnten vier Actors erschaffen werden und jedes beinhaltet eine Wand. So können die vier Gebäudeseiten leicht gedreht werden und frei bewegt werde. Leider aber hat man dann halt eben nicht nur einen Actor, sondern gleich 4. Das sieht mir nicht nach einer optimalen Lösung aus. Es soll ja eine einzige Konstruktionsein schlussendlich. Könnte man Acors zu einm verschmelzen? Oder aus einem anderen die gedrehte Wand entnehmen und im ersten einfügen (also zweiten Actor erzeugen, Wand bauen, actor drehen und dann das gedrehte Mesh in den ersten actor überführen - aber es muss dann so ausgerichtet bleiben, wie sein Actor es war)? Oder gibt es andere Wege? Kann man in einem Actor mehrere Teilmeshes (z.B. Gebäudeteile) haben - jede (jeder Gebäudeteil) aufgebaut aus mehreren kleinen Parts, aber dennoch sollen die Gebäudeteile unabhängig voneinander bewegbar und drehbar sein. Dabei soll aber jeder Gebäudeteil für sich so ein festes Gefüge bilden, dass er als Ganzes gedreht und bewegt werden kann, obwohl er einst aus kleineren Teilen zusammengesetzt wurde.
  • (Engl) To let to spawn several actors by the constructionscript: when 4 Actors are spawned and each of them contains Mesh-Components which constitute a wall, then each actor can be rotate easily and the four walls can put together to one building. But - then there are four single actors. This don’t seems to be the best solution. I would like to have one single construction. Is it possible to fusion this actors to one single actor? That meens, is it possible to take the static mesh component of three of them and put them to the first actor? Or is there an another way to construct a part of building made out of different single parts and connect theese in a way, that this part of building can rotate as a whole - independently of other parts of this acors? That means: moving and rotating of one part of building must be possible, even wher this actor have other parts of buildings - and theese should also can be moved and rotated independently of each other.

If you want optimizations then I would stay away from actors per wall segment. All actors need their own transforms nodes and separate draw calls even if they would be in the form of child actor components inside the main building actor.

If you want performance then you need use hierarchical instanced static meshes. This will allow for the static meshes to have level of details.

You would need 1 HISM component per instance of repeatable mesh (so roof, wall, door frame)

You add in this component, set its static mesh and the use add instance on the HISM component putting in the offset from the center of the HISM comp.

I would be the only real option for complex tasks like this.

If I were you I would make a function that would take in a

  • a HISM component
  • a transform
  • a static mesh
    and build a row of instances connected to the passed in HISM component along the set transform with the set static mesh

Then you could have a loop of these functions for the wall, then the roof etc.
Doors are a little more complicated but I can explain it sometime down the line if you go this route

Wow, great! This sounds very, very great - I will start some recherches and try to realize this way! Thanks a lot, I will report the results :slight_smile:

1 Like

Hello,
I recherched and tried a little and I wonder if I understood the using of HISM correct :slight_smile:

In using it seems to be similar than a classic InstStMComp, is it correct? I Tried it this way:

In both ways the result seems to be the same. Is it correct, that the benifit of HISM is, that a lot of semilar components can be added (often used for foliage) and also LOPs are included? Are there more advantages?

My hope would be that several little parts can connected to a bigger part and this bigger part can be connected with other bigger parts and so on - But it is necessary for my project that such a bigger part can be used as it would be one single unit. If it is possible, than I could let create some of these bigger parts and some of them I could move and rotate as it would be just a mesh - independent of moving and rotation of the other bigger parts.

Is it possible?

Best regards and thanks alot :slight_smile:

Now I think, I have an awesome joke for you.

I guess the solution will be this absolut essential basic standard tool: :see_no_evil: :man_facepalming:

image

Since decardes I program in pascal/Delphi/Lazarus. So it is a new experiance to program with UE :see_no_evil: :laughing: I started some month ago and I’m just learning and trying.

I will report the results :slight_smile:
Best regards and have a nice weekend
Thanks a lot :smiley:

Now the question is: When I have added Components with the methods “Add (hierarchical) Instanced Static Mesh Component” and “Add Instance”
Who is child of whom and how it can be changed? :thinking:

Here an example: Three Components are added and every Component consists out of several Meshes.

I think there is a way to struct the relationship between Components? Ownership? Parent-Child- Relation?

The Effect should look like this (yes, i know that it will not be shown and i can’t see such a tree, but despite this the effect should be similar, i guess, isn’t it?) :

image

Have a nice Friday, till later

The basic workflow is exactly like classic instanced static meshes.
You only need one component per model and usually just add instances in a for loop to it.

It has the added bonus that it can be dynamic, so you can destroy segments if needed.
This is how you can add in unique elements like doors where you destroy a specific segment via it’s index and there you can spawn a door frame (probably in its own HISM instance group)

So it would look like this
HISMComponent => wall (4 x loop for basic box)
HISMComponent => floor (looped tile width x length)
HISMComponent => wall => remove segments with door index
HISMComponent => door frame => spawn at position used in door index removal
HISMComponent => roof (looped tile width x length reduced by 1 segment around)
HISMComponent => roof perimeter (same function as walls just roof edges)

The HISMComponent is the parent to which you add instances. Think of it as a collection of instances. it is the main transform and holds all of it’s instances by index.

Your blueprints have no need for child actor components. They are costly performance wise.

You should just have the root component and all HISM collections and their instances should be made at runtime through the constructor calling functions.

Here is my BP for floor creation

It uses a mesh that has the pivot in the center, might need a 1/2 offset if you want a shift to the edge of the tile