Discussion :

[N_I_C_S]

Salut,

J'aimerais présenter ce projet sur lequel je suis depuis quelque temps. Il s'agit principalement de proposer un (mini)moteur 3D temps réel profitant pleinement de la compatibilité Java, c.a.d n'utilisant aucune librairie graphique (openGL/directX, exit). Mon espoir est qu'à terme on puisse utiliser ce genre de technologie sur toutes machines (surtout mobiles).

Presentation et demos ici.

[N_I_C_S]

Salut,

J'aimerais avoir vos commentaires sur le projet.
Je rappelle qu'il s'agit d'une tentative de système 3D software implémenté en Java (c.a.d 100% multi-plateforme).

Fonctions :

- Importation de scènes vrml_1/vrml_97/milkshape3d/3DSmax.ASE.
- manipulations graphiques : translations, rotations, echelles, lumières diffuses, fil-de-fer, zooms, face-optimization,...
- Systeme physique : gravité, glissement d'un objet dynamique sur un décor.

Les démos : http://www.malville.net/web3d/demosIndex.html

--------------------------------------------------------------------------

Sinon, PS :
J'aimerias connaitre vos strategies de collision (en detail) sur un BSP !!
Pour ma part, j'ai développè une "chose" entre la reconnaissance de sphère et la 8-Box.

Thank U !

[broumbroum]

Salut!
J'aimerais te poser la question si tu utilises un moteur 3D pourquoi ne pas s'acquitter des ralentissements avec un affichage en software pour un graphisme accéléré par OpenGL? Surtout que la librairie JOGL est sortie et apporte bcp d'améliorations au niveau de la vitesse d'affichage.

[Baptiste Wicht]

Chapeau, je suis bluffé

Faire ca en pur Java, c'est très bien

Ca montre qu'on peut faire de très bonne chose en Java et en plus sans utiliser de librairies externes.

Continue comme ça

[daed]

bravo !

ça tourne trés bien, aucun bugs , aucun ralentissements !

bonne continuation dans ton projet
si tu fais un bon site animé en 3D tout simplement je pense que ça cartonnerais.

[N_I_C_S]

Salut,

Je vous remercie pour vos encouragements !

En ce moment, je bosse (doucement) sur une sorte de z-buffer logiciel à base de BSP (sorte de "BSP dynamique optimisé") qui me permettra à terme d'attaquer les animations hiérarchiques.

a++ !

[Cheps]

En ce moment, je bosse (doucement) sur une sorte de z-buffer logiciel à base de BSP (sorte de "BSP dynamique optimisé") qui me permettra à terme d'attaquer les animations hiérarchiques.

Pourquoi pas faire un vrai z-buffer? C'est certainement plus facile qu'un "BSP dynamique optimisé", et ne coûte rien en calcul.

[broumbroum]

Qu'est-ce qu'un BSP?

[Laurent Gomila]

Qu'est-ce qu'un BSP?

Regarde dans la programmation 3D

[N_I_C_S]

Salut,

Pourquoi pas faire un vrai z-buffer? C'est certainement plus facile qu'un "BSP dynamique optimisé", et ne coûte rien en calcul.

Le problème est qu'un vrai z-buffer est un service offert en hardware par les cartes graphiques. Mon but est d'essayer de m'affranchir des systèmes matériels (en utilisant strictement la JVM 1.1) et de voir ce qu'on peut faire en 3D réellement multi plate-forme. Dans ce sens, je ne peux que simuler un z-buffer.

Si je voulais reproduire logiciellement le fonctionnement d'un z-buffer, il faudrait d'abord bloquer une grosse quantité de mémoire (480000 float pour un écran 800x600) puis gérer en bloc cette structure monstrueuse : calcul des pixels concernés par chaque primitive 3D, pour chaque pixel calcul de profondeur, mise à jour d'un color-buffer (480000 infos de plus), affichage pixel par pixel de l'écran.

Ces traitements son totalement incompatibles avec de la 3D temps réel. Il a donc fallu avoir un peu d'imagination et c'est comme ça que j'ai pensé à ma petite solution .

[Cheps]

480000 float ça fait un peu moins de 2Mo, c'est ridicule sur un ordinateur moderne. Bon ça peut faire beaucoup sur des plateformes mobiles, je te l'accorde

Par contre au niveau des calculs c'est vraiment très léger je pense (quoique je me rends pas du tout compte de la puissance dont tu disposeras sur ces platteformes).

Dans tous les cas, bonne chance.

[Sivrît]

480000 float ça fait un peu moins de 2Mo, c'est ridicule sur un ordinateur moderne.

Ca fait aussi interpoler la distance pour chaque pixel affiché, donc généralement plus de 480000 fois (suivant recouvrement des polygones), et ce pour chaque frame. En plus pour chaque pixel il faut faire une comparaison, ce qui veut dire un branchement dans le code et ça c'est mauvais pour le pipeline du processeur. Le z-buffer est facile à cabler et tès bien quand on a du hard pour le faire. En soft je suis sceptique.


J'en profite pour tirer mon chapeau, car le résultat est bien fluide sans avoir d'accès bas niveau. J'aime bien Java, mais sans le voir j'y aurais pas cru (pas que je pense Java lent, mais à ce point là ).

[karmaGfa]

Elle est vraiment cool ta lib 3D. Chapeau.

[N_I_C_S]

Merci beaucoup.

J'en profite pour annoncer que mon système de tri de profondeur est au point, et de nouvelles démos vont bientôt être mises en ligne (il faut que je me bouge...).

[Baptiste Wicht]

Merci beaucoup.

J'en profite pour annoncer que mon système de tri de profondeur est au point, et de nouvelles démos vont bientôt être mises en ligne (il faut que je me bouge...).

Cool, j'attends ça avec impatience, bonne chance pour la suite

[N_I_C_S]

Salut,

première démo "à l'arrache" de ma classe Z_Control (tri dynamique des faces, gestion des chevauchements, optimisation de composition de l'image) : http://www.malville.net/web3d/demosIndex.html sous "test de profondeur".

Ma classe est une tentative d'émulation soft de z-buffer par un moyen très différent, et l'affichage n'est pas exempt de défauts. N'hésitez pas à indiquer les problèmes de rendu que vous trouvez génants, moi-même ayant du mal à être objectif.

Merci et a++

ps : je vais tâcher de faire quelques démos un peu plus "esthétiques"...

[billynirvana]

J'approuve les concepteurs et surtout les développeurs qui s'handicapent de toutes autres libraires que le JDK de base! Comme une sorte d'(auto) sado masochisme

bravo en tout cas!

Kurt

[N_I_C_S]

J'approuve les concepteurs et surtout les développeurs qui s'handicapent de toutes autres libraires que le JDK de base!

Je ne pense pas que la démarche de se passer de libs soit si absurde que ça. Mon but est de faire un système 3D minimal "universel" capable de tourner sur à peu près n'importe quoi. Vu la disparité du matos d'une part et la tendance de standardisation des systèmes d'autre part, ce genre de projet me semble pertinent. Plus pragmatiquement, quand le parc des téléphones portables aura atteint des performances telles que la 3D sera devenue rentable, une API comme ça pourra intéresser beaucoup de monde.

Comme une sorte d'(auto) sado masochisme

Au niveau du vécu, c'est cool, je te rassure. Plutôt que d'éternellement faire joujou avec 2 glRotatef et 3 glBindTexture, ou se lancer dans un n-ième moteur C++/D3D/OGL ou Java3D, je trouve beaucoup plus motivant d'explorer de nouvelles possibilités. Maintenant, si les mecs qui essayent d'innover sont qualifiés de pervers...

bravo en tout cas!

Je te remercie.

[guiloic]

Certes, mais je pense qu'une librairie telle que celle là n'a pas d'intérêt à long terme puisque de plus en plus de plateformes mobiles disposent d'un accélérateur 3D.

Mais c'est du bon taf en tout cas

[plegat]

une librairie telle que celle là n'a pas d'intérêt à long terme

Elle permet de se passer de la partie native des afficheurs 3D actuels.

Perso, j'utilise actuellement JOGL pour une appli, et ceci nécessite d'utiliser une version de la librairie par architecture (une pour Win, une pour Linux, une pour Solaris...).
Avec une librairie commune, ça simplifie la chose, pas besoin de faire 36 versions de déploiement avec le jar et les binaires qui vont bien... et ça évite à l'utilisateur d'aller réfléchir pour récupérer la bonne version...

Mais bon, pour le long terme, seul l'avenir le dira.


Sinon, question plus pragmatique, je n'ai pas vu d'histoire de licence pour ton api sur le site. On peut s'en servir pour tester?