Les matheux sont dans la place - pt=prout

[Apokteino]

Tu veux du Q ?

Une fille en plus ! c'est rare !

La prof de maths.

[Froyok]

Note bien que tout ce dont tu as besoin pour la formule du calcul d'angle que j'ai donné, c'est les distance AB, AC et BC et note aussi que tu connais (puisque c'est toi qui l'impose visiblement) AC puisque c'est le rayon du demi-cercle.

Harf oui, je connais C grâce à la distance minimum que j'impose (distance à laquelle le joueur doit se trouver par rapport au mur), voir même la distance du joueur tout court et la normale, non ?

[Anonyme20240202]

Harf oui, je connais C grâce à la distance minimum que j'impose (distance à laquelle le joueur doit se trouver par rapport au mur), voir même la distance du joueur tout court et la normale, non ?

Ouais ouais t'as tout cqui faut il me semble mais là je vais m'écrouler j'aligne plus deux mots, tu devrais t'en sortir.

[Froyok]

Ouais je pense, enfin faut que je pose ça sur le papier avant. Car la ça reste brouillon (c'est le bordel de dedans ma tête).

Encore merci !

[BoudBoulMan]

Celui du joueur l'est forcément, c'est le mur qu'il faut vérifier. Mais le truc c'est comment déterminer un vecteur qui suit la surface de mon mur sur l'axe z ? Le point de départ par exemple la ou touche mon lancé de rayon

Il faut bien voir qu'un vecteur n'est pas positionné dans l'espace.
Donc, un vecteur parallèle à l'axe z, c'est simplement un vecteur qui n'a de composante non nul qu'en z, donc un vecteur multiple de (0, 0, 1).

Ensuite, si tu veux le placer quelque part, tu dois spécifier son point origine qui lui appartient au mur. Les coordonnées de ce point sont les composantes d'un vecteur qui partirait du l'origine des axes jusqu'à ce point. Disons que ce point est (Xm, Ym, Zm)

Et donc, pour trouver tous les points de la droite que tu cherches (une droite parallèle à z qui appartient au mur), tu fais la somme du vecteur du point du mur (pour te positionner sur le mur) avec un multiple de (0,0,1) (pour te déplacer sur ce mur selon l'axe z).

Et donc, tu obtiens le point (x, y, z) = (Xm, Ym, Zm) + k(0, 0, 1)
Donc x et y sont constants. Et z = Zm + k
où Zm est le point que tu considère (mais tu peux prendre ce que tu veux au final puisque tu y ajoutes k) et k varie de - l'infini à + l'infini (à moins que ton mur soit de hauteur finie, dès lors tu devras limiter les valeurs possibles de z)

Sinon, pour trouver ce point de départ sur le mur. Tu pars des équations de la droite du rayon lancé par le joueur et des équations du plan du mur et tu trouves l'intersection.

Voilà, j'espère que c'était compréhensible.
Faut bien faire la différence entre un vecteur et un segment de points de l'espace.
Un vecteur n'est pas clairement positionné quelque part. Il te faut une équation d'une droite pour ça.

[Vautour]

Tu veux du Q ?

Une fille en plus ! c'est rare !

Vous n'enregistrez pas les questions à la fin de l'exposé ?

[ducon]

Euh mais pourquoi pas?
C'est une suite de nombres réels, dont la limite est 1, qui est un entier.

Je sais, je pinaille, hein.

Je comprends pas ce blocage.
(enfin évidemment, l'assertion "c'est une suite dans Q qui a une limite" serait fausse mais spas le problème)

Je ne refuse pas que la limite soit 1, le nombre entier, je signale qu’il faut faire attention à ce dont on parle. Une suite d’éléments de ℝ ne peut avoir de limite que dans ℝ (car ℝ est complet par définition), si on est très chiant, étant donné que les sous-ensembles de ℝ ne sont en fait que des ensembles injectés, donc en toute rigueur casse-couille, pas dans ℝ.
Là, c’est vrai que le pinaillage ne sert à pas grand chose, mais dans d’autres cas où on a des tas d’ensembles injectés, de quotients ou d’extensions dans tous les sens, il faut faire gaffe à ce qu’on écrit. Il garder en tête, dans un tout petit coin, ce genre de choses.

[mescalin]

Vous n'enregistrez pas les questions à la fin de l'exposé ?

Bah on a demandé aux commanditaires et ils nous ont dit que c'était pas la peine (en gros ils avaient la flemme de faire passer un micro dans les rangs).

[BoudBoulMan]

les sous-ensembles de ℝ ne sont en fait que des ensembles injectés, donc en toute rigueur casse-couille, pas dans ℝ.

Mais comment est-ce possible ?

[Vautour]

Je pense que ducon parle des ensemble numériques habituels, c'est à dire N, Z et Q. Par construction, ce ne sont pas des sous-ensembles de R.

[Froyok]

Il faut bien voir qu'un vecteur n'est pas positionné dans l'espace.
Donc, un vecteur parallèle à l'axe z, c'est simplement un vecteur qui n'a de composante non nul qu'en z, donc un vecteur multiple de (0, 0, 1).

Ensuite, si tu veux le placer quelque part, tu dois spécifier son point origine qui lui appartient au mur. Les coordonnées de ce point sont les composantes d'un vecteur qui partirait du l'origine des axes jusqu'à ce point. Disons que ce point est (Xm, Ym, Zm)

Et donc, pour trouver tous les points de la droite que tu cherches (une droite parallèle à z qui appartient au mur), tu fais la somme du vecteur du point du mur (pour te positionner sur le mur) avec un multiple de (0,0,1) (pour te déplacer sur ce mur selon l'axe z).

Et donc, tu obtiens le point (x, y, z) = (Xm, Ym, Zm) + k(0, 0, 1)
Donc x et y sont constants. Et z = Zm + k
où Zm est le point que tu considère (mais tu peux prendre ce que tu veux au final puisque tu y ajoutes k) et k varie de - l'infini à + l'infini (à moins que ton mur soit de hauteur finie, dès lors tu devras limiter les valeurs possibles de z)

Sinon, pour trouver ce point de départ sur le mur. Tu pars des équations de la droite du rayon lancé par le joueur et des équations du plan du mur et tu trouves l'intersection.

Voilà, j'espère que c'était compréhensible.
Faut bien faire la différence entre un vecteur et un segment de points de l'espace.
Un vecteur n'est pas clairement positionné quelque part. Il te faut une équation d'une droite pour ça.

J'ai rien compris.
Faut que je relise des cours...

Sachant que les vecteurs ça à toujours été un gros charabia pour moi, je suis super paumé la.

[Vautour]

Sachant que les vecteurs ça à toujours été un gros charabia pour moi, je suis super paumé la.

Bah, un vecteur dans ton cas, c'est juste une classe de bipoints équipolents. Je ne vois pas où est le problème.
Bon, si ca ne te convient pas comme définition (incomplète d'ailleurs), tu peux dire que c'est un élément d'un espace vectoriel, qui est par définition un groupe commutatif muni d'une action d'un corps (vérifiant les axiomes classiques). Et un groupe commutatif (G,*), c'est un ensemble G muni d'une opération * associative et commutative, possédant un élément neutre et un inverse. Je ne vois pas ce qui est difficile là-dedans

Ou pour ton cas, plus sérieusement : un vecteur dans l'espace, c'est une flèche de longueur fixée, de direction fixée, que tu peux bouger par translation. Ca peut être défini par 3 coordonnées, qui représentent le déplacement entre les deux extrémités de la flèche.
Un point est aussi donné par 3 coordonnées, mais qui représentent sa position. C'est fondamentalement différent.

[Froyok]

Bah, un vecteur dans ton cas, c'est juste une classe de bipoints équipolents. Je ne vois pas où est le problème.
Bon, si ca ne te convient pas comme définition (incomplète d'ailleurs), tu peux dire que c'est un élément d'un espace vectoriel, qui est par définition un groupe commutatif muni d'une action d'un corps (vérifiant les axiomes classiques). Et un groupe commutatif (G,*), c'est un ensemble G muni d'une opération * associative et commutative, possédant un élément neutre et un inverse. Je ne vois pas ce qui est difficile là-dedans

Ou pour ton cas, plus sérieusement : un vecteur dans l'espace, c'est une flèche de longueur fixée, de direction fixée, que tu peux bouger par translation. Ca peut être défini par 3 coordonnées, qui représentent le déplacement entre les deux extrémités de la flèche.
Un point est aussi donné par 3 coordonnées, mais qui représentent sa position. C'est fondamentalement différent.

Ça oui je comprends, bah alors c'est quoi la normale, j'ai l'impression que je mélange tout.

[BoudBoulMan]

Un vecteur est juste défini par sa longueur, son orientation et son sens. Sa position dans l'espace n'a aucune importance.

Par exemple, 4 points A (0,0,0), B (2,3,4), C (1,6,2) et D (3,9,6)
On pourrait définir les vecteurs AB et CD
On obtient pour AB (2-0, 3-0, 4-0) = (2,3,4)
et pour CD (3-1, 9-6, 6-2) = (2,3,4)

On a bien des segments positionnés à des endroits différents, ils définissent le même vecteur.
Donc la question "mon vecteur fait-il partie du mur?" n'a pas de réponse possible.
Tu peux par contre dire si une droite fait partie d'un mur.

Et une droite peut être définie par un vecteur (pour indiquer son orientation) ET un point (pour la positionner dans l'espace)

En utilisant les bons termes, tu trouveras plus facilement les outils mathématiques qui te permettront de calculer des angles, des intersections, etc.

Pour calculer des angles, tu utilises les vecteurs associés aux droites en utilisant le produit scalaire comme te l'as expliqué Kamikaze.

Pour trouver des intersections, il faut se servir des équations des droites et des plans.

Pour trouver l'équation du lancé de rayon, tu peux te servir du vecteur renvoyé par ta fonction et de la position du joueur.

Par exemple, si la position du joueur est: (a, b, c),
et le vecteur renvoyé est: (d, e, f)

Alors tu peux définir les équations paramétriques de ta droite (où le paramètre ici est le réel k):
x = a + k * d
y = b + k * e
z = c + k * f

Tu remplaces les x,y,z de l'équation de ton plan du mur (que tu devrais avoir, c'est toi qui a positionné ce mur) par les expressions ci-dessus. Et tu trouves la valeur de k.
Tu mets cette valeur dans les équations paramétriques et tu trouves le point d'intersection.

Edit: et la normale à un plan c'est un vecteur perpendiculaire à ce plan
donc il t'indique l'orientation du plan, après à toi de trouver un point de ce plan pour le positionner correctement.

[Froyok]

Un vecteur est juste défini par sa longueur, son orientation et son sens. Sa position dans l'espace n'a aucune importance.[...]

Merci !

Pour trouver l'équation du lancé de rayon, tu peux te servir du vecteur renvoyé par ta fonction et de la position du joueur.

Par exemple, si la position du joueur est: (a, b, c),
et le vecteur renvoyé est: (d, e, f)

Sauf que ma fonction ne renvoit pas de vecteur (enfin si la normal). Tout ce que j'ai c'est un point de départ (le joueur) et le point d'arrivé (donc l'intersection ?) ainsi que la distance entre les deux.

Edit: et la normale à un plan c'est un vecteur perpendiculaire à ce plan
donc il t'indique l'orientation du plan, après à toi de trouver un point de ce plan pour le positionner correctement.

En fait ma fonction trace me renvois le point de collision avec une surface ainsi que la normale à ce point précis. Donc en fait j'ai mon point et mon vecteur ?

[Tramb]

Un point est aussi donné par 3 coordonnées, mais qui représentent sa position. C'est fondamentalement différent.

Fondamentalement différent pour un matheux, mais un codeur, il aime bien les coordonnées cartésiennes, et confondre OM avec M

[BoudBoulMan]

En fait ma fonction trace me renvois le point de collision avec une surface ainsi que la normale à ce point précis. Donc en fait j'ai mon point et mon vecteur ?

Oui, s'il te renvoit le point d'intersection du rayon avec le mur et la normale au mur, t'as toutes les infos

A partir du point d'intersection et du point du joueur, tu calcules le vecteur qui indique l'orientation de la droite qui relie le joueur au point d'intersection.
Avec le produit scalaire entre ce vecteur et la normale, tu peux en déduire l'angle

Faudrat juste faire gaffe aux signes que tu utilises. En fonction de la position de l'angle que tu souhaites (angle entre le rayon et la tangente au mur ou angle entre le rayon et la normale), tu devras utiliser le vecteur dans un sens ou dans l'autre (et donc faire (point du joueur - point d'intersection) ou l'opposé)
Des petits dessins aident bien à pas se tromper à ce niveau-là.

[Tramb]

Et aussi, pourquoi vouloir un angle?
En général tu peux rester en sin et cos, avec des produits scalaires, des produits vectoriels, et des normalisations pour une grande majorité de calculs.
Ca évite de coûteuses fonctions trigonométriques inverses.

Petit rappel fondamental:
dot(u,v) = |u|*|v|*cos(u,v)
|cross(u,v)| = |u|*|v|*sin(u,v)
Avec des vecteurs unitaires (normalisés), c'est fort utile.

Et si t'as vraiment besoin d'angles, bosse en quaternions, pas en angles d'Euler!

[Froyok]

Fondamentalement différent pour un matheux, mais un codeur, il aime bien les coordonnées cartésiennes, et confondre OM avec M

Rien compris.

Oui, s'il te renvoit le point d'intersection du rayon avec le mur et la normale au mur, t'as toutes les infos

A partir du point d'intersection et du point du joueur, tu calcules le vecteur qui indique l'orientation de la droite qui relie le joueur au point d'intersection.
Avec le produit scalaire entre ce vecteur et la normale, tu peux en déduire l'angle

Faudrat juste faire gaffe aux signes que tu utilises. En fonction de la position de l'angle que tu souhaites (angle entre le rayon et la tangente au mur ou angle entre le rayon et la normale), tu devras utiliser le vecteur dans un sens ou dans l'autre (et donc faire (point du joueur - point d'intersection) ou l'opposé)
Des petits dessins aident bien à pas se tromper à ce niveau-là.

Va pour le dessin, je suis paumé la.

Et aussi, pourquoi vouloir un angle?
En général tu peux rester en sin et cos, avec des produits scalaires, des produits vectoriels, et des normalisations pour une grande majorité de calculs.
Ca évite de coûteuses fonctions trigonométriques inverses.

Petit rappel fondamental:
dot(u,v) = |u|*|v|*cos(u,v)
|cross(u,v)| = |u|*|v|*sin(u,v)
Avec des vecteurs unitaires (normalisés), c'est fort utile.

Et si t'as vraiment besoin d'angles, bosse en quaternions, pas en angles d'Euler!

Je parle d'angle car j'y connais rien... Je comprends rien à ta proposition...

[Tramb]

Bah en fait tu veux orienter ton joueur.
Quelle API vas-tu utiliser? Une avec des angles, vraiment?
Ou t'as un SetDirection peut-être?

Pour ma remarque OM = M, ça veut dire que même si ce que dit notre ami charognard est juste, c'est à dire qu'un point n'a rien à voir avec un vecteur, tu peux t'autoriser la confusion en représentant le point par le vecteur entre l'origine de ton monde et le point en question. Et tout n'est que vecteur.

(Ou alors passer en 4 dimensions en coordonnées homogènes avec w=0 pour une translation et w=1 pour une position, en plus c'est SIMD-friendly)

[Froyok]

J'ai ça à ma disposition :
http://wiki.beyondunreal.com/UE3:Obj...ions_%28UT3%29
Ensuite j'ai une fonction setRotation qui permet d'orienter le joueur si je lui envois un vecteur.

Mon jeu travaille en radians. (Un peu bizarres d'ailleurs... )

[Møgluglu]

Pour ma remarque OM = M, ça veut dire que même si ce que dit notre ami charognard est juste, c'est à dire qu'un point n'a rien à voir avec un vecteur, tu peux t'autoriser la confusion en représentant le point par le vecteur entre l'origine de ton monde et le point en question. Et tout n'est que vecteur.

[hs]
Dans l'idéal, il serait plus propre d'avoir 2 types différents pour les vecteurs et les coordonnées de points.
D'une part parce que certaines opérations genre additionner 2 points n'ont pas de sens, donc ça permet de renforcer le typage (on distingue bien les pointeurs et les entiers après tout).

D'autre part parce qu'il n'y a rien qui dit que les formats numériques employés sont les mêmes. Les coordonnées cartésiennes dans le monde 3D pourraient par exemple être en virgule fixe (on veut minimiser l'erreur absolue, pas l'erreur relative par rapport à l'origine), alors que les vecteurs sont bien en virgule flottante.
Ou on pourrait avoir besoin de double précision dans les coordonnées mais se contenter de simple précision pour les vecteurs.

Aujourd'hui les programmeurs emploient du flottant simple précision pour tout, mais c'est juste parce que vous êtes des feignasses
(et aussi parce qu'on a plein d'unités qui calculent dans ce format dans les CPU et les GPU...)
Mais ça pourrait (et devrait) changer un jour.
[/hs]

[Tramb]

Ouais on est des feignasses, mais on a aussi des bonnes excuses:
Les SIMD courants calculent deux double en même temps contre quatre float.
La mémoire et la bande passante sont extrêmement limitées sur consoles.
Du coup, pour les problèmes de précision, il vaut mieux les gérer autrement qu'utiliser le double, genre adresser des sous domaines en float ou en fixed point, etc... mais on essaye (en tout cas chez nous) toujours de se ramener à du calcul flottant bien dans le range qui va bien.

Pour la propreté, dans R4, c'est nickel
pos = (px,py,pz,1)
xlate = (tx,ty,tz,0)
(pos+xlate).w = 1 donc une position
(xlate1+xlate2).w = 0 donc une translation
(pos1+pos2).w = 2 donc une connerie

[Froyok]

J'ai mal à la tête...

[BoudBoulMan]

Va pour le dessin, je suis paumé la.

Déjà, si on a deux vecteur A et B, séparé d'un angle θ comme indiqué ici:

Le produit scalaire vaut |A| . |B| . cos(θ)
et correspond à la somme des produits de chaque composante, c'est-à-dire que si A c'est (Ax, Ay, Az) et B c'est (Bx, By, Bz), alors le produit scalaire vaut: Ax*Bx + Ay*By +Az*Bz
(ceci n'est pas une propriété générale des produits scalaires mais ça s'applique dans ce cas-ci où les axes x, y et z sont orthogonaux entre eux)

Et donc, connaissant les composantes de A et B, tu peux en déduire l'angle entre eux.

Donc, si on applique ça à ton problème:


Si je comprend bien, grâce à ta fonction, tu peux récupérer les points A et B (désolé d'utiliser les mêmes lettres qu'au-dessus ) et le vecteur n.
Tu veux calculer l'angle θ.
Cette angle sépare les vecteurs n et AB ( cad. de A vers B ), on peut donc le calculer à partir du produit scalaire entre n et AB.

On obtient:
cos(θ) = ( n.AB ) / ( |n| . |AB| )
où le produits scalaire (n . AB ) est calculé en faisant la somme des produits des composantes.

Disons que la zone dans laquelle tu considères que le joueur est de face va de -30° à 30° (on obtiens alors une zone de 60° centrée sur la normale)
Le cosinus vaut sqrt(3)/2 à 30° et prend des valeurs supérieures pour un angle plus petit que 30°.
Donc, ton joueur se trouve face au mur si cos(θ)>sqrt(3)/2
et donc si ( n.AB ) / ( |n| . |AB| ) > sqrt(3)/2

[Møgluglu]

Ouais on est des feignasses, mais on a aussi des bonnes excuses:
Les SIMD courants calculent deux double en même temps contre quatre float.
La mémoire et la bande passante sont extrêmement limitées sur consoles.
Du coup, pour les problèmes de précision, il vaut mieux les gérer autrement qu'utiliser le double, genre adresser des sous domaines en float ou en fixed point, etc... mais on essaye (en tout cas chez nous) toujours de se ramener à du calcul flottant bien dans le range qui va bien.

Oui, on est d'accord en fait. Pour les calculs il n'y a pas trop d'intérêt à multiplier les formats au-delà de simple, double et les formats entiers. Par contre pour gagner en bande passante mémoire on a un choix beaucoup plus large, entre FP16, les formats à exposant partagé et autres formats compressés. D'autant plus si la conversion est gérée en matériel.

Donce je retire ce que j'ai dit, vous n'êtes pas autant des feignasses que les programmeurs de HPC qui codent tout en double.

Pour décider de quelle précision est suffisante, vous faites comment? Empiriquement en testant et en diminuant tant que l'image produite reste correcte? Par expérience et estimations de bon sens? Par calculs?

Pour la propreté, dans R4, c'est nickel
pos = (px,py,pz,1)
xlate = (tx,ty,tz,0)
(pos+xlate).w = 1 donc une position
(xlate1+xlate2).w = 0 donc une translation
(pos1+pos2).w = 2 donc une connerie

Mais c'est qu'en plus ça marche.
Mais même avec la 4e composante "gratuite", ça fait toujours cher pour quelque chose qu'on pourrait faire vérifier statiquement par le compilo avec un peu de surcharge d'opérateurs.

[Tramb]

Pour décider de quelle précision est suffisante, vous faites comment? Empiriquement en testant et en diminuant tant que l'image produite reste correcte? Par expérience et estimations de bon sens? Par calculs?

Ca dépend des gens, en général, c'est empirique dans la majorité des cas, sauf pour les trucs vraiment fondamentaux genre l'échelle du jeu. Si ça passe pas, on réfléchit. Si ça passe, on se demande jusqu'où on peut dégrader pour optimiser (et on dégrade encore de 20% de trop )

Mais c'est qu'en plus ça marche.
Mais même avec la 4e composante "gratuite", ça fait toujours cher pour quelque chose qu'on pourrait faire vérifier statiquement par le compilo avec un peu de surcharge d'opérateurs.

Bah, disons que si tu passes une position dans une matrice de projection, tu te retrouves avec des w qui ne sont ni 0 ni 1, donc ça compliquerait encore le système de typage.
Dans la naïveté de ma jeunesse, j'avais tenté un truc du genre mais ça pose trop de problèmes.
Exemple, la fonction qui renvoie le ième axe d'une matrice 4x4 renvoie quoi?
l0,l1,l2 sont des directions, et l3 une position, pour une matrice de changement de repère classique.
Mais si c'est une matrice de projection, ce n'est plus le cas.

Bref, on a préféré relâcher le typage et checker au runtime plutôt que devenir (encore plus) fous.
Ceci dit ça aurait du sens d'exposer ça à des non-programmeurs dans les langages de script, parcequ'ils font rarement des trucs funky, et qu'ils pourraient toujours revenir aux types racines.

[Dr.Kant]

Tu veux du Q ?

Une fille en plus ! c'est rare !

J'ai tenu 30 minutes, mais ca reste compréhensible pour des gens qui ont font des fausses math. J'ai trouvé ca moins fnu que l'exposé sur le transport et l'autre sur la méca quand même.

En tout cas merci, en plus c'est fort bien filmé et monté.

[MrBeaner]

Yep, bonne idée ce topic!

Une bière à qui me guide dans ma recherche à démontrer mathématiquement que de l'identique ne peut naître l'altérité. C'est pour une réflexion philosophique. Mais j'aimerais bien pouvoir démontrer ça en langage mathématique.

Merci d'avance.

[Vautour]

Si tu es capable de poser ta question plus mathématiquement, je pourrai tenter de répondre ...