Script en 3ds Max

[Andres3d]

Hola que interesante Halfvector, yo estoy probando un método como el de smile de bullet impact system, pero con Particle Flow, ya por lo menos conseguí un método con script operator como deformar la malla para los impactos, lo de la sangre también se puede con un Particle Flow con Spawn test.

Bueno: yo sé que lo que se quiere aquí es crear un script o más bien una herramienta como la de smile, pero eso requiere de mucho conocimiento de la materia, pero ánimo yo por mi parte segiere probando con Particle Flow, hasta que quede algo decente, ok saludos.

Posdata: hola smile, te quería comentar que yo quede muy interesado con la creación de la herramienta que mencionaste de romper objetos por medio de un bitmap, ya por lo menos tengo dos script uno que es el típico script que rompe en pedazos los objetos polys y otro que crea desplazamientso por medio de un bitmap blanco y oscuro, solo quería saber dónde puedo encontrar más ayuda pues ya e postedado en otro sitios y no, y ya me estoy leyendo la ayuda de Maxscript que es bastante, ok saludos de nuevo.

[slime]

[]. Pero bueno, no tengo demasiados conocimientos en estos temas.

Pues menos mal, porque lo has dicho prácticamente todo. Lo único que hay que tener en cuenta es cuando se tienen varios objetos en la escena que están en la trayectoria del arma. Yo hice un loop pasando por todos los objetos, detectando intersección con un rayo y midiendo las distancias. El objeto que intersecte cuya distancia es la mínima es el que hay que cargarse.

Y respecto a los deflectores, tal vez sea mejor que ponga un control para seleccionar los objetos sobre los que cae la sangre por aquello de que optimice quien quiera. A ver lo que puedo hacer.

Mucho mejor porque si no va a ser super lento. En cualquier caso, los deflectores de 3ds Max son malísimos y muchas opciones no están soportadas con Maxscript.

Algo interesante para ir montando el sistema es empezar, por ejemplo, detectando cuando hay colisión del rayo, puedes pintar el objeto dependiendo de si existe o no. Luego ir más, allá generando algo en el punto de impacto y luego ya hacerlo con múltiples objetos. Suerte y ánimo. Sigue ensenando progresos.

Posdata: hola smile, te quería comentar que yo quede muy interesado con la creación de la herramienta que mencionaste de romper objetos por medio de un bitmap.

Hola andros. No he mirado nada sobre eso, pero pensándolo bien, no sé si sería posible hacerlo de manera sencilla con Maxscript, sería más interesante compilar una herramienta usando el SDK.

[HalfVector]

Yo hice un loop pasando por todos los objetos, detectando intersección con un rayo y midiendo las distancias. El objeto que intersecte cuya distancia es la mínima es el que hay que cargarse.

Exacto. Es justamente la función que he puesto en mí anterior mensaje. Recorre todos los objetos de la escena (en este caso sería solo objetos que seleccionara el usuario) y detecta la colisión con el más cercano.

Pero hay algo que me llama la atención en el sistema que creaste y es que la teselación es bastante limpia. Pero esto sólo he podido ver en polymeshes y no en trimeshes:


Y teniendo en cuenta que intersectrayex te devuelve el índice del triángulo (y no del polígono, ya que funciona sólo con edit_mesh) en el que se produce la intersección, es de suponer que la teselación hay que llevarla a cabo sobre un edit_mesh y no un edit_poly. En ese caso sólo se me ocurre crear una función propia para detectar la colisión con polígonos en vez de triángulos. O eso o es que se me escapa algo.

Aunque ahora que lo veo con más calma, parece más un MeshSmooth. ¿es posible?:


En fin, espero que no le importe a Bea que me haya ido un poco por las ramas, aunque lo cierto es que esto le puede venir bien para potenciar aún más su sistema. Gracias.

-- IMÁGENES ADJUNTAS --

[slime]

El tema de la subdivisión fue el más complicado porque el max se colgaba al seleccionar zonas de geometría en cadena (¿) y hubo que encontrar un hack para que la cosa funcionase. Ahora no me acuerdo de cómo lo hice, pero casi estoy seguro que hacia varias pasadas para recoger información, porque después de subdividir el cálculo de colisiones y el trazado de rayos podía ser muy lento.

Creo que era algo así:
A) detección de puntos de colisión en todo el rango, generación de sistemas de partículas y parámetros.

B) subdivisión y atacheo de deformadores en geometría.

El código no me lo lleve de blur. A ver si me hago una copia para el recuerdo.

[HalfVector]

Ahora no me acuerdo de cómo lo hice, pero casi estoy seguro que hacia varias pasadas para recoger información, porque después de subdividir el cálculo de colisiones y el trazado de rayos podía ser muy lento.

Pues sí, tienes razón, teselar antes de calcular los puntos de intersección haría que todo fuera más lento. Así que efectivamente lo mejor es hacer el proceso en varias pasadas.

Incluso se me ocurre que una de las pasadas (después de haber creado las partículas) podría consistir en calcular los objetos que hay dentro del radio de acción de las salpicaduras de sangre. Sería cuestión de calcular el bbox del sistema en el punto de máximo alcance de las partículas y entonces llevar a cabo una comprobación bbox vs bbox con los objetos de la escena. De esta forma la elección de los deflectores sería automática. No sé, habría que pensar mejor eso. Saludos.

[Birkov]

Este mensaje para adheridos ya que se está poniendo la mar de interesante, vosotros seguid disertando que yo escucho atentamente.

[slime]

Sería cuestión de calcular el bbox del sistema en el punto de máximo alcance de las partículas y entonces llevar a cabo una comprobación bbox vs bbox con los objetos de la escena. De esta forma la elección de los deflectores sería automática. No sé, habría que pensar mejor eso.

Muy buena idea, lo único que se necesitaría ahora es la posibilidad de asignar geometría a deflectores con Maxscript. En la versión 7 no se podía. Si cargas el código de los deflectores, es del año de la pera.

[HalfVector]

Muy buena idea. Lo único que se necesitaría ahora es la posibilidad de asignar geometría a deflectores con Maxscript. En la versión 7 no se podía. Si cargas el código de los deflectores, es del año de la pera.

Sí, me acuerdo que una vez me mencionaste ese problema cuando discutiamos sobre los puntos flacos de Maxscript. Pues va a ser que con 3ds Max 8 sigue sin poderse.

saludos.

-- IMÁGENES ADJUNTAS --

[HalfVector]

Bueno, pues como decía Slime y confirma la referencia de Maxscript, no se puede asociar un objeto a un deflector a través de Maxscript.

Evidentemente esto es del todo inaceptable y me imagino que, por ejemplo, Bea lo necesitara si decide meter deflectores para que la sangre colisione con los objetos.

Así que sólo se me ha ocurrido una solución para este problema, y es programar unas extensiones para Maxscript a través de C++, utilizando el SDK.

Pues nada, dicho y hecho. He creado un gup (global utility plug-in) que implementa dos métodos. Uno para recoger el objeto asociado a un udeflector y otro para asociar un objeto al udeflector.

Pongo un ejemplo.

Si tenemos un udeflector llamado udeflector01 y una esfera llamada sphere01 y queremos que la esfera esté asociada al deflector, lo que tenemos que hacer es escribir:

udeflectorhelper, setnode $udeflector01 $sphere01

Este método devuelve true si el objeto se asignó correctamente. De lo contrario devolverá false.

Por otra parte, si lo que queremos es recoger el objeto asociado al deflector udeflector01, escribimos:

udeflectorhelper, getnode $udeflector01

Este método devuelve un nodo que apunta al objeto asociado con el deflector. Si el deflector no tiene ningún objeto asociado, devuelve undefined.

Para instalar el plugin no hay más que copiar el archivo udeflectorhelper, gup al directorio de plugins de 3ds Max. descargar udeflectorhelper.

El plugin lo he compilado para 3dsMax 8 pero me imagino que si hiciera falta podría compilarlo para max 7. Saludos.

-- IMÁGENES ADJUNTAS --

[bealobo]

Bueno, yo iré poco a poco y por partes, porque, aunque se algo de programación acabo de empezar con el script de 3ds Max. De momento lo de la geometría me parece complicado. Así que lo primero que haré será lo de los rayos, los impactos y el sangrado. Veremos cómo me va.

Os lo estáis trabajando un montón, me ayudan mucho estas conversaciones. Gracias.

[HalfVector]

De momento lo de la geometría me parece complicado. Así que lo primero que haré será lo de los rayos, los impactos y el sangrado. Veremos cómo me va.

Si, lo mejor en estos casos es ir muy poco a poco. Incluso si es necesario, crear pequeños tests al margen de la aplicación principal. De esta forma te será más fácil aislar los problemas que te puedas encontrar. Sobre todo, teniendo en cuenta que la depuración es uno de los puntos flacos de Maxscript (a pesar de que pusieron un debugger con la versión . Saludos.

[slime]

Fantástico, Halfvector. Ese plugin me habría ayudado un montón, una pena que ya no trabaje con max.

[HalfVector]

Fantástico, Halfvector. Ese plugin me habría ayudado un montón, una pena que ya no trabaje con max.

La verdad es que este hilo me está viniendo bastante bien para profundizar un poco más con el SDK, que hacía bastante tiempo que lo tenía abandonado.

Y pasando a otra cosa, estaba yo tirando unas líneas para la serie de tutoriales de Maxscript cuya primera parte espero que no se retrase demasiado, () y de pronto me he planteado una cuestión.

En uno de los mensajes dije que la dirección que debían tener los emisores de partículas era la normal de la superficie en el punto de intersección. Pero de pronto he caído que seguramente no es la mejor dirección.

Así que he montado una prueba con Maxscript que orienta unas flechas en ciertas direcciones de interés:


Por una lado tenemos el incident Vector (i) que es el Vector director del proyectil y luego tenemos el normal Vector (n) (la normal de la superficie en el punto de intersección, datos que nos devuelve la función intersectionrayex). Pero cómo se puede ver, parece que el Vector normal no es el más indicado para emitir las partículas.

Así que luego he pensado que tal vez el mejor Vector sería el reflection Vector (r) que es el Vector incident reflejado sobre la normal:

r = i - 2 * n * (Dot n i)

Pero aun así no me convencía, me parecía una dirección demasiado forzada. Así que finalmente he pensado que tal vez, la mejor dirección de emisión sería un Vector a medio camino entre la normal y el Vector reflexión, al cual he denominado half-way Vector (h):

h = n + r

Eso, sumado a un cono de emisión con una cierta apertura, podría quedar bien. Las partículas serían emitidas en direcciones comprendidas entre el Vector normal y el Vector reflexión.
¿Qué opináis? Saludos.

-- IMÁGENES ADJUNTAS --

[Chaman]

Si el desprendimiento de partículas se corresponde a una reacción producida por un impacto, la mayoría de partículas deberían desplazarse en torno a la misma dirección del impacto y en sentido opuesto (por algo el principio de acción-reacción, no), quizá con algunas partículas díscolas que vayan en alguno de los vectores que indicas. Pero el grueso debería ir en la misma dirección que el impacto, pero en sentido contrario.
¿No?

[HalfVector]

La verdad es que me imagino que esto variara en función de la composición de la superficie. Porque, por ejemplo, si disparamos a una superficie de tierra en una dirección similar a la que muestro en la imagen, es posible que gran parte de los trozos desprendidos vayan en una dirección similar al Vector reflexión.

También hay que tener en cuenta que conforme el Vector incidente sea más perpendicular a la superficie, más coincidirá con el Vector reflexión, por lo que más se cumplirá el principio de acción-reacción. Saludos.