De mon côté, je ne laisse pas tomber OpenGL 2.x, l'Ungine aura deux Renderer OpenGL, l'un 2.x et l'autre >3.
Le problème c'est pour les shaders, est-ce que je dois imposer Cg? :/
Parce que ça va être difficile de jouer avec plusieurs langages, surtout si c'est l'Ungine qui doit fournir des codes de base (Pour le rendu basique)
De mon côté, je ne laisse pas tomber OpenGL 2.x, l'Ungine aura deux Renderer OpenGL, l'un 2.x et l'autre >3.
C'est une solution. Je salue le faite d'avoir pris la voie la plus dure ! Bon courage
Citation
Le problème c'est pour les shaders, est-ce que je dois imposer Cg? :/
Je ne pense pas qu'il est de probleme a imposer un langage (comme CG) pour les shaders. En effet, quelqu'un qui sait ecrire un shader en GLSL pourra facilement l'ecrire en CG et vis vers ca !
Donc je pense que la bonne strategie est tu implemente que pour CG puis si tu as le temps, tu autorise GLSL (avec un code d'exemple basique par exemple).
Cependant, je pensais que CG etait plutot utiliser pour avoir des shaders en OpenGL ou DirectX mais pas pour supporter differentes verison de GLSL...
J'ai passé ces deux dernières semaines à me renseigner sur les shaders avec OpenGL, et j'ai commencé à les implanter dans le moteur hier.
Le renderer OpenGL 2.1 de l'Ungine n'utilisera aucune fonction dépréciée (Pour preuve, j'utilise le header d'OpenGL 3).
Cependant, il ne supportera le GLSL que jusqu'à la version 1.30 (Pour la simple raison qu'après cette version, il devient obligatoire de préciser manuellement la sortie du fragment shader, chose uniquement possible avec l'api OpenGL 3/4).
Il fournira également une interface Cg.
Le Renderer OpenGL 3 ne sera pas très différent, mais il fonctionnera avec un core profile, donc pas de fonctions dépréciées.
Support de GLSL à partir de la version 1.30
Pas de support de Cg (Pas tant que Cg ne supportera pas OpenGL3).
Quant au moteur lui-même :
Support des fragment/vertex shaders (Geometry shaders à venir), avec les langages : Cg/GLSL/HLSL.
Ce support est évidemment limité par le Renderer, qui peut ne pas supporter les geometry shaders ou un/plusieurs langages de shaders.
Par exemple le Renderer OpenGL ne supporte évidemment pas le langage HLSL.
Cependant, l'Ungine étant basé sur les shaders, le Renderer doit supporter obligatoirement les fragments/vertex shaders ainsi qu'un langage.
Les shaders sont gérés via la classe Shader. On indique le type du shader dans le constructeur.
Cette classe permet ensuite de charger le shader via un nom de fichier ou une chaine de caractère.
C'est à ce moment qu'il faut préciser le langage utilisé.
Quant à la compilation, elle se fait via la méthode Compile, qui renvoie un booléen
En cas d'erreur, le log de la compilation peut être récupéré via la méthode GetInfoLog
On peut ensuite utiliser le shader.
Pour activer un shader, rien de plus simple, il suffit de l'envoyer à la méthode Set(Fragment/Vertex)Shader
L'Ungine ne fonctionnant plus avec le pipeline fixe, l'absence de fragment/vertex shader est comblée par un shader de base.
Il n'est donc pas obligatoire d'utiliser les shaders
Voici un petit code d'exemple :
Ungine::Shader vShader(Ungine::ShaderType_Vertex);
if (!vShader.LoadFromFile("vertexShader.txt", Ungine::ShaderLanguage_GLSL))
{
std::cout << "Unable to load vertex shader" << std::endl;
return 0;
}
if (!vShader.Compile())
{
std::cout << "Unable to compile vertex shader" << std::endl;
std::cout << "Log: " << vShader.GetInfoLog() << std::endl;
return 0;
}
// Boucle de rendu
while (...)
{
UngineRenderer->SetVertexShader(&vShader);
// Rendu avec vertex shader personnalisé
UngineRenderer->SetVertexShader(NULL);
// Rendu avec shaders de base (Équivalent du pipeline fixe)
}
Les paramètres sont envoyés via une méthode du Renderer (Qui envoie le paramètre aux shaders actuel).
Les matrices se gèrent comme avant, et sont envoyées automatiquement aux shaders.
Petite précision pour les programmeurs OpenGL : En effet, la notion de program n'existe pas, ou plutôt est transparente.
Le Renderer OpenGL créé un program pour chaque paire de shaders utilisée lors d'un rendu, c'est donc effectivement une opération qui peut échouer si le linkage du program échoue.
Si cela arrive, l'erreur est loggée évidemment, et j'hésite ensuite sur le comportement à adopter, le rendu doit-il être effectué avec les shaders de base ou bien doit-il être abandonné?
Si cela arrive, l'erreur est loggée évidemment, et j'hésite ensuite sur le comportement à adopter, le rendu doit-il être effectué avec les shaders de base ou bien doit-il être abandonné?
Moi j'ai adopter le comportement suivant :
- Erreur de Link ou de compilation (création shader) : Erreur et lever d'exception qui arrête le moteur.
- Erreur de GetUniformLocation (ou autre) quand on utilise le shaders : Erreur qui doit être visible au programmeur mais pas de lever d'exception. Pour la simple raison que quand on développe des shaders des fois on retire du code qui code qui peut provoquer ce genre d'erreur.
Sinon pour la première type d'erreur, tu pourrais désactiver le rendu mais le problème est que le programmeur ne saura pas si l'erreur est du a l'algorithme de son shader ou bien a un problème de compilation.
Les shaders ont été implantés à la base du moteur avec succès, il reste encore deux-trois trucs à terminer dans l'implémentation, mais à part ça, tout fonctionne bien
Tout rendu passe dorénavant par des shaders,
Toutefois, pour que le moteur soit utilisable simplement, des shaders de base sont fournis, ils remplacent le pipeline fixe.
Voici la scène de départ :
Ensuite, je me suis un peu amusé avec un vertex shader, ce qui a donné des résultats surprenants :
(Je précise que je n'ai pas bougé la caméra entre ces deux screenshots)
Et dans un domaine un peu plus utile, j'ai ensuite testé le per-pixel-lighting, ce qui a donné ceci :
Il faut avouer que c'est quand même plus agréable comme ça non?
Pour ce qui est de l'API, elle est simple :
Ungine::Shader fShader(Ungine::ShaderType_Fragment);
if (!fShader.LoadFromFile("fragmentShader.glsl", Ungine::ShaderLanguage_GLSL))
{
std::cout << "Unable to load fragment shader" << std::endl;
std::getchar();
return 0;
}
if (!fShader.Compile())
{
std::cout << "Unable to compile fragment shader" << std::endl;
std::cout << "Log: " << fShader.GetInfoLog() << std::endl;
std::getchar();
return 0;
}
À partir du moment où un shader est compilé, on peut l'envoyer au Renderer :
UngineRenderer->SetFragmentShader(&fShader);
Il suffit d'envoyer NULL pour activer le shader de base.
Quant aux paramètres, il s'envoient à n'importe quel moment via la méthode SetParameter :
La valeur est retenue pour chaque paramètre jusqu'à ce que le shader soit réinitialisé ou détruit.
Il est également possible d'utiliser des shaders de langages différents dans un même rendu.
Par exemple, des shaders GLSL pour l'éclairage, et puis des shaders Cg pour les ombres.
(Il est toutefois impossible de mélanger un fragment shader Cg avec un vertex shader GLSL).
Ce n'est pas conseillé pour des questions de performances, mais je ne sais pas encore quel impact ça a sur le framerate.
Enfin, une chose à la fois
Une fois que j'ai réglé mes petits soucis, j'attaque l'animation des meshs
Après plus d'un mois de travail sur cette révision, je la sors enfin sur le SVN
Voici le changelog, les révisions sont de la plus récente à la plus ancienne, mais les changements sont dans l'ordre dans lequel ils ont étés appliqués.
Citation : Change log r9-r11
r11 (09/08/2011) :
-Ajout de fichiers oubliés lors du commit précédent
-Suppression de quelques fichiers inutiles
r10 (09/08/2011) :
Ungine Core:
-Set(Fragment/Vertex)Shader(NULL) n'a désormais plus d'effet lorsque le shader par défaut est déjà en place
-Utiliser le filtrage trilinéaires active maintenant la génération des mipmaps
-Correction d'un bug empêchant le shader d'utiliser toutes les unités de texture
-Ajout d'un fallback dans le cas où le Renderer ne supporterait pas les VBOs
-Le temps renvoyé par Clock::Tick() est maintenant en millisecondes
-Ajout d'un avertissement lorsqu'un thread tente d'utiliser la méthode Wait sur lui-même
-Nouvelle classe File pour gérer les fichiers, utilisant l'API système (Permettant l'Unicode et les tailles 64 bits)
-La méthode Window::SetCursorPos envoie dorénavant un event MouseMoved par défaut (Contrôlable via le troisième argument)
-Correction d'un crash lors de l'utilisation de Renderer::SetTarget(NULL)
-Correction d'un bug qui empêchait les textures affectées par un RenderTexture de revenir à l'état normal après suppression de ce dernier
-Correction d'un bug de Drawable::SetOrigin(float, float) qui n'affectait pas correctement la valeur Y
-Correction d'un bug de Filesystem::ReadCharacter(UInt32, Endianness) qui ne déplaçait pas le curseur dans le fichier
-Correction d'un bug de Image::Get(const String&, bool) qui ne prenait pas en compte le second argument
-Correction d'un bug de String::FindLast(char, int) qui provoquait une boucle infinie
-Correction d'un bug de UnicodeString::FindLast(UInt32, int) qui provoquait une boucle infinie
-Ajout d'un opérateur de copie pour la classe SceneNode
-Ungine::ByteSwap prend maintenant la taille en second argument (plutôt que de la déterminer via l'utilisation de template)
-Suppression d'un header inexistant du projet CodeBlocks (UngineCore/src/Ungine/Loaders/STB/image_DXT.h)
-Correction d'un bug de Filesystem empêchant une inversion correcte des octets en fonction de l'endianness
-Ajout d'une macro de dépréciation
-Filesystem est maintenant déprécié, utilisez la nouvelle classe File comme remplacement
-Math::GetNumberLength peut maintenant recevoir un nombre 64 bits
-String::Number(double) et UnicodeString::Number(double) prennent en compte l'option UNGINE_CONFIG_REAL_PRECISION
-String::Number(double) et UnicodeString::Number(double) n'affichent plus les zéros inutiles
-La classe Logger fonctionne dorénavant avec des UnicodeString
-Ajout de Ungine::GetLastSystemError() qui permet de récupérer la dernière erreur système sous forme de texte
-Correction d'un crash lors de l'utilisation de UnicodeString::GetUtf32Buffer
-Correction du mode d'ouverture du fichier par le loader MD2
-Les chemins de fichier utilisent maintenant la classe UnicodeString
-Correction d'un bug de String::Unicode qui n'effectuait pas de conversion correcte
-Correction du caractère de remplacement de String::Unicode
-Correction de UnicodeString::operator=(const UnicodeString&) qui n'augmentait pas le compteur de référence
-Correction d'une exception lancée par std::isspace dans la classe UnicodeString (Méthodes affectées : FindLastWord, FindWord, GetWordPosition, IsBlank, Trim, Trimmed)
-ResourceModified envoie maintenant un entier correspondant au degré de modification de la ressource
-Nouvelle architecture des ressources (Mesh et Font)
-Correction des shaders par défaut qui n'étaient pas considérés comme compilés
-Correction du clonage de texture qui ne copiait pas tous les paramètres
-Correction d'un leak causé par (Render)Window::GetTitle sous Windows
-Ajout d'une classe Directory pour gérer les dossiers
-(Unicode)String::Split* : Ajout d'un paramètre pour définir la position de départ de séparation de la chaine
-Ajout de listeners pour la création/destruction de thread
-Ajout de ThreadLocalVar, qui simule une variable thread-local
-Ajout d'un header interne pour désactiver le debuggage
-Marquage du Randomizer comme déprécié
-Correction d'un crash lors de la suppression anticipée d'un SubMesh/SubMaterial
Ungine OpenGL Graphics Module:
-Correction d'un bug et optimisation du lock des textures
-Correction d'un bug de GLSLManager::SetVertexSource(const void*, const VertexDeclaration*, unsigned int) qui ne prenait pas en compte le stream
-Suppression du troisième argument inutile de GLSLProgram::OnNewParameter
-Correction de la vérification de la version OpenGL
-Changement de la version OpenGL requise (2.1 => 2.0)
-Les paramètres définis mais inexistant au sein d'un shader ne sont plus conservés
-Utilisation de l'API Core pour les buffers
-GLSLShader::SetParameter émet maintenant une erreur si l'on tente de redéfinir un paramètre existant avec un type différent
-Texture::DownloadTexture réinitialise dorénavant l'image si la texture n'est pas créée
-Texture::DownloadTexture a été renommé pour Texture::Download
Après avoir travaillé tout ce temps sur les bases du moteur, je pense passer bientôt aux fonctionnalités "avancées" (Frustrum, éclairage, animation, ...).
Le dernier gros changement que je ferais impliquera le renommage de deux classes :
String deviendra AnsiString
UnicodeString deviendra String (Et gèrera de l'UTF-8 au lieu d'UTF-32)
(La fonction chercher/remplacer devrait suffire pour adapter le code existant)
Le noyau fait un peu plus de 42 000 lignes de code
Le module graphique OpenGL en fait 4700
C'est du bon travail je trouve. Bravo.
J'ai une question sur ta méthode pour le développement de code sur plusieurs platformes (i.e Win32/linux/*bsd).
J'ai vu que tu utilises la meme technique que les programmeurs de Boost par exemple en faisant une classe abstraite puis des classes dérivée pour chaque platforme.
Aurais tu sous la main un article ou quoi qui explique cette technique en démontrant idéalement les avantages de cette technique.
Merci d'avance.
Oh y'a des sources disponibles, le projet est libre ?
Citation : Lynix
Petite précision pour les programmeurs OpenGL : En effet, la notion de program n'existe pas, ou plutôt est transparente.
Le Renderer OpenGL créé un program pour chaque paire de shaders utilisée lors d'un rendu, c'est donc effectivement une opération qui peut échouer si le linkage du program échoue.
Si cela arrive, l'erreur est loggée évidemment, et j'hésite ensuite sur le comportement à adopter, le rendu doit-il être effectué avec les shaders de base ou bien doit-il être abandonné?
glLinkProgram() est une opération lente, ton idée est courante mais inefficace, à moins que tu aies un système de cache qui doit être super relou à gérer.
Oh y'a des sources disponibles, le projet est libre ?
En effet, mon moteur est dorénavant libre
Citation : Yno
glLinkProgram() est une opération lente, ton idée est courante mais inefficace, à moins que tu aies un système de cache qui doit être super relou à gérer.
Il y a effectivement un système de cache, chaque program n'est créé qu'une fois pour chaque paire, et le program est détruit lorsqu'un des shader qui le compose est détruit, ou alors change de code source. Tout ce qui entraîne une suppression de l'implémentation du shader (Côté noyau) reconstruit le program (Côté module).
Côté progression, les animations fonctionnent dorénavant avec le format MD2
Sortie de la r12, elle apporte les animations et améliore les performances.
Citation : Changelog r12
Global:
-Mise à jour du fichier des testeurs
-Correction d'un commentaire de l'exemple 5 ("Temps requis en secondes" -> "Temps requis en millisecondes")
-Mise à jour de Cg
Ungine Core:
-Suppression de deux header inexistant du projet CodeBlocks (UngineCore/src/Ungine/Unix/Clock.h, UngineCore/src/Ungine/Windows/Clock.h)
-Mise en application des paramètres de chargement des Ressource
-Suppression d'un header inutile de StaticMesh
-Correction d'un bug dans le clonage d'un StaticMesh
-Ajout d'une macro d'assertion
-Définition automatique de la macro NDEBUG lorsque l'Ungine n'est pas compilé en mode debug
-StaticMesh envoie maintenant un numéro lors d'une modification
-Remaniement des erreurs du MediaManager
-Le Loader MD2 est désormais capable de charger les animations
-Optimisation de la mise à jour du VBOs du Mesh
-Ajout d'un mode de lock pour les buffers (BufferLock_DiscardWrite)
-Ajout d'une option de configuration : UNGINE_CONFIG_THREADSAFE (Protège certaines classes des accès concurrents)
-Window et RenderWindow sont maintenant thread-safe
-Ajout de l'information FPS pour les Meshs (Nombre de frame par seconde pour les animations)
-Ajout d'une option de configuration : UNGINE_CONFIG_UNSAFE (Désactive certaines vérifications basées sur le code pour améliorer les performances)
-Config.h est maintenant inclus dans le fichier Prerequesites.h
-(Unicode)String::operator[unsigned int] const ne renvoie plus de référence
-(Unicode)String::operator[unsigned int] const ne renvoie désormait plus d'exception en cas d'erreur
-VertexDeclaration : la taille du buffer et le stride sont maintenant gardés en mémoire (Optimisation de GetBufferSize et GetStride)
-Ajout d'Utf<8|16>::GetByteSize et Utf<8|16>::GetTrailingBytes
-Le VertexDeclaration des Sprite n'est plus déclaré à l'initialisation mais comme variable statique de Sprite::Render
-File::Read et File::Write ne prennent plus l'endianness en argument, à la place il est précisé comme attribut du fichier (Get/SetEndianness)
-Ajout de File::IsAbsolute(path) (Attention, ne prend qu'un path déjà standardisé)
-CanonicalizePath transforme maintenant un path relatif en absolu, mais sans le nettoyer (au contraire d'AbsolutePath)
Eh beh, t'as bien progressé! Il me tarde de te voir finir les aspects 'complexes' du moteur graphique (éclairages dynamiques, etc.), parce que te connaissant, tu nous sortiras encore des performances à faire pâlir Crytek.
EDIT: Quoi qu'ils ne soient pas vraiment une référence d'optimisation...
EDIT: Quoi qu'ils ne soient pas vraiment une référence d'optimisation...
Euh, cite moi une reference en terme d'optimisation alors ?
Je fais tourner Crysis 2 a fond, alors que Oblivion tourne entre 4 et 40 fps (et pas a fond)
fin du HS
Sinon, bonne initiative de donner les sources, j'essaierais de regarder en detail quand j'aurais le temps
Pour l'eclairage dynamique, tu risques de devoir refaire une partie du systeme de shader, pour pouvoir gerer le nombre de sources de lumiere (probablement generation de certaines parties/totalité du shader, l'utilisateur appelant une fonction ou ecrivant une fonction)
Pour l'eclairage dynamique, tu risques de devoir refaire une partie du systeme de shader, pour pouvoir gerer le nombre de sources de lumiere (probablement generation de certaines parties/totalité du shader, l'utilisateur appelant une fonction ou ecrivant une fonction)
Je ne comprends pas cette remarque, le système de shaders est bas-niveau, on donne le code du shader, on l'envoie au Renderer, on exécute le rendu et où est le problème ?
Si je veux utiliser plusieurs lumières dynamique, que ce soit avec du per-pixel-lighting ou du deferred shading, je devrais exécuter au moins x rendus (x étant le nombre de lumières) et compter sur le blending pour avoir le résultat en une seule image, non?
(Je sais que le deferred shading ne demande qu'une fois le rendu des vertices, cependant il faut bien faire un rendu 2D par lumière ensuite)
Oui, tu dois avoir raison, j'avais oublié/écarté le deferred shading, l'idée que je proposais était d'effectuer toutes les passes du deferred shading en une seule passe, ca a des avantages et des inconvénients
Par contre, je maintient que proposer une base de code(GLSL) pour que l'utilisateur n'override qu'une partie du shader est une bonne idée.
Désolé, je m'exprime mal, enfin bon boulot en tout cas, moi j'ai pas la patience
Ce serait difficile de proposer un code de basique constant pour chaque shader, enfin en tout cas je n'en vois pas l'intérêt, par exemple le module graphique n'envoie certaines variables uniformes que si elles sont déclarées dans le shader, c'est à dire si le shader les utilise.
Donc à part la déclaration du main je ne vois pas très bien ce qui reste contant
Donc à part la déclaration du main je ne vois pas très bien ce qui reste contant
Les entrées et les sorties, la seule chose qui varie, c'est le traitement(code utilisateur ou code moteur emulant + ou - le pipeline fixe) et la quantité des entrées sorties (presence ou pas de texture, normal map, etc.)
Mais mon idée est peut etre contraire à l'esprit de l'Ungine, et sans doute pas une priorité si tu mets en place le deferred shading
Par contre, c'est à peu pres ce qui est utilisé dans Ogre3D (Génération du shader d'après un material ou on décrit le/les shaders dans un language non dependant du Rendererer(GL/DX))
Sinon, il y a actuellement deux modules : Core(qui n'en est pas un en fait) et Graphics, je me demandais si separais le resource management et le scenemanagement dans deux autres modules ne serait pas une bonne idée(interface publique avec singleton dans les includes, quand le module est chargé, le pointeur du singleton est initialisé -> le module graphics verifie que le singleton est != NULL, ou une exception est levée)
Après, c'est juste des remarques qui essaient de te faire couler sous les choses à faire, = pas prioritaires, ni importantes
Pour le resource management, tu entends quoi par là ? Parce que le ResourceManager (bien que rudimentaire) fait son rôle et ne nécessite pas tellement de personnalisation, enfin je pense.
Pour le SceneManager je prévois un système basé sur le polymorphisme, ce qui permettrait aux plugins de rajouter des SceneManager par exemple.
Désolé, au moment ou j'ai posté, j'avais le souvenir d'avoir vu le ResourceManager dans UngineGraphics, et je n'avais pas vu que UngineGraphics contenait seulement l’implémentation OpenGL
l'Ungine est déjà sous licence libre, après pour le port, ça devrait être possible de faire une interface C, étant donné que tout le polymorphisme est encapsulé.
Mais ce n'est pas du tout ma priorité pour le moment par contre.
Je travaille actuellement sur les AABB et les OBB, je ne sais pas encore si le frustum sera dans la r13 étant donné que je vais me concentrer sur le moteur physique.
Oh au fait, j'ai découvert un très gros leak dans la classe qui gère les MD2 animés, il est corrigé dans la r13.
Sortie de la r13, elle n'apporte pas la physique comme prévu parce que j'ai du corriger de nombreux bugs qui embêtaient les utilisateurs.
Citation : Changelog r13
Global:
-Mise à jour de l'exemple 8 (Paramètres des loaders)
Ungine Core:
-Les macros Windows ne sont maintenant définies que lors de la compilation de l'Ungine (pour prévenir des conflits)
-Correction d'un bug de Camera::Draw entraînant une reconstruction d'un SceneNode à chaque appel
-Optimisation : changement du container pour les childs des SceneNode (list => set)
-Correction de fuites de mémoire dans MD2Mesh
-Correction d'un crash lors d'un rendu d'un Mesh sans vertices
-Réécriture de la classe AxisAlignedBox
-Il est maintenant possible de récupérer l'AABB d'un Mesh
-Rajout des définitions de M_PI et de M_SQRT2 dans Math.h (M_PI n'était pas standard et empêchait la compilation)
-Correction de l'inclusion de ressources (Sansation_Regular) qui ne passait pas chez tous les compilateurs
-Rajout de la surveillance Resource à la classe Font
-Font et Mesh sont maintenant informés lors de la suppression (imprévue) de leur implémentation
-Correction d'un leak mineur d'UnicodeString::Hash
-La configuration UNGINE_CONFIG_BUFFER_FILE_SIZE a été renommée UNGINE_CONFIG_FILE_BUFFERSIZE
-Disparition de la configuration UNGINE_CONFIG_BUFFER_SIZE
-Les fonctions GetDigestLength et GetHashName des Hash sont maintenant statiques
-Les options de configurations sont maintenants expliquées par des commentaires
-Le fichier de configuration de l'Ungine fonctionne maintenant par valeur plutôt que par définition
-Ajout d'une macro de mutex statique
-Suppression de la méthode File::GetEndianness (Aucune utilité)
-String et UnicodeString sont maintenant vidées avant de récupérer la saisie d'un flux
-String et UnicodeString supportent la surchage de std::getline qui prend un séparateur comme troisième argument
-Meilleure gestion des erreurs de la classe Mesh
-Rajout de l'implémentation de Mesh::IsAnimated (Oubliée dans le précédent commit)
-Correction d'une petite erreur de nom dans une exception lancée par Vector4 (Merci à Fullmetal alchemist)
Ungine OpenGL Graphics Module:
-Standardisation des Mutex selon ThreadSafety.h
-Les appels SetTexture(i, NULL) ne sont plus ignorés
-Amélioration des performances sur la récupération d'informations venant du Renderer
-Amélioration des performances sur le paramétrage du test stencil
Pour la physique, le plus difficile est de penser à une interface de base qui soit compatible avec tous les moteurs physiques, et de fournir le reste sous forme "d'extensions".
Mes priorités sont le frustum culling (Ainsi que la gestion des OBB), le module physique, gérer d'autres formats de fichier.
Je vais me remettre au C++ et tester ton moteur très rapidement, car depuis le début je suis le projet, et je ne suis toujours pas déçu des améliorations
Alors je compte remanier un peu la gestion du moteur, tout d'abord au niveau des versions, qui étaient déterminées en fonction du nombre de build.
Désormais la version majeure et la version mineure seront gérées manuellements, la version majeure sera 0 jusqu'à la sortie stable (Pas avant un moment), la version mineure augmentera régulièrement (Et je viendrais poster le changelog).
La différence avec le précédent système, c'est que chaque version mineure est associée à plusieurs commit, chacun apportant sa contribution (qui se retrouve dans le changelog).
Je ne compte pas faire de version mineure étalées sur plusieurs mois, mais plus rapprochées, quand les fonctionnalités sont stables
La différence avec l'ancien système, c'est que des corrections de bug ou des fonctionnalités implémentées peuvent se retrouver sur le SVN sans que je ne vienne le dire ici.
l'Ungine va donc passer en version 0.14 dès le prochain commit (Que je viendrais poster ici), il entraînera la disparition de GLEW des dépendances, des corrections de bug, des méthodes renommées, une meilleure gestion des bibliothèques dynamiques ainsi que le support des extensions et des plugins.
l'Ungine va aussi bientôt supporter les autres IDE avec une génération des projets via premake
Des nouvelles, sur le plan personnel je rentre en terminale demain et le disque dur de mon ordinateur portable est endommagé (Ce qui signifie que je vais avoir du mal à travailler dessus), je suis en train de le réparer avec HDD Regenerator, on verra bien ce que ça donne (Au pire le disque dur est toujours sous garantie).
Du côté de l'Ungine, ça avance assez bien, corrections de bugs, changement de l'interface et nouvelles fonctionnalités.
Je pensais ouvrir un forum bientôt, une fois l'Ungine "exploitable".
Je poste aussi pour vous parler d'un changement important, même si ça n'affecte pas directement pas les utilisateurs :
l'Ungine utilise dorénavant OpenGL 3 si possible.
J'ai totalement remanié la gestion d'OpenGL afin de charger chaque fonction manuellement, suivant les header GL3.h, glext, wglext glxext (Disponibles sur le site d'OpenGL).
Plus aucune fonction dépréciée n'est utilisée.
Cependant, cela ne signifie pas que le Renderer est incompatible avec les cartes ne supportant pas OpenGL 3, les fonctions du noyau qui sont chargées existent à partir d'OpenGL 2.0 (Ce qui est donc la version minimale requise).
Attention cependant que, pour l'instant, les FBOs doivent être supportés, que ce soit par OpenGL 3 ou par une extension d'OpenGL 2, afin que le module fonctionne.
Je vais voir pour utiliser les pixel buffer du système dans le cas contraire.
Je vais aussi me débrouiller pour créer des contextes OpenGL 3 si c'est supporté (Dans le cas contraire, le contexte sera créé de façon classique).
Côté noyau, je travaille sur l'implémentation du culling
Edit : J'ai oublié de préciser que j'allais aussi utiliser les matrices column-major, qui sont directement compatibles avec OpenGL et DirectX (La transposée posant des problèmes de calculs).
J'ai chaque jour deux heures de train à faire, ce qui me fait deux heures de programmation grâce à mon ordinateur portable (Qui est en ce moment-même en train de régénérer ses secteurs défectueux).
Puis il faut dire que je ne consacre pas beaucoup de temps à l'étude de toute façon
Côté Ungine je suis en train de remanier la gestion des contextes OpenGL, le but étant de rendre ça thread-safe
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)