Comme je dois retravailler sur le module graphique, j'ai pensé faire un diagramme des classes de celui-ci.

Je prévois de réunir les modules graphiques 2D, 3D et le Renderer en un seul module, je ne sais plus pourquoi je les avais séparé mais ce n'est définitivement pas une si bonne idée.

Les diagrammes sont bien sur incomplets, il ne s'agit que de ce que compte implanter maintenant.

Bulle normale : Les classes du noyau de l'Ungine
Bulle grasse : Les classes du module (Interface)
Bulle pointillée : Les classes du module (Implémentation, invisibles pour les utilisateurs)

Les flèches normales (noires pleines) signifient "A est utilisé par B"
Les flèches creuses signifient "A est hérité par B"

Donc, le diagramme du module graphique :

(Cliquez ici pour le voir en taille réelle)

Pour Texture, il s'agit d'une classe du noyau mais pouvant aussi être utilisée avec le module Renderer (Transférée sur la carte graphique).
Cela ne se fait qu'en cas de besoin, mais j'hésite à changer ce comportement en divisant ma classe Texture actuelle en une classe Image (Dans le noyau, représentant un tableau de pixel sur lequel on peut effectuer des opérations) et une classe Texture dans le Renderer (Représentant une texture dans la VRAM).

Ce schéma avait été demandé au début du topic d'Utopia, et ça me trottait en tête, je suis heureux de l'avoir enfin fait.

Salut,

Je viens juste dire que j'ai pris la décision de distribuer le noyau de l'Ungine sous la licence LGPL dès qu'il sera suffisamment stable (Et possédera suffisamment de fonctionnalités)

Quant aux modules, je ne sais pas encore si je les distribue avec la même licence ou une licence plus permissive.

J'ai mis à jour la liste des fonctionnalités en prenant en compte la réécriture du module graphique.

J'ai aussi mis à jour l'organigramme, ce que je fais assez souvent d'ailleurs.

Bonne soirée

Cool
Ça c'est bien !

Pour ton benchmarK#2, la console se lance et rien ne s'affiche, ton log :


Je précise que je suis sous Seven 64Bits ( 6GO de Ram, i7 quadcore 3 Ghz et 2x Radeon H5400 1Go, comprends que j'avais envi de détruire le score de ton belge ) J'ai essayé de l’exécuter en *32 mais rien à faire il cherche à le lancer en *64 ce qui explique probablement le bug.

EDIT, bon je l'ai lancé en virtual *32 et ça ne marche toujours pas ( en même temps je me faisais pas beaucoup d'illusions ) j'ai tout de même 20M0 de chargé en Ram

Je m'y pas du toiut en moteur graphique.
est'il possible de l'intégrer dans un programme java ou C++?
Comment ça s'utilise? une interface facile d'acces sur laquel on peut créer nos objets ou il faut "programmer" ?

Citation : shayologo

est'il possible de l'intégrer dans un programme java ou C++?

L'Ungine étant programmé et interfacé en C++, il est fait pour le C++, je ne m'y connais pas en Java mais je doute qu'on puisse utiliser une interface C++.

Après, il y a sans doute moyen de faire un binding Java ou C pour pouvoir utiliser l'Ungine dans ces deux langages.

Citation : shayologo

Comment ça s'utilise? une interface facile d'acces sur laquel on peut créer nos objets ou il faut "programmer" ?

L'Ungine est composé de plusieurs dizaines de classes, qui permettent chacune de gérer une chose en particulier.
Cependant, le moteur est programmé dans l'optique de rendre la vie facile à l'utilisateur tout en donnant un accès au bas-niveau si besoin est, pour ne laisser aucune fonctionnalité de côté.

Par exemple, en une seule ligne de code, on peut charger un modèle dans un format supporté par l'Ungine (Pour l'instant le .obj et le .md2) et sa texture par défaut.

Exemple :

Ungine::Model goblin("models/goblin.md2"); // Prend un deuxième argument booléen, par défaut sur true, pour charger la texture automatiquement

En une ligne de code, on peut aussi obtenir le hash d'une chaîne de caractère ou d'un fichier.

Par exemple :

std::cout << Ungine::Filesystem::Hash("models/goblin.md2", Ungine::Hash::Get("MD5")) << std::endl;

Le Ungine::Hash::Get n'est qu'un raccourci vers une des classes de Hash déjà créée à l'initialisation du noyau.

Cependant, si on veut faire les choses correctement (Ou sans initialiser le noyau de l'Ungine), on ferait comme ça :

Ungine::Hash::MD5 hash;
std::cout << Ungine::Filesystem::Hash("models/goblin.md2", hash) << std::endl;

Petite précision, dans l'Ungine les méthodes Hash renvoient un objet de HashDigest, qui contient le digest sous la forme normale, c'est-à-dire une suite d'octets, mais lorsqu'il est affiché (Ou via la méthode .ToHex()), cette suite d'octets est transformée en caractère hexadécimaux, c'est-à-dire la forme "visuelle".

Il y a beaucoup de choses dans l'Ungine qui peuvent se faire en une seule ligne, charger un module, initialiser le noyau, afficher une scène, ouvrir une fenêtre de rendu, ...

Bref, c'est simple à utiliser et ça cherche à automatiser certaines tâches (Cf texture récupérée automatiquement via un mesh), tout en permettant un accès bas-niveau.

Je pourrais savoir en quoi consiste clairement le Hash ? Car j'en entends souvent parler avec quelques choses comme le MD5 etc ...

Mais c'est toujours expliqué de façon archaïque .

Le hash c'est une fonction qui te fournit un produit de longueur généralement fixe pour n'importe quelles données entrées.

Par exemple, prendre le MD5 d'un fichier donnera une suite de 16 octets (32 caractères hexadécimaux), ce qui est pratique, par exemple dans la seconde démo technique de l'Ungine, j'ai intégré les hashs des ressources dans le programme, et il vérifie que ça correspond avant de lancer un benchmark.

On s'en sert aussi pour enregistrer des mots de passe, par exemple le site du zéro utilise une fonction de hachage sur les mots de passe afin de ne pas les garder en clair dans la base de donnée, si quelqu'un y accède, il ne peut pas accéder aux mots de passes car on ne peut pas récupérer les données d'origine d'un hash.

Tu trouveras plus d'informations sur wikipédia : http://fr.wikipedia.org/wiki/Fonction_de_hachage

Vraiment, je suis impatient, ton moteur à l'air très complet !

Ah merci

Donc en faite sa serait comme un code encastré dans un fichier pour vérifier si c'est bien le fichier qu'on cherche ?

Pas vraiment, en fait le hash c'est quelque chose qu'on calcule, pas un code qui se trouve dans le fichier au départ.

Tu envoies n'importe quelles données (Autant que tu veux) à la fonction MD5, elle te renverra un digest de 16 octets, cependant l'intérêt c'est que le moindre changement dans les données d'entrées change du tout au tout le résultat du MD5, on peut alors facilement vérifier que des fichiers sont égaux via cette méthode.

Citation : Benchmark

Démo technique de l'Ungine #2 : Résultats du benchmark
Carte graphique : Radeon X1950 Pro
Module graphique : Ungine Renderer Module (0.0.434 - OpenGL 2.1.8545 Release)

Test n°1 - Modèles - Score : 122438
Test n°2 - Shaders - Score : 35647
Test n°3 - Textures - Score : 23750
Test n°4 - Masques (Stencil) - Score : 32173

Score global : 214008

Très surprenant, fluide. Bonne continuation!

A j'ai enfin compris !

Merci beaucoup . J'attends le moteur avec impatience

Waow quand je regarde les schémas et tout je remarque le grand sérieux du projet!! Continue!

Tiens, puisqu'il a été remonté, j'en ai profité pour faire le bench...

Citation : Benchmark

Démo technique de l'Ungine #2 : Résultats du benchmark
Carte graphique : ATI Radeon HD 4800 Series
Module graphique : Ungine Renderer Module (0.0.434 - OpenGL 3.3.10243 Compatibility Profile Context)

Test n°1 - Modèles - Score : 220016
Test n°2 - Shaders - Score : 59159
Test n°3 - Textures - Score : 36887
Test n°4 - Masques (Stencil) - Score : 73082

Score global : 389144

Processeur Intel Core2Duo E8400 @3Ghz.
2Go RAM
Windows 7 Pro 64 Bits

0 problèmes rencontrés avec les 2 démos.

Quand il est fini, je prend

Interessant.

Je tenterai dans la matinee !

Citation : damjuve

Pour ton benchmarK#2, la console se lance et rien ne s'affiche, ton log :

14/11/2010 00:13:04 - Ungine Core initialized (0.1.660)
14/11/2010 00:13:04 - Mounting Renderer module from UngineRenderer.dll...

Je précise que je suis sous Seven 64Bits ( 6GO de Ram, i7 quadcore 3 Ghz et 2x Radeon H5400 1Go, comprends que j'avais envi de détruire le score de ton belge ) J'ai essayé de l’exécuter en *32 mais rien à faire il cherche à le lancer en *64 ce qui explique probablement le bug.

EDIT, bon je l'ai lancé en virtual *32 et ça ne marche toujours pas ( en même temps je me faisais pas beaucoup d'illusions ) j'ai tout de même 20M0 de chargé en Ram

Malheureusement je ne peux strictement rien y faire sans être sur un pc ayant ce problème, et vu que très peu de pc ont ce bug, je ne peux vraiment rien faire pour l'instant.

Tu as ce bug avec la première démo aussi?

Oui j'ai testé les deux démo, tu ne sais pas d'où ça peut venir ?
Je peux peut-être essayé de compilé en 64bits si ça t'intéresse contacte moi par mp

a+ damjuve

Le problème c'est que les packages MinGW compilent presque tous en 32 bits.

J'ai trouvé un package permettant la compilation en 64 bits pour windows, depuis un 32 bits, 64 bits ou même linux (cross-compilation).

Encore faut-il le faire marcher (Nécessite cygwin), je vais jetterais un coup d'oeil.

Mais les deux démos marchent sur beaucoup de 64 bits, c'est étrange.

Vraiment cool comme projet, j'essayerais probablement de créer quelque chose quand il sera stable. Moteur graphique + physique + réseau, c'est vraiment parfait, et gratuit (ou pas? ) ça serait une première (du moins à ma connaissance...

Moteur audio, graphique, physique, réseau, libre et gratuit.

Licence LGPL permettant de l'utiliser dans presque tous les projets.

Je ne peux qu'imaginer la tête des gens si je le faisais sous licence GPL (Licence que je déteste)

Bonjour, ce projet a l'air d'être très sérieux en effet, mais qu'est-ce qui me ferait préférer Unigine à Ogre3d (en l'état actuel ou en l'état futur, peu importe) ?

hum le fait que ogre3d n'est qu'un moteur graphique, et qui plus est détestable à installer, alors que ceci regroupe physique,graphique,audio,reseau est je pense une bonne raison.

Premièrement, c'est Ungine, pas UNiGiNE (Les noms sont proches mais quand ils sont bien écrits, facilement reconnaissables l'un de l'autre).

Pour ce qui est de OGRE, je dois avouer avoir créé l'Ungine au départ pour deux raisons :
1) Je détestais l'architecture d'OGRE.
2) Je voulais savoir ce qu'il se passait derrière

Le code de l'Ungine est propre, facilement lisible, bien que j'oublie souvent de mettre des commentaires.
Par choix, je ne documente pas à l'intérieur du code, je trouve que ça réduit énormément la lisibilité, j'écrirais une documentation plus tard.

De fait, on comprend facilement les opérations réalisées par l'Ungine, que j'essaye d'optimiser niveau vitesse, bien que je sois très souvent confronté au choix vitesse/mémoire, éternel dilemme des programmeurs

Après, si on oublie le côté graphique pour l'instant, l'Ungine propose bien plus qu'OGRE ou un autre moteur graphique

N'ayant jamais eu besoin d'utliser un moteur de jeu, je me demande :

Ton moteur on pet l'utiliser avec quels langages de prgogrammations ?

Il est programmé en C++, et s'utilise avec ce même langage.

Je ne prévois pas de faire de wrapper pour d'autres langages pour l'instant, après tout quoi de meilleur que du bon C++ pour un jeu ?

Là c'est ton avis. Le but n'est pas de débattre dessus mais je trouve que c'est quand même dommage.

Oui, c'est mon avis et je suis bien conscient que ce n'est pas vrai pour autant, mais le fait est que le C++ est le langage le plus utilisé pour les jeux (Et est concurrent avec Java pour le langage le plus utilisé au monde).

Après, si on me propose des wrappers, je me ferais un plaisir de les proposer avec l'Ungine

Mais on a le temps de voir la réponse arriver, il faudra d'abord sortir le moteur

Je viens tout juste de terminer d'intégrer le filtrage des textures dans l'Ungine, j'ai fais une petite démo pour tester ça, ce n'est pas une démo technique et c'est assez limité, mais ça vous permet de voir ce sur quoi je travaille

A télécharger ici