csRollingBall from César Sáez on Vimeo.
En principio pareciera que animar una esfera rodando por una superficie no representa ningún problema pero en la práctica y debido a que resulta muy fácil caer en gimbal lock (inevitable según la trayectoria que siga la esfera) se puede tornar en una tarea que al menos requerirá de bastante tiempo de ajuste y prueba y error. Pensando en esto hice un script para 3dsmax que automatiza la animación y además permite bakear esa animación evitando luego problemas al "renderear" en varias máquinas.
Lo que hace el script es crear un mini rig para la esfera seleccionada donde añade un rotation script al padre de la esfera, ese rotation script calcula en quartenions la rotación en función de su movimiento con respecto al frame anterior y su radio.
Esta semana pretendo trabajar en una integración un poco más genérica que no dependa de ese mini rig y que haga el bake directamente dentro del rango de frames que le demos, a ver si hay suerte :)
Salu2
lunes, agosto 18, 2008
csRollingBall
domingo, agosto 10, 2008
Rigging Notes: Squash&Stretch (part 3)
Al fin! tras dar muchas vueltas he llegado a una solución, voy a tratar de explicarla lo más claramente posible para el que le interese seguirla pero antes que nada quiero explicar algunas cosas para que se entienda más fácilmente como llegar a la solución.
Parábolas, parábolas y más parábolas... ese es el dilema en este tema, antes de mostrar las expresiones necesarias y tal quiero que unifiquemos un concepto: "funciones".
Que son las funciones (matemáticas)?
Seguro en wikipedia hay una descripción sumamente correcta pero para este ejercicio y sin querer entrar demasiado en profundidad vamos a entender a una función matemática como la relación entre 2 "variables" que nos permiten obtener los valores deseados.
Me explico: siempre que hacemos alguna expresión o relacionamos 2 cosas recurrimos a una función, por ejemplo si quiero que el cubo 1 se mueva en X la mitad que el cubo 2 lo más probable es que metamos una expresión en la posición X del cubo 1 que diga algo como 'cubo2.posX / 2' (dependiendo del software la sintaxis cambia). Lo que acabamos de hacer es definir una función equivalente a "y = x / 2" cuyo fin es calcular los valores de y para los distintos valores posibles en X, define una relación entre ambos parámetros.
Hace unos párrafos comentaba que las parábolas son la clave en este asunto, antes de pasar al 3D sería importante saber ¿porque parábolas? si analizamos la 2º parte de esta investigación personal notaremos que el modelo matemático que define la conservación de volumen a lo largo del elemento corresponde a una parábola (al menos a eso llegué), suena complejo pero si uno ve gráficamente la curva de un SS puede apreciar que no es una recta y que esa curva se parece mucho al arco que sigue una parábola.
Y ya que hablamos de funciones y de parábolas... cual es la función que define a una parábola?
Y = X^2 (se lee y es igual a X cuadrado)
Ya estamos casi listos, nos falta encontrar un método rápido para graficar una función, se puede hacer por scripting en nuestro software 3D pero a mi me resultó especialmente útil esta página, simplemente pones la función y un applet java la grafica por uno al instante :)
Ahora ya podemos empezar a hablar sobre el rigging de esta cosa :)
________________
El problema:
Necesitamos calcular el escalado "por elemento" basándonos en el SS general del rig.
Con que contamos?
Tenemos 1 spine IK compuesta de 5 elementos con SS (sin conservación de volumen aún), los 2 controles IK de la ik spine y un parámetro que se refiere a la posición de la influencia máxima del SS.
Paso 1: Conservación de volumen general
Sabemos que nuestro rig debe conservar volumen respecto a la posición del control general pero debe hacerlo de "modo local" para cada elemento (cada elemento tendrá distinta escala). Como en todo problema es conveniente ir resolviendo de menos a más asi que creo que es pertinente mencionar al menos como calcular la conservación de volumen general (la solución estándar mencionada en la parte 1)
Debemos saber:
Distancia entre los 2 controles ik (la calcularemos con una expresión)
Largo de nuestro rig (sin SS)
Debemos calcular:
Debemos calcular que porcentaje de "estiramiento" tiene el rig actualmente con respecto al original, para ello con una "regla de 3 simple" podemos llegar a ese porcentaje.
largo(sin SS)/100% = distancia/ x%
x% = 100% * distancia / largo
Con eso tenemos el porcentaje de cuanto se estira/aplasta, para mantener volumen lo que debemos hacer es escalar en los ejes transversales la inversa de eso y tendriamos nuestra conservación de volumen global.
SS = 1 / (distancia / largo) = largo/distancia
Paso 2: Calculando la posición de los elementos
Sabemos que cada elemento del rig debe tener un factor de escala diferente para que se genere ese falloff que buscamos, por consiguiente sabemos que tenemos que relacionar de alguna forma la posición de estos elementos con la de los extremos de nuestro rig. Dependiendo como esté montado el rig podemos tenerlo "gratis" o debemos calcularlo nosotros mismos.
Posición de los elementos "gratis":
Si los elementos van montados sobre una curva mediante un constraint/"motion path" probablemente tendremos un valor que nos indique en que porcentaje de la curva se encuentra (o la coordenada en U de la curva nurbs).
Calcular la pos porcentual de los elementos:
En caso de que los elementos no tengan esa relación creada (una ribbon spine por ejemplo) tocaría calcularlo, es básicamente el mismo concepto que con el % de estiramiento que comentaba arriba pero esta vez con respecto al control IK de la base del rig.
distanciaControlesIK / 100% = distanciaElemento / x%
x% = 100% * distanciaElemento / distanciaControlesIK
Paso 3: Graduando el SS con respecto al centro (posición fija)
Sabemos que el modelo matemático que tiene que ver con la forma en que se conserva el volumen tiene que ver con una parábola entonces veamos como hacemos para convertir todo esto a números :)
Se acuerdan de la parte 2 de estas notas? En resumen llegamos a que la relación entre la distancia de máxima influencia y la posición relativa de cada elemento era algo como:
y = 1- 4 * (distElemento - 0.5)^2
NOTA: 4 es la amplitud para que funcione bien con la zona de máxima influencia en el centro, Ya hablaremos de esto más adelante.
Esto nos daba un factor donde entre más cercana esté la posición relativa del elemento con la de máxima influencia (0.5, el centro) se hará 0 (cero), mientras que a media que se aleja llega a 1.
Ahora... como podemos relacionar el SS global con esta función? Potenciación!
Básicamente si elevamos cualquier número a 0 (cero) nos da 1 y si lo elevamos a 1 nos da el propio número:
a^0 = 1
a^1 = a
De esta forma si elevamos nuestro factor de SS global con el de conservación de volumen local obtenemos el falloff que estamos buscando, quedaría asi:
SSGlobal ^(1 - 4 * (distElemento-0.5)^2)
donde "SSGlobal = largo/distancia" como comentamos anteriormente.
Perfecto! tenemos nuestro falloff... pero aún nos falta algo, si cambiamos el control que define la distancia (distControl en la función) veremos que no se actualiza correctamente cuando la zona de máxima influencia está en los extremos. Eso sucede porque el falloff está calculado para la distancia desde el centro a los extremos y no desde un extremo al otro, lo que define eso es la amplitud y en nuestro caso la tenemos fija al valor 4.
Paso 4: Calculando una amplitud variable:
La amplitud es lo que determina que tan abierta es nuestra parábolacon un valor de 4 es lo suficientemente abierta para que si x = 0.5 (dist porcentual entre el pto de máxima influencia y el elemento) nos de un valor de cero y si x = 0 nos de un valor igual a 1.
El problema está en que para que funcione correctamente debemos abrir o cerrar la parábola en función de la posición de cada elemento y para ello debemos buscar una ecuación que nos permita que cuando la dist porcentual entre el pto de máxima influencia y el elemento (x) sea 0.5 nos de un valor de 4 y que cuando x = 0 = 1 nos de un valor de 1. La respuesta: Nuevamente una parábola!
En este caso:
4 - 12 * ( x - 0.5 ) ^ 2
donde x es la dist porcentual entre el pto de máxima influencia y el elemento.
Parte 5: Uniendo todo!
Ahora que tenemos todo calculado en funciona de los elementos que queremos calcular la expresión final nos debería quedar algo como.
(largo/distancia) ^(1 - (4 - 12 * ( distElemento-distControl - 0.5 )^2) * ( distElemento - distControl )^2)
Lo que aplicado a XSI (en una expresión sería)
pow( 1 / spine_csaez.spineCurve.Spine_Control.scale, 1 - ( 4 - 12 * pow( spine_csaez.volumeCtrl.Position * 0.01 - 0.5, 2 ) ) * pow( 0.01 * ( this.kine.pathcns.perc - spine_csaez.volumeCtrl.Position ), 2 ) )
Wow, intimidante no? jeje
Con esa expresión en cada escalado en los ejes Y Z de nuestros elementos podemos lograr un resultado como el que buscabamos más un control animable (en mi caso del 0 al 100) que permite mover la zona de máxima influencia... a todo esto muchos se preguntará para que moverla? porque si la puedo mover es relativamente sencillo scriptar todo esto y tener una solución aplicable a brazos, piernas, espaldas y a la mayor parte de los elementos de un rig con SS, es dar la flexibilidad a la solución para poder ser aplicada en diversas zonas de nuestro rig sin tener que reinventar la rueda cada vez que se quiera utilizar :)
Supongo que no hay ser en el planeta capaz de leer todo, quedó bastante extenso, pero quería cerrar en esta tercera parte (me queda scriptarlo pero de eso no pretendo comentar nada en el blog, no tiene mucho sentido). Si la explicación es extensa imagínense lo que me costó dar con ella! espero que la disfruten e implementen en sus rigs, vale la pena ;)
Salu2
miércoles, agosto 06, 2008
Rigging Notes: Squash&Stretch (part 2)
Hola, continuamos con la segunda parte de las notas personales sobre temas de SS y su conservación de volumen en jerarquías, para el que no sabe a que me refiero lo remito a la parte 1 donde trato de comentar "la problemática".
Ok, entonces quedamos en buscar la forma de lograr un falloff en el stretch. Pareciera evidente que vamos a necesitar una serie de deformadores a lo largo de nuestro hueso para poder lograr definir diferentes niveles de escalado según el SS a nivel global, por otro lado también parece evidente que a cada uno de estos huesos le necesitaremos calcular un "factor" con el cual definir la cantidad de stretch según la posición de un ayudante en una curva o algún atributo personalizado que agreguemos a nuestros controles. Bajo esa premisa trataré de ir exponiendo poco a poco como he planteado el problema hasta ahora y la solución con la que he dado hasta el momento.
Ok, para aislar el problema vamos a tratar de hacer lo siguiente, vamos a poner 5 cubos independientes uno al lado del otro y un control con un constraint a una curva que trataremos de vincular a el escalado de cada hueso, el efecto al que deberíamos llegar es algo asi como el que se ve en el dock de macOSX cuando se pasa el cursor sobre los iconos. Cuando logremos solventar todos los problemas supongo que en lugar del null sobre la curva podremos usar un atributo normal, esta forma de hacerlo es sólo para mantenerlo todo lo más gráfico posible :)
Nuestro escenario:
El constraint nos brinda un parámetro (%age en XSI) que representa que porcentaje recorrido lleva en la curva, como queremos calcular un factor en funciona a la posición de ese null lo primero que habría que hacer si o si sería expresar la distancia entre cubos de forma porcentual para que todo esté en un "mismo idioma", de esta forma tenemos que el cubo 1 está en el 0%, el 2 en el 25%, el 3 en el 50%, el 4 en el 75% y el 5 al 100% (en el rig real calcularemos estas pocisiones, por ahora no tiene sentido concentrarnos en eso).
Como relacionar el %age del null con el de los cubos?
Esta es la parte más interesante de decifrar para mi, vamos a tratar de llegar a una expresión que lo permita! un poco de prueba y error y con suerte llegaremos al modelo matemático adecuado :)
En una primera instancia pensaba en restar el %age con el % del elemento para de esa forma lograr un falloff a medida que se acercan (el valor se iría gradualmente a cero) pero enseguida nos encontramos con otro problema, el falloff sería lineal! es decir, la curva hacia el lugar de máximo SS sería una linea lo cual porsupuesto no tiene mucho sentido.
Entonces... como logramos una curva? mmm busquemos entre las funciones matemáticas que graficadas se acerquen a lo que buscamos, yo estube tratando de dar con una y la más manejable y a la vez simple es una simple parábola del tipo y = x^2, esto nos daría una parábola hacia arriba pero jugando un poco con la ecuación llegue a que algo como y = 1- (amplitud)*x^2 nos da una curva que es ideal para nuestros propósitos.
Grafiquemos (con un script en nuestro programa 3d no debería ser muy difícil) la curva con diferentes amplitudes para entender un poco más de que estamos hablando! a mi me da algo como lo que sigue (variando la amplitud de 0.5 hasta 4):
Yuju! tenemos nuestra expresión que nos permitiría un falloff perfecto para este caso! ahora sólo nos queda incluirlo en una expresión dentro de la escala de cada caja y debería funcionar. La expresión que estoy usando en cada caja CONCEPTUALMENTE (para no limitarlo a ningun software) es algo asi:
Si:
1 - (módulo de (%_en_path - %_elemento)/100) * multiplicador < 0
entonces:
100% de escala
en caso contrario:
1 - (módulo de (%_en_path - %_elemento)/100) * multiplicador
Escrito como expresión para XSI sería algo asi (para la primera caja)
cond( ( 1 - null.CustomPSet.multiplier * ( abs( null.kine.pathcns.perc - 100 ) / 100 ) ) < 0, 1, 1 + ( 1 - null.CustomPSet.multiplier * ( abs( null.kine.pathcns.perc - 100 ) / 100 ) ) )
Y el resultado de todo este experimento resulta en algo como el siguiente vídeo.
Ahora, que tan correcta es la expresion que logramos para definir la futura curvatura del SS en nuestro rig?
En XSI no hay un deformador de SS propiamente tal pero hice un par de pruebas con 3dsmax donde si tiene un modificador y la comparación de una caja con stretch versus la función ploteada es la siguiente.
Como se puede ver el modelo matemático pareciera ser el mismo que el del modificador de 3dsmax! we got it!
Que nos queda?
Aplicar todo esto a un rig y vincular esta conservación de volumen al largo de una cadena de huesos (o lo que sea), eso quedará para la parte 3.
Salu2
lunes, agosto 04, 2008
[update] csRuler
Hola, no se si se acuerdan de un script que hice casi hace 7 meses que genera una regla para medir en XSI? bueno, producto de mil problemas para encontrar un lugar estable donde hostearla he decidido subir algunos scripts a highend3d.com, porque highend3d? porque es una comunidad muy estable y tiene toda una estructura que permite mantener al día scripts sin dejar regada la web de versiones que no necesriamente son la más reciente.
¿Que hay de nuevo en la versión 0.2?
- Los clusters de la curva ahora están "lockeados" para evitar problemas de representación (gracias por la sugerencia Alan!)
¿Que hay de nuevo en la versión 0.15?
- Limpieza del código.
- Ahora es Addon para una instalación más sencilla (drag&drop).
- Ahora se puede encontrar la csRuler directamente desde Model -> Get -> Primitive
Link de descarga
__________________
Por otro lado hace unos meses me llevé una grata sorpresa cuando Alan Fregtman me comentó que había introducido csRuler como una herramienta auxiliar en TopixFX y que salvo algunas pequeñas correcciones el script funcionaba bastante bien para ellos. Siempre es grato hacer herramientas que sean útiles y no queden en el baúl de los recuerdos, recibir feedback es muy motivante!
domingo, agosto 03, 2008
Rigging Notes: Squash&Stretch (part 1)
Hola, hace unos días que me viene rondando en la cabeza que la solución del squash&stretch (SS de acá en más) no está del toda resuelta en la mayoría de los rigs que populan la red y hay aún ciertas cosas que pareciera no se toman en cuenta, yo obviamente me incluyo en el grupo de los que no lo tenemos resuelto pero poco a poco me gustaría ir pensando en voz alta y exponiendo la problemática que veo a la actual solución estándar de SS y ojalá proponer alguna solución.
Ok, arranquemos.... que tiene de malo la forma de lograr SS en la mayoría de los rigs que rondan por internet (la forma estándar)? primero no es que tengan algo "malo" (de hecho funcionan!), es sólo que la forma de resolver el problema para mi gusto no logra una conservación de volumen fiel al concepto en 2D y me gustaría explorar soluciones junto con ustedes. A continuación explico más en detalle a que me refiero.
Supongamos que tenemos 1 cadena de 1 hueso (2 joints) con SS que deforman una esfera. La forma estándar de hacerlo sería obligar a que la longitud del hueso sea igual a la distancia entre el hueso/joint y el effector de la IK, luego para conservar volumen probablemente diremos en la escala de los ejes correspondientes que "1 / raíz cuadrada de (largo actual / largo original)". Dependiendo del software varía la forma de hacerlo pero a razgos generales esa es la lógica, algunos lidearán con escalados (como Maya) y otros con longitudes (3dsmax/XSI) pero la base es la misma.
Para concretar algo usaré XSI, hice un setup como el que comentaba arriba y logramos algo como esto:
Nada extraordinario, pareciera funcionar bastante bien, ahora probemos hacer exactamente lo mismo pero con un cilindro en lugar de esfera:
Oops, a esto me refería! no es que esté mal pero no les dá sensación de escalado más que de SS? no les parece que la conservación de volumen pese a ser aplicada de forma matemáticamente correcta se ve algo "robótica"?
Hace días que vengo pensando en que esta forma de emular el SS no está del todo lograda, en este caso me dirán "claro, es sólo 1 hueso" pero acaso en la mayoría de los rigs no se hace prácticamente lo mismo? se aplica una conservación de volumen uniforme a todos los componentes cuando yo creo que se debería buscar una curvatura/falloff tal como se dibuja en 2D. Es común ver piernas que se estiran sin lograr que en la zona de la rodilla sea levemente más delgada que la cadera o el pie, o columnas que se aplastan de forma uniforme en lugar de que tenga más squash en la barriga que en la cadera o el pecho. Esa uniformidad en la conservación es lógicamente más rápida de configurar pero creo que no logra plenamente el objetivo del rig, es un detalle que aparentemente a nadie pareciera importarle pero que bajo mi perspectiva puede marcar una diferencia clara en el appeal del personaje.
Ok, entonces como lograrlo? esa es la pregunta! yo creo que primero deberíamos trazar los requerimientos para luego buscar formas de solucionarlo. Me parece que necesitamos además de un SS gradual algo que nos permita establecer donde queremos la zona de máxima influencia de la conservación de volumen y en segundo lugar (y ya que estamos entrando al mundo cartoon) creo que sería útil tener un multiplicador animable del efecto.
El multiplicador supongo que con un valor numerico puesto en algún atributo queda solucionado pero el control de la zona con mayor conservación de volumen me gustaría que fuera algo más visual. Pensando en voz alta me imaginaba un null/locator/helper con un constraint a una curva que siga el rig (supongomos una columna) donde su posición dentro de esa curva establezca el lugar de máxima influencia, sería algo bastante cómodo para el animador y a la vez un lindo desafío al tener que hacerlo todo procedural :)
Entonces como seguimos? eso queda para la parte 2, para la próxima entrega ya estaré en condiciones de poner un par de pruebas con el control de influencia gradual (al menos es mi objetivo) y luego más adelante veremos como implementarlo en un rig usable (ribbon spine quizás?), ya veremos que pasa, por ahora dejo la inquietud planteada.
Salu2!
viernes, agosto 01, 2008
csTwist, twist bones al instante!
3dsmax no es mi software favorito para hacer rigging pero poco a poco me he ido armando un toolset para rigging que me permite trabajar más cómodo y rápido, la última adquisición es un script para hacer twist bones, básicamente eliges un punto de inicio, uno de término y el eje en el cual quieres que haga el falloff (el falloff va desde el punto inicial al final, es sólo en 1 sentido).
Les dejo un videillo rápido mostrando más o menos como funciona el script y un ejemplo "real" de aplicación :)
csTwist from César Sáez on Vimeo.
Espero que les guste!
sábado, julio 12, 2008
Preguntas y respuestas: XSI, Maya, 3dsmax y Blender
Siguiendo la Sugerencia de Pablo en los comentarios de la entrada anterior voy a tratar algunas preguntas en una entrada aparte para dejarlas más a la vista de quien le interese leerlas.
Antes que nada aclarar que es sólo MI OPIONIÓN ACTUAL y que no se debe tomar como nada más que eso, es sólo una opinión que mañana puede cambiar y que no tiene porque ser la verdad absoluta, es sólo como yo veo las cosas actualmente.
¿Porque decidiste meterte más con el Softimage XSI?
Pregunta de Juan Carlos Cruz García
En principio todo arrancó porque hace unos años yo estaba bastante obsesionado con mental ray y como usuario de 3dsmax en aquella época era muy difícil encontrar shaders/recursos que se comentaban para otros softwares y en muchas ocaciones me topaba con algunos "puntos débiles" en la integración de mental ray a 3dsmax.
Un ciber-amigo en 3DPoder (Pablo, alias Rashek) me comentó las maravillas de la integración de Mental Ray en XSI y me dijo que ¡tenía que probarlo!, me insistió tanto que lo instalé y el me fue guiando en mis primeros pasos con XSI. En principio no me gustó demasiado, todo se me hacía engorroso y volví a 3dsmax... pero luego cuando lo volví a intentar y limpié mi mente de comparaciones al fin pude ver lo que realmente me ofrecía XSI y me terminó gustando mucho! no tan sólo la integración con mental ray (que es la mejor sin duda) sino la filosofía del software, su estructura e incluso la política de desarrollo que tienen con el software la gente de Softimage.
¿Cuál es la diferencia de Maya, 3dsmax y XSI?
Pregunta de Juan Carlos Cruz García
Son softwares diferentes y tienen una estructura diferente entre si. Depende a que nivel lo quieras ver, como usuario puede que las diferencias no sean tantas (más allá de la interface y una que otra feature) pero cuando quieres profundizar un poco más te encuentras con "el abismo" :)
Para mi (y esta es una opinión personal, no lo tomes como ley) Maya y XSI tienen muchísimo más potencial que 3dsmax básicamente por su estructura. Verás, en 3dsmax muuuchas cosas se fueron agregando sin una mayor planificación ni preparación del core del programa, el resultado es que hoy en día es bastante desordenado todo y no es tan fácil de acceder a cierta información del programa (mediante el SDK) lo que a la larga (o corta) te limita técnicamente en mucho sentidos. Se da mucho que cada herramienta es un mundo propio y no necesariamente comparte criterios con la que está al lado (efecto secundario de la compra de plugins y la política de "desarrollo" de Autodesk), el software termina siendo la suma de muchos módulos que por si solos hacen bien su trabajo pero que si los quieres combinar o aprovechar sus características para hacer algo extra a lo que pensaron sus desarrolladores las cosas no siempre funcionan (no hay tanta flexibilidad si te sales de lo habitual).
En XSI o Maya el panorama es muy diferente, generalmente los diversos módulos del software conviven de mucho mejor forma entre si y eso te permite utilizar lo mejor de cada uno para crear algo nuevo. Eso te da una flexibilidad y versatilidad que los hace mucho más viables de usar en casos donde lo que "viene de fábrica" no siempre satisface tus necesidades o bien no quieres amarrarte a el workflow o "la-forma-de-hacer-las-cosas" del software en cuestión.
Entre XSI y Maya también hay diferencias, yo creo que Maya es un GRAN software pero a veces lo encuentro un poquitín "viejo" en algunos aspectos, está muy bien pensado pero creo que se está quedando un poco en el pasado (y ahora que lo tomó Autodesk el panorama pinta peor aún). XSI tiene un core mucho más nuevo/moderno que a mi en lo particular me resulta cómodo y me parece que es el software al que hay que apostar, Softimage hace un gran trabajo en su desarrollo creando en cada versión herramientas novedosas (GATOR, DELTA, MOTOR, ICE, etc, etc, etc) y no limitándose a comprar el plugin de moda o imitando lo que hace el vecino.
Que pensas de blender? en comparación con las potencialidades de los otros soft.
Pregunta de Pablo Lizardo
Yo Blender lo conozco muy poco como para dar una opinión con un real conocimiento de causa, me parece que su avance en estos 4~5 últimos años ha sido impresionante! también me gusta mucho la filosofía de Blender Institute de hacer proyectos interesantes (Orange, Peach y Apricot) en los cuales ver que es lo que realmente hace falta en esas producciones y desarrollar el software en base a eso.
Ahora bien, siendo justos con la respuesta anterior habría que comentar la parte que para mi refleja realmente la versatilidad de un software para hacerlo "todo terreno", lo que en gran medida define su flexibilidad en una producción y que a veces no está tan a la vista de todos. Hace no mucho vi una entrevista a Ton en la que se refiere a la estructura actual de Blender y los cambios que están haciendo para la 2.5. Yo no sé lo suficiente de Blender como para opinar en base a mi experiencia pero la forma en que describe la estructura actual de Blender justamente denota algo parecido a lo que comentaba con respecto a 3dsmax, no hay una estructura unificada e incluso no hay acceso a cierta información de la parte antigua de Blender. Lo bueno es que para la 2.5 van a reescribir gran parte del core de Blender (lo que es algo muuuuuy importante) y tratarán de solventar esos problemas, es una gran noticia que además de incluir las herramientas de moda se preocupen por los cimientos y afronten el problema, probablemente halla que reescribir mucho y no será algo que se pueda hacer de la noche a la mañana pero al ser open source muchos desarrolladores desinteresados pueden ayudar a terminar la tarea haciéndolo algo mucho más factible que para cualquier software comercial.
Blender va muy bien encaminado, pasó de ser "una cosa rara" a un software que no tiene mucho que envidiar a cualquier gama-alta. Creo que dentro de poco comenzaremos a ver más y más trabajos profesionales hechos con Blender, ciertamente hoy por hoy su "no uso" en la industria no tiene que ver con su capacidad sino con el mercado que se tiene que ganar, yo creo que de aquí en más llega la hora de cosechar para Blender ;)
