Modèle de construction procédurale

Le modèle Verse - Procedural Building est un exemple de projet de l’Unreal Editor pour Fortnite (l’UEFN) Re: Imagine London (code d’île : 1442-4257-4418) qui présente le système de construction procédurale écrit en Verse.

Le système de construction procédurale est entièrement implémenté et créé dans Verse au lieu de Fortnite. Ce système vous donne plus de contrôle sur le mode d'assemblage des maillages dans vos projets.

Dans Fortnite, vous pouvez concevoir votre gameplay avec des pièces de construction prédéfinies (sol, plafond et mur). Le système de construction procédurale développe vos possibilités afin de vous permettre de créer des voxels avec des catégories qui définissent des systèmes sous-jacents dans lesquels vous pouvez rapidement placer d'autres voxels lorsque le système place son maillage.

Pour accéder à ce modèle dans le navigateur de projets de l'UEFN, atteignez Exemples de fonctionnalités > Exemples de jeux > Verse - Procedural Building.

Le système de construction procédurale fonctionne en deux phases.

• Lors de la première phase, vous éditez une grille de voxels, une grille 3D où chaque cellule est une case, en ajoutant ou en supprimant des voxels.

• La seconde phase s'exécute à chaque modification de la grille de voxels. La modification de la grille de voxels prend les informations des voxels et exécute un processus qui génère les bons maillages aux bons endroits.

Vous pouvez ajouter et supprimer les catégories de voxels Bâtiment et Parc. Chaque catégorie suit des règles différentes concernant la manière dont les maillages doivent être générés. Ces règles font référence au graphique ou à l'arbre des opérations qui seront effectuées pour passer des voxels placés aux maillages réels

Utiliser le modèle

Chaque niveau de votre projet comporte une classe de niveau supérieur, notamment la classe root_device. Lorsqu'un joueur rejoint le jeu, la classe root_device crée pour lui des données global_player_data qui définissent les informations affichées sur son interface.

Chaque zone de construction possède un appareil build_zone qui définit les dimensions du site en voxels. La position de cet appareil définit l'origine du site. La zone de construction utilise un objet build_system pour gérer les mécaniques de construction et un appareil spawner_device pour générer des maillages d'accessoires de bâtiment. La zone de construction contient également une grille voxel_grid, une grille mesh_grid et un système wfc_system.

Chaque zone de construction contiendra les éléments suivants :

• build_zone(appareil) - définit les dimensions du site en voxels.

• build_system - gère les mécaniques de construction.

• spawner_device(appareil) - génère des maillages d'accessoires de bâtiment.

• spawner_asset_references (appareil) - référence tous les accessoires générés.

Lorsqu'un joueur pénètre dans un build_zone, déclenché par un appareil Volume, player_data est créé pour gérer l'entrée et la modification des voxels de ce joueur.

Construire avec des voxels

Ce modèle introduit un vector3i [type]() pour représenter les voxels selon leurs coordonnées X, Y, et Z [integer]().

Vous trouverez ci-dessous un exemple de script utilisant vector3i.

vector3i<public> := struct<computes><concrete>:
    @editable
    X<public>:int = 0
    @editable
    Y<public>:int = 0
    @editable
    Z<public>:int = 0

Grilles de voxels

Une grille de voxels est une grille 3D de cellules pour chaque zone de bâtiment qui stocke des informations sur le type de voxel de bâtiment présent. Ces grilles sont implémentées dans la classe voxel_grid sous la forme d’une matrice 1D de références facultatives à voxel_cell [objects](), comme indiqué ci-dessous.

    # Main array representing the 3D grid of voxels
    var Cells<public> : []?voxel_cell = array{}

Par défaut, un objet de cellule de voxel contient uniquement un [enum]() pour le type de voxel, comme indiqué ci-dessous.

# Category of voxel in our build grid
build_category<public> := enum:
    Building
    Park
    NewBuildingType
# Structure stored for each occupied voxel
voxel_cell<public> := struct<computes>:
    Category<public>:build_category

Vous pouvez ajouter des catégories de voxels de bâtiment en étendant l'énumération, comme indiqué ci-dessus.

Le code ci-dessous convertit une coordonnée de voxel 3D en un [index]() 1D.

  # Gets the 1D array index from a 3D location in grid
    GetVoxelIndex<public>(X:int, Y:int, Z:int)<transacts>:int=
        return (X * (Size.Y*Size.Z)) + (Y * Size.Z) + Z

Raycasting

Une fois la grille de voxels définie, le système effectue une vérification de collision de rayons pour s'assurer de la face ou du côté du voxel touché par le rayon. Chaque voxel possède six faces, comme un dé. Lors du lancer de rayons, vous devrez savoir à la fois quel voxel et quelle face sont touchés pour tracer la surbrillance et générer un nouveau voxel contre cette face.

Les contrôles de collision de rayons sont principalement gérés dans la classe ray_caster. Elles s'effectuent en déterminant d'abord dans quel voxel le rayon commence, en transformant l'emplacement de la caméra dans l'espace local de la grille. Une division par dimensions de voxel, comme indiqué ci-dessous, a ensuite lieu.

    CurrentVoxel := vector3i:
        X := Floor[InitialPosition.X / GridSize.X]
        Y := Floor[InitialPosition.Y / GridSize.Y]
        Z := Floor[InitialPosition.Z / GridSize.Z]

La fonction [Next]() est appelée de manière répétée pour déterminer par quel voxel le rayon va passer ensuite, vérifiant à chaque fois si ce voxel est considéré comme solide.

### Entrées du système de construction

La fonction SelectModeTick_Trace dans player_data s'exécute pour chaque image et gère la majeure partie de la logique de modification des voxels et de mise à jour du curseur. Deux appareils [Input Trigger]() sont utilisés pour savoir quand les boutons Tir et Visée sont enfoncés, et pour définir les variables de logique PlacePiece et DeletePiece.

Cette fonction nécessite une logique supplémentaire puisque les voxels Park sont considérés comme des voxels de surface uniquement, ce qui signifie qu'ils ne bloquent pas les rayons et ne peuvent exister que sur des voxels solides (le sol ou les bâtiments). Vous pouvez mettre à jour la fonction CategoryIsSurfaceOnly lors de l'ajout d'une nouvelle catégorie que vous souhaitez affecter uniquement à la surface.

La construction turbo (turbo building) est également prise en charge en maintenant enfoncé le bouton Tir pour placer rapidement plusieurs voxels dans un plan. Cette fonction vérifie également si un joueur se trouve à l'intérieur d'un voxel avant de l'ajouter à la fonction CheckPlayerOverlapsVoxel.

Générer des accessoires

Cet exemple de projet repose sur la génération d'accessoires à [runtime](). La ressource creative_prop_asset n'est actuellement pas reflétée automatiquement dans les fichiers de manifeste Verse. Vous devez donc utiliser un objet proxy (une instance de piece_type dans la classe piece_type_dir) pour référencer des accessoires spécifiques dans Verse.

L’appareil spawner_asset_references utilise ensuite un champ @editable pour chaque accessoire et une table de mappage du proxy à la ressource réelle. Pour ajouter un nouveau maillage, vous devez d’abord créer un BuildingProp pour celui-ci, ajouter un nouveau proxy, ajouter une propriété à l’appareil, puis mettre à jour la table de mappage (comme indiqué ci-dessous). Enfin, recompilez et actualisez la nouvelle propriété sur l'appareil pour pointer vers le nouvel accessoire.

    Building1_corner:piece_type := piece_type{}

@editable
    BP_Building1_corner : creative_prop_asset = DefaultCreativePropAsset

PT.Building1_corner => BP_Building1_corner

Génération procédurale dans Verse

Cet exemple implémente deux types de génération procédurale dans Verse : la grammaire des formes et la réduction de fonction d'onde. La grammaire des formes s'applique aux bâtiments 3D, tandis que la réduction de fonction d'onde est utilisé pour les zones 2D (plates).

Un exemple de génération d'accessoires de bâtiment est donné ci-dessus.

Un exemple de génération d'accessoires de parc est donné ci-dessus.

Pour les deux techniques, vous devez créer un ensemble d'accessoires de type bâtiment modulaire que Verse génère ensuite à l'exécution. Ce code est déterministe, puisqu'il ne supprime et ne génère des accessoires que selon les besoins.

Grammaire des formes

Tous les voxels d'une catégorie sont transformés en boîtes convexes plus grandes afin d'appliquer ce qu'on appelle la grammaire des formes.

La grammaire des formes se compose de règles simples, chacune acceptant une boîte et générant une ou plusieurs sous-boîtes pour les règles ultérieures.

Par exemple, une règle peut découper une grande boîte en un morceau de sol d'un voxel de hauteur, tandis que les coins et les murs sont attribués à des règles différentes. Une règle spéciale peut faire apparaître un accessoire de la même taille et au même emplacement que la boîte.

Chaque règle est définie comme une classe Verse distincte, dérivant de la classe vo_base (opérateur de volume). Ces règles sont assemblées dans une arborescence d'ensemble de règles à l'intérieur d'une classe dérivée de l’ensemble de règles rs_base.

Cette approche simplifie la création de nouvelles règles, permet d'expérimenter différentes idées et attribue des styles distincts à chaque type de bâtiment. L'application de règles différentes au même ensemble de voxels donne des résultats variés.

Vous trouverez ci-dessous un exemple simple d'opérateur de volume ` vo_sizecheck`.

# Check all dimensions of a box are >= a certain size
vo_sizecheck := class(vo_base):
    Size:vector3i = vector3i{X:=0, Y:=0, Z:=0}
    VO_Pass:vo_base = vo_base{}
    VO_Fail:vo_base = vo_base{}
    Operate<override>(Box:voxel_box, Rot:prop_yaw, BuildSystem:build_system):void=
        if(Box.Size.X >= Size.X and Box.Size.Y >= Size.Y and Box.Size.Z >= Size.Z):
            VO_Pass.Operate(Box, Rot, BuildSystem)
        else:
            VO_Fail.Operate(Box, Rot, BuildSystem)

Il remplace la fonction Operate définie dans la classe de base, vérifie la taille de la boîte entrante et décide laquelle des règles suivantes appeler : vo_pass ou vo_fail.

Les ensembles de règles contenant de nombreux opérateurs de volume sont faciles à configurer dans Verse. Vous pouvez remplacer la fonction setupRules et déclarer vos [operators]() et leurs [parameters](). Le point de départ, ou opérateur racine, est assigné à VO_root, comme indiqué ci-dessous.

# Rules for 'Building1' style
rs_building1<public> := class(rs_base):
     RuleSetName<override>:string = "Building1"
    SetupRules<override>(PT:piece_type_dir):void=
[...]
        # Rules for one floor of the building
        FloorRules := vo_cornerwallsplit:
            VO_CornerLength1 := vo_corner:
                VO_Corner := vo_prop:
                    Prop := PT.Building1_corner

Cette méthode permet de créer facilement de nouveaux opérateurs et ensembles de règles pour différentes catégories de bâtiments. Les ensembles de règles sont assignés dans InitRuleSets et sélectionnés pour une catégorie particulière dans SelectRuleSet, qui se trouvent tous deux dans build_system.

Réduction de fonction d'onde

La réduction de fonction d'onde (WFC) est une technique permettant de générer aléatoirement une zone en fonction de règles qui déterminent le mode d'association de pièces.

Dans cette implémentation, vous pouvez utiliser un ensemble de tuiles, puis spécifier lesquelles d'entre elles peuvent être adjacentes. Les étiquettes s'appliquent à chaque arête, et seules les tuiles dont les étiquettes correspondent peuvent être placées.

Vous trouverez ci-dessous un exemple d'étiquette d'arête issu de la classe wfc_mode_factory.

    WaterEL:wfc_edge_label := wfc_edge_label:
        Name:="Water"
        Symmetric := true

Vous trouverez ci-dessous un exemple de définition de maillage pour l'exemple ci-dessus.

    Park_Grass_Water_InCorn:wfc_mesh := wfc_mesh:
        Props := array:
            PT.Park_Grass_Water_Incorn
        Name := "Park_Grass_Water_Incorn"
        Edges := array:
            WaterEL
            WaterEL
            WaterToGrassEL
            GrassToWaterEL

Vous pouvez spécifier des étiquettes dans le sens horaire, en commençant par la direction +Y.

L'arête inférieure de cet exemple est "eau vers herbe", car chaque arête est considérée dans le sens des aiguilles d'une montre. Avec ce système, il est facile d'ajouter de nouvelles étiquettes et de nouveaux maillages, ou de nouveaux modèles WFC à votre gameplay.

L'algorithme WFC sélectionne un emplacement sur la grille, choisit ou réduit au hasard les options possibles, puis propage les conséquences de ce choix aux options possibles à d'autres emplacements. Ce processus se poursuit jusqu'à ce que toute la région soit générée.

La classe wfc_system contient l'état actuel de tous les carrés. L'opérateur de volume spécial vo_wfc détecte l'état et génère les maillages appropriés.

Extensions potentielles

Vous trouverez ci-dessous quelques façons de transformer cet exemple en de nouvelles expériences.

Ajouter une nouvelle catégorie de voxels/grammaire de formes

• Développer l'enum build_category

• Actualisez toutes les instructions case qui doivent gérer la nouvelle catégorie

• Créez un nouvel ensemble de règles dérivé de rs_base

• Mettez à jour SelectRuleSet pour utiliser le nouvel ensemble de règles pour la nouvelle catégorie

Ajouter de nouveaux maillages au modèle Park WFC

• Créez un accessoire de bâtiment pour chaque nouveau maillage (comme décrit dans la rubrique Générer des accessoires ci-dessus).

• Ajoutez une nouvelle étiquette wfc_edge_label (si vous le souhaitez) sur GetParkModel dans wfc_model_factory.

• Ajoutez une nouvelle instance wfc_mesh pour chaque nouveau maillage/accessoire, définissant l'étiquette de chaque arête.

• Appelez Model.AddMesh pour chaque nouveau maillage.

Ajoutez un nouveau modèle WFC

• Ajoutez une nouvelle catégorie de voxels pour le nouveau modèle.

• Ajoutez une nouvelle fonction à wfc_model_factory pour créer le nouveau modèle.

• Ajoutez un nouveau membre wfc_model à build_system (comme Park_WFCModel).

• Ajoutez une nouvelle fonction comme AddParkWFCTile qui ajoute des carrés à l'aide du nouveau modèle.

• Modifiez SelectModeTick_Trace pour appeler la nouvelle fonction pour la nouvelle catégorie.

Vous pouvez également générer des voxels de manière procédurale. Dans l'exemple de projet, il existe des boutons qui ajoutent des régions de construction ou de parc aléatoires à la zone de construction. Cette opération utilise les fonctions ClearRegion et AddRegion de build_system, qui pourraient servir de point de départ pour un système de génération aléatoire de niveaux.

Performances de Verse

Le code Verse de cet exemple de projet garantit que le code est suffisamment rapide pour traiter les modifications en temps réel. Les grandes matrices étant susceptibles d'entraîner des problèmes de performances, il est important de garder à l'esprit les informations suivantes :

• Utiliser une boucle for pour renvoyer une matrice est plus rapide que de la construire élément par élément, car chaque ajout copie la matrice, ce qui peut entraîner une complexité en O(N2). Par exemple :

  Verse

            * set OptionalArray := for(I := 0 .. ArraySize-1):
                false
  

  Copy full snippet(2 lines long)

• Ne transmettez pas de grandes matrices par valeur. Placez-les plutôt dans un objet et appelez des méthodes ou transmettez l'objet.

• Les matrices multidimensionnelles sont lentes, car le premier opérateur [] transmet une copie à l'opérateur [] suivant.

• L'appel de .Length sur une matrice crée en réalité une copie de la matrice à l’heure actuelle. Il peut donc être plus rapide de suivre soi-même la taille des grandes matrices.

Il est également très utile d’utiliser la macro profile, afin de mieux comprendre quelles parties du code prennent le plus de temps à s’exécuter.