Discussion :

[zenux]

Merci c'est très gentil

Oui, j'aimerais bien aussi avoir une scène un peu plus complexe. Le problème, c'est qu'il me faut énormément de temps pour modéliser un simple objet dans Blender et que je n'ai pas encore d'idée sur le type de jeu que je voudrais. Du coup, j'ai tendance à re-switcher rapidement sur le dev. du moteur.

[zenux]

Quelques news:

1) Moteur physique: avant, j'utilisais l'algorithme de 'sweep and prune' pour détecter les objets qui pouvaient potentiellement être en collision.
Je viens de développer un nouveau algorithme pour le moteur: AABB tree. Apparement il est plus performant pour les mondes très dynamique et surtout ça permet de faire du 'ray test' de façon beaucoup plus efficace/optimisé.

2) Moteur physique: j'ai développer le ray test (lancé de rayon avec possibilité de savoir quels objets sont touchés par la rayon). C'est très utile pour:

• Savoir si l'ennemi peut voir le joueur ou si il est caché derrière un objet.
• Savoir si l'ennemi est touché par une balle de fusil ou si celle-ci a heurté un mur, etc.
• ...

Voici un exemple de lancé de rayon (vert) et le 'hit point' (en rouge):


3) Le jeu: je commence à avoir une idée qui émerge dans ma tête pour le type de jeu que je veux faire.
Ca sera un jeu d'infiltration en deux temps. Je m'explique:

• Dans un premier temps, le joueur entre dans le jeu en mode 'fantome' (les ennemis ne le vois pas). Il effectue et enregistre un certain nombre d'actions (émettre un bruit à un endroit X, crochetter une porte, etc...).
• Ensuite, on rentre dans un jeu d'infiltration classique avec une petite différence: le joueur à la possibilité d'exécuter les actions enregistrées précédemment n'importe quand afin de lui faciliter l'infiltration.

[etienne etienne]

Bravo, beau boulot, je suis épaté.

J'ai voulu essayer la version compilée, je suis sur Linux Mint et j'ai un message d'erreur à propos de glibc:
./greencity: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/lib/greencity/libsfml-window.so.2.3)

J'espère que ton projet va continuer, ça m'intéresse beaucoup et je vais suivre l'évolution de ton joujou

[super_navide]

Bravo , je trouve que la gestion des ombres est superbe , je vais essayer d'utiliser la même technique car elle est bien meilleur qu'une simple shadow map.
Les shaders sont très bien écrit aussi.

[zenux]

Merci Etienne (je suis aussi épaté que ton premier message sur ce forum me soit destiné )
Concernant le problème, je pense que la lib. 'libstdc++.so.6' n'est pas assez récente (http://askubuntu.com/questions/57550...fix-this-error). C'est vraiment dur de distribuer une application Linux qui fonctionne chez tout le monde

Merci Super_navide. Les ombres, c'est mon pire cauchemar. Après avoir galéré des jours et des jours, le meilleur résultat que j'obtiens est de combiner ces techniques:
* Parallel split shadow map (scene dependent, limitation de la distance d'affichage des ombres)
* Blur shadow map (Gaussian blur H & V)
* Variance shadow map
* Shadow map cache
Par contre, je suis encore "loin" d'atteindre un résultat d'un jeu AAA (The Witcher, Far Cry 3...). Je me demande vraiment comment ils font.
A mon avis, je peux encore améliorer un peu mes ombres en utilisant le 'mipmap' & 'anisotropic'.

[super_navide]

Ouais les ombres c'est un cauchemar , dans mon moteur j'ai une seul ombre celle du soleil mais le problème est que la porté de l'ombre c'est le monde entier.
J'ai utilisé une shadowmap de résolution 4096*4096 et je l'a met à jour uniquement quand on ouvre des portes par exemple pour laisser passer la lumière.

[yildiz-online]

Merci Etienne (je suis aussi épaté que ton premier message sur ce forum me soit destiné )
Concernant le problème, je pense que la lib. 'libstdc++.so.6' n'est pas assez récente (http://askubuntu.com/questions/57550...fix-this-error). C'est vraiment dur de distribuer une application Linux qui fonctionne chez tout le monde

Tu peux faire un chroot et compiler contre une version plus ancienne de libc.

[super_navide]

Ya que moi que ça choque c'est moche

Le but c'est pas que ce soit moche , c'est un moteur de jeux avec des fonctionnalités très importante comme une superbe gestion des ombres et de la physique.
Donc merci d'éviter ce genre de commentaire et de respecter le travail qui est fait.
Encore bravo.

[super_navide]

Tu n'utilise pas la technique du Sub-Pixel Shadow Mapping ( https://www.researchgate.net/publica...Shadow_Mapping )pour gérer les ombres ??
J'ai trouvé cette technique sur internet elle a l'air encore plus efficace.

[zenux]

J'ai déjà essayé d'implementer differentes techniques (exponential SM, trapezoidal SM...) pour améliorer la qualité des ombres mais ça prend énormément de temps et très souvent, il y a des gros désavantages/artifacts.

Je n'ai pas testé le SPSM mais quand je lis les différents documents/présentations venant des gros moteurs comme UnrealEngine, CryEngine, Frosbite: je me rends compte qu'ils utilisent presque tous les mêmes techniques (PSSM/CSM + Variance SM + PCSS) malgré qu'il y a des dizaines de 'paper' qui proposent des solutions toutes plus miraculeuse les une que les autres.
Bref, ça demande énormément d'énergie pour parfois n'obtenir rien du tout

[super_navide]

J'ai déjà essayé d'implementer differentes techniques (exponential SM, trapezoidal SM...) pour améliorer la qualité des ombres mais ça prend énormément de temps et très souvent, il y a des gros désavantages/artifacts.

Je n'ai pas testé le SPSM mais quand je lis les différents documents/présentations venant des gros moteurs comme UnrealEngine, CryEngine, Frosbite: je me rends compte qu'ils utilisent presque tous les mêmes techniques (PSSM/CSM + Variance SM + PCSS) malgré qu'il y a des dizaines de 'paper' qui proposent des solutions toutes plus miraculeuse les une que les autres.
Bref, ça demande énormément d'énergie pour parfois n'obtenir rien du tout

La technique du SPDM a l'air quand même la plus efficace mais elle a un point faible il faut que quand tu écrire en plus de la profondeur dans la shadow map les 3 sommets du triangle que tu es en train de dessiner.
J'ai regardé sur internet il y a aucune primitive qui permet depuis le fragment shader ou le vertex shader d'accéder aux 3 sommets du triangle.
La seul solution que j'ai trouvé c'est de la fournir quand tu créé ton VBO, mais il y a un gros inconvénient , c'est que tes VBO prennent plus de place en mémoire , tu peux plus utiliser des index pour les triangles tu es obligé de dupliquer les sommets.

Je pense que je fais essayé plus tard cette technique du SPDM .

J'ai regardé le code de tes shaders ils sont très très bien écrit et super lisible contrairement au miens qui sont lisible que par moi même.

[zenux]

Ces derniers mois, j'ai eu beaucoup moins de temps à consacrer au moteur et au jeu.
J'ai quand même pu reprendre voilà quelques semaines et j'ai commencé l'implémentation du Continuous Collision Detection (CCD) dans le moteur physique.
Cela permet d'éviter aux objets de passer à travers les murs quand ils ont une trop grande vélocité.

Voici une mini démo où un cube tombe du ciel à très grande vitesse:
Sans CCD:

Avec CCD:

Il me reste à:
- Gérer la restitution au moment du choc. En effet, actuellement, l'objet s'arrête immédiatement et ce n'est pas très naturel.
- Gérer les objets non convexes (compound shapes)

[Dabou Master]

Je viens de voir le cube 3D le plus lourd de la galaxie, je peux mourir en paix .

Et si tu le laissais tomber tel quel et que tu rajoutais juste de la poussière ?^^

Roh ça va si on peut plus plaisanter ...




PS. N'empêche ç'aurait été le premier cube super héros ...

[zenux]

Content que ça fasse rire C'est juste une vidéo venue d'un univers parallèle avec des lois physiques différentes

Je viens d'injecter des 'predictive contact point' dans mon solveur de contraintes afin d'avoir une réponse à la collision plus réaliste.
Le résultat n'est pas 100% convaincant dans toutes les situations vu que les calculs sont pas mal simplifiés pour des raisons de performance. J'ai aussi un manque de connaissance en math qui me pose aussi pas mal de problèmes.

Voici le résultat final (je dois encore ajuster quelques paramètres mais je doute que j'obtiendrai un meilleur résultat):

[marshiell]

La physique a l'air génial, bravo

[Guntha]

Je ne vois pas le challenge d'implémenter une CCD entre un objet qui bouge et un objet statique (ici le sol) (même moi je sais le faire x) ). Voir un test de la CCD entre 2 objets qui bougent à grande vitesse, là ça serait balèze :p

La réponse physique dans la dernière vidéo est super crédible

[Dabou Master]

J'avoue je trouve le résultat très convaincant, j'attendrai qu'un autre développeur moins contrariant fasse mon premier cube super-héros .






(c'est une blague d'infographiste, pouvez pas comprendre bande de méchants barbus)

[dragonjoker59]

Moi je peux, j'ai un TD avec plein de cubes

[dragonjoker59]

Moi je trouve ça pas mal, comme gestion de physique, de ce qu'on en voit.
D'ailleurs, je me pose une question, il y a pas mal de moteurs physiques open source (je pense particulièrement à ODE), pourquoi ne pas en utiliser un?

[zenux]

Merci à tous pour vos messages

il y a pas mal de moteurs physiques open source (je pense particulièrement à ODE), pourquoi ne pas en utiliser un?

Mon but premier n'est pas de sortir un jeux video. Je fais ce moteur physique par plaisir dans le but d'apprendre.

je ne vois pas le challenge d'implémenter une CCD entre un objet qui bouge et un objet statique (ici le sol) (même moi je sais le faire x) ). Voir un test de la CCD entre 2 objets qui bougent à grande vitesse, là ça serait balèze :p

Personnellement, je ne trouve pas ça si simple. Je ne gère pas que les cubes mais aussi tout type de forme convexe et forme composée. Implémenter l'algorithme de GJK pour du CCD n'a pas été super facile. Je fais aussi très attention aux performances (broadphase, narrowphase, etc...) et à la qualité du code source.
Je n'ai pas encore fait de test pour du "dynamic vs. dynamic". Ca me semble assez difficile de gérer cela correctement à 100%. Pour l'instant, je crée des 'predictive contact points' qui ne seront pas à 100% correcte pour deux objets dynamiques à très grande vitesse. Et en fin de cycle: je m'assure que le solveur de contraite ne va pas faire de bêtises (faire du tunneling entre deux objects dynamiques ou dans un objet qui à la base n'était pas candidat à une collision) en modifiant la velocité. Je ferai le test entre deux objets dynamiques une fois que j'aurais peaufiné le CCD.