Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 29 sur 38 PremièrePremière ... 192122232425262728293031323334353637 ... DernièreDernière
Affichage des résultats 841 à 870 sur 1123
  1. #841
    Citation Envoyé par Sifr Voir le message
    Moi je galère un peu sur la partie son à multi gérer toutes les sources pour que ça forme pas un pic de sonorité ou des parasites.
    J'ai trop d'idées je t'écris ça plus tard dans la journée je suis sur un truc là.

  2. #842
    Pour répondre à la question de la conception actuelle :

    J'ai un audiolistener qui est positionné sur le terrain avec un raycast depuis la caméra pour suivre sa position. Ca me permet de positionner l'écoute en fonction de la position sur la map.
    A la caméra j'ai attaché une audiosource pour émettre la musique qui est donc captée par l'audio listener.
    Pour la musique j'ai un sous mixer du mixer général pour adapter le volume de la musique
    Pour les batiments j'ai aussi une audiosource en boucle pour les bruits d'ambiance locaux genre industrie ou même je pense rajouter pour les forêts par exemple quand les troupes se planquent dedans.

    Chaque objet porte une audiosource qui est rattaché au sous mixer SFX du mixer général (ça permet de manager un peu la multitude de sons mais y'a encore des parasites et des cumules dans les batailles).
    J'ai en détail :
    - une audio source sur chaque unité = bruit de moteur quand en mouvement
    - une audio source sur l'objet arme = bruit du tir
    - une audio source sur l'objet projectile (puisque tout tir est modélisé par une trajectoire) pour le bruit type missile en mouvement par exemple
    - une audio source sur l'objet particle d'impact = bruit d'impact
    - une audio source sur l'objet effet explosion/mort etc...
    Bref chaque action porte une audio source - c'est sans doute bourrin par rapport à ce qu'on pourrait faire avec un peu d'expérience.

    J'ai tenté de créer par exemple un micro décalage de lancement de son quand on sélectionne plusieurs chars ou hélicos pour éviter le cumule de son mais ça marche que moyennement.
    J'avais l'idée de faire qu'une lecture de son en fonction du type d'unités sélectionnées mais ça me semblait compliqué de faire un manager à côté.

    J'ai lu aussi que le PlayClipAtPoint n'était pas forcément pertinent pour une multitude de sources en terme de perfos - c'est pour ça que je suis en mode une action = un objet = une audiosource

    EDIT : ce que j'ai oublié aussi de rajouter c'est que chaque projectile ayant une modélisation ça veut dire qu'un soldat équipé d'une arme auto peut vider son chargeur et que chaque balle émet du coup un son donc s'il tire en burst bah j'empile rapidement une dizaine d'audiosources à quelques milli secondes d'intervalles.
    Je pourrais créer un son unique type gatling en boucle pour le burst mais ça change la logique où un son = un proj = il me faudrait un truc pour jouer le son et à côté compter le nombre de balles avant de rejouer.
    C'est le pire des cas.

    Après un MLRS c'est moins problématique parce que les rockets sont lancées à 0.2 sec d'intervalle donc y'a pas cet effet de cumule.
    Dernière modification par Sifr ; 23/02/2022 à 12h59.

  3. #843
    J'ai lu ce que tu as fait, et c'est ce que j'appellerais l'approche naïve et sans doute celle vers laquelle je serais allé initialement.

    Tout ce que je vais dire est à prendre avec avec des pincettes parce que je ne suis aucunement un expert dans la partie audio d'Unity et encore moins un sound designer.

    Je pense que dans ton cas il y a deux objectifs: Diminuer le nombre d'audiosources, et diminuer le nombre de sons joués en simultané.

    Le fait d'avoir un audiolistener situé au niveau du terrain et qui se déplace avec ta caméra, je pense que c'est très bien.

    Ensuite, je conseillerais d'avoir une seul audiosource par unité. Dans un STR, tu n'as pas besoin de ce niveau de précision sonore, et tu n'es pas obligé pour une même unité de jouer un son de déplacement et de tir simultanément par exemple. Tu n'as pas besoin que le son de ton missile suive ton missile, le joueur s'en tape amha. Un projectile aura un bruit à sa source (unité qui tire), et un bruit à sa destination (unité qui reçoit les dégâts). Tes audiosources pourraient avoir un falloff très rapide pour éviter que les sons en dehors du centre de l'action ne viennent perturber l'action.


    Mais en fait, dans ton cas, je pense que je ferais quelque chose d'encore plus drastique qui me permettrait de gérer aussi bien la quantité d'AudioSource (qui ne dépendrait plus du nombre d'unités) ainsi que centraliser la gestion des sons que tu souhaites jouer en fonction de tout ce qui est déjà en train d'être joué. J'explique.
    Tu pourrais avoir, autour de ton audiolistener, quelques audiosources disséminés sur ton terrain (principalement pour gérer la spacialisation), qui se déplacent également avec ta caméra. Quand n'importe quel élément de ton monde (unité, projectile, batiment,...) veut jouer un son, il va juste appeler SFXManager.Instance.PlaySound(AudioClip clip, Vector3 position). Cette méthode va déterminer l'audiosource le plus proche sur lequel jouer le son, ainsi que la nécessité de jouer ce son (Hors screen? Nope. Même son de tir déjà joué il y a 10 ms? Nope. Trop de sons joués actuellement? Nope. etc...)


    Pour gérer les autres sont que ceux émis par ce qui est sous tes yeux, tu peux aussi avoir un AudioSource 2d avec une haute priorité qui jouera les sons "destinés au commandant" (unité terminée, batiment important attaqué) ou gérer ça via des AudioMixer en les splittant par exemple: SFX ingame bataille/SFX ingame notifications/SFX UI/Musique.

  4. #844
    Je suis pas tout à fait d’accord avec l’approche de la réduction de sources sonores.

    C’est ce qui donne l’ambiance et le feedback de l’action, y compris off screen car ça permet de savoir si y’a un truc qui barde pas loin.

    Ca m’a toujours gonflé de voir les obus ou rockets des artilleries tirer mais n’avoir que le bruit d’impact sur certains STR parce que l’unité est off screen.

    Mais j’ai réduit la voilure quand même, j’ai fait un pool audio avec un objet source et je le pose à la bonne position et ainsi de suite avec une limite de sources.
    Ca m’a réglé un vieux truc qui me faisait couper un son avant qu’il soit fini quand je désactivais un projectile.
    Du coup je peux enfin profiter des sons à réverbérations comme les snipers
    Et pour les moteurs je teste si le son est déjà lancé et j’en lance qu’un ou deux tout au plus.

  5. #845
    Ca y est : j ai bouclé un système audio potable.
    Approved by un test de 100 unités avec des smg et des MLRS en face
    Plus aucune saturation.

    Je suis parti sur un pool d’audioobjects, un dictionnaire pour compter les occurrences actives et mettre une limite par type puis globale et j’ai tuné la distance de son.

    Ca rend bien et effectivement passé un seuil de 5 sons identiques ça se perçoit plus visuellement donc ca va côté charge.

    Et puis j’ai affiné pour trois fois rien avec les cams overlay mon fog of war

  6. #846
    Vous pensez que c'est compliqué de porter son jeu pour la steamdeck ?
    J'ai pas réfléchi outre mesure si unity marche sur Linux

  7. #847
    J'ai jamais essayé mais tu as en natif l'option de compiler pour Linux (ou Mac ou Windows). Donc non, cela ne devrait pas être compliqué et relativement transparent si tu as installé l’éditeur avec les bonnes options par contre cela ne sera peut être pas non plus totalement sans effort.
    Faut essayer et tester.
    C'est pour cela que je ne fais jamais de build Mac pour mes jeux, comme je n'en ai pas je ne peux pas tester. D’expérience sur un vieux projet (au temps où un de mes collaborateurs en avait un), si avec le même projet changer de plateforme a la compilation est facile, obtenir le même résultat par tout est bien plus complexe.

  8. #848
    Bon, après une énième rage sur les fps qui s’effondraient au delà d’un certain stade de combat, genre 50 unités contre 50 sur des escarmouches locales x par le nombre de points d’affrontements ce qui était quand même pas bien gros à mon sens et surtout pas fun si je devais mettre une limite à la population, j’ai finalement viré tous mes colliders pour tout gerer à la distance via sqrmagnitude.

    J’ai gardé les colliders que pour les hitbox et les objects d’impact d’arme.

    Et c’est le miracle : même chargé à 4000 unités sur le terrain je descends pas en dessous de 30fps dans Unity et cela même en end game avec de la mitraille de partout.

    Y’a que les brochettes de forces spéciales qui tirent comme des tarés qui m’impactent un peu mon framerate de confort.
    Mais ça je peux le traiter en réduisant la frequence de balles reelles et modifier l’effet pour simuler plusieurs tirs factices.

    Par contre ça a cassé mon module d’infiltration en forêt, on peut pas gagner à tous les coups, va falloir encore un peu bosser

    D’ailleurs j’avais introduit un système vision + radar soit deux range de possibilite de détection.
    En bidouillant j’ai étendu cela à une liste en fonction du type d’unité via un dictionnaire.
    Et je suis tombé à peu près sur un système qui simule les optiques type Wargame/Warno.
    C’est rigolo. J’ai pas poussé l’implémentation vu que je cherche à retrouver l’accessibilité du STR bien propre mais ça m’en laisse sous le coude si ça le reste marche bien.

  9. #849
    Tu as profilé pour être sur que le problème vient bien de la physique? ça me surprend parce que 50 contre 50 c'est pas non plus énormissime.

  10. #850
    Oui c’était bien les colliders dans le profiler,
    Pour preuve vérifiée, c’est que tant que les unités n’étaient pas dans leur zone respective de vue/action, j’avais aucune perte de fps et dès que le contact était établi, ça ramait un max.
    J’avais déjà levé une partie de l’anomalie en changeant les colliders et leurs layers pour faire un test.
    Après y’a sans doute des subtilités d’experts que je choppe pas, mais dans ma logique, j’ai atteint le seuil pour plus m’embêter à penser perfos avec tout ce que j’ai rajouté.

    Je me concentre sur la visu et l’équilibrage, un peu de création de sympa de map et ça tournera assez pour que je m’amuse sans être obligé de renier un critère qualité qui serait pas passé sur un jeu officiel

  11. #851
    J'ai une question bien basique et je me demande encore comment c'est possible que j'ai pas rencontré ce problème avant

    En fait, au début je mettais des petits bâtiments pour simuler des villes/villages mais c'est pas très chouette parce que j'avais pas de dalles et trottoirs + route.
    La route c'était en fait la texture de terrain direct en dessous.

    Donc j'ai rajouté un plan à la base de mes bâtiments avec un bord noir et des pointillés pour la route de sorte que ça fasse des tuiles et donc des routes à la connexion.
    Avec un algo je génère des randoms de mes modèles de base et ça me fait vite fait bien fait des villes/villages pas si déconnants.

    Mais le truc idiot, c'est que ma route (= mon socle de batiment) à Y=0 se mélange avec mon terrain lui aussi à Y=0 dans les zones planes.

    J'ai pas ce problème avec mes bâtiments de base car ils cachent le terrain donc ça pose pas de problème vu qu'ils sont plus hauts et n'ont pas de socle.

    J'ai cherché sur le net et je trouve pas trop de choses explicites.
    Souvent la map des villes est générée sans terrain ou le paysage fait partie du mesh global donc pas de superposition. Voir le socle a lui même une épaisseur du coup pas de risque de "mélange" qui clignote.

    C'est quoi la bonne manière d'aborder ça ?

  12. #852
    Citation Envoyé par Sifr Voir le message
    J'ai une question bien basique et je me demande encore comment c'est possible que j'ai pas rencontré ce problème avant

    En fait, au début je mettais des petits bâtiments pour simuler des villes mais c'est pas très chouette parce que j'avais pas de dalles et trottoirs + route.
    La route c'était en fait la texture de terrain direct en dessous.

    Donc j'ai rajouté un plan à la base de mes bâtiments avec un bord noir et des pointillés pour la route de sorte que ça fasse des tuiles et donc des routes à la connexion.
    Avec un algo je génère des randoms de mes modèles de base et ça me fait vite fait bien fait des villes/villages pas si déconnants.

    Mais le truc idiot, c'est que ma route (= mon socle de batiment) à Y=0 se mélange avec mon terrain lui aussi à Y=0 dans les zones planes.

    J'ai pas ce problème avec mes bâtiments de base car ils cachent le terrain donc ça pose pas de problème vu qu'ils sont plus hauts et n'ont pas de socle.

    J'ai cherché sur le net et je trouve pas trop de choses explicites.
    Souvent la map des villes est générée sans terrain ou le paysage fait partie du mesh global donc pas de superposition. Voir le socle a lui même une épaisseur du coup pas de risque de "mélange" qui clignote.

    C'est quoi la bonne manière d'aborder ça ?
    Ça s'appelle le z-fighting et la bonne manière de l'aborder c'est de faire des volumes "réels", par exemple des socles avec des épaisseurs sur tes bâtiments.
    Fais en sorte que ta route ait une petite épaisseur, ou fais un prefab pour que ton plan ait un léger offset par rapport au y=0.

  13. #853
    Oui, le Z-fighting c'est super courant.
    Il suffit d'éradiquer la cause, c'est à dire les objets placés à la même hauteur. De manière générale, il vaut toujours mieux donner une épaisseur aux choses (les routes) mais si ce n'est pas possible tu peux introduire de très légères variations aléatoires de hauteur à l’instanciation de l'objet, invisibles à l’œil nu mais qui feront disparaître le Z-fighting. Satisfactory procède ainsi.
    Perso tous mes objets ont une hauteur, mais ce n'est pas une obligation canonique.

  14. #854
    Je suis parti donc sur le micro changement de hauteur.
    Ca résout le problème effectivement mais je pensais qu’il existait un truc plus technique.

    Bon maintenant je cherche des idées pour « modéliser » la disponibilité des unités et sortir du carcan classique du STR.
    J’aimerai bien y ajouter un plus pour le fun.
    Pour le moment je me vois mal produire des unités et n’en donner le contrôle au joueur qu’à X% d’un taux d’opérationnabilité.
    Je voulais baser ça sur la logistique d’appro.

    Mais si je mets juste un batiment d’appro x X points c’est juste de la limitation de pop.
    Si je tente la conséquence, ça pourrait être une réduction de puissance de feu sur le matériel mecanique mais c’est un peu léger.

    Je pensais aussi sinon fournir un batiment qui produit tout seul des unités détruites par le passé à un rythme Y en fonction d’un taux de rentré de pognon - mais ça perd de sa symbolique initiale.

    A l’occaz’ pour la gloire si quelqu’un a une idée magique à tester…

  15. #855
    Je comprends de plus en plus les gens qui gueulent contre le niveau de finition de Unity…

    Je suis passé à la dernière LTS… je build et ça prend des plombes par rapport à avant.
    Genre 10x le temps de build.

    Je regarde, il crée plein de variants de shaders.
    OK sur le forum y’a un thread qui dit qu’ils ont crée pleins de features géniales et donc que ça pourrit le temps de build.
    Heureusement ils proposent des options pour l’inutile.

    Mais non, elles sont déjà cochées et sont finalement inopérantes vue les réponses au thread.

    C’est des champions - ça m’a coulé l’envie de continuer pour un bon moment…

  16. #856
    Passer de 2019 à 2021 cela fait effectivement très très mal.
    Heureusement on a passé totalement 2020 pour conserver notre santé mentale.

    Par contre Plastic >>>> collab, ce qui n'était pas non plus très difficile. Au passage il vaut mieux utiliser le plugin de Plastic dans Unity le moins possible et passer par le client externe.

  17. #857
    Je suis en train d'essayer d'utiliser Unreal Engine (Je ne conseille pas du tout de faire le switch si tu comptes un jour finir ton jeu ! ).
    C'est... Agréable pour plein de petites features. C'est relou pour tout le reste, surtout parce que j'ai l'impression qu'Unreal demande d'être beaucoup plus carré. Et il faut réapprendre la logique du moteur. Et apprendre soit C++ soit leur blueprint.

    Mais en même temps... C'est agréable en termes de leveldesign. Je trouve tout beaucoup plus simple en fait d'utilisation. Et bien entendu, mettre à jour le moteur ne casse pas complètement ton projet. Et c'est facile parce qu'il y a plein de truc tout fait pour les FPS.

    Je voulais essayer pour faire joujou avec le RTX et leur machin qui permet de ne plus réfléchir au nombre de vertices de tes assets (). Je me tâte à rester du coup.

  18. #858
    Aucun risque pour moi de changer vu que :
    - j'ai investi le PIB du Zimbabwe dans des assets du store
    - je hais profondément et infiniment le C++
    - on ne fera jamais de FPS
    - on a tendance au contraire à faire des trucs de niche


    Par contre j'ai un énorme doute sur "mettre à jour le moteur ne casse pas complètement ton projet". C'est simplement qu'il y a bien moins de versions majeures chez Epic, ce qui n'est pas un mal. Par contre va passer ton gros projet d'UE3 à UE5 et on va voir si rien ne casse. On peut demander à Psyonix, cela fait des années qu'ils bossent dessus. A l’intérieur même d'une version l’évolution est facile mais c'est kif-kif pour Unity.

    En ce qui concerne le RTX c'est dispo pour Unity aussi (HDRP sur 2022 je crois), mais je suis toujours sceptique d’implémenter un truc dont bénéficiera un petit (voire infime pour moi) pourcentage des utilisateurs. Pour nanite et le fait de ne plus avoir besoin de LOS, je ne sais pas, je demande à voir dans le temps des retours d’expérience. Ce qui est plus bluffant pour moi c'est l'illumination globale de lumen, mais là aussi je demande à voir dans le temps.

  19. #859
    J'ai deux questions sur UE:
    - Il faut toujours quitter et relancer l'éditeur quand tu modifies ton C++ ?
    - L'éditeur fait toujours souffler ta machine dès le moment où tu le lances ?

    @Sifr: C'est clair que les temps de build sont de plus en plus longs... Et puis c'est buggé, parce qu'en général si tu relances l'éditeur ça devient plus rapide pendant un moment.
    J'ai mis ça en place sur mon projet qui a quand même pas mal réduit les temps de build.

  20. #860
    Au passage si Unity vous pop souvent pendant que vous l'utilisez (juste après avoir sauvé un truc habituellement) un message à propos de la mise à jour des assemblies, un simple ALT+TAB sur VS et un CTRL+S (même s'il n'y a rien de neuf à sauver) règle le problème.

  21. #861
    Un autre truc que je comprends pas dans les builds : avant j’avais l’impression qu’il faisait du différentiel mais là je prends le temps de faire le build qui dure des plombs et à la seconde fois juste derrière il me met exactement les mêmes actions et donc ces variants de shader…

    Je suivais les versions à chaque publi mais je crois que je vais tenter une dernière fois de migrer vers la dernière 2022 quitte à tout péter si c’est pas compatible.

  22. #862
    Y'a des trucs un peu dangereux à monter de version aussi... Genre tu updates de 2021.1 à 2021.3 et ton package Android passe de 60 à 70 Mo.. Ou bien tu perds 5 fps au passage.. Ou ça change la version min supportée d'Android...
    Faut vraiment le faire pendant la préprod uniquement je pense, et ensuite le considérer seulement si une feature est un must-have pour ton projet.

  23. #863
    La dernière vraie version confort pour moi était la 2019 LTS.
    Maintenant si tu as vraiment besoin des nouvelles fonctionnalités (genre le RTX pour le HDRP), alors effectivement tu peux monter sur la 2022. Mais franchement je ne le conseillerais pas vu qu'elle vient tout juste de sortir de bêta est ne sera pas LTS avant un bail.
    Ceci dit, passer la semaine dernière de 2021.3.1 à 2021.3.2 m'avait provoqué des erreurs quantiques (Unity qui se plaint d'une bibliothèque présente et dans Assets et dans Packages alors qu'avant 0 souci), donc même en LTS on est plus à l'abri de l'exotique.

  24. #864
    C’est con quand même leur truc :
    - tu builds après pas mal de temps ça prend des plombes dont les shaders variants ;
    - avant de builder tu éteins le pc et tu redémarres une session toute propre et là le temps de build est classiquement supportable

    Bon la bonne blague sinon histoire de se foutre de la gueule du noob en Unity : pourquoi d’un coup mon jeu a plus le même tête en build qu’en lancement sous l’éditeur… ? Prise de tête garantie jusqu’à je me rende compte que oui dans les jeux les graphics settings ça se gère et non je l’ai jamais mis en place du coup sous Unity en mode ultra et en build, je sais pas pourquoi par défaut dorénavant en low…
    Simple à résoudre mais bête comme chou.

    C’est bien la peine de passer un tiers du temps de dév sur l’IA et pas être fichu de penser aux graphics settings.

  25. #865
    Citation Envoyé par Sifr Voir le message
    - avant de builder tu éteins le pc et tu redémarres une session toute propre et là le temps de build est classiquement supportable
    Il faudra que j'essaye pour voir.

  26. #866
    Est ce que vous avez un petit soft gratuit à me conseiller pour configurer une installation sous windows avec possibilité propre de désinstallation pour déployer un jeu Unity ?

    Par le passé j’avais un soft qui était sympa quand je déployais des mods mais impossible de remettre la main dessus… en même temps ça fait au moins quinze ans que j’ai pas retenté le truc

  27. #867
    C'est pas wix et inno setup les plus populaires ? ça marche avec tout, peu importe que ce soit du Unity ou pas.

  28. #868
    Je vais regarder merci

    Ce jour fut l’objet d’une décision sauvage : tout tournait bien, bien net, propre et précis - donc logique j’ai tout cassé pour refaire le système de gestion de ressources…. Oh joie de galères en galères… et les collecteurs s’acharnent dorénavant sur des points de ressources vides

  29. #869
    Je pense fortement pousser un build dans la nature pour avoir un feedback réel pour le fun par contre me reviennent les questions en suspend associées à cette étape :
    - vous prenez en compte le risque de décompilation ? Il semble que sur Unity ça soit assez accessible.On doit s’en inquiéter ?
    - les debug.log vous les neutralisez ou y’a une option spéciale pour éviter de générique du baratin chez le user ?
    - vous gérez comment les crédits via l’asset store ? J’ai fait un panel avec le nom du package et l’auteur pour les musiques et les sons + une ou deux textures. Ca suffit ?

  30. #870
    1) tous mes jeux sont en CC BY-NC-SA (ou une variante) donc je m'en tape assez largement. Il suffit de demander poliment et les gens auront le code source, s'ils veulent à la place se décarcasser à le décompiler, chacun son truc.
    2) j'évite que mes jeux plantent
    3) à toi de voir, mais comme j'ai payé avec mon pognon les assets que j'utilise, je ne me sens obligé de rien. Par contre si tu utilises des assets gratuits ou open sous quelques licence que ce soit, les mettre dans les credits me parait la moindre des choses. La démarche souhaitée est toujours indiquée dans la license de toutes manières.

Page 29 sur 38 PremièrePremière ... 192122232425262728293031323334353637 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •