3D Java 100% software

**N_I_C_S** · 12/02/2007, 02h23

Oui, oui, tout à fait, c'est en téléchargement libre ! (edit : http://www.malville.net/web3d/description_javagl.htm)

D'ailleurs, euh, j'avais jamais pensé à ça

...
De toute façon j'en ferai qqch de libre et open source (pour l'instant y a pas les sources, un peu par égocentrisme et un peu parce que là c'est le bordel

).
Faut que je me renseigne, j'y connais vraiment rien en licences...

Sinon, bien parlé, c'est exactement l'idée du projet, le retour aux fondamentaux d'un langage managé : la compatibilité. Avec l'arrivée de toutes ces API supplémentaires, on a les inconvénients d'un langage interprété sans les avantages !

Pour ce qui est du long terme, je pense (ça n'engage que moi...) que les préoccupations hardware vont disparaître peu à peu (à part les communications réseau qui vont exploser). les communications distantes toujours plus performantes associées à des puissances de calcul en progression exponnentielle sonneront le glas du materiel dédié. Un premier pas dans ce sens est le projet de microsoft de prise en charge software du son ! Je suis sûr qu'à terme l'unification inévitable du matos tuera les cartes graphiques.

Mais, comme tu le dis, seul l'avenir le dira...

**bafman** · 12/02/2007, 08h29

pour les licences, si tu veut faire de l'open source, tu a en gros 3 grande familles :

le style GPL, contaminante, c'est a dire que si quelqu'un utilise ta lib, il est obligé de faire un projet en GPL (ce n'est pas toujours apprecié en entreprise)
le style LGPL, qui permet de faire des projet non open source, mais si l'utilisateur modifie la lib, il est obligé de distribuer la version modifiée des sources de la lib
le style zLib qui permet de modifier la lib original sans rien redistribuer

bien entendu, il existe plein de licences open source, ici je ne cite que les plus connus (enfin, celle que JE connais le plus en fait

)

**Matthieu Brucher** · 12/02/2007, 08h36

Envoyé par N_I_C_S

Un premier pas dans ce sens est le projet de microsoft de prise en charge software du son !

Ils ont mis quand même plusieurs années avant de pondre qqch de correct pour remplacer ASIO, sachant qu'Apple avait fait ça il y a déjà dds années avec Core Audio. Donc on a encore le temps de voir venir !
Mais je suis d'accord sur le fnd, il y a(ura) convergence.

**N_I_C_S** · 16/02/2007, 11h21

[comment : j'avais laissé ici un post n'ayant aucun rapport avec la discussion]

Désolé, et merci beaucoup Wichtounet pour ta réaction, je vais me calmer...
( à la Jugnot : "ouais, j'ai bien compris, là..." )

Edit : je viens de lire les règles du forum, je te remercie vraiment, je ferai attention.

a++

**Baptiste Wicht** · 16/02/2007, 20h23

C'est pas bien grave

Faut juste éviter de faire ça trop souvent, je peux comprendre la frustration de ne pas pouvoir aller poster dans un sujet intéressant.

**N_I_C_S** · 18/06/2007, 10h33

Salut,

Après de nombreux mois d’inactivité, le projet JavaGL reprend doucement.
Dernièrement, le système de Z-Buffer logiciel a été amélioré et un petit système d’animation par bones est désormais intégré (demo : http://malville.net/web3d/demosIndex.html).

Etapes suivantes :
- Amélioration des animations (implémentation des skins).
- Amélioration du système de collisions.
- Meilleure organisation des composants.

Lorsque tout sera bien stable, je diffuserai les sources de la bibliothèque sous licence GPL et me consacrerai à la partie web du projet (à savoir : qu’est-ce qu’on peut faire exactement pour le multijoueur avec J2EE?

).

a+

**N_I_C_S** · 31/10/2007, 14h25

Salut, quelques nouvelles !
La finalisation de la bib (oui, je propose ce diminutif pour bibliothèque...) a pris beaucoup de retard (boulot, boulot...) et des soucis avec mon FAI m’ont empêché de communiquer.

Bref, j’ai mis en ligne une dernière démo "technique" liée au système d’animation de la bib (http://www.malville.net/web3d/demosIndex.html sous "Système d'animation Skin/Bones") et je prévois de tout balancer sur SourceForge début Décembre.

Petite question subsidiaire :
Les sources ont été rédigées en français (les méthodes s’appellent par exemple afficherTriangle() ou produitScalaire() ). Pensez-vous que ce soit un handicap à plus ou moins long terme ? Cela peut-il s’avérer gênant pour une personne habituée au vocabulaire DirectX/OpenGL ? De même, vaut-il mieux faire les docs et tutoriaux en anglais ? Toutes vos remarques sont les bienvenues.

**sinok** · 31/10/2007, 16h45

La communauté java est très majoritairement anglophone, donc gros oui pour les tutos en anglais, c'est comme çà que tu fera connaitre ton API

**phpmad** · 01/11/2007, 12h48

Avant la doc en anglais, please, mets les noms de fonctions et variables en Anglais. C'est dur à dire mais je pense que l'anglais est la LANGUE de l'informatique...et c'est trop tard pour les autres langues.

**N_I_C_S** · 06/11/2007, 10h15

Ok, bien reçu

C'est clair, c'était un mauvais choix à la base...
Pas grave, je vais faire chauffer le refactoring

Merci et a+

**N_I_C_S** · 08/11/2007, 14h25

Petite info intéressante :
jusque là, le projet gérait le rendu en double-buffer par la méthode "hardware" (classe BufferStrategy), et j'ai reprogrammé celui-ci en software en m'inspirant de ceci .
Eh bien après de nombreuses mesures j'ai constaté un gain de performance sur l'ensemble de la lib d'au minimum 275%

CA POUTRE A MORT

Bon j'ai testé uniquement sur PC/Windows, mais quand même...

Voilà. Un conseil pour ceux qui veulent faire du graphique Java : utiliser le rendu software, ça speede et c'est compatible JVM 1.0.

**Baptiste Wicht** · 08/11/2007, 14h39

C'est bizarre...

Normalement on utilise le Double Buffering Hardware quand le Software ne suffit pas, pas le contraire

Ou alors, je suis à côté de la plaque...

Tu avais programmé ton hardware comme sur la faq java ? Ou tu avais utilisé une autre manière de le faire ?

**N_I_C_S** · 08/11/2007, 15h16

C'est bizarre...

Normalement on utilise le Double Buffering Hardware quand le Software ne suffit pas, pas le contraire

Je suis bien d'accord, c'est pour ça que j'avais jamais essayé avant...
La seule difference avec la faq, c'est que j'avais pas mis un setIgnoreRepaint(true) mais je pense pas que ça change grand chose.

Franchement, je comprend pas !! Ca le fait sur 3 PC différents donc ça vient pas d'un matos particulier...
Peut-être qu'un Graphics venant d'un BufferStrategy supporte moins bien les milliers d'accès d'une scène 3D (d'habitude un affichage java est fait de moins d'éléments), je ne sais pas...

En tout cas, ça va de toute façon vers plus de compatibilité donc c'est bon pour le projet, mais effectivement je vais quand même éplucher attentivement mon ancien code, même si ça déchire

c'est quand même bizarre !

**Baptiste Wicht** · 08/11/2007, 15h29

Envoyé par N_I_C_S

Je suis bien d'accord, c'est pour ça que j'avais jamais essayé avant...
La seule difference avec la faq, c'est que j'avais pas mis un setIgnoreRepaint(true) mais je pense pas que ça change grand chose.

Franchement, je comprend pas !! Ca le fait sur 3 PC différents donc ça vient pas d'un matos particulier...
Peut-être qu'un Graphics venant d'un BufferStrategy supporte moins bien les milliers d'accès d'une scène 3D (d'habitude un affichage java est fait de moins d'éléments), je ne sais pas...

En tout cas, ça va de toute façon vers plus de compatibilité donc c'est bon pour le projet, mais effectivement je vais quand même éplucher attentivement mon ancien code, même si ça déchire

c'est quand même bizarre !

Ouais, je comprends pas non plus...

Tu as essayé en rajoutant le setIgnoreRepaint(true), même si je doute que ça puisse venir de là ?

**N_I_C_S** · 08/11/2007, 15h44

Ca y est, je viens d'essayer : aucun changement !
En tout cas, même si cette différence vient d'une bêtise de ma part (en plus je pense pas), ça met en évidence l'importance du rendu graphique pur par rapport aux traitements dans un projet 3D : c'est ENORME, je pensais pas à ce point là

**N_I_C_S** · 09/11/2007, 03h48

A tout hasard, voici le code de mon affichage hardware :
(Attention, ne pas reproduire commercialement ce code, il était presque sous licence GPL

)

déclarations globales :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
private static BufferStrategy strategie; //Double-Buffer actuel
	private static Graphics dessin; //Graphics actuel
	private static HashMap listeComposants; //HashMap stockant toutes les cibles d'affichage associées à leur objet Display

Une classe Display dont une instance est associée à un composant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private static class Display {
		private BufferStrategy strategie;
		private Graphics graphics;
 
		public Display(BufferStrategy str) {
			strategie = str;
			graphics = strategie.getDrawGraphics();
		}
 
		public BufferStrategy getBufferStrategy() {
			return strategie;
		}
 
		public Graphics getGraphics() {
			return graphics;
		}
	}

Une méthode d'inscription et stockage d'un composant cible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public static void open(Frame arg) {
 
		arg.createBufferStrategy(2);
 
		listeComposants.put(arg, new Display(arg.getBufferStrategy()));
		select_target(arg);
	}

Une méthode pour choisir le composant cible d'affichage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public static void select_target(Component arg) {
		Display rendu = (Display)listeComposants.get(arg);
		if(rendu == null)
			return;
 
		strategie = rendu.getBufferStrategy();
		dessin = rendu.getGraphics();
 
		largeurEcran = arg.getWidth();
		hauteurEcran = arg.getHeight();
		centreX = largeurEcran / 2;
		centreY = hauteurEcran / 2;
	}

code d'affichage d'un polygone :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
dessin.setColor(couleurCourante);
		if(remplirPolygone)
			dessin.fillPolygon(x2D, y2D, nbSommets);
		else
			dessin.drawPolygon(x2D, y2D, nbSommets);

Enfin, méthode de swap-buffer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static void swap_buffers() {
		strategie.show();
		dessin.clearRect(0, 0, largeurEcran, hauteurEcran);
	}

Si quelque chose vous semble incorrect, pouvez-vous m'en faire part ?

**TrYde** · 09/01/2008, 10h14

Bonjour, je me permets de remonter ce sujet pour faire part d'une API que j'ai trouvée sur le net justement pour la 3D en software, plus précisément il s'agit d'un portage de OpenGL en java, sous license LGPL.

http://nis-lab.is.s.u-tokyo.ac.jp/~robin/jGL/

Les perfs sont bonnes, je l'utilise pour des surfaces avec heightmaps de haute résolution, et la syntaxe est tout simplement la même qu'OpenGL, donc pour la javadoc, le manuel d'OpenGL suffit.

N_I_C_S, la connaissais-tu ? Si non, tu peux y jeter un oeil, les sources et les exemples sont assez clairs et le rendu est sensiblement le même que java3d.

Dans le même temps, ça peut interesser des développeurs de jeux 100% java, 100% portable.

Cordialement.

**N_I_C_S** · 09/01/2008, 13h39

Salut,
Non, je connaissais pas, ça a l'air bien fichu comme alternative à JOGL

. Cependant ce n'est pas un projet software, c'est un wrapper java pour OpenGL. En ce qui me concerne, j'essaye de faire une api n'utilisant pas OpenGL ou DirectX, juste les fonctions java standards (bien que je me mette à douter du bien-fondé de la démarche, mais bon c'est un autre sujet...)

Quoi qu'il en soit, J'en profite pour annoncer la mise en ligne imminente de la partie stable de l'api comprenant un package de rendu 3D, un package d'animation et un package physique réduit à sa + simple expression (grave en chantier, je rame...). Le projet sourceforge est approuvé, j'ai plus qu'à le gaver

.

Et bonne année à tous !

**TrYde** · 09/01/2008, 14h11

Cette api JGL est purement 100% Java, il n'y a aucun appel à OpenGL, nul besoin de librairie ni d'installation préalable, juste le petit jar de 100ko et tout marche. C'est pour cela que je la présente ici.

J'ai eu l'occasion de tester ta librairie mais j'avais des problemes avec ma surface, un objetBSP, que je définissais triangle par triangle. Il y a une sorte de découpage de mes triangles et ça finit par faire des trous et des faces en trop

Ci joint un screenshot de cette surface et le code pour la générer

A part ça la mise en oeuvre est bien simplifiée, bon travail

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private static Bsp createPlane(float[][] grid) {
        Bsp plane = new Bsp();
        for (int i = 0; i < grid.length-1; i++) {
            for (int j = 0; j < grid[i].length-1; j++) {
                float x = i - grid.length/2f;
                float y = j - grid[i].length/2f; 
                Triangle trTopRight = new Triangle(
                        new Vecteur3d(x, y, grid[i][j]), 
                        new Vecteur3d(x+1, y, grid[i+1][j]),
                        new Vecteur3d(x+1, y+1, grid[i+1][j+1]));
                Triangle trBottomLeft = new Triangle(
                        new Vecteur3d(x, y, grid[i][j]), 
                        new Vecteur3d(x+1, y+1, grid[i+1][j+1]),
                        new Vecteur3d(x, y+1, grid[i][j+1]));
 
                // Couleur moyenne
                trTopRight.couleur = Grid2D.computeColor(
                        ( grid[i][j]+grid[i+1][j+1]+grid[i][j+1]+grid[i+1][j] ) / 4f);
                trBottomLeft.couleur = Grid2D.computeColor(
                        ( grid[i][j]+grid[i+1][j+1]+grid[i][j+1]+grid[i+1][j] ) / 4f);
 
                plane.ajouter(trTopRight);
                plane.ajouter(trBottomLeft);
            }
        }
 
        return plane;
    }

**N_I_C_S** · 09/01/2008, 14h37

Envoyé par TrYde

j'avais des problemes avec ma surface, un objetBSP, que je définissais triangle par triangle. Il y a une sorte de découpage de mes triangles et ça finit par faire des trous et des faces en trop

Oui, c'est à cause de la non-utilisation d'un z-buffer qui m'a obligé à trouver des solutions détournées et quand il y a beaucoup de faces le résultat n'est pas forcément très "propre"

. Cela dit, c'est une vieille version de JavaGL et celle que je vais mettre en ligne est plus au point là-dessus et, je l'espère, marchera mieux...

Envoyé par TrYde

A part ça la mise en oeuvre est bien simplifiée, bon travail

Merci beaucoup

, c'est vrai que j'ai essayé de mettre l'accent sur la simplicité des méthodes

.