Versión para imprimir
Hola chicos, acabo de actualizar mi web con un nuevo tutorial: un bosque con cien polígonos. Arboles de dos dimensiones, y media.
También se podría subtitular como RPC casero.
Aunque está basado en un software que no es 3ds Max, creo que sus principios son perfectamente adaptables a cualquier herramienta. Y, sobre todo: no penséis sólo en árboles.
Espero que os interese.
Un cordial saludo y feliz 2007.
Eterea, eres un máquina. Por mí, pasas al grupo de investigadores, (aunque yó, eso lo solucioné hace tiempo).
Está muy bien, todo muy bien explicado e ilustrado, hay un par de cosas sobre el script (de hecho, ya las comentas tú en el tutorial y están así porque tuviste que hacerlo todo muy rápido).
La cuestión de generar un fotograma aleatorio inicial para cada árbol la podrías solucionar creando un array de 100 posiciones y almacenando en cada posición del array el resultado de la función random esto como todo tiene ventajas e inconvenientes, ahorras procesador ya que solo calculas una vez el fotograma inicial, pero consumes más memoria Ram, lo mismo sucede con el calculo del fotograma de las sombras, todo es cuestión de probar a ver qué compensa más.
Por lo demás me gusta mucha la idea y sobre todo el resultado, si algún día me meto con el Maxscript intentaré adaptar tu idea.
Está muy bien la técnica.
posdata: a ver si alguien se anima a pasar el script a Blender.
Excelente, ya me lo miraré con las pestañas en alto, un saludo y feliz año.
No me digas que usas el electricimage? Pues eres la segunda persona en mi vida que conozco que lo usa.
Jam, yo usaba un G4 con macos9 donde solo rulaba el formz y el electricimage.
No sé mucho de script en ese programa, pero el problema del valor aleatorio se puede resolver haciendo una primera pasada para asignarle a un atributo del objeto un valor entre 0 y 360 (o un valor cualquiera al que le apliques módulo 359). Luego ya vendría el script de verdad en el que se calcularía que valor se va a mostrar (sumando el del atributo que tengas, y haciendo el módulo 360 al final de todo).
Me parece un buen método, muchas gracias por la aportación. Estaría interesante implementarlo en Blender. ¿Klópes?
Vaya, =o. Me ha encantado, sobre todo la animación al final, excelente trabajo.
Excelente tutorial. Muy bien explicado, ameno y claro. Mychas gracias por la aportación y el esfuerzo.
¿Mars?Cita:
No sé mucho de script en ese programa, pero el problema del valor aleatorio se puede resolver haciendo una primera pasada para asignarle a un atributo del objeto un valor entre 0 y 360 (o un valor cualquiera al que le apliques módulo 359). Luego ya vendría el script de verdad en el que se calcularía que valor se va a mostrar (sumando el del atributo que tengas, y haciendo el módulo 360 al final de todo).
Me parece un buen método, muchas gracias por la aportación. Estaría interesante implementarlo en Blender. ¿Klópes?
La forma más sencilla que veo es generar una semilla a partir del nombre del objeto, y el valor aleatorio obtenido a continuación dará un ángulo adicional. Gracias, Cristóbal, muy buen tutorial.
Este método lo intenté aplicar en un proyecto antiguo, pero al ver que tenía que hacer un script y sólo tenía 10 horas para hacer el proyecto, no he vuelto a retomar el tema, no sin antes cagarmensusmuelas.
En cuanto a los mapas de normales, sí lo probé y queda muy bien, aparte de que aumenta la sensación de que los árboles son diferentes.
Veré lo que puedo hacer, esclavistas. Que sois, no encuentro el icono del látigo.
Tú programa y calla. Puede ser tu charla en Blendiberia para dejar boquiabierta a la gente (y no sólo adormilada, como de costumbre).
Hola chicos. Me alegra mucho que os haya gustado el tutorial y que lo encontréis interesante (y útil). Como ya he comentado en otro sitio, creo que está técnica tiene muchas posibilidades. Antes de preparar el tutorial no esperaba demasiado de ella, pero la verdad es que, ahora veo que hay todavía muchos aspectos en los que se puede mejorar, aparte de lo que ya adelanto en las conclusiones del tutorial:
- Implementar en el script una orden que haga que cada árbol varíe ligeramente de tamaño (eso esta chupado).
En el propio script también se podría implementar un valor aleatorio de color que se superpusiera a la textura base de cada árbol (la movie). De ese modo conseguiríamos que cada árbol tuviera un tono de color distinto al de al lado (esto también esta chupado).
Si no vamos a girar 360 grados en torno a los árboles podríamos aprovechar los 360 fotogramas de la movie inicial para disparar cada menos grados (1 cada 0,5 grados, por ejemplo, y así podríamos girar 180 grados en torno a los árboles finales, pero con una velocidad angular el doble de lenta). Esto es algo que puede utilizarse en la mayoría de las situaciones: imaginad que tenemos una casa rodeada de bosque. Nosotros nos moveremos en torno a la casa, pero probablemente no nos alejaremos de ella adentrándonos en el bosque. Por lo tanto, la mayor parte de los árboles los veremos desde un abanico de ángulos muy restringido (desde la zona de la casa), con lo cual podremos, o bien economizar frames en el vídeo inicial, o bien que los frames correspondan con variaciones angulares menores.
Quedaría por ver cómo quedaría un elemento al ser capturado desde una posición más elevada (no frontal). Si eso funciona bien, podría sacárselo mucho partido para representar las plantas y arbustos bajos que normalmente visualizamos un poco desde arriba.
Quiero hacer la prueba con escultura, mezclando la textura animada con un mapa de normales animado. Estoy convencido de que tiene que rular de miedo.
Klopes: a ver si consigues que esto funcione en 3dsmax, estoy convencido de que tiene que ser sencillo, aunque yo no tengo ni idea de 3ds Max y mucho menos de su sistema de scripting (ya me viene justo con el de electric). Un abrazo y ya iréis contando.
Ni yo. Hablamos de Blender.Cita:
Hola chicos. Klopes: a ver si consigues que esto funcione en 3dsmax, estoy convencido de que tiene que ser sencillo, aunque yo no tengo ni idea de 3ds Max y mucho menos de su sistema de scripting (ya me viene justo con el de electric).
Por cierto, señor Cristóbal: usted que no sabe quién soy yo, ¿verdad?
Para que te ubiques, digamos que una vez a la semana te tengo al otro lado de la mesa, soy Carlos, de lsluz.
Bien. Lo de los ángulos en picado le he dado algunas vueltas () y todo depende de lo que queramos gastarnos. Está claro que algo así hace falta porque basta que la cámara esté un poco inclinada para que el método no funcione. Lo más lógico parece almacenar la película según proyección esférica (por latitud y longitud del ángulo de la cámara), aunque no es muy económico porque al llegar a latitudes altas (picados), las diferencias en longitud son mínimas. Pero es que cualquier otra forma es mucho más complicada.
Supongamos que hacemos 1 frame por ángulo de longitud (0-360º) y de latitud (0-90 grados de cabeceo): tendríamos 360*90=32400 frames.
Si economizamos forzando que la distancia angular entre frames sea parecida, con un factor coseno, nos quedan (dividiendo por pi/2) unos 20626. Seguramente sólo nos harán falta cabeceos pequeños, pero para hacerse la idea, uno de 30º de máximo sólo reduce la película a la mitad. También podemos generar frames separados más de 1º, claro, que es muy factible.
Un inconveniente que veo es la distancia de la cámara al objeto, que puede variar, mientras que las imágenes se han generado desde una distancia fija. Eso en el bosque queda muy bien porque los árboles tienen forma confusa, pero en esculturas puede resultar forzado si queremos mover la cámara libremente.
Al final, el método se parecerá mucho al QuickTime VR para girar objetos (más el potencial del programa que usemos, claro).
Personalmente, no creo que haya que ser muy ambicioso con esto porque pasa lo de siempre: sustituir la velocidad de cálculo por espacio y memoria. El método es estupendo, pero vale para lo que vale. Y todo es investigar hasta dónde llega. Veremos.
Mars, maricón.
Hola Cristóbal, que sepas que te sigo desde hace tres años, cuando vi tu web por primera vez y mostrabas aquellos concept Cars excelentes.
Bueno, yo trabajo con el tema infografía y ahora mismo estoy terminando unas naves que tendré que animar más adelante. Si bien no están dentro de un bosque, este sistema me viene como añillo al dedo, solo que ahora tengo que pasar el script a max.
No he leído el tutorial en profundidad, pero he visto el video final y es acojonante.
Lo leeré con calma y veré si puedo emplearlo.supongo sí. Un saludo y gracias por tu aporte.
Coño, Klópes. Desde luego, si es que el mundo es un pañuelo, y Zaragoza, como diría un buen amigo mío es el, bueno, es igual. Mañana te veo.
Lo que comentas de meter frames también para la latitud lo estuve pensando, pero enseguida me lo quité de la cabeza: esto empezaría a ser como atar perros con longanizas -de graus.
Lo que está claro es que ésta es una técnica para usar sólo cuando te lo pida la situación: habrá innumerables situaciones en la que no será eficaz, pero puede haber otras en las que sí. Si no vamos a elevarnos demasiado en nuestra animación, sino que siempre vamos a estar dentro de lo que podríamos llamar un ángulo de seguridad creo que puede ser muy útil. Yo desde luego espero usarla en un proyecto que ahora tengo entre manos, pero todavía queda tiempo (mucho tiempo) para que se pueda enseñar algo.
Dos cosas más que quería comentaros, como he hecho en otros foros:
- Fijaos en este otro tutorial que ha recomendado un miembro del foro CGnode: .
Lighting flat objects (an application of Normal Maps and raydiffuse..
Es para Autodesk Maya, pero creo que resulta muy interesante (aún me lo tengo que mirar a fondo).
No dejéis de clickar en todas las imágenes porque llevan a unos. Avi muy interesantes, especialmente éste.
Y la otra cosa: si conseguís hacer una buena traducción a otro sistema de scripting (a max o a lo que sea) y os apetece compartirla, estaré encantado de publicarla en mí web, complementando la información del tutorial, y con los correspondientes créditos y agradecimientos al autor del script y un enlace a su web.
Saludicos.
Pues aparte de lo que cuenta, los enlaces que da también son muy interesantes. Le echaré un ojo, hasta mañana.
Yo la verdad, es que de lo del scripting no me he puesto nunca en serio, voy a ver qué tal me va con esto y si consigo algo aparente os lo digo, -las longanizas de graus me chiflan.
Klópes, estoy pensando que para hacer un bosque frondoso con esta técnica y con Blender, tendríamos que prescindir del Raytracing, debido a la poca profundidad que ofrece en transparencias ¿no?
Y por otro lado, el Scanline se haría bastante lento calculando tanta transparencia sobre-puesta ¿no?
Primer problema que me encuentro, se puede cargar un qtvr como textura en max? Editado : no he dicho nada, soy un ignorante.
Sí, pero basta usar ztrasp en el material en vez de la ray transparent, yo sólo la uso cuando hay refracción, nunca para máscaras. Cualquier otra cosa de rayos se integra perfectamente.Cita:
Klópes, estoy pensando que para hacer un bosque frondoso con esta técnica y con Blender, tendríamos que prescindir del Raytracing, debido a la poca profundidad que ofrece en transparencias ¿no?
Y por otro lado, el Scanline se haría bastante lento calculando tanta transparencia sobre-puesta ¿no?
Lo sé, lo sé, por eso hablé de Scanline, lo que ocurre es que hace algún tiempo intenté hacer un bosque (sin animación) y el render se hacía eterno. Debe ser que con el repaso que le dieron al sistema de render, aceleraron el tema de la ordenación de ztransp, porque acabo de hacer una prueba poniendo bastantes planos uno detrás de otro y la velocidad de render ha sido aceptable.Cita:
Sí, pero basta usar ztrasp.
Thanks, perdón por el mini-offtopic.
Hola, mensaje para Cristóbal. Estoy haciendo el tutorial con 3ds Max y tengo ciertas dudas.
1)¿porque usas el segundo plano para hacer la sombra? Yo le pongo el tiz alpha en el canal opacidad ya obtengo la sombra desde el primer yúnic plano (ver fotografía).
Me pierdo algo ahí?
Otra cosa, aún no me he metido con el script, pero tú que cargas en el plamo?
Un avi, un (*.mov) con toda la secuencia, o un tif(jpg, etc), del primer fotograma?
En ese caso, como le el script el resto? En el código le doy la ruta de la carpeta?
Bueno, a grandes rasgos eso. Un saludo.
Otra cosa: como ejemplo alternativo se me ocurre un montón de soldados corriendo colina arriba.
No soy Cristóbal, pero.Cita:
1)¿porque usas el segundo plano para hacer la sombra? Yo le pongo el tiz alpha en el canal opacidad ya obtengo la sombra desde el primer yúnic plano (ver fotografía).
Me pierdo algo ahí?
Tu sombra solo será correcta cuando la luz esté perpendicular al plano.Carga una imagen distinta dependiendo del ángulo con la cámara y el modo de hacerlo depende del lenguaje usado y de la libertad que te deje tu software.Cita:
Otra cosa, aún no me he metido con el script, pero tú que cargas en el plamo?
Un avi, un (*.mov) con toda la secuencia, o un tif(jpg, etc), del primer fotograma?
En ese caso, como le el script el resto? En el código le doy la ruta de la carpeta?
Hola Caronte, gracias por contestar. Lo de la luz en vertical tengo que mirarlo bien, porque no se ha que te refieres. Porque en la fotografía que subí, el sol está entre las 6 y las 7 con respecto a la altura y la sombra se proyecta bien en el suelo.Cita:
No soy Cristóbal, pero. Tu sombra solo será correcta cuando la luz esté perpendicular al plano. Carga una imagen distinta dependiendo del ángulo con la cámara y el modo de hacerlo depende del lenguaje usado y de la libertad que te deje tu software.
Seguro que me dejo algo, asíque lo miraré.
Con respecto al maxscrpit, no lo he usado aún, pero teniendo conocimientos en otros, se supone que habrá que darle la ruta de cada imagen, o subir una cadena por cada imagen, lo cuál sería engorroso.
Bueno a ver qué sale, un saludo y gracias.
No, tu sombra no está bien, esta aplanada y esto pasara más y más conforme te alejes de la perpendicular con el plano del árbol (tanto en vertical como en horizontal).Cita:
Porque en la fotografía que subí, el sol está entre las 6 y las 7 con respecto a la altura y la sombra se proyecta bien en el suelo.
Normalmente se le da un nombre base a la imagen y un índice, este índice es simplemente un número que es cambiado por el script.Cita:
Se supone que habrá que darle la ruta de cada imagen, o subir una cadena por cada imagen, lo cuál sería engorroso.
[ te me has adelantado, Caronte, gracias por los apuntes ;-) ]. Tbc3d: no puedes dejar que sea el mismo plano que contiene la movie del árbol el que proyecte la sombra. Imagina por un momento que en lugar de con árboles estamos jugando con esferas. ¿te imaginas las sombras que proyectaría una esfera sobre un plano dependiendo de dónde fueras poniendo la fuente de luz? Bien, pues ahora imagina que en vez de una esfera tienes un círculo. Si siempre mira hacia la cámara, su perfil externo -su perímetro- Podrá coincidir con una esfera, pero la sombra proyectada por ese círculo plano será muy distinta de la proyectada por una esfera, especialmente si la fuente de luz está muy alta. Imagina el círculo con una luz justo encima. No se proyectaría ningún tipo de sombra (una línea fina, como mucho).
Por eso hay que trabajar la proyección de sombra de un modo independiente al del plano que contiene el árbol (de hecho, aquí también hay ciertas limitaciones: la sombra proyectada de un árbol tridimensional producida por una luz cenital no debería recortar el tronco, sólo deberíamos ver la sombra de la copa.
Respecto al archivo de imagen: yo cargo una movie en el formato nativo de electric (. Img). Aunque también podría cargar directamente una movie. Mov o. Avi. Eso dependerá mucho de tu software (de con que formato de archivo se entienda mejor). Lo importante es que tú puedas indicarle -por medio del script- Que frame determinado tiene que cargar en cada momento. Imagino que tampoco habría excesivo problema en que fuera leyéndolos de una carpeta de archivos independientes (secuencia de. (*.jpg) o. Tif), pero encuentro más práctico poder desenvolverse con un único archivo -la movie.
Ya nos iras contando que tal va ese script. Suerte.
Hola critobal, gracias por tu explicación, y a Caronte también. Claro, ahora lo entiendo, la sombra juega su propio papel. También acabo de darme cuenta que, como con los rpcs), no puedes subir mucho la cámara porque se pierde el ángulo frontal.
Con lo cual, este tutorial también sirve para tomas aéreas de bosques, pero claro, habrá que hacer el 360 grados desde arriba.
Max puede cargar casi todo: avi, (*.mov), tif, Targa, (*.jpg) y hasta puedo cargar la secuencia desde Combustion, con lo cual puedo modificar detalles en este programa que se actualizaran luego en 3dsmax.
Yo uso php y actionscript que se parecen mucho. Supongo que Maxscript será más de lo mismo, asíque tendré que buscar la conexión con el archivo y la cámara, a ver qué pasa.
Bueno, ya os iré contando. Un saludo.
Creo que falta un detalle con lo que dice TBC: el plano de sombra no sólo debe ser fijo, además la textura alfa también será fija, no será la que se ve desde la cámara.
En cuanto a lo de los soldados, adelante, hazlo. De hecho, en el Doom siempre se usó esta técnica (con 8 imágenes en lugar de 360, claro), y creo que se sigue usando para animar ejércitos en tiempo real. Ya se habló de esto hace unos meses en algún hilo muy interesante.
Hola Klópes, estaba sacando cuentas, y.Cita:
Creo que falta un detalle con lo que dice TBC: el plano de sombra no sólo debe ser fijo, además la textura alfa también será fija, no será la que se ve desde la cámara.
En cuanto a lo de los soldados, adelante, hazlo. De hecho, en el Doom siempre se usó esta técnica (con 8 imágenes en lugar de 360, claro), y creo que se sigue usando para animar ejércitos en tiempo real. Ya se habló de esto hace unos meses en algún hilo muy interesante.
Pasa lo que con los rpcs: suponte que ánimo un soldado corriendo por el campo.
Hago un loop con la animaicón, ahora le hago el 360 grados. La putadas es que en el grado 1 tendrá una postura y en el grado 30 tendrá otra. Con lo cual no quedaría bien.
Habría que tener 306º por cada frame (por cada postura del soldado). No es nada complejo, solo que hay que modificar el script para que la cámara tome el cuadro que necesita en ese momento.
Ejemplo: si camframe 20 = soldframe 80.
Entonces soldframe =81 en previus or next camframe.
Me explico. Un saludo.
Te explicas perfectamente. En el Doom, digamos, creo que un ciclo de andar eran 4 frames para un bicho normal. O sea, sólo en andar se usaban 32 sprites, y ya ves lo tosco de la animación.
Pero no vale la pena hacerlo con tanto detalle, sobre todo en animaciones de batalla que son tan rápidas. Pienso que cada 5º se podría hacer, y nos dan 72 gráficos, por. 6 frames de un ciclo de correr, son 432 frames, creo que asumibles, y no hace falta mucho detalle en los gráficos. Pon que hay un espadazo, un bloqueo del arma, otro con escudo, de 4 frames cada uno, imaginemos unas 10 acciones en total de 5 frames de media: 50 frames*72 puntos de vista= 3600 gráficos.
Lo malo es que hay que tenerlo todo en memoria.
Pues, sabes en que pensaba yo? En el desembarco en la costa de Normandía. Una vista altura de hombre, paneando toda la playa de lado a lado y soldados avanzando y otros que caen.
No sé.habría que verlo. Pero la idea me gusta. Pero primero tengo que sacar lo de los árboles que no es poco. Un saludo.
Yo me conformo con un script que mantenga perpendiculares a mi cámara todas las planchas con bitmaps. Que cada vez que mueva mi cámara, dichas planchas roten automáticamente. Claro siempre se vería la misma imagen del árbol, aunque cambiase de ángulo, pero al menos permanecería frontal.
Y otro script que hiciese lo mismo con las planchas invisibles para el render, pero visibles para la sombra. Que permaneciesen perpendiculares a un foco de luz, y rotasen si éste foco de luz se moviese para mantener esa perpendicularidad.
Existe algún script así para max? Sobre todo, el de la cámara, que sería el más útil en principio.
Creo que en LightWave hay un plugin que lo hace, que se llama facecam, pero para max no conozco nada. Saludos.
Para hacer todo eso no necesitas ningún script, cualquier programa decente lo puede hacer con constraints (restricciones?) y un poco de imaginación.
No te puedo ayudar con 3ds Max porque uso Blender, pero poderse se puede.
Festivamente. Tienes razón. Estoy probando la restricción de orientación del 3ds Max, en el menú animación. Y puedes enlazar las planchas a una cámara. No te las pone perpendiculares, eso lo tienes que hacer tú, pero cada vez que mueves la cámara, la plancha se gira manteniendo el mismo ángulo inicial, así que, cumple su cometido.
El problema que le he visto, es que, al subir la cámara y hacer la toma más picada, la plancha también rota tumbandose. Después de pelearme un rato, no he conseguido evitarlo. No me deja elegir los ejes manualmente para eliminar ese eje de rotación que no me interesa nada, ya que desvirtúa el árbol (donde se ha visto un árbol acostado?) o a lo mejor no he sabido dar con la tecla, muy posible.
En otro hilo alguien me dijo un truco clonando otra cámara para evitarlo. Lo que me extraña es que no haya una forma más directa dentro de la misma herramienta para restringir el eje de rotación que uno quiera. Saludos.
En el panel motion, puedes restringir el eje de rotación de los objetos. X, y o z para que así no gire en todos los ejes.
No he podido terminar el código, no sé nada del Maxscript, así que, me puse a estudiar algo y quizá lo que tengo esta todo mal, lo que hice es que mediante un script el plano cambie de id al cambiar su ángulo, aplicándole un material de las imágenes del árbol en varios ID para que al cambiar su ángulo cambie de id y a su vez de imagen del ángulo del árbol, lo malo de esto es que no he encontrado la forma de solucionar un problema, que al rotar el ángulo del plano no cambia de id si no asta evaluar el código otra vez y así sucesivamente.
Muy buena pinta el tutorial de Maya Cristóbal.
Estas con el maxsciptí yo empesén el code para este tutorial en 3dsmax, pero lo dejé por falta de tiempo.Cita:
No he podido terminar el código, no sé nada del Maxscript, así que, me puse a estudiar algo y quizá lo que tengo esta todo mal, lo que hice es que mediante un script el plano cambie de id al cambiar su ángulo, aplicándole un material de las imágenes del árbol en varios ID para que al cambiar su ángulo cambie de id y a su vez de imagen del ángulo del árbol, lo malo de esto es que no he encontrado la forma de solucionar un problema, que al rotar el ángulo del plano no cambia de id si no asta evaluar el código otra vez y así sucesivamente.
Si has visto algún tipo de script cono java o php, veras que es parecido, suerte y ya nos contaras.
TBC3D, efectivamente estoy con el Maxscript, he intentando hacer esto, ya casi lo consigo.
No jodas, que bueno, sería un puntaso. Yo me fui de rosca y ya estaba haciendo pruebas con figuras en movimiento, imagina una secuencia del señor de los anillos, un montón de orkos por el monte.Cita:
TBC3D, efectivamente estoy con el Maxscript, he intentando hacer esto, ya casi lo consigo.
Algo de esto comentaba más arriba. Un saludo y suerte.