Script en 3ds Max

[bealobo]

Bueno. Resulta que estoy haciendo un curso de scripting para max y ahora tengo que hacer un trabajo final, de lo que sea, yo lo quiero hacer relacionado con partículas, pero no se me ocurre nada,
¿Alguien me puede dar alguna idea? Gracias.

[MiguelPerez]

Podrías hacer algo como el impact system de Slime.

[SHAZAM]

A mí me dejó marcado un script de Slime en blur, que puedes ver en su demoreel.

En un hilo relacionado Slime dejó un enlace donde se puede ver en acción un script simulando el de blur, donde además ayudó nuestro genial compañero:
gunfire simulation script.

El enlace directo es:
http://www.alvinvfx.com/gunfirescript/gunfiresimulation.zip. Suerte guapísima.

Edito: que raro, se me a adelantado alguien.

[MiguelPerez]

Al menos tu información es mucho más completa. Si haces alguno chulo, compártelo.

[Chaman]

Pues en las mismas que Bea estoy yo. Cualquier idea es bien recibida.

[-YeraY-]

Bueno y porque no hacen lo mismo, pero en el mar. Impac system en agua? Suerte si se me ocurre algo lo digo.

[Ballo]

¿Y porque no un kisses simulation script? Es que, a mi las balas no me gustan nada de nada.

[bealobo]

Vaya. Kisses simulation script, imagínate nada más abrir daría un aviso con un slogan: tu script del sábado noche.

Bueno, muchas gracias a todos, voy a mirar todo lo que me decís. Ya os comentaré que acabo haciendo.

Y sí, intentaré hacer algo chulo y lo publico por aquí.

[bealobo]

Bueno, ya he visto lo que me comentáis y yo no creo que tenga tiempo para hacer algo tan complejo. Suponiendo que lo supiese hacer, claro.

Pero ya da ideas. Gracias.

[-YeraY-]

Vaya y un script de simulación de rayas en el suelo, es decir, los frenazos o acelerones de un coche, pues eso, que se pueda con un script meter un archivo (*.jpg) y con dicho script poder alargar, ensanchar, acortar, etc la marca, no se sigo pensando.

[Andres3d]

Hola Bealobo: que bueno mira, te recomiendo que te pases por esta web que hay muchos script, con el cual su autor dice que los podemos usar totalmente y que si acaso alguien crea un script con otro efecto basándose de los script de el, que no hay problema, antes que se lo envien, a mi me gustaría aprender un poco más de Maxscript, con eso así poder integrar alguno de estos script con Particle Flow en un operator y hacer algo chebre ok saludos ojalá te sirva. http://www.pxfactory.eu/pf.php?Cpage=scripts.

[c1712105]

Seria bueno un script para girar el viewport como el ZBrush.

[Chaman]

Oye, pues la idea del maestro Yeday de pegar tiros en el agua puede estar entretenida.

[slime]

Yo haría un script para romper objetos de forma realista. De forma fractal se podrían generar pedazos simulando roca, cristal, plástico, etc. Puedes empezar por algo más sencillo y luego ir complicándolo cada vez más. Podría también romperse el objeto con un bitmap. El blanco simularia, por ejemplo, las grietas y el negro los pedazos resultantes. Esto sería muy útil y seguramente que se usaría en muchas producciones.

[Andres3d]

Podría también romperse el objeto con un bitmap. El blanco simularia, por ejemplo, las grietas y el negro los pedazos resultantes. Esto sería muy útil y seguramente que se usaría en muchas producciones.

Vaya sería lo máximo como al estilo de Blast code megaton para Maya e probado el plugin y es muy bueno con eso, pero si en 3dsmax se pudiera uf seria super bueno, ojalá que si logras desarrollar lo compartas.

[bealobo]

Bueno, el problema que tengo con 3ds Max es que mi conocimiento general del programa es bastante limitado (sobre todo el área de modelado). Lo que conozco mejor es el Particle Flow.

Pero bueno, yo me apaño muy rápido, así que, miraré a ver qué hago y cómo. Muchas gracias a todos de nuevo.

[bealobo]

Jai. ¿Se puede acceder a la posición de las partículas de Particle Flow a través del scripting general? Es que por más que miro la ayuda no lo veo claro. Gracias.

[HalfVector]

Jai. ¿Se puede acceder a la posición de las partículas de Particle Flow a través del scripting general? Es que por más que miro la ayuda no lo veo claro.

Hi.

Creo que sí puedes. Mírate la interfaz particleobjectext.

Aquí tienes un ejemplo que accede a la posición, rotación, escalado y tamaño de cada partícula.

pf = $PFSource 01.

For I = 1 todo pf, numparticles() do (tpf, particleindex = i tformat particle #%\nI tformat particle position = %\nVaya, particleposition tformat particle rotation = %\nVaya, particletm.rotationpart tformat particle scale = %\nVaya, particlescalexyz tformat particle size = %\n\nVaya, particlescale.
)

Si no me equivocó es similar a la forma que se utiliza en los scripts internos de Particle Flow. A ver si es lo que buscas. Saludos.

[bealobo]

Gracias, que rapidez. Voy a hacer unas pruebas a ver.

[slime]

Ánimo, Bea.

[Ballo]

Y al final que estás haciendo? Se me ha ocurrido hacer, por ejemplo, a partir de geometría crear efectos. Con una esfera el kame-kame. Te creas una UI que controle de forma automática parámetros del sistema, y tal, yo que sé.

Por cierto, me imagino que ya lo, pero bobo tienes algunos tutoriales de Particle Flow y Maxscript. http://www.scriptspot.com/bobo/. Suerte.

[bealobo]

Gracias por la sugerencia. Creo que haré un script parecido al de Slime, pero más básico y que se complemente. Habrá que crear una pistola y elegir el tipo (dardos, balas), animarla (intentaré que sea con un target). Decir que objetos son orgánicos y los impactos causaran un sangrado.

Qué se yo, todo muy cutre y muy lento seguramente, pero es que, estoy aprendiendo poco a poco.

[MiguelPerez]

Qué bien suena eso. Ánimo.

[bealobo]

Bueno, la cosa va yendo, de momento tengo semiacabada la UI. Sólo he puesto las opciones más básicas y si me da tiempo pondré alguna cosa más, os dejo una captura, en el trozo vacío quiero poner las instrucciones para usarlo, aunque aún no sé cómo se hace.

Y bueno, el diseño es provisional, simplemente necesito algo para empezar a meter funciones y hacer que funcione.

Me he dado cuenta de que todos los objetos van a ser internamente deflectores por si la sangre cae en alguno de ellos. Y estoy pensando que eso va a ser lento lento lento ¿no?

-- IMÁGENES ADJUNTAS --

[Birkov]

Tengo ganas de ver esos avances, lo que preguntas si utilizas todos los objetos como deflectores sí que va a ser lento, me acuerdo cuando vi la demoreel de Slime que me planteé esa misma pregunta, para personajes animados, creo que sería más rápido linkarles deflectores esféricos a las distintas partes del cuerpo que hacer que todo el cuerpo sea un deflector, ya que, calcular colisiones de partículas contra una malla que se deforma debe de costar lo suyo, pero vamos Slime te dirá que es el experto. Suerte con el script.

[bealobo]

Es una movida sí, yo voy a seguir pensando a ver mientras voy haciendo más código.

[HalfVector]

Ante todo decir que sobre estos temas ando escaso. So kep that in mind. ¿Todos los tests de colisión los vas a llevar a cabo a través de Particle Flow o, por ejemplo, la colisión proyectil/objeto la realizaras utilizando alguna función tipo intersectray/intersectrayex/raymeshgridintersectí.

Lo digo porque en ese último caso, las intersecciones proyectil/objeto se precalcularían, con lo cual te ahorrarías que Particle Flow averiguara la intersección en cada frame.

Es decir, al pulsar el botón go, calcularías el punto de colisión de cada proyectil (dependiendo de la cadencia de disparo) y entonces crearías un PFSource en la posición de colisión, con una dirección igual a la normal de la superficie en el punto de colisión (esos datos te lo devuelven las funciones intersectray/intersectrayex/raymeshgridintersect). Ese PFSource sería el emisor de sangre.

De hecho, con ese método creo que podrías hacer algo similar a lo que hace Slime en el impact system (aunque esto que lo confirme el que es el que lo programó), es decir, podrías utilizar esa misma posición y normal de colisión para meter un space Warp de tipo displace y así simular las hendiduras provocadas por los impactos del proyectil. Incluso tal y como hace él, meter teselación en las caras adyacentes al punto de colisión.

Por otro lado, las colisiones sangre/objeto me imagino que sí se controlarían utilizando un test de colisión y deflectores en pf. En este caso, si hay muchos polígonos, me imagino que la simulación sí será lenta (ignoro cómo funciona Particle Flow y las optimizaciones internas que llevara a cabo).

Pero hay que tener en cuenta que en una producción cinematográfica (y hablo desde la ignorancia en este caso) se maneja un entorno controlado por lo que se sabe que objetos tienen que formar parte de la simulación y cuáles no (al contrario que en un videojuego donde las posibilidades de interacción son casi infinitas). Eso quiere decir que no todos los objetos tienen por qué ser deflectores. Sólo aquellos que estén en el radio de acción de cada salpicadura de sangre. O sea, que en ese caso me imagino que es cosa del operador el marcar los objetos que formarían parte de la simulación. O incluso se podría automatizar utilizando algún tipo de heurística. Por ejemplo, sólo añadir como deflectores aquellos objetos que estén dentro de un cierto radio de acción (que dependerá de cosas como el tiempo de vida del sistema de partículas, la velocidad de las partículas, las fuerzas que le afecten, etc).

Pero bueno, no tengo demasiados conocimientos en estos temas así que, invocamos a Slime. Saludos.

[bealobo]

Cuanta cosa, que bien, la verdad es que en un principio lo quise hacer así, es decir colocando un emisor en cada impacto y estuve buscando y no encontré la manera (la ayuda de Maxscript es un infierno), lo quería hacer así porque el chorro de sangre no dependía del impacto de 1 bala y podía hacer más virguerías de manera más simple como simular el tamaño del agujero de la bala con el tamaño del emisor (el nodo collision y el colisión Spawn se me quedaban un poco cortos).

Ahora que se el nombre de las funciones lo voy a volver a investigar. Bien.

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. Muchas gracias a todos.

[HalfVector]

La verdad es que en un principio lo quise hacer así, es decir colocando un emisor en cada impacto y estuve buscando y no encontré la manera (la ayuda de Maxscript es un infierno).

Aunque en la ayuda encontraras más información y más completa, ahí van las posibilidades que tienes utilizando las funciones que he mencionado.
intersectray.

Te devuelve el punto de colisión y la normal en dicho punto. Funciona con cualquier tipo de geometría.
intersectrayex.

Te devuelve el punto de colisión, la normal en dicho punto, el índice del triángulo en el que se produjo la colisión y las coordenadas baricéntricas. Sólo funciona con editable Mesh.
raymeshgridintersect.

Seguramente es la mejor opción de todas, pero por alguna razón no tiene el comportamiento que yo esperaba de ella. Por ejemplo, yo pensaba que si añadías una serie de objetos con los que llevar a cabo el test de colisión, te devolvería el punto de colisión más cercano a la posición desde la que se lanzó el rayo, pero al parecer sólo devuelve la colisión con el primer objeto que se añadió a la lista de nodos. Realmente es un comportamiento muy extraño.

Así que, teniendo en cuenta el problema aparente de raymeshgridintersect, la mejor opción sería intersectray si no necesitas saber el triángulo en el que se produjo la colisión o intersectrayex si necesitas saberlo (por ejemplo, para la teselación).

Aquí te pongo un pequeño script que hice hace un tiempo que hace uso de intersectrayex:

Fn closestrayintersection r = (t- Inicializamos variables tlocal closestdist = 999999999 tlocal closestnode = undefined tlocal closestinfo = undefined t- Recorremos todos los objetos geométricos de la escena tfor n in $geometry do (t - Puesto que intersectrayex sólo funciona con editable meshes - Añadimos un modificador edit_mesh add modifier n (edit_mesh()) t - Calculamos la intersección local i = intersectrayex n r t - Eliminamos el modificador deletemodifier n 1 t - Si hubo colisión if i.= undefined do (t - Calculamos la distancia desde el origen del rayo - Al punto donde se produjo la colisión local Dist = distance r, pues i[1].pos t - Si dicha distancia es menor que la anterior - Distancia más cercana almacenada if Dist < closestdist do (t - Almacenamos la nueva distancia closestdist = Dist - El objeto donde se produjo la colisión closestnode = n - La información de la colisión closestinfo = i ) ) t) t- Si  es distinto de undefined quiere decir que hubo t- Colisión, por lo que devolvemos la información de colisión tif closestnode.= undefined do - Devolvemos:
- La distancia al punto de intersección - El nodo donde se produjo la intersección - La información de intersección de la función intersectrayex return #(closestdist, closestnode, closestinfo) t- Después de todo no hubo colisión treturn undefined).

Probamos la función.

Limpiamos el Listener.

Clearlistener().

Calculamos la posible intersección.

I = closestrayintersection ($tape01 as ray).

Si hubo intersección.

If i.= undefined do (t- Eliminamos el anterior objeto point que pudiera existir ttry(deleete $point01) catch() t- Creamos un objeto point en el punto de colisión tpoint pos:i[3][1], pues wirecolor:red.
)

Para que funcione, tienes que crear una serie de objetos y un tape que es el que hace de apuntador (el rayo). Si se detecta colisión, se crea un nodo de tipo point en el punto de intersección. Saludos.

[MiguelPerez]

También podrías hacer que las partículas dejaran mancha en los objetos mediante una textura. Quedaría mucho más realista.

[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.

[Ballo]

Vaya, half eres un maldito gúru, te odio.

[bealobo]

screen.width-255) {this.width=screen.width-255;this, alt=full view;} onmouseover=if(this, alt) this, style, cursor=hand, border=0>.

Cuando vi esto ayer lo leí rápido y pensé, lo habré leído mal, que cutrerío, menos mal que te lo curras de lo bonito y haz hecho el plugin este half, porque si es por el Maxscript, la verdad es que eso me va a ayudar muchísimo. Supongo que no le importara al profesor. Mil gracias.

Sobre lo de la dirección de salida de las partículas, el halfway Vector parece chulo, pero, lo que va a salir del impacto es un borbotón de sangre que deslizara por la superficie rápidamente o en caso de estar en el aire, rápidamente caerá por efecto de la gravedad, toreo más que película gore. Me parece que quedará más realista. Por lo que realmente la dirección no importa tanto, creo yo.
¿Qué opináis?
Yo lo veo desde mi punto de vista, claro. Tengo que hacer el script y me voy a fijar primero en lo básico y principal y luego añadir chuladas de este tipo, si me da tiempo. O quizás las intente añadir después de la entrega si no me da tiempo.

Tengo un lío en el trabajo difícil de imaginar, y con todo lo que se bien aquí y lo que estoy mirando, tengo unas ganas de pillar el script gracias a todos.

[HalfVector]

La verdad es que eso me va a ayudar muchísimo. Supongo que no le importara al profesor. Mil gracias.

No creo. Eso es sólo una muy parte de lo que tienes pensado hacer. Además, si Maxscript tiene estas lagunas, no es culpa de uno.

Sobre lo de la dirección de salida de las partículas, el halfway Vector parece chulo, pero, lo que va a salir del impacto es un borbotón de sangre que deslizara por la superficie rápidamente o en caso de estar en el aire, rápidamente caerá por efecto de la gravedad, toreo más que película gore. Me parece que quedará más realista. Por lo que realmente la dirección no importa tanto, creo yo.
¿Qué opináisí.

Es cierto que en el caso de la sangre podría estar bien el Vector normal, aunque bien es cierto que podrían saltar despojos de carne, pero tampoco es plan de tirarse al gore.

Esto más que nada ha sido en plan quisquilloso y además, yo creo que en una secuencia de acción rápida poco se notarían estas cosas. Saludos.

Posdata: incluso en el caso de la sangre, el Vector de emisión podría ser el Vector incidente, invertido, tal y como ha dicho Chamanman.

[bealobo]

Bueno, que sepáis que sigo con esto, lo estoy flipando. Cuanto más lo intento y lo pienso y lo remiro, para que tenga algo de flexibilidad acabara siendo más parecido al de Slime de lo que me gustaría. Pero es que el presets que tenía pensado es muy molón, pero al final no sirve nada más que para 3 escenas.

A ver si puedo poner algún avance próximamente, que lo que se está viviendo en el editor de scripts hoy por hoy es una batalla campal.

[HalfVector]

Cuanto más lo intento y lo pienso y lo remiro, para que tenga algo de flexibilidad acabara siendo más parecido al de Slime de lo que me gustaría.

Es que el proyecto se prestaba a ello.

A ver si puedo poner algún avance próximamente, que lo que se está viviendo en el editor de scripts hoy por hoy es una batalla campal.

Hablando del editor de scripts de 3ds Max, mira que es malo. Lo más grave de todo es que sólo tiene un nivel de undo. Y el editor de uis también deja bastante que desear. A ver si mejoran todo eso y también hacen más potente el debugger. Yo la verdad es que, si el script tiene muchas líneas de código, acabo programando en el ultraedit. Además, le metí coloreado de sintaxis que siempre resulta más cómodo.

Ale, ánimo.