[quote="Yakamya"]

Levak a écrit:

Emyl a écrit: Yakamya a écrit: Tu pourrais ainsi passer de l'interpreté au complié, et donc obtenir un gain de temps énome ! Euuh... pas compris ?! Si tu peux utiliser le SDK de Ti en étant agréé par Ti, tu pourras alors compiler ton programme ce qui donnera un programme bien plus rapide qu'un programme interpreté.

Mais... Le SDK est sorti sur nSpire?
Est-il "officiellement" prévu que TI en sorte un?

Hop hop hop...

Traceur de fonctions 3D terminé, car en réalité j'ai du reprendre le code entièrement, bien qu'il marchait, les valeurs d'entrée ne correspondaient pas aux changements que l'utilisateur veut. En plus j'ai changé la syntaxe :

mk_func("Object",3D Function, {xmin, xmax}, {ymin, ymax}, {zmin, zmax}, divisions)

Cependant il faut absolument que je trouve le moyen d'optimiser Make3D !

3 minutes 43 en moyenne pour chacun des rendus :

-1/2(x²+y²) rotation sur X de 70° et de 30°


n'importe quoi avec des racines carré, des divisions et des additions de carré ^^


sin(x).sin(y) ne marche pas terrible du moins pas un truc convenable : 8*sin(x)*sin(y)


Cette fonction correspond à x*y... mais pas à sin(x)*sin(y) qui devrai représenter des bosses et des creux à tout va...

J'ai l'impression que les fonctions cycliques ne marchent pas comme il faut... je ne vois pas le problème... donc je ne peux pas le résoudre "><#

En témoigne la représentation 3D de cos(x²+y²) xD


@+

Après avoir modélisé l'Univers proche (système solaire) plus haut, maintenant Levak nous modélise l'univers lointain, grâce au non moins génial Make3D.

Voici donc des trous noirs:




Levak -> pour ton problème de fonction trigo qui n'oscille pas...

Je pense à un truc mais c'est tellement basique que tu as du déjà vérifier...
Quand mes élèves tracent des graphiques (2D) avec des sinus / cosinus et que ça n'oscille pas comme il faut, je leur dis de vérifier le mode...

Est-ce que ta nSpire ne serait-elle pas passée en mode degré toute seule sans ta permission?
(ou alors peut-être es-tu toi-même passé en degrés pour un éventuel DS de physique d'optique ou mécanique...)
Si c'est le cas, remets-la vite en radians, et colle-lui deux baffes de ma part.


Ta dernière image, c'est quoi?
Le Big Bang?
Levak! Jusqu'où ira-t-il?...

Bon alors les radian ça fait de jolis trucs mais bon... c'est sensé être cos(|x|+|y|) xD

Ouahh LEvak, sublimes tes oeuvres !!!

De toutes façons le truc qui bouffe le plus c'est de devoir stocker chaque points dans une liste de points.
Sans ce problème, donc le fait de pouvoir "afficher" un pixel et de "tracer" une ligne rendrait le truc 10 025 252 996 fois plus simple



xD

Mic doit sûrement regarder que les ratés qui sont beaux, n'est-ce pas ? xD

ça y est j'ai compris mon problème ... il vient du viewer en fait xD

J'avais pas fait gaffe mais tout point qui n'est pas dans le champ de vision du viewer, merde.

En d'autre termes, mon prog suit tellement bien le théorème de Thales qu'il arrive quand même à placer les points dans l'espace, normalement derrières la caméra donc invisibles. En gros il fait une EnvMap pour ceux qui connaissent le terme. ^^

De plus, j'ai également remarqué que mon prog qui trace les fonctions 3D n'est toujours pas convenable. J'aimerais un petit peu d'aide pour reproduire le même principe qu'un traceur de fonctions 2D.

je m'explique :
Actuellement, le traceur 3D demande les dimensions de la grille en x, y et z, la fonction, et le nombre de subdivisions. Jusque là aucun problème. Or un utilisateur qui veut étudier la fonction de -2 à 2 sur x et y ne verra apparaître que les points correspondants à l'intervalle -2;2, et non une contraction normale comme on peu le voir sur les traceur 2D. Pareil pour -10;10 où juste la grille s'étendra et affichera plus de bosses et de creux pour sinx*siny, en gros la courbe aura toujours la même échelle sur tous les axes, quel que soit l'intervalle choisit...

J'aimerais, si possible, que quelqu'un m'explique le principe qu'il faudrait utiliser pour reproduire un traceur 2D natif en 3D (juste un axe de plus)
Actuellement j'utilise deux boucles où j'incrémente X et Y avec comme valeur de départ le minimum de chaque intervalle et comme valeur de fin le maximum de chaque intervalle, logique. L'incrément n'a, je pense, aucun rapport. Au centre de la boucle je calcule bien évidemment gf(x,y).

Zavez compris ? ou il faut que je sorte le code ?

Wow tu es un génie :P