Perso semi lowpoly pour anim/jeux

Bon ça fonctionne presque j'ai un probleme en essayant de recalculer la hauteur des mailles de la displacement map...

C'est quoi les petites boules bleue-ciel ?

j'ai un probleme en essayant de recalculer la hauteur des mailles de la displacement map...

Peux-tu préciser ? Pourquoi dois-tu recalculer, est-ce dans le but de faire une map aléatoirement générée ?

Ah oui expliquons mieux
- Je pars d'une image pour créer la map et son relief. Genre:


Cela me donne un Mesh avec avec une geometry Plane, subdivisé à l'envie pour les détails et avec une échelle pour accentuer + ou - les reliefs, un plane dont les points sont automatiquement déplacé à partir de l'image.
C'est le material qui crée donc une deplacement map (comme une bump map sauf que la les points sont affectés)
J’obtiens donc un mesh  ce plane avec des parametres, pour chaque point normal, position et uv


Mais dont il me faut recalculer la hauteur des points si je veux m'en servir. Hé oui car dans le paramètre position de la geometry de ce plane, la hauteur de chaque point reste la hauteur du plane original (=0)  
Ici par exemple j'ai cette config initiale de map :
let map0={
   heightMap:"img/heightmap-300x300.png",  
   size:200,   // = la taille hauteur et largeur en m
   widthSegment:400,   // =la précision ou subdivision  hauteur et largeur, ça veut dire que là ma subdivision est de 2 par mètre
   displacementScale:10 // =l’échelle de hauteur de la carte
}

Pour l'instant j'essaie sans les collisions et sans physique générale dans le jeu de gérer la hauteur de mon personnage et j'y arrive assez bien (mais peut-être que je devrais utiliser les collisions car la dispacement map peut bloquer des objets par exemple)

Et c'est là qu'on arrive au points bleus : chaque point du plane de terrain c'est mon re calcul des hauteurs, qui devraient chacun se trouver au niveau du sol, donc a moitié visible. Le problème c'est que mon calcul est pas  identique au calcul de three pour trouver les hauteurs et que je me retrouve avec un truc approximatif. Cela fait que mon perso vole ou s'enfonce sur le terrain (comme à la fin de la vidéo) puisqu'il se repère aux points qui sont représentés en bleu

Ok, ça devient plus limpide.

Donc en fait tu génères une texture de type noise !

J'ai fais la même chose pour générer mon terrain 2D dans Godot (mais avec une dimension en moins). Cela dit, je pense que tu aura plus facile de faire correspondre ton terrain en fonction des pixels chaud et froid (entre 0 et 10, ou -5 à 5) pour déformer plus facilement ton terrain.

Bon, comme je ne connais pas Three.js, j'ai triché en consultant Chat-GPT, et il m'a fait comprendre que ce que tu cherche à faire, c'est un shader, ce qui colle avec le fait que ça passe par un matériel.

Il y juste 2 mots qui me gênent: Materiel et animation. Et j'ai le sentiment que certaines boules bleues ne correspondent pas avec ton terrain parce que tu fais une déformation visuelle et non physique, comme si tu utilisais un shapekey dans blender, ce qui colle avec ta vidéo précédente, pour moi.

J'ai posé la question à Chat-GPT et il m'a répondu qu'il faudrait, dans ton cas, utiliser l'algorythme Smoothed Particle Hydrodynamics (SPH). Je ne connais pas ton niveau donc je ne sais pas si tu sera apte à gérer cette partie technique, si c'est trop compliqué, envisager de faire le terrain depuis blender et de faire l'impasse sur la génération aléatoire me semble judicieux.

Pour le fun, je te partage ce que l'ia m'a pondu pour le shader, et pour le SPH. Je ne connais pas l'exactitude du script, ni les éventuels erreurs. Amuses-toi bien !

Code:


// Créer un objet plan
const geometry = new THREE.PlaneGeometry(5, 5, 64, 64);
const material = new THREE.ShaderMaterial({
  uniforms: {
    uTime: { value: 0 },
    uNoiseTexture: { value: new THREE.TextureLoader().load("noise.png") }
  },
  vertexShader: `
    uniform float uTime;
    uniform sampler2D uNoiseTexture;
    
    varying vec2 vUv;
    varying float vNoise;
    
    void main() {
      vUv = uv;
      
      vec4 noise = texture2D(uNoiseTexture, uv * 10.0 + uTime);
      vNoise = noise.r * 2.0 - 1.0;
      
      vec3 pos = position + normal * vNoise;
      gl_Position = projectionMatrix * modelViewMatrix * vec4(pos, 1.0);
    }
  `,
  fragmentShader: `
    varying vec2 vUv;
    varying float vNoise;
    
    void main() {
      gl_FragColor = vec4(vec3(vNoise * 0.5 + 0.5), 1.0);
    }
  `
});

const plane = new THREE.Mesh(geometry, material);
scene.add(plane);

// Animer le plan
function animate() {
  requestAnimationFrame(animate);
  
  material.uniforms.uTime.value += 0.01;
  
  renderer.render(scene, camera);
}
animate();



Code:


// Configurations
const PARTICLE_COUNT = 128 * 128;
const PARTICLE_SPACING = 0.025;
const REST_DENSITY = 1000;
const PARTICLE_MASS = 0.02;
const GAS_CONSTANT = 2000;
const VISCOSITY = 0.1;
const PARTICLE_RADIUS = 0.1;
const MAX_FORCE = 100;
const WALL_DAMPING = -0.5;
const dt = 0.002;
const MAX_VELOCITY = 10;

// Créer un objet plan
const geometry = new THREE.PlaneGeometry(5, 5, 128, 128);
const material = new THREE.MeshPhongMaterial({
  color: 0x3366ff,
  side: THREE.DoubleSide,
});
const plane = new THREE.Mesh(geometry, material);
plane.rotation.x = -Math.PI / 2;
scene.add(plane);

// Initialiser les particules de fluide
const particles = [];
for (let i = 0; i < PARTICLE_COUNT; i++) {
  const x = (Math.random() - 0.5) * PARTICLE_COUNT * PARTICLE_SPACING;
  const z = (Math.random() - 0.5) * PARTICLE_COUNT * PARTICLE_SPACING;
  const y = REST_DENSITY / PARTICLE_MASS / (PARTICLE_COUNT * PARTICLE_SPACING * PARTICLE_SPACING);
  
  particles.push({
    position: new THREE.Vector3(x, y, z),
    velocity: new THREE.Vector3(),
    force: new THREE.Vector3(),
    density: 0,
    pressure: 0,
  });
}

// Animer le plan
function animate() {
  requestAnimationFrame(animate);
  
  // Mettre à jour la position des particules de fluide
  updateParticles();
  
  // Déformer le mesh en fonction des positions des particules de fluide
  deformMesh();
  
  // Rendre la scène
  renderer.render(scene, camera);
}

// Mettre à jour la position des particules de fluide
function updateParticles() {
  // Reset les forces des particules
  for (let i = 0; i < PARTICLE_COUNT; i++) {
    particles[i].force.set(0, 0, 0);
    particles[i].density = 0;
    particles[i].pressure = 0;
  }
  
// Calculer la densité et la pression de chaque particule
for (let i = 0; i < PARTICLE_COUNT; i++) {
  const pi = particles[i];
  
  for (let j = i + 1; j < PARTICLE_COUNT; j++) {
    const pj = particles[j];
    const r = pi.position.distanceTo(pj.position);
    
    if (r < PARTICLE_RADIUS * 2) {
      const q = r / PARTICLE_RADIUS;
      const u = 1 - q;
      const w0 = PARTICLE_RADIUS * PARTICLE_RADIUS / (4 * Math.PI);
      const w1 = -3 * PARTICLE_RADIUS * PARTICLE_RADIUS / (4 * Math.PI * r);
      const w2 = (2 * PARTICLE_RADIUS * PARTICLE_RADIUS * PARTICLE_RADIUS) / (4 * Math.PI * r * r * r);
      const p = GAS_CONSTANT * (pi.density / REST_DENSITY - 1);
      const f = new THREE.Vector3();
      
      // Calculer la force de pression entre les particules
      const pressureForce = pj.position.clone().sub(pi.position).normalize().multiplyScalar(p + pj.pressure).multiplyScalar(w1);
      pi.force.add(pressureForce);
      pj.force.sub(pressureForce);
      
      // Calculer la force de viscosité entre les particules
      const viscosityForce = pj.velocity.clone().sub(pi.velocity).multiplyScalar(w2 * VISCOSITY * PARTICLE_MASS);
      pi.force.add(viscosityForce);
      pj.force.sub(viscosityForce);
      
      // Ajouter la densité de la particule à la densité totale
      pi.density += w0 * u * u * u;
      pj.density += w0 * u * u * u;
    }
  }
  
  // Calculer la pression de la particule en fonction de sa densité
  pi.pressure = GAS_CONSTANT * (pi.density / REST_DENSITY - 1);
}




@redstar :  Arf je ne suis pas sure de comprendre ta réponse sur plusieurs points. ca a l'air compliqué vu de loin, le 2e algo ressemble a du deplacement de gaz, c'est pointu

Pour l'instant je vois si c'est possible d'améliorer la précision de ma méthode avant de laisser tomber et d'essayer autre chose peut être... car je ne suis pas loin d'arriver à mes fins et pour un coût processur et gpu pas trop ouf et des formes de collines que je peux facilement créer dans un logiciel de dessin.

Si tu veux comprendre le principe de la displacement map, il y a une page de démo bien faite ici : https://threejs.org/examples/?q=map#webgl_materials_displacementmap ou tu peux t'amuser a voir les effets de la displacement map sur un visage androide selon l'intensité du scale, ça déplace simplement les vertix en hauteur. Je pense que c'est pas mal comme principe à utiliser pour un terrain. Par contre, three étant assez jeune et en évolution,, pas trop d'aide pour moi là dessu, faut fouiller pour trouver un embryon de réponse quand ça devient un peu technique

Et un lien encore mieux ici : tu as un éditeur de terrain basique,  de l'eau des vagues -> https://stackblitz.com/github/tamani-coding/threejs-buffergeometry-examples?file=README.md  qui est lié à ce projet github (open source)  : https://github.com/tamani-coding/threejs-buffergeometry-examples/blob/main/README.md

Donc je pense que je vais utiliser de ce dernier lien pour expérimenter la chose sous un angle légèrement différent, mais d'abord je vais essayer simplement de voir avec un plane subdivisé et dont je modifie les points pour voir le rendu

C'est effectivement à la base prévu pour de la simulation de gaz mais ça prends en compte la collision physique.

Fais au mieux.

bon je laisse tomber les displacement map pour la map et je me sers d'un plane subdivisé dont je déplace les vertix verticalement : c'est plus simple, un peu moins performant niveau vitesse je pense mais ça fonctionne   donc bon super
Test d'une texture de terrain pour changer (sans bump map ou normal map là)



allez zou la suite : des instances d'objets (pleins de fleurs, pleins de brins d'herbe ? suspense...)

Ça me rappelle les joies du blender game engine

Essai d'instances d'objet
2 types de groupes de brins d'herbe : 1 avec 3 brins et 1 avec 2 brins
chaque groupe devient une instance d'objet en contenant 100 000

Je place donc 200 000 groupes de brins d'herbe (soit 1millions de brins) avec échelle, position et rotation aléatoire pour chaque groupe de brin, tout ceci sur un terrain de 100hectares (=1km²), ça commence à ramer et ça remplit pas beaucoup.


Bon c'est pour tester, hein, si je voulait faire les collines d'Ecosse, même avec 10 miilions d'objets ce serait juste...si si j'ai essayé
Mais j'aime bien le détail du rendu. Dommage que lod fonctionne pas sur les instances. Alors qu'est ce qui se passe? Soit je trouve un moyen d'afficher l'herbe de près uniquement, soit je laisse définitivement tomber l'herbe, soit je fais des maps plus petites, soit je divise les maps en sous-map et charge des bouts de map au fur et à mesure des déplacements genre minecraft, soit un autre moyen qui reste à découvrir.  Peut être un jour les ordis seront suffisament rapides pour faire ce genre de choses, calculer chaque brin jusqu'à l'horizon, genre j'attends 20 ans et ça marchera sans que je me fatigue

Peut être un jour les ordis seront suffisament rapides...

Je te rassure ce n'est pas principalement l'ordinateur. Chaque moteurs de jeu à ses limites et en fonction de comment il a été réalisé, tu peux atteindre ses limites assez rapidement sans pour autant que l'ordinateur montre des signes de faiblesses. Connais ses limites et tu saura y faire avec ses faiblesses.

D'après une rapide recherche par images, je vois que d'autres semblent avoir autant de difficultés que toi à cause du trop grand nombre d’objets présents, donc cela signifie que tu as besoin de revoir l'échelle de ton projet.

Essai d'eau
(un mesh  qui a les dimensions de la map positionné niveau 0)

Hmmm... Un peu petite les herbes... Quelle tondeuse as-tu utilisée ?

La mer fait ramer...
C'est le cas de le dire
Bon là il y a une grande surface (en fait 1km² d'eau) superposée à la map, faudra être plus parcimonieux, faire plusieurs meshs pour chaque endroit de la map ou il y a de l'eau

J'ai ajouté une fonction pour me mouiller le rivage et les profondeurs marines (avec en parametres l'image de texture du terrain, la height map, le niveau de l'eau et de la houle) et en sortie ça me renvoie une nouvelle image de texture de map


Pour l'herbe, je vais faire autrement : essayer la méthode communément utilisée..
utiliser des plane avec texture genre
et les afficher en croisant au moins 2 plane pour une touffe d'herbe
Ou un peu plus élaboré car j'ai vu que si on ne peut pas mettre un LOD dans des instances, on peut néanmoins mettre des instances dans un LOD, :

alors  j'ai du apprendre les calculs de 3D des triangles correctement, trouver les normales d'un triangle et les appliquer a ce qui est dessus... c'était un peu galère, ouf, je me suis accroché et ça va aller
j'ai une belle fonction pour trouver la hauteur sur la carte à telle ou telle coordonnée sans passer par le raycast (qui faisait ça tout seul mais qui était trop trop lent)

voila un début de résultat d'herbe en croisant par 3 images en étoiles comme j'en parlais ci-dessus. C'était plus facile à dire qu'à faire, hum...


j'en ai mis sur la map partout,ça fait 100000 * 3 instances de l'image
c'est évidement trop, et placé très aléatoirement (je n'ai pas empeché les chevauchements), toutes les "étoiles" d'herbes a la même échelle pour l'instant je crois,
et ça fait ramer, normal, mais cà ne vient pas que la mer ce coup.
(vu de haut c'est très moche)

Essai avec juste 2 images croisées au lieu de 3, image étirée en largeur, 300.000 instances de l'image. Résultat : ça remplit mieux, ça rame un peu plus, on perd un peu le détail du terrain surtout que l'herbe n'attrappe ni ne génère d'ombres

J'aime bien cette dernière image.
Je pensais que Unreal pouvait aborber plus de triangles que ça sans trop broncher..
Et en fait je vois par tes essais il faut rester sobre..

L'eau est fait comment ? c'est un simple plane avec textures ou c'est un grid avec déformations?

Pas facile les terrains, ça devient vite très gourmand en ressources.
Ici, en tout cas, on ressent bien l'immensité du paysage, bravo.

Merci! Moi aussi j'aime un peu le paysage mais je vaisessayer d'améliorer

@meltingman
Unreal est certainement plus performant que çà, mais là je suis toujours sur Three.js.
Les grosses différences c'est que :
- three c'est du javascript et unreal c'est en C++ ( en c++ la gestion de la mémoire et tout çà est très optimisée)
- three fais de la 3D pour navigateur web (ici je suis sur firefox), Unreal ou Unity sont multi plateformes (y compris navigateurs il me semble)
- mon programme de développement c'est un éditeur de texte amélioré (léger). Unreal il faut plus de 60G pour installer le programme de développement
- sur Three la page finale reste légeré, le plus lourd c'est les images et les .blend exporté en glb. quand tu charges une page web, en fait c'est du texte chargé puis compilé par ton navigateur, le moteur est le navigateur quoi. Unreal le programme final  sera compilé, "hautement" optimisé... etc.
- three a à peine 10 ans, avant on peinait à faire de la 3D dans le navigateur. Et Three a récemment beaucoup évolué en bien. Unreal est pro depuis pas mal de temps (créé en 1998), ue4 son moteur actuel a 9 ans, bref beaucoup d'expérience...

Donc three n'est pas le plus performant des outils, mais c'est assez fun quand même je trouve. Moi même je suis débutant en 3D, ça n'aide pas. Mon ordi n'est pas une fusée (pas de carte graphique spéciale, c'est une AMD radeon) et je suis en 1600x900 (si je réduis un peu la dimension de la fenetre ça tourne beaucoup mieux)


Pour l'eau je suis sur un plane sans subdivision avec texture et normal map. J'ai repris un sous programme existant dont une partie parle directement shader à la carte graphique (pas du javascript) que je ne comprends pas pour l'instant mais ça marche bien : https://threejs.org/examples/webgl_shaders_ocean.html

Je pensais que Unreal pouvait aborber plus de triangles que ça sans trop broncher..

C'est effectivement le cas: Unreal Engine est leader sur le marché du jeu vidéo point de vue rendu, Unity juste derrière. Gros hic est que Unreal nécessite idéalement d'un ordinateur dernier cris pour profiter de tout ce qu'il propose ou en tout cas un ordinateur qui tien la route (toujours regarder la config recommandée car la minimal est sur-évaluée, même pour un jeu vidéo).

Aaah ok @rulio , c'est très claire, merci pour toutes tes explications et effectivement l'intérêt d'apprendre à coder pour du navigateur est tout autre .
Merci @Redstar, ouaip, moi aussi je tourne avec une petite bécane sans carte graphique et c'est limite pour pas mal de choses dont unreal

Alors, bonne continuation dans cette découverte très intéressante rulio

++

Salut
J'ai essayé de bien coller les pieds sur le sol.
Une première technique fut pas terrible : simplement rotation des chevilles selon l'angle du terrain :
Avantage le personnage restait vertical quelque soit le terrain
Inconvénients :
- manque de précision puisque dans une pente le pieds en arrière flotte tandis que celui devant s'enfonce dans le terrain
- si on monte une pente de biais ça fonctionne mal

Là je suis sur une 2e méthode qui me plait mieux mais un peu plus complexe : placer le personnage sur la normal du terrain ou il se trouve
Inconvénient : le personnage ne reste pas vertical quelque soit le terrain
Avantage :
- les pieds sont biens en jonction avec le sol, sauf à certains endroits



Problème :  à certains endroits, le personnage s'enfonce un peu alors que majoritairement partout cela fonctionne très bien. Bizarre. Est-ce en rapport avec  mes calculs et le gimball lock des rotation Euler ???
A voir... Si qqun connait le sujet je suis preneur

Reste à bouger le centre du corps selon la pente pour simuler l'équilibre...

Tu n'aura jamais une précision exceptionnelle et c'est normal...  enfin, tu m'a compris

Ce dont tu as besoin, c'est une technique qui permet de faire adapter les os du pieds et des jambes selon le sol et je crois que ça s’appelle "l'IK solver" (inverse kinematic). Une animation procédurale, comme quand tu animes ton personnage dans Blender.

Et donc, comme dans blender, je suppose que tu as un "capteur" (comme un cube invisible) qui se contente de monter et descendre (voire pivoter selon la normale de la face) en fonction du terrain, l'IK se contente "d'ajuster" l'armature selon les cubes.

Suite à une rapide recherche, il semble être possible de faire ça dans Three.js.

Beaucoup de jeux l'utilisent en effet, mais tu as également les simulateurs, comme MikuMikuDance, et la VR qui se basent sur cette technique.

Toi t'as encore discuté avec chatgpt
Les simulateurs tu penses aux physic engines? c'est bien,  il en existe de sympas utilisant three, genre Rapier (demo), mais l'appli devient tout de suite plus lourde et ça rame plus puisqu'il y plein de calculs en plus à faire.

iksolver je l'utilise dans blender pour les os, ça me permet de déplacer tous les os du bras en déplaçant seulement 1 os au niveau du poignet. Pareil pour les jambes. C'est aussi géré dans three effectivement (ils sont appliqués et pris en compte de la même façon grace à l'export gltf). Par contre blender est meilleur en édition d'anim' donc je ferais tout ça avec blender.

Plus précisément je pensais a une additive animation (=aa) : à la base c'est une animation dans blender de longueur 2 images
la position 1 c'est la position de base de rotation et de position des os. La position 2 c'est les rotations et positions max de l'aa.
Position2 - position1c'est cette différence qui sera ajouté pour chaque os de l'aa au perso, par dessus d'autres anims ou aa.
Exemple d'aa:
animation avec uniquement une rotation de la tête vers la gauche
position 1 : l'os de la tete à 0, position 2 : la tete tournée à 80° vers la gauche
Dans three, je marche ou je fais nimporte quoi et je peux à tout moment tourner la tete à gauche de 0 à 100% (=80°)
Si je veux tourner la tete de 40°, j'ai juste une ligne de code en plus : MesAnim[nom_anim_tourner_teteG].setWeight(.5)

Donc dans three selon la pente, et donc l'angle de rotation du perso sur x, je pousserais plus ou moins le pourcentage de l'additive animation de se pencher en arrière ou en avant tout en montant ou baissant le bassin...
idem pour l'axe y

et l''additive animation bouge par exemple l'os du bassin, les ik solver font suivre les mouvements joliment, ça ça tourne no problemo

Non, là pour le coup c'est de mon cru: en fait, il y a pas mal d'années, j'avais collaboré avec quelqu'un qui bossait sur l'Unreal Engine: sa volonté étant de faire un jeu du même type que "Escape from Tarkov", qui était annoncé récemment à l'époque (soit 2016-2017).

Et durant le développement, le garçon qui s'occupait de la programmation, m'a partagé ce qu'il avait mis en place qui était cet histoire d'IK. Du coup, comme tu exposes un fait similaire, ça m'a fait repensé à cette histoire...

Après, peut-être que c'est sous une autre appellation mais je ne vois pas pourquoi ça serait ainsi.

ah dac
+j'ai édité mon post précédent entre temps