je suppose que ce probl=E8me est connu, mais je n'ai trouv=E9 aucun sujet
qui en parle ici. En fait, je dessine plusieurs formes (des Box pour
faire un graphique). Le probl=E8me que je rencontre est que certaines de
celles qui doivent =EAtre derri=E8res sont affich=E9es devant, ce qui fait
un rendu tr=E8s bizarre et compl=E8tement surr=E9aliste.
A chaque lancement de mon application, c'est d'autres formes qui sont
concern=E9es. On dirait que Java3D fait le rendu des =E9l=E9ments dans un
ordre al=E9atoire, et pas dans l'ordre dans lequel j'ai mis mes
instructions. Mais le probl=E8me peut venir d'ailleurs, vous le savez
certainement mieux que moi.
Est-ce que vous avez d=E9j=E0 rencontr=E9 =E7a ? Savez-vous comment
r=E9soudre ce probl=E8me ?
je suppose que ce problème est connu, mais je n'ai trouvé aucun sujet qui en parle ici. En fait, je dessine plusieurs formes (des Box pour faire un graphique). Le problème que je rencontre est que certaines de celles qui doivent être derrières sont affichées devant, ce qui fait un rendu très bizarre et complètement surréaliste.
A chaque lancement de mon application, c'est d'autres formes qui sont concernées. On dirait que Java3D fait le rendu des éléments dans un ordre aléatoire, et pas dans l'ordre dans lequel j'ai mis mes instructions. Mais le problème peut venir d'ailleurs, vous le savez certainement mieux que moi.
Est-ce que vous avez déjà rencontré ça ? Savez-vous comment résoudre ce problème ?
Merci d'avance pour vos réponses.
Probablement un probleme de culling: il y'a des optimisations qui font que seules la partie visible des polygones (le "devant") est tracee. Ca peut etre modifie en changeant - le "devant" du polygone (on est "devant" si les points entres sont dans le sens inverse des aiguilles d'une montre). - ou le parametre de culling (voir CULLING_NONE dans la doc).
Cedric.Olmanst@gmail.com wrote:
Bonjour,
je suppose que ce problème est connu, mais je n'ai trouvé aucun sujet
qui en parle ici. En fait, je dessine plusieurs formes (des Box pour
faire un graphique). Le problème que je rencontre est que certaines de
celles qui doivent être derrières sont affichées devant, ce qui fait
un rendu très bizarre et complètement surréaliste.
A chaque lancement de mon application, c'est d'autres formes qui sont
concernées. On dirait que Java3D fait le rendu des éléments dans un
ordre aléatoire, et pas dans l'ordre dans lequel j'ai mis mes
instructions. Mais le problème peut venir d'ailleurs, vous le savez
certainement mieux que moi.
Est-ce que vous avez déjà rencontré ça ? Savez-vous comment
résoudre ce problème ?
Merci d'avance pour vos réponses.
Probablement un probleme de culling: il y'a des optimisations qui font
que seules la partie visible des polygones (le "devant") est tracee. Ca
peut etre modifie en changeant
- le "devant" du polygone (on est "devant" si les points entres sont
dans le sens inverse des aiguilles d'une montre).
- ou le parametre de culling (voir CULLING_NONE dans la doc).
je suppose que ce problème est connu, mais je n'ai trouvé aucun sujet qui en parle ici. En fait, je dessine plusieurs formes (des Box pour faire un graphique). Le problème que je rencontre est que certaines de celles qui doivent être derrières sont affichées devant, ce qui fait un rendu très bizarre et complètement surréaliste.
A chaque lancement de mon application, c'est d'autres formes qui sont concernées. On dirait que Java3D fait le rendu des éléments dans un ordre aléatoire, et pas dans l'ordre dans lequel j'ai mis mes instructions. Mais le problème peut venir d'ailleurs, vous le savez certainement mieux que moi.
Est-ce que vous avez déjà rencontré ça ? Savez-vous comment résoudre ce problème ?
Merci d'avance pour vos réponses.
Probablement un probleme de culling: il y'a des optimisations qui font que seules la partie visible des polygones (le "devant") est tracee. Ca peut etre modifie en changeant - le "devant" du polygone (on est "devant" si les points entres sont dans le sens inverse des aiguilles d'une montre). - ou le parametre de culling (voir CULLING_NONE dans la doc).
Ploc
Ploc wrote:
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Ploc wrote:
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Cedric.Olmanst
Ploc wrote:
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Hmmmm le problème ne vient pas de là, je pense. Déjà parce qu'à chaque lancement, ce sont d'autres parties qui sont concernées, alors que l'ordre dans lequel sont définis les sommets et toujours le même. En fait, je ne définis pas de sommets, puisque j'utilise la primitive Box. C'est pour faire les barres d'un histogramme en 3D... des barres ont un "z" différent, et pourtant certaines Box qui sont sensées être derrière apparaissent à l'avant et masquent en partie une autre qui est sensée être devant. C'est vraiment bizarre.
Merci quand même pour la réponse (et pour l'autre réponse également).
P.S.: C'est pour mon stage de fin d'étude en entreprise :)
Ploc wrote:
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Hmmmm le problème ne vient pas de là, je pense. Déjà parce qu'à
chaque lancement, ce sont d'autres parties qui sont concernées, alors
que l'ordre dans lequel sont définis les sommets et toujours le même.
En fait, je ne définis pas de sommets, puisque j'utilise la primitive
Box. C'est pour faire les barres d'un histogramme en 3D... des barres
ont un "z" différent, et pourtant certaines Box qui sont sensées
être derrière apparaissent à l'avant et masquent en partie une autre
qui est sensée être devant. C'est vraiment bizarre.
Merci quand même pour la réponse (et pour l'autre réponse
également).
P.S.: C'est pour mon stage de fin d'étude en entreprise :)
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Hmmmm le problème ne vient pas de là, je pense. Déjà parce qu'à chaque lancement, ce sont d'autres parties qui sont concernées, alors que l'ordre dans lequel sont définis les sommets et toujours le même. En fait, je ne définis pas de sommets, puisque j'utilise la primitive Box. C'est pour faire les barres d'un histogramme en 3D... des barres ont un "z" différent, et pourtant certaines Box qui sont sensées être derrière apparaissent à l'avant et masquent en partie une autre qui est sensée être devant. C'est vraiment bizarre.
Merci quand même pour la réponse (et pour l'autre réponse également).
P.S.: C'est pour mon stage de fin d'étude en entreprise :)
Ploc
wrote:
Ploc wrote:
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Hmmmm le problème ne vient pas de là, je pense. Déjà parce qu'à chaque lancement, ce sont d'autres parties qui sont concernées, alors que l'ordre dans lequel sont définis les sommets et toujours le même. En fait, je ne définis pas de sommets, puisque j'utilise la primitive Box. C'est pour faire les barres d'un histogramme en 3D... des barres ont un "z" différent, et pourtant certaines Box qui sont sensées être derrière apparaissent à l'avant et masquent en partie une autre qui est sensée être devant. C'est vraiment bizarre.
Le z, c'est l'axe vertical, hein? Sinon, il n'y a pas assez d'elements (voire un bout de code posant probleme) pour donner une reponse plus avisee. Bon courage.
Cedric.Olmanst@gmail.com wrote:
Ploc wrote:
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Hmmmm le problème ne vient pas de là, je pense. Déjà parce qu'à
chaque lancement, ce sont d'autres parties qui sont concernées, alors
que l'ordre dans lequel sont définis les sommets et toujours le même.
En fait, je ne définis pas de sommets, puisque j'utilise la primitive
Box. C'est pour faire les barres d'un histogramme en 3D... des barres
ont un "z" différent, et pourtant certaines Box qui sont sensées
être derrière apparaissent à l'avant et masquent en partie une autre
qui est sensée être devant. C'est vraiment bizarre.
Le z, c'est l'axe vertical, hein?
Sinon, il n'y a pas assez d'elements (voire un bout de code posant
probleme) pour donner une reponse plus avisee.
Bon courage.
- ou le parametre de culling (voir CULLING_NONE dans la doc).
oups! C'est pas CULLING_NONE, mais CULL_NONE (classe PolygonAttributes).
Hmmmm le problème ne vient pas de là, je pense. Déjà parce qu'à chaque lancement, ce sont d'autres parties qui sont concernées, alors que l'ordre dans lequel sont définis les sommets et toujours le même. En fait, je ne définis pas de sommets, puisque j'utilise la primitive Box. C'est pour faire les barres d'un histogramme en 3D... des barres ont un "z" différent, et pourtant certaines Box qui sont sensées être derrière apparaissent à l'avant et masquent en partie une autre qui est sensée être devant. C'est vraiment bizarre.
Le z, c'est l'axe vertical, hein? Sinon, il n'y a pas assez d'elements (voire un bout de code posant probleme) pour donner une reponse plus avisee. Bon courage.
Ploc
Ah oui, je precise que java3d a un comportement relativement coherent d'un lancement a l'autre. Apres, il peut y'avoir des problemes avec la bibliotheque sous jacente (opengl ou directx). Si c'est sous windows, ca peut etre une bonne d'essayer l'autre. Cela dit, il ne faut pas se faire d'illusion, ce que tu fais (sauf erreur de ma part) fait appel a des parties tres utilisees de java3d et donc un bug de cette nature a de forte chance d'avoir ete deja corrige.
Ah oui, je precise que java3d a un comportement relativement coherent
d'un lancement a l'autre.
Apres, il peut y'avoir des problemes avec la bibliotheque sous jacente
(opengl ou directx). Si c'est sous windows, ca peut etre une bonne
d'essayer l'autre.
Cela dit, il ne faut pas se faire d'illusion, ce que tu fais (sauf
erreur de ma part) fait appel a des parties tres utilisees de java3d et
donc un bug de cette nature a de forte chance d'avoir ete deja corrige.
Ah oui, je precise que java3d a un comportement relativement coherent d'un lancement a l'autre. Apres, il peut y'avoir des problemes avec la bibliotheque sous jacente (opengl ou directx). Si c'est sous windows, ca peut etre une bonne d'essayer l'autre. Cela dit, il ne faut pas se faire d'illusion, ce que tu fais (sauf erreur de ma part) fait appel a des parties tres utilisees de java3d et donc un bug de cette nature a de forte chance d'avoir ete deja corrige.
Cedric.Olmanst
Je suis clairement d'accord, un bug pareil ne serait pas resté bien longtemps, surtout avec Sun et Silicon Grahics qui travaillent dessus.
J'ai trouvé un paragraphe intérressant dans le tutorial de Sun, page 9 sur 40 (numérotée 1-3), dans le pdf j3d_tutorial_ch1.pdf.
"Consequently, the visual attributes of each visual object depend only on its scene graph path. The Java 3D renderer takes advantage of this fact and renders the leaves in the order it determines to be most efficient. The Java 3D programmer normally does not have control over the rendering order of objects²."
Et la note en bas de page :
"²The only control a Java 3D programmer has over the rendering order is with the OrderedGroup class node. This class is not covered in this tutorial. See The Java 3D API Specification for details."
Je pense donc que c'est dans cette direction que je dois aller. Qu'en penses-tu ? Si j'attache mes barres translattées dans un OrderedGroup, ça devrait aller mieux non ?
Quoiqu'il en soit, je vais tenter le coup ce week-end, et je te dirais si ça fonctionne mieux maintenant.
En tout cas, merci d'avoir essayé.
Je suis clairement d'accord, un bug pareil ne serait pas resté bien
longtemps, surtout avec Sun et Silicon Grahics qui travaillent dessus.
J'ai trouvé un paragraphe intérressant dans le tutorial de Sun, page
9 sur 40 (numérotée 1-3), dans le pdf j3d_tutorial_ch1.pdf.
"Consequently, the visual attributes of each visual object depend only
on its scene graph path. The Java 3D renderer takes advantage of this
fact and renders the leaves in the order it determines to be most
efficient. The Java 3D programmer normally does not have control over
the rendering order of objects²."
Et la note en bas de page :
"²The only control a Java 3D programmer has over the rendering order
is with the OrderedGroup class node. This class is not covered in this
tutorial. See The Java 3D API Specification for details."
Je pense donc que c'est dans cette direction que je dois aller. Qu'en
penses-tu ? Si j'attache mes barres translattées dans un OrderedGroup,
ça devrait aller mieux non ?
Quoiqu'il en soit, je vais tenter le coup ce week-end, et je te dirais
si ça fonctionne mieux maintenant.
Je suis clairement d'accord, un bug pareil ne serait pas resté bien longtemps, surtout avec Sun et Silicon Grahics qui travaillent dessus.
J'ai trouvé un paragraphe intérressant dans le tutorial de Sun, page 9 sur 40 (numérotée 1-3), dans le pdf j3d_tutorial_ch1.pdf.
"Consequently, the visual attributes of each visual object depend only on its scene graph path. The Java 3D renderer takes advantage of this fact and renders the leaves in the order it determines to be most efficient. The Java 3D programmer normally does not have control over the rendering order of objects²."
Et la note en bas de page :
"²The only control a Java 3D programmer has over the rendering order is with the OrderedGroup class node. This class is not covered in this tutorial. See The Java 3D API Specification for details."
Je pense donc que c'est dans cette direction que je dois aller. Qu'en penses-tu ? Si j'attache mes barres translattées dans un OrderedGroup, ça devrait aller mieux non ?
Quoiqu'il en soit, je vais tenter le coup ce week-end, et je te dirais si ça fonctionne mieux maintenant.
En tout cas, merci d'avoir essayé.
Cedric.Olmanst
L'axe z, c'est celui qui, dans le repère canonique non modifié, pointe vers l'utilisateur. L'axe vertical dirigé vers le haut, c'est la y.
En fait, tu as fait de la 2D comme tout le monde lors de tes études, où tu avais les axes x (abscisse) et y (ordonnée). Et bien en 3D, ces deux axes restent là, à la même place. On ajoute juste un 3ème axe, z, dirigé vers l'utilisateur.
Voilà...
L'axe z, c'est celui qui, dans le repère canonique non modifié,
pointe vers l'utilisateur. L'axe vertical dirigé vers le haut, c'est
la y.
En fait, tu as fait de la 2D comme tout le monde lors de tes études,
où tu avais les axes x (abscisse) et y (ordonnée). Et bien en 3D, ces
deux axes restent là, à la même place. On ajoute juste un 3ème axe,
z, dirigé vers l'utilisateur.
L'axe z, c'est celui qui, dans le repère canonique non modifié, pointe vers l'utilisateur. L'axe vertical dirigé vers le haut, c'est la y.
En fait, tu as fait de la 2D comme tout le monde lors de tes études, où tu avais les axes x (abscisse) et y (ordonnée). Et bien en 3D, ces deux axes restent là, à la même place. On ajoute juste un 3ème axe, z, dirigé vers l'utilisateur.
Voilà...
Ploc
wrote:
L'axe z, c'est celui qui, dans le repère canonique non modifié, pointe vers l'utilisateur. L'axe vertical dirigé vers le haut, c'est la y.
En fait, tu as fait de la 2D comme tout le monde lors de tes études, où tu avais les axes x (abscisse) et y (ordonnée). Et bien en 3D, ces deux axes restent là, à la même place. On ajoute juste un 3ème axe, z, dirigé vers l'utilisateur.
Merci, je ne demandais pas un cours de 3D, je me debrouille un peu avec. En fait, avec le recul, la position de l'axe n'a pas grande importance. Cela dit juste mon avis, il me semble qu'il vaut mieux considerer un repere comme etant absolu avec des conventions habituelles en 3D: z represente les verticales. Apres, ce n'est qu'une question de position d'oeil et de transformations.
Cedric.Olmanst@gmail.com wrote:
L'axe z, c'est celui qui, dans le repère canonique non modifié,
pointe vers l'utilisateur. L'axe vertical dirigé vers le haut, c'est
la y.
En fait, tu as fait de la 2D comme tout le monde lors de tes études,
où tu avais les axes x (abscisse) et y (ordonnée). Et bien en 3D, ces
deux axes restent là, à la même place. On ajoute juste un 3ème axe,
z, dirigé vers l'utilisateur.
Merci, je ne demandais pas un cours de 3D, je me debrouille un peu avec.
En fait, avec le recul, la position de l'axe n'a pas grande importance.
Cela dit juste mon avis, il me semble qu'il vaut mieux considerer un
repere comme etant absolu avec des conventions habituelles en 3D: z
represente les verticales.
Apres, ce n'est qu'une question de position d'oeil et de transformations.
L'axe z, c'est celui qui, dans le repère canonique non modifié, pointe vers l'utilisateur. L'axe vertical dirigé vers le haut, c'est la y.
En fait, tu as fait de la 2D comme tout le monde lors de tes études, où tu avais les axes x (abscisse) et y (ordonnée). Et bien en 3D, ces deux axes restent là, à la même place. On ajoute juste un 3ème axe, z, dirigé vers l'utilisateur.
Merci, je ne demandais pas un cours de 3D, je me debrouille un peu avec. En fait, avec le recul, la position de l'axe n'a pas grande importance. Cela dit juste mon avis, il me semble qu'il vaut mieux considerer un repere comme etant absolu avec des conventions habituelles en 3D: z represente les verticales. Apres, ce n'est qu'une question de position d'oeil et de transformations.
Ploc
wrote:
Je suis clairement d'accord, un bug pareil ne serait pas resté bien longtemps, surtout avec Sun et Silicon Grahics qui travaillent dessus.
J'ai trouvé un paragraphe intérressant dans le tutorial de Sun, page 9 sur 40 (numérotée 1-3), dans le pdf j3d_tutorial_ch1.pdf.
"Consequently, the visual attributes of each visual object depend only on its scene graph path. The Java 3D renderer takes advantage of this fact and renders the leaves in the order it determines to be most efficient. The Java 3D programmer normally does not have control over the rendering order of objects²."
Et la note en bas de page :
"²The only control a Java 3D programmer has over the rendering order is with the OrderedGroup class node. This class is not covered in this tutorial. See The Java 3D API Specification for details."
Je pense donc que c'est dans cette direction que je dois aller. Qu'en penses-tu ? Si j'attache mes barres translattées dans un OrderedGroup, ça devrait aller mieux non ?
Je ne crois pas que le probleme vienne de la. Si le scenegraph est exactement le meme, les objets les plus proches de l'oeil cacheront ceux se trouvant derriere. Et ce quelques soient les optimisations et l'ordre de trace utilise pas java3D. C'est un principe fondamental des moteurs 3D et depuis 5 ans maintenant, que je n'ai jamais vu transgresse dans java3D.
Quoiqu'il en soit, je vais tenter le coup ce week-end, et je te dirais si ça fonctionne mieux maintenant.
En tout cas, merci d'avoir essayé.
De rien, mais ne remplace un bout de code posant probleme.
Cedric.Olmanst@gmail.com wrote:
Je suis clairement d'accord, un bug pareil ne serait pas resté bien
longtemps, surtout avec Sun et Silicon Grahics qui travaillent dessus.
J'ai trouvé un paragraphe intérressant dans le tutorial de Sun, page
9 sur 40 (numérotée 1-3), dans le pdf j3d_tutorial_ch1.pdf.
"Consequently, the visual attributes of each visual object depend only
on its scene graph path. The Java 3D renderer takes advantage of this
fact and renders the leaves in the order it determines to be most
efficient. The Java 3D programmer normally does not have control over
the rendering order of objects²."
Et la note en bas de page :
"²The only control a Java 3D programmer has over the rendering order
is with the OrderedGroup class node. This class is not covered in this
tutorial. See The Java 3D API Specification for details."
Je pense donc que c'est dans cette direction que je dois aller. Qu'en
penses-tu ? Si j'attache mes barres translattées dans un OrderedGroup,
ça devrait aller mieux non ?
Je ne crois pas que le probleme vienne de la.
Si le scenegraph est exactement le meme, les objets les plus proches de
l'oeil cacheront ceux se trouvant derriere. Et ce quelques soient les
optimisations et l'ordre de trace utilise pas java3D. C'est un principe
fondamental des moteurs 3D et depuis 5 ans maintenant, que je n'ai
jamais vu transgresse dans java3D.
Quoiqu'il en soit, je vais tenter le coup ce week-end, et je te dirais
si ça fonctionne mieux maintenant.
En tout cas, merci d'avoir essayé.
De rien, mais ne remplace un bout de code posant probleme.
Je suis clairement d'accord, un bug pareil ne serait pas resté bien longtemps, surtout avec Sun et Silicon Grahics qui travaillent dessus.
J'ai trouvé un paragraphe intérressant dans le tutorial de Sun, page 9 sur 40 (numérotée 1-3), dans le pdf j3d_tutorial_ch1.pdf.
"Consequently, the visual attributes of each visual object depend only on its scene graph path. The Java 3D renderer takes advantage of this fact and renders the leaves in the order it determines to be most efficient. The Java 3D programmer normally does not have control over the rendering order of objects²."
Et la note en bas de page :
"²The only control a Java 3D programmer has over the rendering order is with the OrderedGroup class node. This class is not covered in this tutorial. See The Java 3D API Specification for details."
Je pense donc que c'est dans cette direction que je dois aller. Qu'en penses-tu ? Si j'attache mes barres translattées dans un OrderedGroup, ça devrait aller mieux non ?
Je ne crois pas que le probleme vienne de la. Si le scenegraph est exactement le meme, les objets les plus proches de l'oeil cacheront ceux se trouvant derriere. Et ce quelques soient les optimisations et l'ordre de trace utilise pas java3D. C'est un principe fondamental des moteurs 3D et depuis 5 ans maintenant, que je n'ai jamais vu transgresse dans java3D.
Quoiqu'il en soit, je vais tenter le coup ce week-end, et je te dirais si ça fonctionne mieux maintenant.
En tout cas, merci d'avoir essayé.
De rien, mais ne remplace un bout de code posant probleme.
Cedric.Olmanst
Ouais, c'est clair que ça devrait être le cas, puisque le DepthBuffer est activé (valeur par défaut) donc y a aucune raison que ça ne marche pas... t'as raison. Je vais poster mon code ce soir, tu verras peut-être directement ce qui ne va pas :)
C'est quand même une galère, de commencer en Java3D, j'ai du mal :) Ca fait quelques jours que j'ai commencé à lire le tuto, et je galère pas mal, mais bon je fais des progrès petit à petit quand même, ça devrait aller d'ici peu de temps (j'espère).
Ouais, c'est clair que ça devrait être le cas, puisque le DepthBuffer
est activé (valeur par défaut) donc y a aucune raison que ça ne
marche pas... t'as raison. Je vais poster mon code ce soir, tu verras
peut-être directement ce qui ne va pas :)
C'est quand même une galère, de commencer en Java3D, j'ai du mal :)
Ca fait quelques jours que j'ai commencé à lire le tuto, et je
galère pas mal, mais bon je fais des progrès petit à petit quand
même, ça devrait aller d'ici peu de temps (j'espère).
Ouais, c'est clair que ça devrait être le cas, puisque le DepthBuffer est activé (valeur par défaut) donc y a aucune raison que ça ne marche pas... t'as raison. Je vais poster mon code ce soir, tu verras peut-être directement ce qui ne va pas :)
C'est quand même une galère, de commencer en Java3D, j'ai du mal :) Ca fait quelques jours que j'ai commencé à lire le tuto, et je galère pas mal, mais bon je fais des progrès petit à petit quand même, ça devrait aller d'ici peu de temps (j'espère).
