Marobax's Lab - Que La Lumière Soit

Discussion dans 'Tutoriels & ressources' créé par Marobax, 8 Septembre 2013.

  1. Marobax

    Marobax Member

    Salut les gars ! Il y a une course à la lumière ces derniers temps (surtout sur le forum anglais). C'est pourquoi je crée ma propre lumière dynamique. Un script en 3 partie (fichus variables globales en scripting visuel) appelé "Let There Be Light*" (*Que La Lumière Soit) ! Sans plus attendre, voici ce dont il est capable. (+ = Bon Point / - = Mauvais Point)

    + Tourne à 40FPS dans le mode 1 source de lumière sur les vieux PC (testé avec 2*2.2Ghz, AtiRadeon2011 = 45FPS)
    + Tourne à FULL FPS dans le mode 1 source de lumière sur les nouveaux PC (testé avec 4*2.9Ghz, GForce2012)
    La preuve: [​IMG]
    ~ Tourne à 20FPS avec le mode 3 source de lumière sur les vieux PC (pire ordi testé et qui ne tourne même pas TACOS: 2*1.3Ghz, Intel(R)4 2009 = 10/15FPS)
    + La lumière est effective dans un rayon de 10 blocs.
    + Déplacer les objet lumineux ne fera pas baisser vos FPS
    + La moittié des objets réagissant à la lumière sont rafraichit tout les 5 tics (6 rafraichissement/secondes pour la map entière) [augmentation de 5 fps]
    + Utilise la méthode des objets sombre a la place d'utiliser la méthode d'augmentation de la luminosité
    + Chargement instantané avec la scène
    - Pas d'ombre (Ça augmente les lags)
    - Besoin d'une organisation précise de la scène (pour l'instant)
    - Pas vraiment optimisé pour les grandes maps (La map ci dessous fait 1157 blocs, vous pouvez mettre deux fois plus de block que dans la première version)

    Voici une image de la version 1, Je ferais une vidéo quand le script sera mieux.

    [​IMG]

    Voici une image de la version 2 avec un autre tileset, Je fais une autre mise à jour pour réduire les calcules et peut être que je rajouterais les ombres.

    [​IMG]

    Si vous voulez en savoir plus, venez dans le projet "M@X's Lab". Le twitter de mon groupe @JustKubes.
  2. Marobax

    Marobax Member

    Version 2 ! Plus de lags sur les ordis nouveau et normaux, et 20 fps pour les vieux pc.
  3. Canardu57

    Canardu57 Administrator Membre du personnel Administrateur

    Woaw ! Felicitation, le résultat est vraiment impressionnant ! Ça fait plaisir de voir que la commu FR peut "rivaliser" avec nos amis anglophones :D
  4. Marobax

    Marobax Member

    Ne vous inquiétez pas, je travail toujours dessus, mais il est probable que la version utilisable par tout le monde soit posté plus tard. En effet, je travail sur d'autres scripts/jeux en ce moment.
    (Je devrais atteindre les 30~60fps dans la prochaine version, cette fourchette dépend de la taille de la map bien sur)
  5. Marobax

    Marobax Member

    Le calcul a été considérablement réduit. En effet, précédemment, chaque model calculait sa distance aux sources, ce qui ne sera plus le cas d'ici peu. Mise à jour du script en cours.
    Erwan0fil aime ça.
  6. Tritonis

    Tritonis Member

    Si tu parvient à vraiment faire un truc genre lanterne ça me plairai pour mon jeu, la nuit !
  7. Marobax

    Marobax Member

    Ouaip mais ça fait depuis longtemps que je bosse plus dessus ^^'
  8. Tritonis

    Tritonis Member

    Bas je peut me contenter d'un truc simple (le truc de l'image me suffit) si on peut alterner jour/nuit.
  9. Tritonis

    Tritonis Member

    D'ailleurs, est ce que les models sont affectés par l'ombre et la lumière ?
  10. Marobax

    Marobax Member

    Non, il est impossible de considérer la forme d'un model.
  11. Marobax

    Marobax Member

    Après un an d'expériences j'en suis à ce niveau :

    Je travail actuellement sur une version 2D de ces lumières car après recherche, les calculs sont beaucoup trop lourds pour la 3D quelque soit la technique employé. A ce jour, j'ai développé plusieurs techniques 3D et j'en ai d'autres en tête, mais la limite n'est pas au niveau du code mais plutôt au niveau du nombres de modèles affichés à l'écran ou en apparaissant dans la scène et qu'il est impossible (ou presque) de diminuer. Petit exemple, j'utilisait un modèle par bloc dans la version que je vous ai montré, et pourtant, même avec des optimisations au niveau du calcul, les fps ne suivaient pas vraiment sur des pc pas tout jeunes, pourtant j'avais le script le plus optimisé parmi les concurrents de la course à la lumière sur le forum anglais.
    Et là je parle d'un système sans ombre (qui nécessite des lancés de rayons et des détections de blocs ce qui coûte immensément plus au processeur qu'un simple calcul de distance), il me faudrait 6 fois plus de modèles (car 1 bloc a 6 faces) pour commencer à émuler des ombres en plus des calculs qui vont avec, de même, il me faudrait un calcul supplémentaire pour chaque map/modèle que je voudrais détecter pour en faire des ombres. Et bien sur, ces calculs sont multipliés par le nombre de faces testés.

    Pour pallier à ça, j'ai découvert plusieurs chemins :
    - Réduire le nombre de modèles (visibles ou non)
    - Réduire l'angle de vue de la caméra ou la taille de la fenêtre [Je me suis refusé cette possibilité]
    - Utiliser une technique de LightUp (modèle blanc au lieu de modèles noirs) [Dégradation des textures (première image postée)]
    - Ne pas poser de modèle sur un bloc entouré ou sur les faces cachés et utiliser un algorithme qui prédit l'utilité de déposer des faces. [Gain négligeable par rapport à la multiplication par des modèles (par face)]
    - Changer l'unité ce qui permet de faire les ombres (modèles ou autre)
    - Utiliser un modèle avec animation ou chaque image clé correspond à un état possible du bloc [perte de performance, pb d'update et il faudrait une
    animation de (nb d'opacités possibles)^6 images clés pour représenter toutes les possibilités sans perte de qualité]
    - Utiliser une map avec des blocs semi-transparents (jusqu'à 256 niveaux d'opacité) [obligé d'avoir une map à scale>1 ce qui entraîne un décalage progressif plus on s'éloigne de l'origine les faces qui pointent vers l'origine s'enfonce progressivement dans les blocs. La fonction SetBlock est très coûteuse]
    - Utiliser un rendu de texte avec des caractères carrés semi transparent pour représenter les ombres [Avantage : On peut utiliser un texte pour représenter une même face sur une infinité de bloc alignés. Le nombres de textes augmente plus lentement que le nombre de bloc. Par contre, les conversions entre valeur de l'ombre et les caractère est difficile, le nombre de niveau d'ombres en est donc très limité. Il faut 2 texte pour face car les textes n'ont pas d'épaisseur]
    - Réduire, optimiser ou simplifier les calculs
    -Espérer qu'Élisée optimise les calculs de rayon [CraftStudio est en fin de vie et le moteur n'est peut être plus optimisable]
    - Réduire la qualité des ombres et lumière en faisant des calculs de groupe de blocs [qualité médiocre des ombres et lumières]
    - Générer des prédictions pour éviter de faire des calculs [Trop de mémoire usés et trop peu de connaissance dans le domaine]
    - Générer mes propres paquet de données au lieu de faire des demandes au moteur de rendu de CraftStudio [Gain intéressant et nécessaire mais initialisation plus longue et mémoire lourde]
    - Éparpiller les calculs et rafraîchissement dans le temps et/ou réduire leur fréquence [Perte de fluidité des ombres mais augmentation des fps du jeu, gène oculaire et apparences non professionnelles des ombres.]
    - Faire un Simili Shader (RayTracer)
    - Utiliser plusieurs textes collés à la vue de la caméra et lancé de rayons pour chaque unité d'ombres [Très peu de modèles mais calculs très peu optimisables par les méthodes précédente et lancé de rayons important. Impossibilité d'utiliser une unité d'ombres par pixels (j'en suis à des unités de 8*8 pixels) dégradation des ombres en conséquences. Bug de lancé de rayon, caméra à la vue fixe et fenêtre à la taille très rigide]

    D'après mon expérience, l'utilisation de textes semble la plus pertinente, voici le nombre de composants nécessaires pour X^3 blocs selon les divers méthodes (sans optimisations) :
    | 1ModelParBloc | 1ModelParFace | 1TextPour1Ligne |
    1^3 Bloc | 1 | 6 | 6 |
    10^3 Blocs | 1 000 | 6 000 | 660 |
    100^3 Blocs | 1 000 000 | 6 000 000 | 60 600 |
    1000^3 Blocs | 1 000 000 000 | 6 000 000 000 | 6 006 000 |

    Voici un schéma de la plage que recouvre les 3 techniques, de l'optimisation absolue aux valeurs maximales (présentés sur le tableau ci-dessus). L'axe des abscisses représente de gauche à droite le nombre de blocs à éclairer (1, 10, 100, 1000000, 100000000)
    . L'axe des ordonnées de haut en bas représente le nombre d'objets et de composant de rendu nécessaire pour éclairer les blocs. La surface verte correspond à la méthode "1 Modèle par bloc", la surface rouge correspond à la méthode "1 Modèle par Face", la surface jaune correspond au chevauchement des deux surfaces, et la ligne Violette correspond à la méthode "1 Texte pour 1 Ligne".
    [​IMG]

    J'étudie encore la possibilité de fusionner ces techniques mais elle généreront nécessairement des calculs supplémentaires ou de la perte de mémoire. Toujours est-il que l'utilisation de rendus de texte semble être assez pertinent malgré leur difficulté d'utilisations. Un bémol cependant, la mise à jour d'une seule face avec cette méthode entraîne nécessairement la mise à jour de toute la ligne (il faut changer le texte affiché par le rendu de texte).

    Si quelqu'un à fait des découvertes, qu'il a trouvé des méthodes d'optimisations ou qu'il a des idées, qu'il en parle ici. ^^
    Dernière édition: 14 Novembre 2014

Partager cette page