Import graph_pi et problèmes avec la 3D

[jmbdeblois]

Non, j'ai windows XP Pro.
Je vais essayer sur un ordi avec la dernière Ubuntu. On verra si ça passe.

[GM]

J'espère que la prochaine version 1.95 améliorera la situation.

Bonne nouvelle sur le forum officiel :

Today I finally booted into MSWindows to investigate these "out of memory" reports.
Inexplicably, the CYGWIN library used to support the MSWindows version of Asymptote
apparently has a default memory limit of 384MB:

http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html

The 1.95 release of Asymptote (coming soon) will disable this limit (this release
will also produce much smaller 3D PDF files).

[OG]

Bonjour

Il y a donc un réel problème de mémoire mais d'une façon générale il faut
bien comprendre la signification du code

Code : Tout sélectionner

surface s=surface(f,(-1.1,-.5),(1.1,.5),95,75,monotonic);

où on créera une surface type carreaux de Bézier avec carreaux.
Selon la régularité, l'existence de forte variations ou non, ce nombre peut être
insuffisant ou vraiment trop grand (par exemple pour .
En théorie cela se comporte mieux et approche mieux que des facettes (des carreaux plats)
de même que pour les fonctions réelles de la variable réelle le spline cubique
par rapport à l'approximation affine.

O.G.

[Francky]

graph_pi étant "loadé" (on peut aussi le mettre dans le répertoire de travail de son fichier principal, si c'est juste pour un test) Pb réglé.

Alors,
c'est là, je crois, l'objet de digressions sur l'intérêt du libre vs le monde privateur, alias linux vs windows.

Si linux est encore à la traine en 3D par rapport à windows, ce qui précède n'étant que LE contre-exemple qui accompagne la règle,
cela pourrait à terme changer grâce notamment au potentiel du code libre, la réactivité des développeurs ...

Un mot sur les deux constructeurs majeurs :
Nvidia : fourni un driver propriétaire efficace pour la 3D, mais ne libère pas le code.
Le driver libre, "nouveau" c'est le nom du dernier, est expérimental pour la 3D.

ATI : fourni quelques driver proprio (en gros, pour les cartes les plus récentes) ET libère le code, ce qui laisse supposer que le
driver libre va devenir le meilleur à terme.

Actuellement sous linux, il vaut mieux avoir nvidia qu'ati, ça "marche" mieux,
mais mon sentiment est que ça peut changer, et que l'esprit ATI est plus tourné vers le libre.
Ce n'est que mon sentiment.
De même, je crois plus en l'avenir de linux en général vs windows ...
C'est aussi un choix éthique.

[GM]

Pb réglé.

On ne savait pas que tu en avais un en rapport avec ce sujet... mais tant mieux.

[jmbdeblois]

Merci, je vais tester des exemples simples. Et puis je ferai la même chose sous Linux, on verra bien. Je n'ai pas non plus besoin d'une grande utilisation des surfaces 3D, mais ça peut servir de savoir faire !

[jmbdeblois]

J'ai testé ceci : (une de surfaces préférées !)

Code : Tout sélectionner

import math;
import graph3;
import palette;

size3(8cm,8cm,IgnoreAspect);
size(8cm,0);

currentprojection=perspective(camera=(7.44,3.35,-1.67));

real f(pair z){
   return cos(z.x)*sin(z.y);
   }

surface s=surface(f,(-3.14,-3.14),(3.14,.3.14),50,50);

draw(s,paleyellow,black,light=Viewport);

ça passe bien effectivement. J'aime bien l'option

monotonic

qui est plus esthétique, mais ça rame un peu plus quand même.
En revanche, de mettre le graph_pi.asy dans le répertoire où est mon fichier asy n'a rien changé au dépassement de mémoire.
Et le double clic droit marche bien !
Je vais donc suivre les évolutions d'Asymptote de prêt.
Merci à tous.

[GM]

Code : Tout sélectionner

surface s=surface(f,(-3.14,-3.14),(3.14,.3.14),50,50);

Un point de trop avant le dernier 3.14 : tu ne visualisais pas ce que tu voulais me semble-t'il.
Utilise pi.

ça passe bien effectivement. J'aime bien l'option

monotonic

qui est plus esthétique, mais ça rame un peu plus quand même.

Essaye aussi cela :

Code : Tout sélectionner

surface s=surface(f,(-pi,-pi),(pi,pi),20,20,Spline);

Tu vas gagner en fluidité et cela sera aussi esthétique.

[jmbdeblois]

j'avais mis pi avec une majuscule (!) et effectivement le . en trop me donnait un avertissement mais fonctionnait avec évidemment un tracé de -pi à 0.3 !!

En revanche l'option Spline est très bien. Même avec une grille 50*50, ça passe, mais finalement par rapport à ta 20*20 ne propose pas beaucoup mieux.

Je n'ai pas lu la doc (oui, shame on me) mais j'ai quand même été surpris par le (-pi,-pi), (pi,pi) qui diffère des logiciels de calculs que j'ai l'habitude d'utiliser. Mais pourquoi pas !
Pour ceux que cela intéresse, j'avais programmé il y a bien longtemps, un logiciel de tracé OpenGL qui s'appelle Multimaths, qu'on peut trouver sur mon site http://www.infiniment.info. Je n'avais rien fait sur l'impression, la flemme.

[GM]

En revanche l'option Spline est très bien. Même avec une grille 50*50, ça passe, mais finalement par rapport à ta 20*20 ne propose pas beaucoup mieux.

C'est pour cela qu'Olivier disait :

Code : Tout sélectionner

ce nombre peut être insuffisant ou vraiment trop grand

En fait cela dépend de ce que tu traces.

Pour le premier exemple que tu donnais... il fallait un nombre suffisant de carreaux pour être "propre" au niveau de la jonction surface/plan et pour la même raison choisir plutôt Monotonic que Spline : c'est un bon exemple pour comprendre une différence entre les deux qui n'est pas évidente à comprendre avec ton second exemple.