Renderer pour torque

Bonjour à tous,

je vais commencer cette semaine a intégrer Spark au moteur Torque en version 1.5.2 et 1.8.2 et je posterais les résultats au fur et a mesure.

pour la version 1.5.2(pas de support des shaders) ça devrait être assez facile car entierement openGL 1.5 et il y a dejà un renderer Spark OGL
pour la version 1.8.2 ça va se compliquer un car il y a une couche d'abstraction le "GFX" qui cible soit DirectX soit OpenGL selon qu'on est sur mac ou pc windows.

M'enfin quoi qu'il en soit c'est un challenge pour moi que je releverai avec un grand plaisir

J’espère que c'est le bon endroit pour poster ce genre d'infos?.

Salut,

c'est cool çà. Tu te bases sur quelle version de spark ? la 1 ou la 2 ?

Pour la version de torque basée sur openGL 1.5, tu peux effectivement utiliser les renderer OpenGL. Tout ce que tu aura a faire est une classe System qui s'intègre dans torque (soit en dérivant SPKSystem, soit en le wrappant).

Pour l'autre version, il faut coder les renderers. Le Quad Renderer est le seul qui soit vraiment nécessaire je pense.

Je te conseille de te baser sur le module pour Irrlicht histoire de voir comment c'est fait.

Si tu as des questions n'hésites pas.

je vais utiliser la 1.05.04 pour TGE 1.5.2

je penses utiliser la version 2 pour TGEA 1.8.2

Comme ça je verrais les 2 versions

merci pour les premiers axes et conseils sur le dev.

@++

Hello,

C'est très sympa d'ajouter un nouveau moteur pour SPARK! Une fois que tu aura fini de faire les renderers, est-ce que tu serait prêt à faire un wrapper pour permettre l'utilisation du moteur 3D de Torque dans l'éditeur que je developpe (si la license de Torque l'autorise ^^) ?

Bon courage!

Salut,

Bien oui je serais prêt a faire un wrapper par la suite ou un module d'export des systems générés avec l'application vers torque. Je connais bien Qt aussi.

C'est sympa, merci!

Alors ça avance, je pourrais bientôt mettre des Screenshots.

J'aurais cependant 2 petites questions qui me sont venues à l'esprit. J'ai lu beaucoup de reproche concernant la STL(peu portable et peu performante) perso j'ai jamais eu de problème avec cependant pourquoi ne pas avoir opter pour une lib comme boost?, vériez vous un inconvénient à ce que j'essai de remplacer la STL par boost?

Ceci après avoir terminer l'intégration actuelle bien sur, car vaut mieux une version qui fonctionne avec la STL qu'une qui ne fonctionne pas avec boost.

Autre point sur lequel je bosse particulièrement c'est la prise en charge réseau, Torque possède la TNL(Torque Network Library) qui permet de ghoster les objets à travers le réseau et de créer des datablocks partagés pour économiser les ressources en bandes passantes(entre autres). Ces datablocks en l'occurence sont figés après créations durant leur temps de vie comme les modèles dans sparks(distribué à la premiere connection et pis c'est tout), je dois donc interfacer les modèle selon certaines règles d'implémentation des datablocks Torque.

Voilà.

Cool,

pour la STL, on ne peut pas lui reprocher des problèmes de performances dans la mesure ou la STL définie une norme et non une implémentation. Pour la portabilité, chaque compilo C++ se doit de disposer d'une implémentation de la STL, donc en théorie on peux difficilement faire plus portable. (en meme temps le fait d'avoir une implémentation qui peux varier peut causer des soucis de portabilité mais dans ce cas ca vaut aussi pour toute la norme C++)

Après ca reste une norme très générique donc oui on peut toujours faire du code très spécifique qui ira plus vite (avec un très bon niveau en C++). Bref je pense que c'est un faux problème. Maintenant il m'est arriver de constater des problèmes de perf avec l'implementation visual de la stl mais en général c'est du à des checks qui peuvent sauter avec un define (qui pour le coup n'est pas portable). Et puis la STL peut être facilement tunée/optimizée la plupart du temps en spécialisant des templates.

Enfin bref, j'avais pas envie de recoder des container pour le moteur et je ne désirais pas rajouter une dépendance vers une lib externe pour çà et de toute fàçon ca ne changerai pas grand chose au perf car le code critique n'est pas au niveau de l'utilisation de la STL.

Pour boost, c'est plus une extension (grosse) de la STL qu'un solution de remplacement. Ca ne réimplémente pas l'existant mais propose des choses en plus. Et c'est très bien comme çà car le principale défaut de la STL pour moi est d'être un peu trop light (pas de hash maps, de pointeur intelligents et pleins d'autres trucs). D'ailleurs la prochaine norme de la STL devrait inclure pas mal de morceau de boost.

Pour la question du réseau, c'est pas très clair, tu pourrais préciser.

Ok pour la STL, ça m'aide a clarifier les choses et me permet d'apprendre à justifier mes choix le cas échéant avec des explications simples et précises.

Pour la partie réseau en fait c'était pas une question lol juste pour dire sur quoi je bossais, la dessus je n'ai pas de problème particulier, pour l'instant...

Merci encore
@++