Tema: Challenge Nº3: "Rig conjunto" WIP César Sáez

[Cesar Saez]

Edito para rescatar un videillo con el resultado de esto y que la gente no tenga que recorrer todo el hilo para entender de que va el rollo.




00:00 - Intro
01:00 - Rig overview
03:00 - Init
05:22 - Multipose setup
09:05 - Main setup
10:30 - Spine setup
12:35 - Head setup
15:00 - Left leg setup
22:55 - Right leg (via template)
25:35 - Left arm setup
31:25 - Right arm (via template)
33:50 - Closing

----

Hola,

Ya se que este desafío lleva un buen tiempo dormido/acabado pero en estos días he estado pensando seriamente en hacer un nuevo autorig (el 4to, ufff) utilizando las lecciones aprendidas de los anteriores, creo que este desafío es una buena oportunidad para volcarlo en un personaje libre de contratos de confidencialidad y restricciones por el estilo. También sé que pronto implementarán soporte para escribir Kinematics en ICE y quizás no merece la pena ponerse ahora con esto pero como no hay deadline que cumplir me lo pretendo tomar con calma y disfrutar del proceso

El enfoque inicial del reto no se adapta exactamente a lo que pretendo lograr, quiero hacer un rig modular y la base deformable quizás no es tan intercambiable como en un rig "tradicional", de todas formas intentaré cubrir todas las áreas del personaje propuesto (afortunadamente es sencillo) y que salga algo animable de todo esto.

Por que hacer un WIP del proyecto?
Porque me encantaría recibir vuestros concejos y sugerencias, ya sea desde un punto técnico como desde el punto de vista del animador y sus necesidades, todos los comentarios son y serán bienvenidos.

Por ahora no llevo nada, sólo las ganas de hacerlo, en cuanto monte un poco la base del sistema ya les iré mostrando avances y quien sabe si al final de todo esto tenemos un nuevo rig gratuito que tanta falta le hace a la comunidad de XSI


Por cierto, pretendo desarrollar el autorig y las herramientas que rodeen al rig en python, pyQT es una muy buena alternativa para la GUI pero por temas de portabilidad usaré el soporte nativo.

[Cesar Saez]

Propuesta para la convención de nombres.

MODELS/SUBMODELS (4 campos)

tipo_nombre_descriptor_terminador

donde...
- tipo: "C" (character)
- nombre: nombre del personaje
- descriptor: descripción del contenido del model (mesh, faceRig, defRig, animRig, etc).
- terminador: "X", es para mantener el nombre único de los models ante múltiples instancias.

OBJETOS/COMPONENTES (4 campos)

lado_parte numerador_descriptor_tipo uso

donde...
- lado: "L", "M", "R" (esto no lo tengo tan claro, bastará con 1 caracter?)
- parte: sección a la que pertenece (leg, arm, spine, head, tail, etc)
- numerador: usaré nombres genéricos para fácil categorización posterior, acá irá la numeración
- descriptor: breve descripción de la función del objeto
- tipo: "D" (dummies), "S"(shapes), "B"(bones)
- uso: "H" (hidde), "F" (frozen), "A" (animated), "D" (deformer)

La convención es levemente diferente a la que acostumbro usar y necesito comentarios y sugerencias, seguro que me estoy dejando mil cosas (clusters por ejemplo) pero de momento es una primera propuesta.

Que les parece?
Gracias

[Sumatra]

Que les parece?

Que tengo ganas de animar un rig tuyo
A estas alturas retiro mi propuesta de challenge que inicié en su día y me ofrezco como tester de los rigs que vayais haciendo las mentes pensantes.

Lo de los nombres no me molesta ni me importa, pero llegado el momento te sugeriré cosas con las que me encuentro agusto cuando animo, por si las quieres usar en tu construcción del rig.

[Kinght]

 Habrá que estar atento .. ánimo Cesar

[Cesar Saez]

Muchas gracias por los ánimos

A falta de comentarios técnicos sobre la convención de nombres (ya le preguntaré a Ángel el martes en el curro) me he puesto con la guía, de momento estará pensada/implementada para bípedos, los cuadrúpedos están dentro de los planes pero aún no lo implementaré.

En cuanto a programación he organizado la guía como un objeto en si mismo que contiene subobjetos que corresponden a las partes del bípedo. El Objeto de la guía tiene métodos para simetrizar los puntos de control, control de visibilidad y tal mientras que los subobjetos/partes tienen un "estado" que luego pretendo utilizar para deducir que debe crear el autorig. Me falta por hacer el exportador e importador a XML (para salvar/cargar presets).

Sobre los nombres tengo una pregunta técnica... convendría hacerme una API de nombres antes de seguir no? como debería enfocarla?

Dejo una capturilla de la guía, no es gran cosa pero al menos así parece que esto se mueve

Un saludo

[Ángel Sánchez]

Me parece un gran proyecto César, pero creo que por mi parte al menos, lo único que puedo hacer es leer y aprender, mi nivel no alcanza como para ayudar en esto... Así que seguiré mucho este proyecto (me interesa muchisimo) y esperaré ver tus avances.

[Rchals]

Un proyecto muy muy interesante. Intentaré ayudarte en lo que pueda, aunque mis conocimientos de python todavía no están a tu altura. :-P

[agedito]

Bueno, ya le he soltado todo el tostón a Cesar sobre los nombres. Más o menos resumiendo...

Con los nombres siempre hay que buscar un equilibrio entre uso y mantenimiento. Por ejemplo, convenio de nombres con campos opcionales es muy versatil para el usuario, pero luego la API de nombres se complica... Es más facil descomponer un nombre si sabemos cuantos y que campos tienen que si no.

Una restricción que le he sugerido es que el campo parte no termine en número, así facilmente podemos separar la parte del numerador sin tener que fijar un número de cifras fijo para el cardinal.

Respecto a la API, le he sugerido tener el convenio de nombres separado de la API en sí, de esa forma se pueden cargar distintos convenios de nombre para por ejemplo renombrar de un convenio antiguo a otro.

Hemos estado un buen rato hablando y alguna nueva me ha dado Cesar bastante interesante...

[Cesar Saez]

Gracias, ha sido una interesante charla

Ya tengo entretención para estrenar el nuevo cacharro

[Ángel Sánchez]

Novedades César? o en kandor no te dejan respirar?