Je ne comprends pas trop quelles informations tu fournis au "brain" et à quels moments.
Mince j'ai oublié de vous commenter ce bout de code
Les informations que j'envoie via la fonction CollectObservations correspondent a:
- La vitesse de l'agent
- La distance par rapport a la cible
Et c'est tout, c'est volontairement succint, mais selon moi il n'y a pas besoin de plus d'informations pour que le brain sache quoi faire
De ce que je vois, pas d'erreur fondamentale dans le code! Essaye de jouer avec les hyperparamètres de l'apprentissage pour voir, normalement c'est une tâche facile ça devrait pas poser problème à apprendre! Une possibilité, c'est qu'il est entré dans un minimum local sous-optimal (foncer pour minimiser les pertes) et il n'a même pas l'occasion d'expérimenter ce qui se passe si il avance doucement.
En effet, au début il a un comportement erratique. Il va avancer de façon complètement chaotique, aléatoire au départ. Quand il arrivera dans la zone "danger", la probabilité qu'à chaque frame sa vitesse soit inférieure à 2 jusqu'au bout risque d'être très faible et il risque de ne jamais y arriver. Pour vérifier ce fait, et d'autres informations utiles, je te propose de collecter plus d'infos que celles générées par défaut par unity (reward), telle que le nombre de fois qu'il arrive au bout, la distance moyenne atteinte, le temps moyen etc... Bref, du coup à mon avis, il va donc se rendre compte que ce qu'il a de mieux à faire c'est de foncer et après yolo, il aura déjà "brûlé" dans ses paramètres un fort biais pour que son action soit égale à 1. Tu peux remédier à cela en jouant sur les hyperparamètres qui favorisens l'exploration et réduisent le biais.
Ce que tu peux faire aussi, c'est le guider un peu plus en lui donnant une petite récompense à chaque fois qu'il s'approche de la cible, comme ça il comprend plus vite qu'il doit avancer, et au moment où il devra apprendre à ralentir, les paramètres ne seront pas encore trop "brulés".
Merci pour ton retour
Je viens de tenter de faire ca en modifiant le code suivant:
Par celui-ci:Code:if(DistanceFromTarget() < 20.0f [...] { AddReward(-1f * DistanceFromTarget() / 20.0f); Done(); }
Afin de donner une récompense plutot qu'une punitionCode:if(DistanceFromTarget() < 20.0f [...] { AddReward(1f * DistanceFromTarget()); Done(); }
Tu veux dire en remontant ces informations via des AddVectorObs ?Code:[...]je te propose de collecter plus d'infos que celles générées par défaut par unity (reward), telle que le nombre de fois qu'il arrive au bout, la distance moyenne atteinte, le temps moyen etc...
Pour un néophyte comme moi, faut pas se leurrer, c'est ca qui est le plus intimidantCode:[...]Tu peux remédier à cela en jouant sur les hyperparamètres qui favorisens l'exploration et réduisent le biais[...]
Par contre en observant le board tensorflow, je vois que l'entropy reste a une valeur raisonnable, ce qui, si je ne m'abuse, est sensé faire en sorte que les décisions restent aléatoires, du coup je n'ai pas forcément besoin de modifier mon parametre "Beta" tout de suite
https://imgur.com/a/5NFYjTi
Bon, je vais déja tenter en modifiant la reward recue quand on s'approche de la cible
Ca fonctionne enfin !
Je fais quelque tests et je posterai ce qui a fonctionné tout a l'heure
Si tu fais le changement que tu indiques il va juste s'arrêter à 20 il me semble, car c'est là qu'il peut collecter le plus de reward. Il faut que tu fasses un truc du genre vérifier que la distance from target a diminué et lui récompenser la diminution (normalisée pour qu'au total sur tout son parcours ça fasse 1). Il peut pas aller en arrière non? Mais tu gardes la pénalisation si il va trop vite, sinon il l'apprendra jamais.
Nein, pas du tout, en les enregistrant dans des structures de données C#classique et en printant (ou en écrivant dans un fichier) les statistiques qui t'intéressent! En gros c'est juste monitorer plus finement ce qui se passe.
Ouai les hyperparamètres c'est ce qui demande ce qu'on appelle les "Dark Skills" dans le milieu. L'entropie ça donne un peu une idée mais c'est difficile à évaluer, vaut mieux utiliser tes propres observations.
Hello !
Petite question moteurs de jeu ...
Voilà j'ai envie de me faire un petit plateformer en 2D (à base de sprites 2D, pas en 2,5D) Unity a-t-il maintenant un mode 2D bcp mieux gaulé ? Gère-t-il enfin bien les tilesets ?
Ou dois-je me tourner vers un moteur dédié genre Game Maker Studio 2, Godot ou autre ?
Battletag : AduNaph3L#2694 || Steam : Wensicia || PSN : AduNaph3L
Réponse courte : oui.
https://www.youtube.com/watch?v=bOOqMYFQL9I
Battletag : AduNaph3L#2694 || Steam : Wensicia || PSN : AduNaph3L
Question bête et un peu HS : Qu'utilisez-vous pour créer des Sprites et des animations ?
Pour le moment je veux faire des trucs tout simples et basiques, plus pour m'amuser qu'autre chose.
Tout ce que j'ai pour le moment c'est Illustrator CC que j'utilises pour dessiner quelques sprites 2D et After Effect (que je ne sais pas utiliser).
Il y a Spriter pro qui peut être utile pour les animations. Moi je l'ai eu dans un humble bundle, pour Steam. D'ailleurs dans le humble bundle cité page précédente, certains packs utilisent et fournissent les fichiers pour éditer les animations avec Spriter.
J'ai d'ailleurs une clé en rab provenant d'un autre Humble Bundle si tu veux. Contacte moi en mp si t'es intéressé
ps : il y a eu une version 2 en development, qui sera gratuite pour ceux qui ont déjà la version 1, en tout cas sur Steam
Venez voir mon site, Geek Passion, avec entre autres : Mon super casse brique - The Witcher 3 en 360°.
Venez vider votre backlog grâce aux events du backlog sur cpc-backlog-event.
Oh <3
Ça a l'air super pratique et vraiment bien fichu, je te MP !
Sinon il y a DragonBones en gratuit et open source mais jamais testé.
Venez voir mon site, Geek Passion, avec entre autres : Mon super casse brique - The Witcher 3 en 360°.
Venez vider votre backlog grâce aux events du backlog sur cpc-backlog-event.
Pour info, il y a des cours passés momentanément gratuits sur Udemy.
J'ai trouvé ça sur Dealabs, je vous mets le lien ici : https://www.dealabs.com/bons-plans/s...nglais-1398585
Coin,
Sur l'optimisation graphique, j'ai une question assez simple.
Si je veux créer une map avec plein d'objets texturés (je pense à quelque chose d'assez simple, pensez au rendu des jeux Build Engine par exemple), vaut-il mieux avoir un seul material avec une grande texture atlas, ou une petite texture par objet ?
Si j'ai bien compris l'objectif est de diminuer les draw calls (donc un seul material), mais ça va pas prendre plus de VRAM si chaque objet utilise une grande texture ? Et plus de GPU car il y a plus de pixels dans la texture à afficher ?
De manière générale, avez-vous des liens intéressants pour l'optim graphique (je pense aux draw calls mais aussi à l'occlusion culling, aux LOD, à l'éclairage, aux différents post process et leur impact sur les performances,...).
Merci !
Pour ta question, ça sera a priori plus optimisé d'avoir un seul material ; tu auras un seul draw call, et la texture unique de toute façon ne sera pas beaucoup plus grande que toutes les petites textures additionnées. Après, fais gaffe à l'optimisation prématurée, est-ce que ta scène va vraiment avoir tant d'objet que ça va commencer à ramer ?
Disons que je me cherche un workflow qui me plait et qui soit efficace pour la modélisation, et je voudrais juste pas tomber dans des pièges grossiers.
Mais j'en suis pas encore à compter les draw calls
Un cookbook gratuit sur Unity, ça peut en intéresser certains je crois: https://www.packtpub.com/packt/offers/free-learning
Côté audio, pour sonoriser vos scenes, vous utilisez quoi comme sources qui passent bien dans le système audio de Unity ?
Y’a des références de liens qui existent quelque part ?
Coucou les canards,
J'avais quelques idées de proto et j'essaie de me remettre dans le game et du coup j'ai installé une version récente d'Unity.
C'est moi ou tout est pété ? Avec le nouveau Scriptable Render Pipeline, on a perdu la compatibilité avec plein d'assets. Même des trucs venant d'Unity comme la Post Processing Stack affichent des erreurs même en utilisant l'ancien système de rendu. Quasiment chaque mise à jour pète des assets
Sauf que la nouvelle stack est pas prête du tout, plein de choses sont incompatibles ou semi-compatibles (ex les Terrain et la plupart des shaders). Les outils dédiés au SRP comme le shader graph ou le nouveau post process sont tout buggés et super difficiles à configurer et les performances sont horribles.
C'est moi qui rate quelque chose et qui doit revoir le SRP depuis 0, ou ils sont vraiment dans une période de transition où ni l'ancien ni le nouveau système sont viables et c'est pas le moment de faire du Unity ?
J'ai réinstallé l'UE4 et c'est la première fois que je pense sérieusement à basculer
Vous pensez quoi vous ?
Ça dépend de quelle version tu utilises. Si tu prends la toute dernière, elle sera truffé de bugs jusqu'à la moelle tant qu'elle n'aura pas ses hotfixs.
Perso c'est rare que je change de version, sauf s'il y a une feature qui est intéressante pour mes projets. Sinon je reste sur le LTS ou les versions compatible à mes projets.
Mais ouai, passer à une nouvelle version peut impliquer pas mal de modifs.
Ben j'avais "un peu" l'habitude de ça, mais avec le nouveau pipeline de rendu j'ai vraiment l'impression qu'ils font ça beaucoup plus à l'arrache que de coutume.
Ils livrent des bribes de trucs tout en sachant que c'est inutilisable avec plein d'outils intégrés à Unity... Je trouve que ça fait très amateur comme démarche.
Aucune idée dans ce cas, désolé.
J'avais une histoire similaire quand ils ont sortis l'UNet. L'essentiel était là, mais il y avait pas mal de problèmes.
Du coup, je me fis pas trop aux dernières évolutions d'Unity. En général, il faut attendre une ou deux versions pour qu'ils puissent patcher la fonctionnalité et rajouter les méthodes manquantes pour que ca soit utilisable.
Tout ce qui est pipeline de rendu nouveau modèle est indiqué comme Preview, donc ce n'est pas vraiment étonnant que c'est encore en chantier. Ajoute à cela que la plupart des producteurs d'assets attendent justement des versions plus matures pour produire des nouvelles versions compatibles et tu as effectivement un gros risque à vouloir être un early adopter si tu veux faire de la prod.
Maintenant c'est un peu habituel avec Unity ces temps-ci, avec par exemple l'Entity Component System qui est utilisable mais tout n'est pas compatible. Ça bouillonne sec et de tous les cotés chez Unity, avec beaucoup de changements plus ou moins radicaux dans les tuyaux donc si tu veux être à la pointe cela demande un certain investissement.
Bref je fais comme Louck et hors patchs essentiels de sécurité je préfère des versions (et assets/technologies) plus anciennes et éprouvées.
Oui mais ce que je reproche, c'est que la PostProcessingStack du store par exemple, développée par Unity, et ciblant le legacy rendering pipeline, ne fonctionne plus non plus sur ce rendering pipeline (ok c'est juste quelques lignes de code à modifier, mais ça prouve qu'ils ont un peu arrêté de la maintenir).
En gros ils font des changements qui cassent l'existant, et les outils censés les remplacer ne sont pas prêts.
Ah clairement, ils considèrent le legacy pipeline comme deprecated alors que le remplaçant est toujours en version bêta (je suis généreux).
Ceci dit je travaille en ce moment sur la 2018.3.8f1 et le post processing fonctionne correctement.