OmniGen 0.3.39

Publiée le 22/10/2026 (version ouverte le 18/10). Validée en jeu le 22/10 (NeoForge 1.21.1, Sodium + Iris, RTX 5070) : 200 à 290 FPS au détail maximal avec le shaderpack Miniature, portée détaillée jusqu'à 128 chunks sur une carte de 12 Go.

✨ Nouveautés

🎬 Mode cinéma (nouveau)

Pour tourner une bande-annonce ou une vidéo sans toucher à la souris.

F7 lance (ou arrête) un script de caméra ; F8 note la position et le regard exacts dans .minecraft/omnigen/cinema/reperes.txt. Les deux touches sont réassignables (Commandes → OmniGen).
Le script est un fichier texte, .minecraft/omnigen/cinema/script.txt (créé avec un exemple), relu à chaque lancement : on le modifie jeu ouvert. Une étape par ligne :
- attendre 3
- bouger duree=4 incline=-25 — relève la tête (+ = vers le bas, comme Minecraft) ;
- bouger duree=12 tourne=+140 — panoramique ;
- bouger duree=6 avance=30 monte=8 fov=60 — travelling, champ de vision ;
- bouger duree=5 x=… y=… z=… yaw=… pitch=… — vers une position et un regard absolus ;
- courbe=douce (défaut), lineaire, entree, sortie.
F9 remet les repères à zéro (l'ancien fichier est gardé, renommé avec la date).
Fluide à chaque image : la pose est calculée pour l'instant exact de l'image, pas au tick. Pendant la lecture : interface masquée, oscillation de vue coupée, souris ignorée ; tout revient à la fin.

🎚️ Profil d'utilisation : Normal, Streamer, Petit PC

Constat : en enregistrant une vidéo, OmniGen occupait tant la carte graphique que l'encodeur d'OBS ne suivait plus ; et l'ancien choix « Affichage » (Stream / Dev / Discret) ne réglait que les messages. Il devient un profil qui règle ce qu'OmniGen PREND (les FPS du jeu ne sont jamais plafonnés) :
- Normal : OmniGen prend ce qu'il faut ;
- Streamer : même rendu que Normal ; moitié moins de fils de maillage, mémoire vive d'OmniGen ≤ 1,5 Go ; le chat d'OmniGen se tait et la barre d'action ne montre plus de coordonnées, mais garde les informations vitales (région voisine verrouillée pendant sa génération, chargement du terrain, portail prêt). Un premier essai bornait le temps de carte du LOD à 3 ms : mesuré en jeu, le LOD coûte déjà 3,2-4,7 ms au détail minimal (coût fixe du fond et de l'horizon) — le détail s'effondrait en méga-blocs sans rien libérer, le jeu remplissant la marge avec plus d'images. Abandonné : pour laisser de la place à l'encodeur, c'est la limite d'images de Minecraft qui compte ;
- Petit PC : réglages de petite machine (réserve ≤ 1 Go, mémoire ≤ 768 Mo, 2 fils, 3 M triangles de détail au lieu de 10 M), terrain lointain voxel borné à 128 chunks (l'horizon lissé prend le relais au-delà). Passer à un profil aux plafonds plus bas (Petit PC) reconstruit tout le terrain lointain (premier essai : la géométrie déjà construite dépassait le nouveau plafond → plus rien ne se rangeait, anneau de trous) ; Normal ↔ Streamer ne reconstruit rien (une reconstruction repasse d'abord par des cases grossières avant l'affinage).
Choix intelligent : au premier lancement, une machine détectée « petite » (puce intégrée, moins de 3 Go de mémoire vidéo, moins de 7 Go de RAM ou 4 cœurs au plus) passe d'elle-même en Petit PC, avec un message. Et quand OBS Studio, Streamlabs, XSplit ou Twitch Studio est ouvert hors profil Streamer, OmniGen le recommande dans le chat, avec un lien qui bascule en un clic (commande /omnigenprofil normal|streamer|petit_pc) ; à la fermeture du logiciel, il propose de revenir en Normal. La liste des programmes est relue toutes les 20 s par un fil de fond.
Portails : plus de coordonnées à l'écran, pour personne (le serveur ne connaît pas le profil du joueur) : « Portail prêt → le Nether (lié au portail d'en face) », « Portail « Base » → Nether ». Elles restent dans le journal du serveur.
Infos développeur (options avancées) remplace l'ancien mode « Dev » : messages détaillés, et une ligne de mesure sous le compteur de FPS (temps de carte du LOD, réserve, portée, profil).

💻 OmniGen s'adapte à la machine (nouveau)

Constat (18/10, journal d'un joueur sur portable) : AMD Radeon Graphics intégrée, 6 Go de RAM, 2 Go donnés à Java, OmniGen seul sans Sodium → 5 à 15 FPS. La mémoire vidéo n'était lue que sur NVIDIA : une puce intégrée recevait les plafonds d'une carte de 8 Go.

Au démarrage, OmniGen lit la carte graphique (et reconnaît les puces intégrées Intel et AMD), la mémoire vidéo (NVIDIA et désormais AMD), la RAM de l'ordinateur, la mémoire donnée à Java, les cœurs et la présence de Sodium. Il en déduit un palier : petite, moyenne ou grande machine ([OmniGen/Machine] dans le journal).
Petite machine : géométrie du terrain lointain plafonnée (proche 384 Mo, anneau fin 192 Mo, couverture 256 Mo), un seul fil de prédiction, portée par défaut 24 chunks (une seule fois, jamais si le joueur l'a changée). Machine moyenne : plafonds intermédiaires, portée par défaut 40.
Un message en jeu annonce le palier, conseille la mémoire à donner à Minecraft pour CETTE machine (la moitié de la RAM, entre 3 et 6 Go) et Sodium s'il est absent.
Bascule « Profil de la machine » (options avancées) pour revenir aux réglages complets.

🌍 English

Ticket de KorinMC (21/10) : « There are no languages except French ». Toute l'interface du client est maintenant traduite en anglais : écran des options, options avancées (les ~106 réglages et leurs descriptions), paliers LOD, choix du terrain lointain, carte et repères, compteur de FPS, messages du chat (profil de la machine, versions, mode cinéma, murs de génération). Le jeu en français garde le texte d'origine ; toute autre langue reçoit l'anglais.
Les noms des réglages restent leurs identifiants (configuration enregistrée, préréglage sûr) : seule leur AFFICHAGE est traduit (client/Tr, table assets/omnigen/i18n/en.json). Les réponses des commandes serveur restent en français pour l'instant.
Bouton YouTube des options : nouvelle chaîne @OmniGenMod. Bouton Discord : nouvelle invitation discord.gg/9GnnmJVwaU.
Sonde au viseur, touche F6 : écrit dans le journal ce que le terrain lointain dessine là où l'on regarde (bloc, prédit ou réel, finesse, sprites, teinte, couleur lue dans l'atlas, peinture, motif) et l'état de l'horizon au même endroit ([OmniGen/Sonde F6]).

🏔️ Horizon lointain lissé (nouveau, palier 3 du terrain prédit)

Constat (21/10, comparatif contre Distant Horizons) : FPS égaux, mais DH voyait plus loin. Les voxels prédits s'arrêtaient au rayon de prédiction (384 chunks) alors que la distance réglée allait jusqu'à 1 024 chunks : entre les deux, rien.

Au-delà des voxels et jusqu'à la distance réglée, un relief continu : tuiles de 512 × 512 blocs, grille de hauteurs au pas de 32, 64 ou 128 blocs selon la distance, normales lissées d'une tuile à l'autre, jupes contre les fentes.
Hauteurs calculées depuis la densité réelle du datapack (compatible Terralith, Biomes O' Plenty, JJThunder…), couleur du biome exact par point, roche sur les pentes, neige en altitude, eau sous le niveau de la mer.
Calcul en arrière-plan (1 ou 2 fils à priorité minimale selon la machine), gardé sur le disque (.minecraft/omnigen/horizon/) : la seconde visite est instantanée. Journal [OmniGen/Horizon] toutes les 30 s.
Profil machine : horizon plafonné à 6 km sur petite machine, 10 km sur machine moyenne.
Bascule « Horizon lointain lissé » (options avancées, allumée par défaut).
Mélange colonnes / lissé (les blocs ne doivent pas trop grossir, même à la lunette) : colonnes façon Minecraft de 4 blocs jusqu'à 2,5 km, de 8 blocs jusqu'à 5 km (relief lu tous les 16 blocs, interpolé, arrondi au bloc ; dessus fusionnés, flancs seulement aux marches, terre sous l'herbe, roche aux marches raides) ; relief lissé au-delà (32 → 64 → 128). Petite machine : lissé seulement.
Comble les manques RÉELS de voxels (région par région), plus seulement au-delà du rayon de prédiction ; dessin groupé (le programme est réglé une fois par image au lieu d'une fois par tuile : −25 ms de processeur mesurés).

🗺️ L'horizon prédit sur la carte

Toute la distance générée se voit maintenant sur la carte. Au-delà du terrain voxel, la carte lit les tuiles de l'horizon sur le disque (pas de 16 à 128 blocs), hachurées comme le reste du prédit. Ligne [OmniGen/Carte] : « pixels pris à l'horizon prédit ».

🟫 Peinture à motif

Dans un même carré de peinture, plusieurs petits carrés, comme les textures de Minecraft. Chaque face peinte est découpée en cases de la taille du motif d'origine ; chacune prend l'une des 16 couleurs de la vraie texture réduite à 4×4, selon sa position. Sur les flancs, la rangée du haut (liseré d'herbe) ne va qu'au sommet. Même géométrie que les flancs tuilés d'avant la peinture. Bascule « Peinture à motif ».
Plus de grain (un arbre au loin ne doit plus être un vert uniforme) : le motif garde 85 % de l'écart à la couleur moyenne (au lieu de 60 %), ±30 % de luminance (au lieu de ±18 %) et les trois quarts de sa teinte.

🧰 Menu des options avancées

Neuf bascules étaient invisibles (absentes de toute catégorie) : hauteur et pente des fluides, escaliers en demi-bloc, plafond et brouillard du Nether, fondu « cape d'invisibilité », LOD à plat près de vous, et les deux sondes de diagnostic. Elles sont rangées et ont leur valeur dans le préréglage sûr.

🎨 Rendu du terrain lointain

⛰️ Détail sur les montagnes du fond lointain

Les montagnes ne sont plus des méga-blocs (le plat peut rester en gros blocs). Le relief de chaque région (écart de surface entre ses chunks, lu dans les résumés déjà calculés) décide : au-delà de 28 blocs d'écart, la région passe en cases de 8 (jusqu'à 350 chunks) puis de 12 (jusqu'à 700), au lieu de 16. Les plaines gardent leurs grandes cases. Sous le plafond de mémoire du fond. Bascule « Détail sur les montagnes ».

🎨 Flancs peints au loin

Quand la texture serait trop étirée, une peinture qui lui ressemble la remplace. Sur les paliers grossiers, le flanc d'herbe répété une fois par case de 4 à 12 blocs empilait des coulures vertes géantes sur les falaises. Au-delà d'un motif de 4 blocs, les flancs sont désormais peints (couleur moyenne de la vraie texture × teinte du biome) : un seul rectangle par flanc, que la fusion des flancs peut réunir. Bascule « Flancs peints au loin ».

🎨 Plus de méga-blocs d'herbe : peinture dès 2 blocs, dessus compris

Fini les méga-blocs d'herbe : la peinture est beaucoup plus détaillée. Les flancs ET les dessus sont peints dès que leur texture serait répétée moins d'une fois par bloc (motif de 2 blocs ou plus) ; les dessus gardent le dégradé de biome à leurs coins.
Sable cyan, glace verte, neige noire : la couleur moyenne était lue au mipmap 4 de l'atlas, alloué mais pas toujours rempli (le niveau réel dépend du plus petit sprite). Lue désormais au niveau 0.
Les maillages construits avant la lecture de l'atlas (au chargement du monde) n'étaient jamais peints : ils sont refaits une fois la lecture faite.
Les faces ÉTIRÉES (un seul sprite sur toute la face : terrain prédit, paliers fusionnés) sont peintes elles aussi dès 2 blocs — c'étaient elles, les méga-blocs restants. Eau et lave gardent leur texture animée.
Horizon : carte de lumière liée explicitement (taches noires), et masqué sur toute région qui a des voxels.

🪨 Roche sous les falaises lointaines

Au loin (paliers de 12 chunks et plus), les murs qui ferment le terrain prenaient le flanc du sol sur 24 à 32 blocs : une pente enneigée devenait une colonne blanche, une prairie une bande verte étirée. Ils gardent maintenant 2 blocs d'herbe, de terre, de neige ou de glace en haut, puis passent à la pierre, comme une vraie falaise — le tout peint, jamais étiré.
Même règle sur les flancs de l'horizon lointain.
Bascule : « Roche sous les falaises lointaines » (activée).

🌅 Horizon lointain : plus jamais sous les voxels, couleurs recalées

Une tuile d'horizon (512 blocs, 16 régions) n'était retirée que si ses 16 régions avaient des voxels : à moitié couverte, elle se dessinait sous le terrain voxel, 4 blocs plus bas. On la voyait à travers l'eau (le bleu criard au loin) et elle affleurait par bandes sur les pentes (les rayures noires la nuit). Chaque tuile est maintenant maillée sans les régions déjà affichées, et refaite quand elles changent. Bascule « Horizon jamais sous les voxels ».
Couleurs mesurées sur capture : herbe de l'horizon (79, 171, 73) contre (120, 120, 78) pour l'herbe voxel juste devant, eau (51, 82, 188) contre (105, 128, 169). Recalées (teinte × texture, comme le voxel). Bascule « Horizon aux couleurs du terrain ».
Les colonnes vont jusqu'à 7 km (cases de 16 blocs entre 5 et 7 km) au lieu du relief lisse en triangles, qui y faisait des pics bariolés hors du style « blocs ».

🌊 Eau du LOD à la hauteur de Minecraft

Un trait sombre en polygone sur la mer, à la limite des vrais chunks. Les eaux dormantes du LOD étaient dessinées à 1 bloc, la vraie eau à 8/9 : 11 cm de marche dont le flanc ombré se voyait. Désormais à 8/9. Bascule « Eau à la hauteur de Minecraft ».

📏 Plus de marche au bord des vrais chunks

Sous shaderpack, l'anneau de LOD situé juste au-delà de la distance de rendu restait enfoncé d'un demi-bloc (biais de jonction), alors que le LOD n'est plus jamais dessiné sur un vrai chunk et que le fond lointain, lui, affleure : une marche à la distance de rendu et une autre six chunks plus loin, dont on voyait le dessous (le trait sombre qui suivait les chunks sur l'eau). Au-delà de la distance de rendu, le LOD affleure partout. Bascule « Pas de marche au bord des vrais chunks » (activée).

🌊 Plus de mur d'eau au bord des régions prédites

Une bande sombre et droite traversait la mer au bord d'une région. C'était une paroi d'eau, de la surface au fond, vue à travers l'eau : émise parce que le chunk voisin n'était pas encore connu au moment du maillage. Une colonne d'eau ne se ferme plus jamais vers l'inconnu. Bascule « Pas de mur d'eau au bord des régions ».

💧 Plus jamais d'eau peinte

Plages et morceaux de mer verts ou cyan (21/10 au soir) : le journal montrait water_still dans la liste des textures peintes. Peinte, l'eau perdait sa texture translucide et ne gardait que la teinte du biome (verte dans un marais, cyan dans une mer chaude). Les fluides ne sont plus jamais peints, sur aucun chemin.
Sonde : une face peinte qui sortirait presque noire est écrite une fois par texture (face peinte presque NOIRE).

🐞 Corrections

🖥️ Écran des options coupé sur les petits écrans

Ticket de KorinMC (22/10) : « Settings GUI is cut. There're more settings above LOD » (écran 1536×864 à 125 %). Les 10 rangées de 38 px dépassaient la hauteur de l'interface (~288 px) : le titre et la rangée « Profil » sortaient par le haut. L'écart entre rangées se resserre maintenant pour tenir dans la hauteur ; sans la place, les libellés de section ne sont pas dessinés.

✅ Plages cyan, neige noire, glace vert citron : la VRAIE cause (débordement de couleur)

Mesuré à la sonde F6 (sable : peinture ×1,058, teinte blanche) : la couleur d'un sommet passait au-dessus de 1, et BufferBuilder.setColor(float…) la convertit en octet SANS la borner — 1,058 → 269 → 13. Le rouge du sable retombait à zéro (turquoise), tout canal au-dessus de 1 (neige, calcite, glace, herbe claire) virait au noir ou au vert. Les couleurs des sommets sont désormais ramenées à 1 en gardant leur nuance (LOD voxel et horizon). Les deux correctifs ci-dessous (texel unique, garde-fou) visaient de fausses pistes ; ils restent, sans effet nuisible.

💡 Lumière du LOD sous shaderpack

Avec un shaderpack, la lumière du terrain lointain était mal rendue, sur tous les packs (sans pack, rien). La sonde des sommets montrait une tangente NULLE (at_tangent = 0, 0, 0) sur les faces peintes : elles prenaient toutes le même point de texture, et Iris calcule la tangente à partir des écarts de coordonnées de texture. Le pack bâtissait donc son éclairage sur un vecteur nul. Chaque coin reçoit maintenant un quart de texel d'écart autour du même texel (même couleur) : tangente propre. Même correctif pour l'horizon lissé. Bascule « Peinture compatible shaderpack » (activée).

🕳️ Trous sous shaderpack : corrigés (mesuré)

Mesure du 21/10 ([OmniGen/Profondeur]) : sous shaderpack, plan lointain de Minecraft 128 blocs contre 17 408 pour le LOD → à 32 blocs, le LOD « paraissait » 6,4 blocs plus près et passait devant le vrai sol (trous, parois sombres).
Sous shaderpack, le LOD ne se dessine plus sur aucun chunk que Minecraft dessine (ni dessous, ni en lisière). Bascule « Pas de LOD sur les vrais chunks (shaderpack) », allumée par défaut.

🧱 Génération par région : plus de région figée à « 0/64 »

La région en cours restait à 0/64, 0 en vol pendant 18 minutes, et rien ne se générait plus autour du joueur. Cause : depuis le 17/10, un chunk déjà complet sur le disque est sauté sans être chargé ; il ne cochait donc jamais sa case dans la région. Une région générée lors d'une session précédente bloquait tout. Les chunks sautés comptent maintenant comme finis.

🟩 Murs lointains verts

Les jupes des paliers fusionnés multipliaient le flanc du sol par la teinte du biome même quand ce flanc n'est pas teinté (flanc d'herbe déjà colorié en marron) : murs verdis, vert franc une fois peints. La teinte n'est plus appliquée qu'aux flancs teintés, comme au maillage fin depuis le 08/09.
Sonde d'à-coups : la ligne [OmniGen/À-coup] nomme maintenant les deux étapes les plus lourdes du dessin (étapes du terrain voxel, horizon : choix des tuiles / envois / dessin, lecture de l'atlas).

⬛ Flancs peints : couleurs lues sur la carte graphique

Glace peinte en vert citron, neige peinte en noir. La couleur moyenne était lue dans l'image d'origine de chaque texture, qui n'est plus fiable dans son pack une fois l'atlas envoyé à la carte (des mods d'optimisation libèrent cette mémoire) : on y lisait n'importe quoi. Elle est maintenant lue dans l'atlas tel que la carte le dessine, au niveau de mipmap où une texture 16×16 tient en un pixel, qui est sa moyenne. Une lecture sur le fil de rendu, quelques centaines de Ko, refaite après F3+T. Tant qu'elle n'est pas faite, les flancs gardent leur vraie texture. Couleurs écrites dans le journal ([OmniGen/Peinture]).

⬛ Flancs peints noirs, verts ou cyan : première piste (mipmap)

Le journal du 21/10 au soir montrait des couleurs lues justes et aucune face peinte noire : le défaut n'était pas la couleur. La face peinte étalait tout le sprite du béton blanc ; un flanc fin à l'écran fait prendre à la carte un mipmap très réduit, où un texel mélange le béton et ses VOISINS dans l'atlas. Les faces peintes échantillonnent désormais un point unique au centre du sprite : blanc pur à toute distance.

🛡️ Garde-fou de la peinture

Toute face qui sortirait CYAN ou presque NOIRE alors que sa texture ne l'est pas n'est pas peinte : elle garde sa vraie texture. Chaque cas est écrit dans le journal (texture, teinte d'entrée, multiplicateur) et compté sur la ligne [OmniGen/GPU] … flancs. Motif adouci (±18 % de luminosité, teinte proche de la moyenne) : plus de minerais en pavés.

💥 Plantage du pilote graphique à 4 Go de géométrie

Deux plantages natifs le 21/10 au soir (accès mémoire interdit dans glMultiDrawElementsBaseVertex), le second 0,4 s après l'agrandissement de la réserve de géométrie à 4 095 Mo. Plafond ramené à 3,5 Go : au-delà, le LOD libère de la place au lieu de grossir (c'est aussi ce qui provoquait le gel de 10 s).

⚡ Performances

🎚️ Détail du terrain : le pilote ne dégrade plus l'image pour rien

Mesure du 22/10 : le pilote de détail (crans 0 à 7, taille d'un bloc à l'écran) tombait au cran le plus grossier pendant le chargement (« 33 FPS ») et y restait : 5 min de verrou, 115 FPS pour remonter. Or le cran ne décidait pas des FPS (128 au cran 2, 100-115 au cran 0). D'où les méga-blocs devant, avec un lointain plus fin que le proche.
Plus de jugement pendant la première minute ; il faut 5 s d'affilée sous 90 FPS pour baisser ; 30 s de répit après un changement de cran ; chaque baisse est vérifiée et annulée si elle ne fait pas gagner 8 % d'images.
Plus rapide (un joueur ne reste pas immobile des minutes devant le paysage) : montée en 8 s quand les FPS dépassent 2× l'objectif, deux crans d'un coup au-delà de 2,5×. Le cran tenu 60 s est retenu (config/omnigen-detail.txt) : la partie suivante démarre directement au bon cran. Mesuré : cran 1 → 7 en 34 s au lieu de 3 min 30, puis directement au cran 7 ; 200 à 290 FPS au cran 7 avec Miniature (RTX 5070).

🏔️ Fond lointain : affiné au-delà de l'anneau

Mesure : le fond n'affinait qu'une fois toute la portée couverte en 16×16 (~52 000 régions : jamais) ; au-delà de ~166 chunks, tout restait en pavés de 16 blocs. Il prend maintenant son palier fin (8, 12, 14) jusqu'à 350 chunks pendant la couverture, le plus proche d'abord. Anneau fin : 1 Go sur les cartes de 12 Go (au lieu de 600 Mo).
Le proche d'abord : le fond ne grandit plus au-delà de 80 % (fin) / 84 % (couverture) de la réserve, et rend sa mémoire au-delà de 86 % (régions fines à plus de 200 chunks → couverture). Sans ça, la portée détaillée reculait de 64 à 30 chunks (« des gros blocs devant pendant quelques secondes »).
Bouche-trous du proche (régions dont les chunks ne sont pas prêts) : 4×4 sous 32 chunks seulement, 8×8 au-delà (3,5 Mo → 0,6 Mo par région ; 74 régions = 257 Mo en tournant la tête).

📦 Réserve de géométrie : 5 Go sur les cartes de 12 Go

La réserve (3,5 Go) était le vrai frein du détail, pas les FPS. Sur les cartes de 12 Go et plus, elle passe à 5 Go et le proche à 3 Go. Depuis les pages, aucun tampon ne dépasse 256 Mo (le plantage du 21/10 venait d'un tampon unique de 4 Go).

📄 Réserve de géométrie en pages : plus de gel de 10 s ni de tampon géant

Mesure du 21/10 : une image de 10,6 s au moment où la réserve passait de 3,7 à 4 Go — elle créait un tampon neuf et y recopiait tout. La réserve est maintenant faite de pages de 256 Mo : grandir = ouvrir une page, rien n'est recopié ; Le dessin se fait page par page (dessin direct et dessin trié par la carte), chaque page a sa propre liste de commandes.
Une page ouverte reste ouverte pour la session : les rendre à la carte dès que la fin de la réserve reculait faisait ouvrir et fermer 40 pages en 30 s (premier essai du 22/10, image de 4,4 s).
Les seuils de recul de la portée « pour la mémoire » suivent maintenant le plafond réel de la réserve (ils visaient encore l'ancien plafond de 4 Go et ne se déclenchaient plus).

🗺️ L'horizon sur la carte charge bien plus vite

Carte dézoomée : ~4 000 tuiles d'horizon à l'écran pour un cache de 384 → des milliers de fichiers relus à chaque rafraîchissement, au pas le plus fin. La carte lit maintenant le pas qui correspond à son zoom (au plus grossier, un fichier fait 300 octets) et garde jusqu'à ~24 Mo de tuiles en mémoire.

🔧 Diagnostic et développement

🔍 Diagnostic : trous sous shaderpack

Constat (17/10) : sous shaderpack, des trous près du joueur (le LOD apparaît à la place du vrai sol). Sans pack, rien.
Cause probable, à confirmer en jeu : sous pack, Minecraft et le LOD n'utilisent pas le même plan lointain, donc pas la même échelle de profondeur ; le LOD gardé sous les vrais chunks paraît plus proche qu'il n'est (~4 blocs à 64 blocs de distance) et passe devant le vrai sol.
Nouvelle bascule de diagnostic (options avancées, coupée par défaut) : « Profondeur du LOD alignée sur Minecraft (diagnostic) », et une ligne [OmniGen/Profondeur] dans le journal (plans lointains et écart calculé).

🔎 Mesures ajoutées

Sonde F6 : sol de la colonne visée (hors feuillage), palier du maillage de chunk, région lointaine qui la dessine, horizon AU POINT visé — pour les feuilles qui flottent au loin.
À-coups : « chunks proches » détaillé (fond lointain, ordonnanceur, tri et dessin par la carte, dessin par le processeur) ; les quatre étapes les plus lourdes sont écrites.
Temps de carte du LOD découpé par part (horizon, terrain trié, chunks rejoués, fond, ordonnanceur, tri, attente du processeur), triangles du fond lointain, temps processeur moyen de chaque étape ; composition de la réserve (proche, fond fin, couverture, bouche-trous).
Défragmentation moins gourmande tant que la réserve a de la marge (~8 Mo copiés par image au lieu de ~26).

🛠 Développement

Compilation automatique sur GitHub Actions à chaque push sur main ; le jar est publié en artefact.

📌 À savoir

Serveur : mettez le même jar sur le serveur (serveur arrêté) pour la génération par région et le terrain partagé.
Détail du terrain : OmniGen règle tout seul la finesse du terrain lointain selon vos images par seconde (objectif 100 FPS, jamais plafonnées) ; le réglage trouvé est retenu pour les parties suivantes (config/omnigen-detail.txt — supprimez-le pour repartir de zéro).
Profil : Normal par défaut ; Streamer si vous enregistrez ou diffusez (OBS, Streamlabs…) ; Petit PC choisi tout seul sur les petites machines. Commande /omnigenprofil.
À suivre en 0.3.40 : un nouveau format de stockage du terrain lointain (bien plus de détail au loin pour la même mémoire, avec les vraies textures), et des corrections sur l'horizon prédit avec Terralith.

OmniGen

Links

Tags

Creators

Details

0.3.39

Compatibility

Changes