Empiler des surfaces

Pour toute demande d'aide sur des exemples non finalisés, c'est ici.
Les exemples aboutis et intéressants seront ajoutés aux sous-forums qui suivent.

Règles du forum
Pour toute demande d'aide pour la conception (ou la confirmation d'un code) d'une figure Asymptote, c'est ici.

J'invite ceux qui ont régulièrement des questions à poser à aller dans leur panneau de l'utilisateur pour indiquer dans la signature de leurs messages :

  1. Nom du système d'exploitation (W7 ou Ubuntu 12.04 ou ...)
  2. Version d'Asymptote et éditeur utilisé pour les figures Asymptote
  3. Distribution LaTeX et éditeur utilisé pour les tex.


On va gagner du temps dans les réponses !
mumblee
Messages : 38
Enregistré le : jeu. 11 mars 2010, 10:29
Localisation : Lille

Re: Empiler des surfaces

Message non lu par mumblee » lun. 15 mars 2010, 21:35

OG a écrit :Je ne sais pas si la complexité du deferred est préférable à prendre Z=0.0001.

Il faut que je regarde vos solutions en détails pour les comprendre, mais il ne me semble pas que ça réponde à la question de départ : "espacer" deux surfaces d'un pixel. amha ça pourrait être utile dans d'autres situations non ?

Sinon le gain est vraiment appréciable entre la superposition de deux carrés
par rapport à la construction initiale (couronne carrée + carré) évidemment en
stockant la face de base créée par surface(.) et en translatant, tournant pour
construire ton cube ?

Pas possible : les couleurs sont différentes d'une face à l'autre, et je trace les faces "à la demande". Le mieux ce serait que je dépose les sources ici. Elles sont presque présentables, de mon point de vue, mais je suppose que vous aurez plein d'améliorations à proposer !
Pour le gain, de temps de compilation,je ne sais pas comment le mesurer, à part avec un time. Mais avec mon "vieux" portable Dell et sa carte intel945GM, l'openGL n'est pas top, et moins il y a de sommets pour définir un chemin à tracer plus c'est maniable dans la fenêtre de visualisation en 3D.

a+
Fabrice Eudes

OG
V.I.P.
V.I.P.
Messages : 142
Enregistré le : dim. 7 mars 2010, 22:27

Re: Empiler des surfaces

Message non lu par OG » lun. 15 mars 2010, 21:48

Je ne sais pas si "décalage de 1 pixel" est possible.
Pour la 3D je ne sais pas si une surface possède une épaisseur.
Et en vectoriel décaler d'un pixel me paraît bizarre.

O.G.

mumblee
Messages : 38
Enregistré le : jeu. 11 mars 2010, 10:29
Localisation : Lille

Re: Empiler des surfaces

Message non lu par mumblee » lun. 15 mars 2010, 21:59

Bon, le code en l'état actuel avec un fichier exemple. Il reste à ajouter des paramètres (pos, alpha, beta, gamma) pour positionner le cube et le faire pivoter (@Gaëtan : un peu comme l'exemple que tu avais posté sur mathematex).
Je ne sais pas si je vais encore travailler dessus tout de suite, mais je suis quand même preneur de vos remarques :)
Fichiers joints
Rubik.zip
module (en devenir, mais commenté) et exemple d'utilisation.
(3.05 Kio) Téléchargé 184 fois
Fabrice Eudes

mumblee
Messages : 38
Enregistré le : jeu. 11 mars 2010, 10:29
Localisation : Lille

Re: Empiler des surfaces

Message non lu par mumblee » lun. 15 mars 2010, 22:05

OG a écrit :Je ne sais pas si "décalage de 1 pixel" est possible.
Pour la 3D je ne sais pas si une surface possède une épaisseur.
Et en vectoriel décaler d'un pixel me paraît bizarre.

Bon, tant pis alors. Le passage dans la doc qui m'a fait me demander si c'était envisageable est le suivant, dans Base modules/three/tube (p129 ?)
The setting thick=false can be used to disable this feature and force all lines to be
drawn with linewidth(0) (one pixel wide, regardless of the resolution). By default, mesh
and contour lines in three-dimensions are always drawn thin, unless an explicit line width
is given in the pen parameter or the setting thin is set to false. The pens thin() and
thick() defined in plain pens.asy can also be used to override these defaults for specific
draw commands.

Mais bon, j'ai peut-être pris mes désirs pour la réalité...
Fabrice Eudes

Avatar du membre
GM
Administrateur du site
Administrateur du site
Messages : 1419
Enregistré le : dim. 7 mars 2010, 14:50

Re: Empiler des surfaces

Message non lu par GM » mar. 16 mars 2010, 01:00

OG a écrit :Et en vectoriel décaler d'un pixel me paraît bizarre.

A moi aussi : car qu'est ce qu'il devient le pixel si tu zoomes (dans un sens ou l'autre) via opengl. :mrgreen:
Tu peux zoomer sur un plan : son épaisseur ne va pas augmenter.
Index des fonctions - Exemple de lien donnant le résultat d'une recherche sur les mots 'arc' et 'triple' : http://asy.marris.fr/indexasy/?filtre=arc triple
Mes configurations (le 31/03/19) :
PC n°1 :Windows 10 - Asymptote(2.59)+MikTeX2.9 - Editeurs : Notepad++, TeXworks, Visual Studio Code.
Mes autres PC : Ubuntu 18.04LTS - Asymptote(2.52-?? git) + TexLive2018
Mon serveur : Debian Jessie - Asymptote(2.52-1 git) + TexLive2018
Merci de préciser la votre !

mumblee
Messages : 38
Enregistré le : jeu. 11 mars 2010, 10:29
Localisation : Lille

Re: Empiler des surfaces

Message non lu par mumblee » mar. 16 mars 2010, 09:14

GM a écrit :
OG a écrit :Et en vectoriel décaler d'un pixel me paraît bizarre.

A moi aussi

À John Bowman aussi (1 pixel ?) :)

Bon, j'essaie de reformuler autrement : si je dessine un petit carré au même endroit qu'un carré plus grand, que se passe-t-il ?
En 2D, cela dépend de l'ordre des commandes:

Code : Tout sélectionner

unitsize(1cm);

fill(scale(0.5)*unitsquare,blue);
fill(unitsquare,red);

fill(shift(2,0)*unitsquare,red);
fill(shift(2,0)*scale(0.5)*unitsquare,blue);

En 3D, OpenGL ne sait pas quel carré afficher, ça clignote constamment. C'est un peu normal : avec deux surfaces d'épaisseur zéro, laquelle prend le pas sur l'autre ?...

Code : Tout sélectionner

import three;
currentlight=nolight;
unitsize(1cm);

draw(surface(scale3(0.5)*unitsquare3),blue);
draw(surface(unitsquare3),red);

draw(shift(2,0,0)*surface(unitsquare3),red);
draw(shift(2,0,0)*surface(scale3(0.5)*unitsquare3),blue);

En fait, je ne sais pas si asymptote peu y faire quoi que ce soit, c'est peut-être la faute d'OpenGL ? Mais ce serait agréable de pouvoir déclarer quelque chose comme : « la surface n°2 est de tel côté de la surface n°1 », un genre de système de calques.

John a dit qu'il va ajouter le fait de pouvoir avoir des couleurs différentes pour les deux côtés d'une surface mais, même si c'est intéressant, le problème que j'évoque restera : le clignotement restera visible d'un côté sur les deux.

J'espère avoir été plus clair.

De toute façon, pour mes cubes, je me débrouillerais autrement :)
Fabrice Eudes

Répondre