CBNA SmartLight - Moteur de lumière

blendman a écrit:

On peut l'utiliser dans un projet commercial ?

Bien entendu. Le moteur, les démos techniques et l'utilitaire qui iront avec seront tous open source et libres d'utilisation.

blendman a écrit:

Est-ce que tu gères les lumières dynamiques avec les normal map ?

Non. J'avais fait quelques tests de normal mapping avec GameMaker, mais c'était atrocement lent: GM est incapable de gérer nativement un rendu pixel par pixel correct (sans DLL donc). En trifouillant un peu il serait quand même possible d'y arriver, mais pour le moment ce n'est que trop demander au GML.

blendman a écrit:

Je suppose que ça fonctionne aussi pour de la 2D iso (je veux dire un moteur 2D, pas de 3D hein )

Ça fonctionne avec tous les types de 2D sous GameMaker.

Max a écrit:

Hum question, prenons un exemple : un feu de camp qui projette de la lumière sur une maison en ruine; une voiture passe entre le feu de camp et la maison, il y aura un effet de lumière adapté ?

Tout à fait. Et ce quelle que soit la forme de la sprite, sa position, son origine, son alpha, sa direction, son scale.. Il suffit de placer la lumière, de définir quels objets doivent projeter une ombre, et tout le reste est géré automatiquement.

gabin49 a écrit:

Est-il possible de faire des lumières directionnelles (des spots dans Blender) car dans la vidéo je n'ai vu que des lumières multi-directionnelles (des cercles), car pour la voiture de Max, des phares qui vont dans le sens de la voiture seraient plus réalistes

Oui, je n'ai pas pensé à le montrer dans la vidéo (quelques spots sont par contre visibles sur les screenshots), c'est tout à faire possible.

Wargamer a écrit:

Possible de mettre un masque pour l'ombre ?

Tu veux dire, utiliser un mask au lieu de la sprite de base d'un objet pour le rendu de l'ombre ?

Chaque fonction permettant de configurer la projection des ombres dispose d'un argument permettant de sélectionner un mask (Voir la documentation).

Max a écrit:

Dans la partie de la vidéo ou tu passes une lumière entre des poteaux, comment as-tu donné cet effet de 3d aux poteaux ?

Sinon, les caisses, arbres, tonneaux de la première scènes sont de bêtes sprites ? On croirais de la 3d, c'est le genre de rendu utopique que je vise pour mon rts :p

Tout est en 2D avec des sprites 2D. Le but du moteur de lumière/ombres est justement de briser l'apparence plate d'une scène en 2D, en usant d'éclairages volumétriques et d'objets qui projettent leurs ombres les uns sur les autres, donnant ainsi l'illusion que certains objets sont plus hauts/gros que d'autres.

shm32 a écrit:

Est-ce que ça prend en charge l'axe Z ?

Plus ou moins. Par exemple, les ombres solaires utilisent un système de layers: les objets assignés au layer 2 projetteront leur ombre sur le layer 1, ceux du layer 1 projetteront leur ombre sur ceux du layer 0, et ainsi de suite (c'est ce qui donne l'impression de volume et de hauteur des objets). De même, il est possible de configurer la longueur des ombres projetées par les lumières dynamiques, en donnant l'impression que certaines lumières sont au plafond alors que d'autres sont au niveau du sol.

Il existe également une variable global.sl_z[obj] permettant de choisir l'altitude d'un objet (Voir la documentation).

Arkanisa a écrit:

Sur la vidéo et sur les screens, tout est vu de haut. Penses-tu qu'on pourra l'utiliser dans les jeux de plateforme vus de côté ?

Le moteur offre 100% de son potentiel uniquement en vue de dessus, effectivement. Par exemple, les ombres solaires seront difficilement utilisables dans un jeu en vue de coté (ou alors il faudra bidouiller). Le moteur de lumière par contre, s'adapte très bien à tout type de perspective.

shm32 a écrit:

Peux-t-on régler la qualité des ombres ?

Oui, la taille des textures/surfaces utilisées peut être configurée, ainsi que le nombre d'itérations nécessaires au rendu.

Wargamer a écrit:

Ça pompe combien de foutre 5000 lumières dynamiques ? (voire si ca pompe moins que des particules je les changes direct )

5000 lumières dynamiques c'est impossible, a moins d'avoir un ordinateur de la NASA.

En ce qui concerne la vitesse de rendu, les lumières et ombres ne sont pas spécialement légères, mais pas spécialement lourdes non plus. Tout dépend de la façon dont elles sont utilisées et la manière dont elles sont configurées. Sur mon pc (2Go de RAM et 1Go de VRAM), la démo présentée sur les screenshots tourne à ~60 fps au pire, et à plus de 90 fps au mieux.
Un processeur de plus de 2 GHz associé à une CG disposant d'environ ~384 Mo de VRAM avec une vitesse d'échange correcte sont normalement suffisants pour faire tourner le moteur.

Note: le moteur a été optimisé depuis.

jo a écrit:

Et la transparence? Par exemple une vitre bleutée a côté d'une lumière ?

Ça serait chouette, mais non ce n'est pas possible. Par contre en ce qui concerne la transparence des sprites, plus l'alpha d'un objet est faible, moins l'ombre qu'il projète est dense.

Max a écrit:

Juste une question : dans la doc, je cite :

Citation :

[...]
sl_tod[a,6] Longueur des ombres du soleil (en pixel)
[...]

or, comment obtenir cette valeur ? Le moteur ne peut la calculer si on entre la taille pour minuit et midi ?

Comme l'a dit robotic c'est une valeur à définir soi-même, il n'y a pas de système pour définir ça automatiquement car j'ai pensé que ce serait contre productif. Il faut modifier les valeurs manuellement pour chaque segment en se repérant avec la courbe d'aperçu de l'éditeur.

Je pourrait faire un script qui calcule ça tout seul, mais à mon avis ça causerait plus de problèmes que ça en résoudrait. Je vais tout de même me pencher sur la question.

PsycKho a écrit:

2go ram, gts250 en cg, ça passe niquel. Juste de temps en temps la démo accélère.

L'effet d'accélération dans la démo est dû au fait que la vitesse de mouvement est calculée en fonction de la variable 'fps', dont la fréquence de rafraîchissement est assez lente. Parfois il arrive donc que la var fps indique une valeur qui ne correspond pas à la vitesse effective du jeu, ce qui accélère la vitesse des objets (oui c'est un peu bête de ma part d'avoir codé ça de la sorte).

Ce 'bug' provient donc uniquement de la façon dont est programmée la démo, et n'est en aucun cas relatif à SmartLight lui-même.

SPLN a écrit:

Y a t-il une fonction permettant de savoir si un objet ce trouve dans l'ombre d'un autre objet? Car avec ce principe avec ton moteur on pourra créer des jeux d'infiltration à la Metal Gear Solid Like avec beaucoup de facilité.

Non, mais pour concevoir ce dont tu parles il suffirait d'user d'une fonction du type collision_line pour détecter si un objet est dans l'ombre d'un autre ou pas.

Citation :

D'où viennent les sprites et backgrounds des démos (plantes, barils, etc) ?

Tous les sprites et backgrounds des démos et exemples ainsi que les textures de lumières fournies avec le moteur sont de ma création; à l'exception du sprite de véhicule blindé, dont la source est spécifiée dans le fichier d'aide de la démo technique.

PsycKho a écrit:

[...] je ne trouvais juste pas une fonction enable / disable pour la light, alors par flemme de chercher, j'ai tenté avec le scale. Mais j'ai trouvé, c'est bien expliqué =)

La variable sl_light_active permet d'activer/désactiver une lumière. Je suppose donc que tu l'as trouvée, je la cite juste à titre indicatif.