Maxscript orientar objeto a normal de un vértice

[Leandro Salerno]

Hola qué tal, estoy trabajando en un script que estoy necesitando, en principio para linkear un objeto a un vértice de una malla.

Utilizando DependsOn en un script controller en position transform.

.
DependsOn $box01.

Polyop, getvert $box01 1.
).

Funciona perfecto.

Ahora el segundo paso es conseguir que este objeto este orientado a la normal de este vértice seleccionado, pero no lo consigo.

Se puede extraer la normal del vértice con getnormal pero tengo dos problemas.
-el primero es que getnormal funciona con editable_mesh y no con editable_poly.
- y el segundo problema es que tengo conflictos con Euler vs Quaternions, intente convertirlos, pero no tuve éxito.

La idea es que este objeto que ahora está enlazando al vértice seleccionado, pueda rotar en función de la orientación de este vértice o el objeto del que depende.

Se les ocurre alguna idea para poder resolver esta cuestión?
Muchas gracias por adelantado. Saludos.

[Cesar Saez]

Utilizando DependsOn en un script controller en position transform funciona perfecto.

Yo te recomendaría (si trabajas con un max superior a la versión que averigües sobre los nodos porque entre otras cosas te permitirán independencia de nombres en el script.

-el primero es que getnormal funciona con editable_mesh y no con editable_poly.

Puedes acceder a la trimesh en lugar del nodo agregando un, Mesh, de esta forma debería funcionar también con editable poly.

Ejemplo:
Getnormal $.Mesh 6 -retorna el Vector normal del vértice 6 en el objeto seleccionado.

- y el segundo problema es que tengo conflictos con Euler vs Quaternions, intente convertirlos, pero no tuve éxito.

Lo que pasa es que getnormal te retorna el Vector de la normal del vértice, pero no directamente el ángulo. Yo en tu lugar reconstruiría directamente toda la matriz de transformación, seguramente este tutorial te sirva mucho para hacerte una mejor idea de cómo funciona el tema. Saludos.

[Leandro Salerno]

Bien getnormal $.Mesh funciona perfecto, ya no hay problemas entre editable poly y editable Mesh. Con respecto a la orientación, sigo sin poder solucionarlo.

Ahora comprendo que getnormal devuelve el Vector y no el ángulo, por lo tanto no se puede tan sencillamente.

Entonces lo que hay que hacer con el Vector que devuelve getnormal es calcular el ángulo para poder asignarlo al objeto.

Aquí está el problema, leí la explicación varias veces, hice algunas cuantas pruebas, pero sigo sin comprenderlo del todo.

Hice un intento de reconstruir la matrix3 algo, así como.

DependsOn $box01.

Pos= polyop, getvert $box01 1.

Rot=getnormal $box01.Mesh 1.

Matrix3 [1,0,0] [0,1,0] [0,0,1] pos).

Pero no hay caso, lógicamente me falta calcular el ángulo. Gracias por todo cesar.

[Cesar Saez]

Aunque tuvieras la normal te hace falta un Vector que te indique la tangente y luego mediante un producto cruz de las matrices sacar un tercer Vector perpendicular a los anteriores para generar los 3 vectores necesarios en tu matriz de transformación, 3d implica 3 ejes.

Leete el tutorial que te mencionaba en el mensaje anterior que te va a ayudar mucho a entender qué es y cómo funcionan las matrices de transformación, a mí me fue muy útil.

[Leandro Salerno]

Como te comentaba leí el tutorial varias veces y creo comprender que son las matrices de transformación, pero según me decís, para conseguir la orientación hay que realizar varios cálculos matemáticos con ciertas fórmulas que por ahora desconozco.

Supongo que, de alguna manera lo resolveré. Gracias por todo. Saludos.

[Leandro Salerno]

Bueno luego de leer bastante llegue a un resultado que funciona parcialmente bien. Primero en lugar de intentar alinear a un vértice, lo hago con una cara.

Por ejemplo, un scriptcontroller en transform, para la cara 76 de la sphere02.

DependsOn $sphere02.

Pos= polyop, getfacecenter $sphere02 76.

Norm = (polyop, getfacenormal $sphere02 76).
Worldupvector = [0,0,1].

Rightvector = normalize(cross worldupvector Norm).

Upvector = normalize(cross RightVector Norm).

Matrix3 RightVector upvector Norm pos).

El objeto queda alineado a la normal y rota también, a primera vista perfecto, pero en determinadas circunstancias el objeto alineado rota en un eje.

Estoy cerca, pero falta.

[Cesar Saez]

Ahora sí, el código tiene mucho más sentido. Yo creo que el problema es que tomas como base para calcular la matriz un worldupvector que no viene a nada, simplemente es un Vector que apunta hacia arriba, pero no tiene relación con la orientación del componente en particular al que quieres pegarle el helper. Yo cuando hice un script parecido en lugar de usar un worldupvector usé un Vector entre el componente seleccionado y su vecino (en el fondo la tangente de la superficie), de esta forma puedes calcular los 3 vectores y siempre tendrán relación con la orientación del componente. Saludos.

[Leandro Salerno]

Pero la tangente de la superficie no sería el RightVector? ¿Y el RightVector no lo tengo que calcular con el worldupvector?
No comprendo bien.

Probé usando:

worldupvector = normalize (cross pues Norm)

Funciona perfecto cuando el objeto lo muevo o roto, pero si lo que se mueven son los vértices, o uso algún modificador, nuevamente aparecen errores en la rotación local del point pegado, obviamente tampoco es la solución.

Creo que ya se me está escapando el tema. Saludos.

[Cesar Saez]

Pero la tangente de la superficie no sería el RightVector? ¿Y el RightVector no lo tengo que calcular con el worldupvector?
No comprendo bien.

Me preguntas por el nombre de la variable o lo que realmente estas calculando? Si es por el nombre de tus variables tiene sentido que la tangente a la superficie se llame RightVector.

Yo a lo que me refería antes es que con esa solución cuando gires la esfera el dummie no va a quedar fijo ya que depende de un Vector inventado que simplemente apunta hacia arriba del mundo, haz la prueba y gira tu esfera hacia abajo (verás cómo mientras la giras la esfera va cambiando la rotación en z de tu dummie). Es lo mismo que cuando usas un constraint y tienes que establecer tu propio upnode (o upvector o cómo se llame en max). Yo te recomendaría que en lugar de usar un Vector inventado apuntando hacia arriba del mundo uses un Vector que apunte hacia el polígono/componente vecino.

Probé usando:

worldupvector = normalize(cross pues Norm)

No quiero parecer rudo, pero ¿sabes que estás haciendo exactamente con esa línea? Estas normalizando el producto cruz entre el Vector de la normal y la posición. Es un poco como mezclar peras con manzanas.

[Leandro Salerno]

No te preocupes, eso no es ser rudo, no me molesta mezclar peras con manzanas o bananas, equivocarse y seguir equivocándose hace que se encuentre el camino y se aprenda, así que, no pasa nada, saludos y gracias por tu tiempo.

[Leandro Salerno]

Bueno seguramente me siga equivocando, pero ahora llegue a esto. Aparentemente lo veo funcionar muy bien, pero no sé si me estoy engañando.

DependsOn $teapot01.

Pos= polyop, getfacecenter $teapot01 858.

Pos2= polyop, getfacecenter $teapot01 844.

Norm = (polyop, getfacenormal $teapot01 85.
Worldupvector = pues - pos2.

Rightvector = normalize(cross worldupvector Norm).

Upvector = normalize(cross RightVector Norm).

Matrix3 RightVector upvector Norm pos.
)

César gracias por tu orientación, comentarios y tu tiempo, me hiciste pensar mucho, abrazo grande.

[Cesar Saez]

Está muy bien. Lo único que creo te faltaría es normalizar el Vector entre los 2 componentes, procurar de hacer locales tus variables para evitar problemas de evaluación cuando tengas varios objetos con el script de forma simultánea y en lugar de usar directamente el $teapot01 usar un nodo que te permitirá no amarrarte a nombres y va a evaluar un poco más rápido.

-- forma de calcular el Vector normalizado entre 2 puntos.
- y guardarlo en una variable local:
Local worldupvector = (pues - pos2)/length(pues - pos2)

Por hola estas usando max 8? Si es así probablemente el script no te tomara los modificadores sobre el editable poly (en versiones posteriores funciona bien), si quieres hacerlo más compatible yo te recomendaría seguir el mismo criterio que llevas hasta ahora, pero usando comandos que funcionen sobre trimesh (como el primer mensaje), el concepto es exactamente el mismo. Casi lo tienes.

Felicidades.

[Leandro Salerno]

Excelente. Si estoy con la versión 2009 así que, no hay problema. Es cierto, tengo pendiente el tema de los nodos, pero tengo que leer un poco sobre ese tema, no lo tengo muy claro todavía, lo importante ahora es que en principio el código funciona genial.

Por lo que estuve probando también, surge un pequeño problema y es que, si a la geometría le sumas un modificador como el MeshSmooth o un TurboSmooth el orden de las caras cambia, entonces el dummie cambia de posición.

Pero bueno por ahora esto me sirve, hasta que tenga que poner un TurboSmooth. Gracias.