Bloxyde

Notes d’architecture et génération progressive

- Le systems d’octree même avec implementation laine n'est pas viableNote

soft reflexion: evaluate probes ddgi hard reflection: trace a real ray transparent medium hTspr1 hSld2 hSld1 -------h1t-------------h1s ----------------h2s 000000111111112x nx0 mx1 1x2 end struct fragment { float length // for transparent uint_8 material uint_8 childs[3] uint_8 operators[3] } fragment solvefragmentgraph( fragment fragmentGraph )

idée system de gennerationn progressive

Objectifs généraux

open world procedural

mining

crafting

building

multiplayer

PVE / PVP

Réglages GPU et coalescence mémoire

static const int MAX_CHUNK_STEPS =16 ;

-> impacte énorme sur les perfs;prendre en compte l’effet de  la coalescence

rayons proches ( exécutés dans les meme work group ) doivent appeler des zones mémoire proche dans la VRAM

Optimisation lookup et paramètres terrain

Beam Optimisation// terrainstatic const float WATER_LEVEL_WORLD = 2.0f;

static const float SAND_LEVEL_WORLD  = 4.0f;

const float freq3D    = 0.015f;

const int   oct3D     = 6;

const float threshold = 0.05f;

const float baseHeight = 16.0f;

const float heightBias = 0.0001f;

///////// Idée pour implémentation multijoueur 👍construire la structure du jeu comme une interaction entre le monde et une session ( un joueur ) . Les accesseurs du monde seront déjà comme des requêtes réseauPeut-on paraléliser la physique sur les ordinateurs des joueurs ?-> facile de répondre quand les joueurs sont espacés , complexe quand ils sont dans les meme “îlots physiques “

Beam optimisation et terrain

ajout d’un effet de chamfer sur les voxels ( uniquement avec la normale )

Idée supplémentaire pour la génération de terrain:ajouter un facteur sinus qui prend du perlin entrée

le masqué par le produit du gradient du perlin densité et l’axe verticalCela permet d'appliquer le sinus uniquement au zones où le gradient est horizontal -> falaises / zone escarpées.zone platezone platezone escarpée

optimisation -> calculé le gradient analytiquement

DDGI, chunks et interface

Il faut corriger tous les artefactes graphiques

ill faut gere dynamiquement les DDGI probes qui sont actifsplutot 16 voxels ou 32 voxels de haut pour le player ?

changement de la taille de chunks ( 32x32x32 -> 16x16x64 ) adaptation de la coarse grid, adaptation des probesamélioration des SSAO

Interface du menu multijoueur;

recherche d’une fonction 3D pour decrire les arbres ( au final faut mieux passer par un vrai algo )

Idée optimisation terrain

mettre un flag pour les objet ayyant une transfo “ translation only “

system de build basique

delete, place, place meme lors de la transition d’un chunkmise à jour coarseGrid avant l’nvois GPU

ajout du deplacement ( pick and drag ) d’objets.

Broad phase, narrowphase et frontières de chunk

Amelioration du moteur physique : fixed dt, sleep mode

Amelioration physiques : meilleurs parametres, empilement

Idée ambiance musicale

Theme creepy : orbital_Drone T/A/N

Nettoyage du moteur physique et description topo

Ajout de rotations dans le moteur physique

liste de correction à faire plus tard

améliorer SSAO

corriger seam voxel

optimisations à faire plus tard: ajouter un mode sleep pour les probslocaliser les changement de topo lors de l’edition

améliorations à faire

water post process

physic split

Fixed DDGI problem

working on dynamic ddgi state and positions

Debut du formalisme Command/Event

FIX zone noires DDGIFIX SSAO + RAY LEAK

Relecture/ Nettoyage

Creation de la classe player;

Nettoyage des initialisations dans le main

Creation de la classe Material et PaletteCentralisation des parametres de generation dans un tunable

Tentative de refactorisation du client ( pas ouf , revenu sur le truc de base )

Nettoyage Chunk.h

idée: faire quelquels prefabs de rochers pour la generation, est ce qu’on fait des arbres prefabes ou proceduraux ducoup ?

Nettoyage ChunCoarseGrid.h

Amelioration du debug topologie

Relecture de PhysicsWorld.h

Note

world -> chunk -> voxel objects -> gride -> entities -> ref to -> navmeshes // un chunk peut poseder differents navmesh déconnecté ex : sommet d'une falaise / endroit clos -> navmesh = surface exposée au dessus && // possible a faire depuis une version low res du chunk ex : /4          getPath( A, B ) concerned vobjects entitie -> model            -> featuremodel -> node name            -> node transforms             -> child nodes

Graphic optimisation

shadow pass optimised

chunk lookup hash -> table

tentative d’opti special terrain -> pas ouf

Optimisation moteur physique : on ne test la penetration EE/ES que si EF ne genere pas assez de contacts

Refactorisation du code

Optimisation moteur physique

Nettoyage du fichier broadphase

toujour entrain de debloat la broadphase,

quelques conventions de code

utiliser du snakeCase les variablesne pas utiliser de redondance avec le type ex: une liste ne dois pas contenir “list” dans son nom:objectList X → cellObjects V

Resumé du fonctionnement de la broadphase

Le filtrage AABB est plus précis que le simple overlap et très peux couteux, en pratique on ajoute un skinning ( offset ) pour eviter le jittering

Definition d’une clef d’acces des objets permettant d’avoir une correspondance entre differencte representation. Avant on utilisait différentes clefs basée sur

ivec4( ivec3 chunkKey, int localObjectIndex )

maintenant on a le meme systeme partout, on garde la meme logique mais avec

using EntityId = uint32_t;

-> En sortie de broadphase, lorsqu’un objet est à cheval entre deux chunks, on a une paire par chunk, donc un objet sur le sol peut generer jusqu’à 4 paires. A voir si y a pas une meilleure façon de faire.-> Relecture de la Narrowphasecréation d’un namespace special pour toutes les fonctions geometriques

/!\ Certain body n’effacent pas l’objectGrid après leur passage.

-> reduction a 4 substep max et 0.25 de threshold pour le tunneling.

Optimisation de la narrowphase, on se sert du niveau Brick8 pour generer des subsets topologiques. Cela permet par exemple de ne pas parcourir toutes les surfaces de terrain lors du sondage. la narrow phase passe de 2ms à 1ms pour un unique RigidBody sur le terrain

En observant le diagram de flamme pour la narrowphase à la base, on voit que le player pickup à l’air beaucoup trop lourd :

→ on la passe en asynchrone

Schéma Narrowphase Partie 1

Ajout d’une phase de culling supplémentaire dans la narrowphase

une premiere collision est effectuée entre les fragment 8x8x8 de voxel plein ou vides. les fragments pleins de l’objet A penetrant des fragments pleins de l’objet B forment des paires. On test ensuite les collision à echelle voxel, à l’interieur de ces pairesEssaie d’optimisation des structures coté CPU ( notamment les nouveaux fragments / fragments binary )

Correction access violation in Broadphase

Implementation de RayCast.h pour passer la detection de voxel coté CPU.

arrete adoucis et anti shimmering.

Le coup niveau fps est de l’ordre de 3ms ce qui fait passer de 140 à 100 fps.

Je retire le chamfer pour l’instant en attendant d’avoir un model qui pompe pas 40 fps.

soft edge remis + gestion du shimmering

2 versions

generation de normales par context

Assez realiste, conserve bien l’aspect +

LOD

On voit que la LOD pose un problème “ quel voxel est représentatif de tel ensemble de voxel, produisant de mauvaises decisions pour préserver une surface fine.

Elle donne une transition moins naturelle.n’ameliore pas les perfs ( -20 fps que les N/Ctx )- Cela induit une mauvais perception des distances

- Introduction de coutures entre les terrains

→ On choisit la methode N/Ctx

→ quantification du rayon primaire pour diminuer encore le shimmering : mauvais

On essaie d’ajouter un pass TAA

Le edge smooth uniquement normal suffit pas car il y a une ambiguité niveau exposition → on passe à un smooth géométrique

On a trois options pour l’adoucissement des bords : effet screen space

effet de normale

deformation geometrique

debut du travail sur la micro geometrie

( le plus difficile en premier : la geometrie externe )comme les shaders deviennent lourds, on doit passer par une etape de debloat, pour faciliter la compilation et le temps optimisation driver.

Je teste deux approches différentes pour les fillets

DDA intravoxel pour la micro géométrie calculée cotée CPU

generation dynamique des surface de fillet entièrement du coté GPU

Aucun des deux n’est satisfaisant.

Nouvel approche

definir une SDF au niveau de la surface des voxels

Première implementation de la SDF

Beaucoup de glitch, de bug et performance très sous-optimales. Mais cela semble etre une solution viable. Pour reprendre le tableau cité plus tot :

Une des raisons pour laquelle cette solution peut avoir des effets minimaux sur les perfs est qu’une partie de la logique est deja existante et necessite juste une adaptation : la DDA fine se fait sur un bitmask de frontiere solide/airla DDA tuile 8x8x8 est juste générée sur ce bitmask ( c’est meme mieux car ce sont des matrices booléene et pas 8bits )la seule logique réellement ajoutée est l’evaluation finale de la SDF et la recherche du materiaux. Le degrés combinatoire est beaucoup plus faible que pour un fillet

Phase d’optimisation de la SDF.

D’après la vidéo de Mike Turitzin, au lieu de stocker les valeurs de controle de la SDF par sommet, on peut regrouper les sommets par cellule dans une brickmap

Cela rend la représentation redondante, mais permet d’obtenir les valeurs en appels mémoire uniques. ( en 3D cela veut dire 41 appel au lieu de 8 par interpolation de la SDF )