En fait, le soucis ne vient pas de ce que tu as exposé, ou même montré avec tes screens Aranoth.

En testant un certains nombres de petit code (comme celui posté plus haut), il semble qu'il y
ai un bug avec OpenGL avec la fonction SetClipPlane, bug qui ne se produit pas avec Directx en
driver. Après il s'agit peut-etre tout simplement d'une mauvaise utilisation des fonctions...

Dernière modification par tmyke (25-10-2008 15:03:16)

Mais justement, c'est quoi le bug ? Vous avez des captures d'écran qui montrent à quoi il ressemble ?
Je ne l'ai pas rencontré avec irr 1.4 et OpenGL

Essais le petit code que j'ai donné (et si tu ne rencontre pas le soucis, cela est peut-etre alors lié un à soucis de pilote ou de
verison de drivers de carte).
Sinon, pour les screens, j'ai posté ici:
http://irrlicht.sourceforge.net/phpBB2/ … hp?t=30776

Dernière modification par tmyke (25-10-2008 15:16:31)

Aranoth ton clip plane est bien situé dans le plan de ton plane water donc il coupe ton cube en dessous de du centre de ton cube. Donc pourquoi ton cube est coupé pile poils en deux (on le voit grace a ta texture aucun des carreaux de ta texture n'est scindées en deux parties) ? maintenant pour t'en convaincre, créé deux cubes que tu place en dessous et un autre au dessus de ton plan d'eau et tu laisse ton clip plane actif pour le voir avec ta camera. Tu verra que le clip plane agit bien comme il le faut dans le principe mais il le fait sur chaque mesh indépendemment.

En effet je confirme le bug avec deux cubes

C'est la même chose avec la dernière version SVN

Donc c'est décidé, de force mais bon, je passe en directX. Cà y est j'ai réussi à exporter mon matériau avec 3ds max sous la forme de *.fx et d'un *.hlsl. Donc pour mes matériaux et mes meshs, je pourrais tout exporter de 3ds max. Et en plus les fx sont utilisables sous irrlicht j'en ai vu une utilisation et vu que les *.fx peuvent contenir les effets du style : les systèmes de particules... C'est de la boulette!

Si cela t'intéresse, j'ai fait une classe dérivée de ImeshSceneNode pour un emploi direct et complet des codes
HLSL (comme ceux du DXSDK ou encore de Cg), en s'affranchissant surtout de quelques limitations d'Irrlicht, comme
par exemple la l'impossibilité avec Irrlicht de sélectionner une des techniques définit, lou de profiter des commutateurs
prédéfinis, etc...

Cela impose juste comme contrainte d'avoir le SDK de DirectX d'installé pour la compilation du code. Et là, je n'ai plus de
soucis de compatibilité et j'en profite à 100%.

Ca peut s'averer intéressant, de plus j'ai déja installé le sdk de directX lorsque j'ai recompiler irrlicht la dernière fois.

OK, je te fait un petit zip pour demain, avec en guise d'exemple un HLSL BasicRender avec 3 lights possibles selon la technique, et un HLSL perPixelLighting sympa.

A la limite quand la compatibilité vous intéresse pas, faites comme moi : XNA

C'est très simple à utiliser, c'est du C#, c'est assez bas niveau pour permettre de faire ce que l'on veut, on peut exploiter à fond les shaders HLSL, etc.

Seul défaut c'est que c'est que c'est limité par les capacités de la XBox 360, donc exit DirectX 10


Après quand la compatibilité est importante, y'a pas le choix : OpenGL (d'où mon cri de désespoir lors de l'annonce du pseudo OpenGL 3)

C'est pour ça que j'ai mon propre moteur 3D après tout

Aranoth :

A la limite quand la compatibilité vous intéresse pas, faites comme moi : XNA

Hmmm, C#, j'accroche pas trop, surtout quand on maitrise plutôt pas mal le C++, et puis j'ai l'impression
(peut-être fausse) d'être enfermé dans un karkan à l'évolution limité....

Aranoth :

Après quand la compatibilité est importante, y'a pas le choix : OpenGL (d'où mon cri de désespoir lors de l'annonce du pseudo OpenGL 3)

A mon grand regret, OpenGL à du mal à prendre le virage du 'NextGen', que cela se disperse, tergiversations et atternuaments. dommage, j'espère que les choses évolueront dans les bon sens dans les mois et les années à venir, c'est jamais bon quand il ne reste plus qu'un seul et incontournable  acteur dans un domaine.

Aranoth :

C'est pour ça que j'ai mon propre moteur 3D après tout

C'est ce que j'avais fait, et plutôt pas mal en plus (Dreamotion3D), mais le dev d'un tel projet n'est pas évident, et passé un certains stade
on passe plus de temps sur le moteur que sur le projet lui-même, donc là aussi c'est un choix, surtout quand cela reste un loisir...

Resultat, s'investir dans un moteur déjà existant, mur, possédant pas mal d'outils et d'Add-on,  et à la communautés importantes, me parrais aujourd'hui
la moins mauvaise option

Dernière modification par tmyke (25-10-2008 20:24:06)

Hmmm, C#, j'accroche pas trop, surtout quand on maitrise plutôt pas mal le C++, et puis j'ai l'impression
(peut-être fausse) d'être enfermé dans un karkan à l'évolution limité....

Si carcan il y a, c'est XNA, pas le C# qui est promis à un avenir plus que radieux. Sans compter que l'évolution du C# est bien plus rapide que celle du C++ (la norme C++09 va permettre de dépoussiérer pas mal le C++, mais rien de comparable avec les avancées du C# et de la plate forme .NET en général.
Non c'est vraiment un langage qui a fait ses preuves, y compris pour la réalisation de jeux.

A mon grand regret, OpenGL à du mal à prendre le virage du 'NextGen', que cela se disperse, tergiversations et atternuaments. dommage, j'espère que les choses évolueront dans les bon sens dans les mois et les années à venir, c'est jamais bon quand il ne reste plus qu'un seul et incontournable  acteur dans un domaine.

Je suis du même avis, mais j'ai peur pour l'avenir. Le gros défaut d'OpenGL c'est son API horrible et incohérente à cause des couches successives (l'API a plus de 17 ans) et par conséquent son implémentation de plus en plus délicate, et donc des drivers buggés (les puces Intel remportent la palme).
Khronos s'est dégonflé au profit des lobbys de l'industrie CAD qui ne voulaient pas changer leur code base, et c'est sacrément dommage.
Heureusement il reste Blizzard, NVidia et Carmack pour nous pondre la prometteuse extension Direct State Access. Mais comme ATI suit pas, c'est foutu.
Le futur d'OpenGL est sombre, la stagnation semble s'être enracinée trop profondément

C'est ce que j'avais fait, et plutôt pas mal en plus (Dreamotion3D), mais le dev d'un tel projet n'est pas évident, et passé un certains stade
on passe plus de temps sur le moteur que sur le projet lui-même, donc là aussi c'est un choix, surtout quand cela reste un loisir...

Oui, j'ai manqué de peu Dreamotion, ayant abandonné le PureBasic peu avant que ce dernier fasse son entrée, ça m'aurait intéressé autrement. Mais les retours ont l'air plutôt bon, bravo.

Resultat, s'investir dans un moteur déjà existant, mur, possédant pas mal d'outils et d'Add-on,  et à la communautés importantes, me parrais aujourd'hui
la moins mauvaise option wink

C'est sur, c'est l'idéal a un détail près : quand on veut bosser sur le jeu en lui même, c'est dur et très énervant d'être bloqué par le moteur 3D.
Certains commencent par corriger les bugs eux même et ajouter les fonctionnalités manquantes, mais au final c'est assez dur de tout faire intégrer au noyau.
C'est pour ça qu'Irrlicht a connu d'innombrables forks. C'est très dommage d'ailleurs, car c'est évident qu'Irrlicht manque encore de maturité.

J'ai été voir et j'ai télécharger le sdk, franchement il est pas mal le moteur dreamotion3D en plus il a l'avantage de gérer la physique. Par contre je me demande quelque chose, est-ce qu'il gére les B3D animés?

johnplayer :

J'ai été voir et j'ai télécharger le sdk, franchement il est pas mal le moteur dreamotion3D en plus il a l'avantage de gérer la physique. Par contre je me demande quelque chose, est-ce qu'il gére les B3D animés?

En fait DM3D supporte les B3D statiques, avant d'arreter le dev du moteur j'étais sur les animations B3D et les shadows.

Aranoth :

C'est sur, c'est l'idéal a un détail près : quand on veut bosser sur le jeu en lui même, c'est dur et très énervant d'être bloqué par le moteur 3D.
Certains commencent par corriger les bugs eux même et ajouter les fonctionnalités manquantes, mais au final c'est assez dur de tout faire intégrer au noyau.

Dans une certaines mesure tu as raison, mais c'est un cercle sans fin: faire son moteur est trop contraignant niveau temps et compétence, et faire
appel à un moteur3D existant est trop 'bloquant' et parfois frustrant. Il faut donc faire des choix (et les plus subtiles) et s'y tenir, sans
quoi on avance pas et en prenant du recul on se rends compte qu'on est toujours au point mort.

Aranoth :

C'est pour ça qu'Irrlicht a connu d'innombrables forks. C'est très dommage d'ailleurs, car c'est évident qu'Irrlicht manque encore de maturité.

Pour la maturité, tout a fait d'accord. C'est un moteur très attachant, et doué d'une bonne communauté, et c'est important, mais une reprise du
code ne lui ferais pas de mal, et meme si je sais que c'est prévue à priorie à partir de la version 1.5, continuer à faire des rendus a partir de
mesh définit en mémoire système, c'est vraiment d'un autre temps

PS: johnplayer: le petit zip promis est pret, je poste cela après déjeuné...

voici donc la petite archive dont je parlais hier. http://www.irrdream.fr/_files/HLSL_Irrlicht.zip

C'est en développement, je tatonne encore, Irrlicht et moi, nous nous cotoyons que depuis quelques semaines et nous nous connaissons
vraiment que depuis une quinzaine de jours.
Donc, en fait j'ai pris la classe CMeshSceneNode, que j'ai modifiée à 'ma sauce', et petit à petit je la façonne à ma main.
Cela évolue tous les jour, je suis dessus d'ailleurs encore en ce moment.
Donc, il ne s'agit que de Mesh statiques, pas des animations, mais je verrais pour y venir après ...
Quand au HLSL que contient le pack, c'est deux HLSL des DXSDK, que je suis en train de décortiquer et d'en comprendre les
mécanismes. Même si je suis pas manchot en 3D, j'avoue que les shaders restent une partie ou je dois faire mes armes et j'ai
beaucoup à apprendre...

Bon dimanche à vous.

Dernière modification par tmyke (26-10-2008 11:44:52)

Merci je regarde ca lorsque j'aurais fini mon robot sous 3ds max. Eh oui, la c'est journee modélisation.

johnplayer :

Merci je regarde ca lorsque j'aurais fini mon robot sous 3ds max. Eh oui, la c'est journee modélisation.

pas d'urgence, sinon pour la modélisation, faudra qu'un jour tu me donnes des cours alors, car c'est un domaine ou je suis pas trop doué... 

Dernière modification par tmyke (26-10-2008 17:40:12)

Ca fait quelques mois que je m'y suis vraiment mis mais avec tout les tutos qu'il y a sur internet j'ai réussi a acquérir un niveau correct, en tout cas assez pour créer mes meshs, créer le mapping UVW pour les coordonnées textures et bien sur le rendu en texture pour créer des textures réalistes sans plomber les FPS dans le jeu pour les petites configs. Sinon si tu veux des cours de 3ds max envoie moi ton adresse MSN et je ferais au mieux pour t'accordez du temps pour d'apprendre la modélisation.
Sinon moi non plus je ne suis pas super doué ni pour la modélisation ni pour la programmation mais je me débrouille en apprenant par-ci et par-là, c'est la magie d'internet!

Je me débrouille quand même, disons que j'arrive à quelques trucs de bases. Quand j'aurais du temps , et un réel besoin, alors je m'y collerais plus
sérieusement...

Pour mon robot, j'ai besoin de créer une réflection sur une sphère mais je ne sais pas transférer le contenu d'une ITexture dans une IImage à un emplacement précis. Je peux faire mes 6 RTTs mais il faut que je les mette dans une IImage puis que je mette cette IImage dans une ITexture que j'utiliserais comme texture de réflection.
J'ai retourné la doc mais rien, il y a bien un moyen : en lisant et écrivant pixel par pixel. Mais bon, je bricole parce que je ne peut pas avoir plus de 4 textures par materiau mais  moyen est quelque peu barbare. Il doit bien y avoir une fonction quelque part.
Alors si quelqu'un a une idée qu'il ne se gène pas à la communiquer.
A la limite s'il y a possibilité de transférer mes RTTs directement dans la texture finale pourquoi pas se serait plus logique d'ailleurs.

Dernière modification par johnplayer (26-10-2008 22:13:16)

Dis moi si je me trompe, mais en final tu cherches à faire de la réflection par CubeMapping, non ?

Exactement. D'ailleurs j'ai essayé de transférer mes rtts dans une 7 eme texture mais ca réagit bizarrement. J'essaie de trouver ce qui ne va pas. Mais il me faudrait juste une fonction viable pour transférer une ITexture (308*308 px) dans une IImage (1024*1024 px) à une position donnée. Ou alors convertir ma ITexture (308*308 px) en une IImage (308*308 px).

tu pourrais par exemple faire comme cela:

- definition donc d'une 7 ieme texture, d'une taille de ton cubemapping.
- définir cette 7 ieme texture en RenderTargetTexture()
- dessiner tes 6 textures en sortie avec l'instruction 'driver->draw2DImage( texture0, position2d<s32>(x,y) );

et voilà. Niveau perf je ne sais pas ce que cela pourrait donner, mais à tester, c'est une idée...

J'y ai pensé (enfin plutot faire un driver->createScreenShot() pour retravailler l'image puis la mettre dans une texture) mais il y a un problème, cela implique que ma device soit carré ! Sinon ma texture sera décalée sur mon mesh. Ou alors il faudrait que puisse rogner l'image.

Si tu veux générer une texture unique pour faire du cubemapping, elle doit avoir ce visage là:



Si tes texture par faces sont en 320 pixel, cela ferait tout en gardant la même echelle d'image une texture cubemap de 1280x960.
Toute les cartes video ne supportant pas ce ratio, tu peut redimensionner, pour arriver à une texture de 1024x1024, même si à plat cela semble un peu faire rabougris, une fois appliqué je ne suis pas sur que l'on voit la différence... à tester.