De la mano de uno de nuestros redactores y diseñadores Rael del Fraile, nos llega este vídeo 3D del pequeño robot cabezudo de Star Wars, bailando al Rey del Pop:
Bien, ya podéis comentar por ahí que vosotros habéis visto a R2D2 bailando a Michael Jackson.
Vamos a simplificar todo lo de los Ohm (Ohmios), dB (Decibelios) y Hz (Hertzios). Hay mucha información técnica por internet explicando qué son, pero no responde a la pregunta rápida de ¿qué necesito valorar a la hora de comprar unos auriculares?, TripleClic pretende hacer la vida más sencilla, así que vamos a simplificar todo eso a un lenguaje más humano:
Hace algunos años, los teléfonos móviles eran accesorios comunes, pero sólo usados para realizar llamadas telefónicas. Pero a día de hoy, el tráfico que nuestras páginas web reciben de los teléfonos móviles no deja de incrementar, encontrándose ya a un nivel en que su importancia no puede pasarse por alto. Y con nuevas oportunidades surgen también nuevos desafíos – y preguntas.
Para facilitar las cosas, incluimos a continuación una lista de preguntas frecuentes, junto con sus respuestas, acerca de cómo optimizar las versiones sólo para móviles de sus páginas web, teniendo en cuenta tanto factores técnicos como de optimización en buscadores y experiencia de usuario.
El diseño web adaptativo presenta ciertas ventajas en comparación con crear una versión independiente y alternativa sólo para sus usuarios móviles:
No obstante, incluso cuando el diseño web adaptativo será probablemente la única tendencia que sobreviva en un futuro no muy lejano, crear una página web adaptativa en lugar de una página web alternativa optimizada sólo para móviles podría no ser la mejor opción si se dan unas circunstancias determinadas:
Si su situación es la contemplada en uno de los escenarios anteriormente mencionados, entonces lo más recomendable es que utilice una versión para móviles, separada de las páginas web de su sitio principal, y que optimice esta versión móvil tanto como sea posible. Esto quiere decir que:
A continuación se presentan otras preguntas frecuentes acerca de cómo optimizar el rendimiento de la versión móvil de una página web.
Existen dos enfoques para servir contenido optimizado para móviles a los usuarios de su página web: mantenerlos en la URL original, pero ofreciéndoles un contenido distinto, optimizado para móviles, o bien redirigirlos a una URL distinta en que podrían acceder a contenidos optimizados para móviles.
El primer enfoque tiene una ventaja desde el punto de vista de la optimización en buscadores: todos los enlaces que apuntasen a una de sus versiones móviles también apuntarían a su versión principal, pasando directamente su ranking a las URLs principales, puesto que ambas serían coincidentes.
No obstante, este enfoque también conlleva algunos riesgos mayores. En caso de tener problemas con esta configuración, como no identificar claramente cuáles son sus contenidos móviles y cuáles sus contenidos originales (en general, más completos) de cara a los buscadores, puede llevar a los motores de búsqueda a pensar que está enviando únicamente contenido muy resumido a todos sus usuarios, o que está utilizando tácticas de optimización reprobables como la ocultación de contenidos o enmascaramiento de URL.
También podrían presentarse problemas de cara a cómo sus usuarios móviles interactuarían con su página web. Si la URL no proporcionara información adicional a sus usuarios acerca de en qué versión de su página web se encuentran, algunos de sus usuarios podrían pensar que ésa es la única versión de su página web (sobre todo, si careciera de un enlace de "visitar la versión original" o si este no fuera lo bastante visible.)
Ése es el motivo de que redirigir a una versión optimizada sólo para móviles tenga sentido, ya que puede resultar más sencillo trabajar con ella, resultando esta muy clara y bien organizada. Pero para ello tiene que asegurarse de que esa URL queda identificada como sólo para usuarios móviles de cara a los motores de búsqueda de Internet, marcada como una versión alternativa, que no compita con sus URLs principales en los resultados de búsqueda.
Mientras que los smartphones de última generación vienen equipados con pantallas táctiles que ya no son tan pequeñas y con potentes procesadores, los teléfonos móviles tradicionales y los smartphones más antiguos pueden carecer de suficiente espacio en su pantalla, o de potencia suficiente en sus procesadores como para ofrecer una buena experiencia de navegación como para que navegar con ellos sea una experiencia lo bastante cómoda en la mayoría de sitios web.
La respuesta a esta pregunta depende de su negocio en particular. Sus estadísticas de navegación resultarán de gran ayuda a la hora de dar con la respuesta adecuada para su caso concreto. Las estadísticas de su servidor deberían darle detalles acerca de los dispositivos que los usuarios de su página web estén utilizando para acceder a ella. Si esa lista contuviera un porcentaje nada despreciable de usuarios utilizando teléfonos móviles antiguos, entonces crear una versión móvil específicamente optimizada para ellos tendría bastante sentido.
Sin embargo, los teléfonos móviles se encuentran en rápida evolución. Dependerá mucho de su mercado objetivo, y del país con el que esté haciendo la mayor parte de sus negocios, pero lo más probable es que los modelos obsoletos desaparezcan rápidamente, quedando sólo una generación de smartphones bastante más potentes, que se asemejarán bastante a pequeños ordenadores de sobremesa en cuanto a su capacidad de proceso se refiere. A causa de lo anterior, en el medio o no tan largo plazo, debería contemplar desarrollar su página web con ese tipo de smartphones en mente.
Después de todo, esto es a lo que apunta la tendencia actual del diseño web adaptativo: en un futuro no tan lejano, las versiones móviles y las versiones pensadas para ordenadores de sobremesa sólo se diferenciarán en la forma en que coloquen en pantalla la información. Mientras tanto, disponer de una única versión alternativa para teléfonos móviles, que sea concisa, rápida de cargar y fácil de navegar, debería satisfacer sin problema las necesidades de sus usuarios móviles.
Google recomienda etiquetar páginas que sean versiones alternativas para móviles siguiendo el planteamiento que se muestra a continuación:
El tamaño de pantalla se utiliza para distinguir a los dispositivos móviles, mientras que el tipo handheld se aplica para hacer referencia a modelos de teléfono móvil más antiguos. En el escenario más frecuente en que sólo se tiene una versión optimizada para móviles, estos indicadores serán etiquetas de enlaces alternativos que debería incluir en su versión original:
Y este es el enlace canónico que debería incluir en su versión móvil:
También puede etiquetar las versiones para móviles dentro de su sitemap.xml, marcándolas como versiones alternativas de una página principal. Cada versión alternativa para móviles debería ser asociada con la página web original con la que se encuentra relacionada. Con lo que el sitemap de su sitio quedaría algo así:
Es importante asegurarse de que esté redirigiendo exactamente a la URL especificada en estas etiquetas alternativas, o podría estar enviando información confusa a los motores de búsqueda, con lo que podría arriesgarse de que marcasen a su página web como spam.
Si su sitio web móvil no fuera un reflejo exacto de su sitio web original (es decir, si no tuviera una página web optimizada para móviles por cada una de las páginas web originales de su sitio web principal) entonces el enfoque más rápido sería también el más seguro: los sitios web móviles pequeños pueden redirigir todas sus páginas a la URL principal de la versión original de su página web, asegurándose de este modo de que todas las páginas web móviles de su sitio web ayudan a pasar pagerank a su página web principal.
Tenga en cuenta que, en un escenario ideal, todas y cada una de las páginas web de su sitio web se correspondería con una página web optimizada para móviles. Si no fuera así, se correría cierto riesgo de que marcadores de página guardados en un dispositivo concreto no llevasen al contenido esperado en otros dispositivos, o a otro casos que, en palabras de Google, serían redirecciones no relevantes — a menos que su página web ofrezca una solución muy concreta pensada en el contexto y segmento de mercado de sus usuarios móviles.
Actualización: en este artículo publicado por Google en su blog oficial, Changes in rankings of smartphone search results (cambios en los ranking de los resultados de búsqueda de los smartphones), Google actualizó lo que consideraría como una redirección no relevante. Según este informe, las páginas a las que se accediera desde un dispositivo móvil, y para las que no hubiera una versión específica optimizada para móvil, no deberían redireccionar a la página principal de su versión móvil, ya que eso sería considerado una redirección irrelevante a partir de ahora.
El enfoque recomendado para páginas que carecieran de versiones móviles consistiría en dejar al usuario acceder directamente a la versión original de la página, aunque no estuviera optimizada para móviles. El formato podría no estar optimizado, pero se garantizaría que el contenido al que el usuario accediera siguiera siendo tan relevante como fuera posible de acuerdo con su consulta de búsqueda original.
Aparte de esto, el enfoque subóptimo recomendado por Google consiste en tener una versión optimizada para móviles de todas y cada una de las páginas de su sitio web (lo que elimina por completo el riesgo de una redirección hacia contenido irrelevante). Mientras que el enfoque óptimo consistiría en utilizar un diseño web adaptativo en todo su sitio web, con una única versión que se vería de una forma adecuada en todo dispositivo posible.
Los navegadores de los móviles se identifican a sí mismos mediante sus user agents cuando solicitan la carga de una página. Discriminando según sus user agent puede enviarles contenidos distintos, o redirigirlos a una página web apropiada.
No necesita crear un listado completo de user agents desde cero. Ya existen fragmentos de código que se encargarán de eso por usted. Detectmobilebrowsers.com es un conjunto de programas de código abierto que se encarga precisamente de eso, ofreciendo fragmentos de código que funcionan en muy diversos lenguajes de programación (código para servidores Apache, Javascript, ASP, PHP, etc.)
Tenga cuidado con esta táctica, puesto que en el futuro pueden surgir nuevos dispositivos móviles. Existe una posibilidad de que el código que utilice para detectar dispositivos móviles se quede desactualizado y que no clasifique ciertos dispositivos dentro de la categoría correcta. Así que, asegúrese de que mantiene actualizadas sus reglas de detección.
Aparte del indexador de páginas web convencional, Google también tiene un rastreador web para webs móviles, Googlebot-mobile, independiente del Googlebot tradicional. Así que tendría sentido que este rastreador móvil accediese a la versión optimizada para móviles de su página web.
Sin embargo, Googlebot-mobile se presenta a sí mismo usando el user agent de smartphones populares. No tiene que considerar a Googlebot-mobile como un caso de redirección específico en el código de detección de navegador que esté usando. Google advierte que discriminar específicamente el rastreador móvil puede considerarse ocultación de URLs, lo que le podría acarrear una penalización a su rendimiento en los motores de búsqueda.
Existen un par de enfoques distintos a la hora de redireccionar a sus usuarios móviles hacia la versión optimizada para móviles. Puede realizar las comprobaciones apropiadas del user agent dentro del propio navegador web de su usuario utilizando una redirección Javascript. O puede utilizar en su lugar redirección en el propio servidor web, de manera que sería este servidor quien comprobase el user agent del dispositivo que le solicita una página web (directamente en el código del servidor utilizando reglas .htaccess en el caso de Apache, o en un lenguaje de programación que se ejecute en el servidor, como .NET, PHP, Ruby o similares).
El problema con una redirección Javascript es que parte de su página web original debería cargarse antes de que su usuario móvil fuera redirigido a la versión adecuada. Por otra parte, una redirección que tuviera lugar en el propio servidor dejaría para el servidor las comprobaciones y proceso relacionado con la redirección, evitando además la carga de contenido innecesario por parte de su usuario móvil.
Teniendo en cuenta que los usuarios móviles disponen de escaso ancho de banda y de capacidad de proceso limitada, las redirecciones que se realizan en el servidor son el enfoque más adecuado puesto que resultarán bastante más rápidas para sus usuarios.
Existen dos tipos principales distintos de redirecciones que se envían como respuesta del servidor a modo de cabeceras HTTP específicas:
Si utiliza cabeceras de repuesta para redirigir a sus usuarios móviles hacia la versión móvil adecuada, en las propias palabras de Google:
Para este propósito, no importa si el servidor redirige con un código de estado HTTP 301 o con un código de estado 302.
Así que no importa qué tipo de redirección se utilice para enviar a sus usuarios móviles hacia su versión optimizada para móviles.
Sin embargo, consideremos un escenario correspondiente al caso peor. Si hubiera alguna configuración inadecuada o problema en el proceso, según el cual los motores de búsqueda no entendieran adecuadamente cuál es la versión principal de su página web, y cuál es la versión optimizada para móviles, entonces utilizar redirecciones permanentes 301 desde su versión original hacia su versión móvil enviaría la mayor parte de su pagerank, tráfico o, en definitiva, usuarios, hacia una versión diseñada como alternativa, más sencilla, optimizada sólo para móviles. Un escenario como tal podría tener consecuencias desastrosas para su versión principal, y por tanto, para su estrategia de optimización en buscadores.
Ese es el motivo de que utilizar una redirección temporal 302 que apunte hacia su versión móvil sea una estrategia más adecuada en términos de prevención de posibles riesgos.
Google menciona como parte de sus directrices para móviles que, en caso de que use cualquier tipo de redirección, cualquier página que esté redirigiendo hacia otra debería incluir una cabecera HTTP Vary para notificar a potenciales rastreadores móviles que explorar esas páginas simulando ser un dispositivo móvil tendría sentido, puesto que distintos dispositivos verían resultados distintos. De ese modo, Google indexaría todas sus páginas móviles, entendiendo mejor la estructura de su página web.
Esto es también cierto para las páginas web que utilizan la misma URL para enviar tanto contenido optimizado para móviles como el contenido principal pensado para el resto de sus usuarios (lo que normalmente se conoce como dynamic serving o envío dinámico). En este caso, utilizar la cabecera Vary se convierte en algo incluso más importante, puesto que los buscadores no dispondrían de ninguna otra forma de saber si existe una versión móvil para la página actual (al encontrarse todas las versiones bajo la misma URL.) También debería asegurarse de que la versión optimizada para móviles no fuera considerada como contenido oculto o enmascarado, o que el contenido de la versión móvil fuera confundido con el contenido de su versión principal. Anunciar diferencias de contenido según el navegador del usuario le vendría muy bien para aclarar estos posibles escenarios.
La cabecera Vary debería enviarse indicando que los contenidos de esa página pueden variar dependiendo del user-agent, con lo que ése debería ser precisamente su valor:
Definitivamente. Algunos de sus usuarios aún querrán acceder a los contenidos completos de su versión principal si tienen la sensación de que no están viendo todos los contenidos de que podrían, y de que su smartphone de última generación podría ser lo bastante potente como para navegar sin problema en la versión principal de su página web.
Si su versión optimizada para móviles fuera lo bastante corta y sencilla (como debería ser), entonces debería incluirse un enlace que apuntase al artículo original relacionado de la versión principal, hacia el final de la página: no habría necesidad de ir hacia la versión regular de la página web si la versión móvil ya facilitase suficiente información por sí misma. No es habitual que un usuario móvil decida ir a la versión principal de una página web nada más aterrizar en dicha versión móvil.
Sin embargo, asegúrese de mostrar este enlace de una forma fácil de ver para sus usuarios. Es verdaderamente importante que haga saber a sus usuarios que existe una versión distinta, potencialmente más completa y vistosa, que también podrían visitar si así lo quisieran.
Esto se vuelve especialmente crítico si sus contenidos optimizados para móviles se proporcionan desde la misma URL que utilizaría para mostrar sus contenidos originales, ya que en este caso ni siquiera la URL daría alguna pista acerca de la existencia de otra versión normal, no optimizada para móviles.
En un escenario ideal en que cada página de la versión original tuviera asociada una página optimizada para móviles, los enlaces que llevasen a la versión original desde las páginas móviles deberían precisamente apuntar a la página relacionada correspondiente, la cual hablará de un tema similar y presentará también un contenido similar.
Ahora bien: la situación puede ser algo más delicada si la parte de su sitio web optimizada para móviles sólo comprendiera un subconjunto del contenido total de la versión original. Este escenario puede tener sentido si lo que busca es ofrecer a sus usuarios una versión móvil simplificada y directa, que fuera adecuada para el segmento de mercado representado por sus usuarios móviles.
Si no hubiera una página web asociada, entonces el modo más adecuado de enlazar a la versión completa original sería apuntar a la página de inicio de su sitio web. Puesto que esta página de inicio resulta el punto de entrada más adecuado para cualquier otra sección de su sitio web, esto debería facilitar las cosas a la hora de encontrar información relevante o ampliada acerca de lo que se estaba consultando.
Sin embargo, eso no sería suficiente. Tenga en cuenta el caso siguiente: un usuario realiza una búsqueda utilizando su teléfono móvil, pulsa en un resultado de búsqueda concreto, y es entonces redirigido a la página principal de su versión móvil, en lugar de ir a la página concreta de la versión original que inicialmente eligió. Puede que no haya ningún problema con esto si su usuario móvil aprecia la facilidad y velocidad de navegación en su versión móvil, asumiendo también que encuentre información relacionada con sus intereses y objetivos iniciales. Pero, ¿qué sucede cuando este usuario no encuentra la respuesta que buscaba a su consulta inicial, y pensase que su smartphone sí sería capaz de navegar en la versión completa original de su página web, en lugar de tener que verse restringido a los contenidos de la versión para móviles? Enviarlo de vuelta a la página de inicio de la versión original sería una barrera de uso para él, actuando como un paso intermedio innecesario.
Por eso debería ofrecer también como parte de su versión móvil un enlace a la página que sus usuarios intentaban visitar inicialmente, y desde la que fueron redirigidos a la versión móvil de su sitio web.
Técnicamente, esto se consigue anotando la dirección de la página donde comenzó el proceso de redirección (por ejemplo, utilizando un parámetro, una cookie o una variable de sesión). Los usuarios móviles que prefieran la facilidad de uso de la versión optimizada para móviles permanecerán ahí sin problema alguno. Y los usuarios móviles que quieran consultar los contenidos originales, hacia los que debería haber dirigido su clic inicial, aún tendrían la opción de consultar exactamente lo que captó su atención en los resultados de búsqueda, sin más que pulsar este enlace adicional.
Los usuarios móviles deberían ser redirigidos hacia la versión optimizada para móviles de su página web. Por lo tanto, cuando uno de sus usuarios móviles prefiera navegar la versión completa de su página web en lugar de la versión optimizada para móviles, porque considere que su smartphone será lo bastante potente como para manejarla sin problema, y pulse sobre un enlace que lleve a su versión original, ¿cómo puede prevenirse que sea redireccionado de nuevo desde la versión original a la versión optimizada para móviles, en un bucle infinito?
Uno de los enfoques más directos para resolver este problema consiste en añadir un parámetro adicional para que no se lleve a cabo esta redirección en el caso de estos usuarios que explícitamente solicitan visitar la versión original desde su teléfono móvil. Añadir un simple parámetro en la URL destino debería bastar. La página web objetivo, parte de la versión original de su sitio web, debería comprobar si la petición original contuviera este parámetro adicional. En caso de encontrarse este parámetro, no se llevaría a cabo redirección alguna, permitiendo a su usuario móvil navegar la versión original de la página.
No obstante, eso puede no ser suficiente. Ese mismo usuario podría querer seguir navegando a otras secciones dentro de la versión original de su página web. Por ello guardar el parámetro que actúa como indicador de que las redirecciones a la versión móvil deben ignorarse en este caso se convierte en algo esencial. Si no se mantuviera ese parámetro, cuando su usuario móvil pulsase un enlace dentro de la versión original, podría se redirigido de nuevo a la versión móvil, que ya había decidido explícitamente no usar.
Así que una vez que se solicite navegar la versión original de la página desde un dispositivo móvil mediante la inclusión de un parámetro adicional como parte de la URL, esta preferencia del usuario debería ser guardada dentro de una cookie, por ejemplo, o incluso dentro de una variable de sesión. Con lo que ése usuario concreto no tendrá que preocuparse acerca de ser redireccionado a la versión móvil de nuevo - al menos, durante esa sesión de navegación.
Estableciendo así una cookie o variable de sesión para ese usuario se evitaría que cualquier página redirigiera en modo alguno a ese usuario móvil.
Por lo tanto, este usuario aún podría volver a la versión móvil siempre que quisiera - no a través de una redirección automática, sino pulsado el botón “atrás” de su navegador web. Este escenario no es muy habitual, pero aún puede darse si el usuario móvil se da cuenta de que su versión original no resulta cómoda de navegar en su teléfono móvil, después de todo. Pero incluso tratándose de un caso no habitual, también conviene estar cubierto para garantizar una experiencia de usuario óptima en todo caso.
Este es el caso que Google llama redirecciones bidireccionales. La ventaja de este enfoque es que impediría que sus usuarios de ordenadores de sobremesa acabasen por error en una página optimizada para móviles, la cual, dentro de sus pantallas más grandes, podría parecer bastante limitada o vacía, y por lo tanto, podría no causar una primera impresión adecuada.
Si está seguro de que la detección de los navegadores móviles que realiza su sitio web está actualizada y no comete errores, entonces estas redirecciones bidireccionales pueden tener sentido. Resultaría muy extraño que un usuario de un ordenador de sobremesa prefiriera ver una versión móvil, más limitada o incompleta, en lugar de navegar en la versión completa y original de su página web.
Por otra parte, algunos usuarios de teléfonos móviles aún podrían estar interesados en navegar la versión completa de su sitio web. Y es aquí donde ese enlace desde la versión móvil hacia la versión original resultaría de utilidad, quedando todo posible caso cubierto.
El único inconveniente de las redirecciones bidireccionales es que resulta de vital importancia asegurarse de que la redirección funciona perfectamente. En caso contrario, podría dejar a sus usuarios bloqueados dentro de un bucle de redirecciones.
Las tabletas tienen unos cuantos puntos en común con los móviles: proporcionan cierta movilidad a sus usuarios, disponen de pantallas táctiles que no tienen por qué ser demasiado grandes, y tienen menos capacidad de proceso que los ordenadores de sobremesa.
Dicho esto, lo cierto es que la mayor parte de tabletas modernas ya permiten navegar en páginas web normales sin ningún tipo de problema. Su capacidad de proceso es suficiente como para poder manejar páginas web normales, y sus pantallas (incluso las menores, de unas 7 pulgadas) ya son lo bastante grandes como para proporcionar un nivel decente de legibilidad en cualquier página web.
Es por ello que sugiero no tratar a las tabletas como si fueran teléfonos móviles, y por tanto, excluirlas del código de detección de user agent móviles.
No obstante, sí que es posible dirigir a los usuarios de tabletas a su versión optimizada para móviles. Esto puede tener sentido en el caso de que su versión original no ofrezca una experiencia demasiado optimizada para tabletas (si tardase mucho en cargar, si tuviera contenido en Flash que no funcionaría en los iPad, o si estuviera principalmente dirigida a un segmento de mercado en que no englobaría a los usuarios de tabletas).
Si está usando el código de detección de navegadores previamente mencionado, detectmobilebrowsers.com, sólo tendría que añadir el siguiente código a la primera expresión regular para tratar a los iPads, Kindle Fire, Playbooks y tabletas Android como si fueran parte del conjunto de dispositivos móviles:
Si queremos tener un diccionario rápido en nuestro navegador, podemos crear un botón en la barra de marcadores o favoritos, que al clicar nos muestra una ventana emergente (Pop-Up), en la que podemos escribir rápidamente una palabra y dar a buscar en el diccionario de la Real Academia Española de la Lengua, sin necesidad de ir a su página, ir al buscador, etc... Nos carga directamente la página con la definición de la palabra que queremos.
Tan sólo hay que crear un marcador/favorito cualquiera, con el nombre que deseemos, y editar el contenido del enlace con el siguiente código:
El Ambient Occlusion es una sombra difusa de cercanía (no proyectada) que todo objeto genera en la cercanía con otro objeto, o con su propia forma, esta sombra es independiente de la iluminación y sombras de la escena, es para oscurecer las zonas cercanas entre sí.
Primero, cambiamos el motor de render de 3dsmax a Mental Ray. En menú Rendering / Render Menú (F10), Common, Assing Render, Production ... activamos Mental Ray.
Una vez en Mental Ray, abrimos el editor de materiales (M). Si estamos en el "Slate Material Editor" (el de nodos) damos a Mode / Compact Material Editor, para verlo por Slots.
En un Slot de material, en lugar del material Standard, hacemos clic y añadimos el Ink' n Paint, así nos aseguramos de que el material no tendrá ninguna sombra, y que será color sólido plano. Para que así sea, en las características del material Ink 'n Paint desactivamos INK (para que no genere trazo), y en Paint Levels ponemos a 1 (para que el material sea un único color plano, sin sombreados).
En ese material Ink 'n Paint, como mapa Lighted, ponemos el Ambient Occlusion, para ello hacemos clic en None, y en los mapas mental ray añadimos Ambient/Reflective Occlusion
En Samples, un número elevado (64 / 80) dejará más limpia la sombra, aunque tardará más el cálculo del render, un número más bajo (8 / 16) agilizará el tiempo de render, pero generará más ruido en las zonas oscuras.
Bright determinará el color de las zonas sin oclusión y Dark las zonas oscuras. Por defecto deberían dejarse en blanco y negro.
Jugando con los valores Spread y Max Distance, configuramos cuánto se expande la oclusión, y el rango que utiliza para expandirlo.
Para realizar el Render de oclusión, en el menú Rendering / Render Setup (F10), pestaña Processing activamos el Material Override, y ahí arrastramos el Material Ink 'n Paint con Ambient Occlusion que hemos creadoo, (esto hará que el material que pongamos ahí, sea el material que se aplica a toda la escena).
En esa misma ventana de configuración de render, en la pestaña Indirect Illumination, desactivamos el Final Gather, para que no calcule rebotes de luz, y nos aseguramos que en la escena no tenemos ninguna otra luz (no vale con esconderlas, hay que desactivarlas o eliminarlas), para que no existan luces ni sombras.
Y comprobamos que el fondo de la escena es blanco: Rendering / Environment (8), Background, Color: Blanco, para que el fondo no quede negro (que sería sombra).
Y damos a RENDER.
Tenemos una imagen blanca con las zonas de oclusión en negro.
En un programa como Photoshop, After FX, etc, componemos esta imagen con la original, poniendo debajo el render normal, y encima el de oclusión en modo Multiplicar. Para que utilice sólo el negro (por eso es importante tener el background blanco)
La vieja herramienta de cortar polígonos está oculta en Maya 2013, en su lugar hay otra llamada Interactive Poly Tool, es muy similar a la Split Poly Tool, con la salvedad de que una vez realizado un número de cortes, no guarda un historial del los cortes en las aristas que después podemos ajustar numéricamente, como sí lo hacía la Split Poly Tool, que aparentemente ha desaparecido, pero sólo está oculta, podemos crear un botón personalizado para ella.
El método más rápido para añadir el botón personalizado es añadir cualquier herramienta al menú Custom mediante el atajo de teclado Ctrl+Shift+Clic izquierdo del ratón, sobre cualquier herramienta de los menús superiores, nos creará la herramienta en la pestaña Custom, si previamente la hemos seleccionado.
Después hacemos clic derecho sobre esa nueva herramienta creada, y damos a Edit. Editamos el código de la pestaña Command y ponemos:
SplitPolygonTool
En la pestaña "Double Click Command", para que al hacer doble clic en el botón nos salga su menú, ponemos:
SplitPolygonToolOptions
Y en la pestaña "Shelves" Le asignamos un nombre en "Icon Label", si queremos que bajo (o sobre) el icono haya texto, o en "Tooltip" si queremos que se despliegue un texto informativo al dejar el puntero encima, y un icono dando a "Browse Maya Icons" a la derecha de "Icon Name".
¡Ya está!, tenemos el botón de nuestra herramienta en la pestaña Custom.
Si en lugar de eso, queremos crear uno desde cero, vamos al menú Window / Settings/Preferences / Shelf Editor. Clic en el botón "New Item" (a la derecha). Modificamos el contenido de igual manera que el anterior método, y damos a Save All Shelves.
Si queremos tener ambas herramientas en el mismo botón. Damos a editar el botón, y en la pestaña "Popup Menu Items", podemos añadir un listado de botones con su código. Por ejemplo, podemos añadir la Split Poly Tools y la Interactive Poly Tools con sus menús de opciones, añadiendo un "New Menu Item" por cada uno de estos cuatro códigos:
SplitPolygonTool
SplitPolygonToolOptions
InteractiveSplitTool
InteractiveSplitToolOptions
Con eso, al hacer clic derecho sobre el botón, nos saldrá un menú contextual con esas 4 opciones, después de las de Edit, Delete, etc.
También Podemos crear un botón que active SplitPolygonTool con un clic izquierdo, e InteractiveSplitTool con doble clic, poniendo el código de una en Command, y el otro en Double Click Command.
Y por cortesía de TripleClic, aquí dejamos un par de iconos para asignarle a esa herramienta, similar al que tenía antaño:
En Maya, cada vez que utilizamos una herrramienta de edición sobre un objeto, nos guarda un historial de esa acción como una pestaña en el Attribute Editor.
Al cabo de muchas acciones, tenemos muchas pestañas. Si estamos conforme con el resultado y queremos Colapsar o Acoplar todo eso para tener sólo la malla limpia, vamos al menú Edit / Delete by Type / History
También podemos crear un botón de acceso rápido a esa acción, haciendo Ctrl+Shift+Clic sobre esa misma herramienta, y nos añadirá un botón en la pestaña Custom, si previamente hemos seleccionado esa pestaña.
En 3ds Max, en el modo de subselección Vertex y Edge, cuando queremos eliminar aristas, pero manteniendo la estructura de polígonos, no vale con dar a suprimir, ya que esto elimina todo, aristas, vértices y polígonos... y perdemos la estructura.
Para mantener la estructura, con las aristas seleccionadas utilizamos el botón Remove o la tecla Borrar (Backspace). Esto nos mantendrá los polígonos, pero siguen por ahí sueltos los vértices que había en las aristas, tendríamos que ir a subselección de vértices, seleccionarlos, y dar a Remove. Si queremos ahorrarnos este paso tenemos dos formas de hacerlo:
Atajo de teclado, con las aristas seleccionadas: Ctrl + Borrar (Backspace), que nos borrará tanto aristas como vértices, pero manteniendo la estructura.
O, con las aristas seleccionadas, dar Botón derecho / Convert to vertex, ahora tenemos seleccionados los vértices correspondientes, sin clicar fuera (para no perder la selección de vértices) volvemos a subselección de aristas, y borramos con Remove o Backspace), una vez eliminadas las aristas, volvemos a subselección de vértices, y debería mantenernos la selección de vértices anterior, ahora podemos borrarlos.
En la barra de iconos superior de 3dsmax, tenemos una serie de botones para seleccionar herramientas, snaps, render, etc... pero podemos añadir nuestros propios botones de acceso rápido para llamar a las herramientas o modificadores que más utilicemos.
Vamos al menú Customize / Customize User Interface
Ahí, en la pestaña Toolbars, hacemos clic en el botón New..., le damos un nombre a nuestra nueva barra de herramientas. En el ejemplo yo la voy a llamar "Accesos":
Tenemos una nueva ventanita con el nombre que le hemos dado. Para agregar botones ahí, seleccionamos la herramienta o modificador que queremos añadir, en el menú de la izquierda. En el ejemplo voy a seleccionar TurboSmooth de la categoría (menú desplegable) Modifiers.
Seleccionamos el "TuboSmooth" y lo arrastramos dentro de la ventanita "Accesos".
Y ahí arrastramos sucesivamente todos los botones que queramos crear.
Muchos por defecto se añaden sin icono, sólo texto, o el icono por defecto. Podemos cambiar la apariencia de ese icono o nombre de botón, haciendo clic derecho sobre él / "Edit Button Appearance".
Una vez tenemos nuestro cuadro de iconos personalizados, si no queremos tenerlos flotando, podemos alojarlos junto al resto, arrastrando la ventanita hacia la zona vacía a la derecha de los iconos por defecto, o donde queramos ponerlos, se acopla en la zona donde lo llevemos.
Para cambiar entre los distintos Filtros de Selección (Geometría, Cámaras, Huesos, etc...) mediante teclas, lo único que hay que hacer es configurar el atajo de teclado que consideremos oportuno, en el menú de atajos de teclado de 3dsmax, como cualquier otro elemento. La única pega es que 3dsmax por defecto no muestra "Selection Filters" en ese menú para configurarlo. Pues muy sencillo, lo creamos mediante un MacroScript:
En 3dsmax abrimos el menú MAXScript / New Script
Y escribimos o copiamos lo siguiente:
El código mostrado en este post de TripleClic, sirve para los Filtros de Selección que vienen por defecto en 3dsmax.
Si nosotros hemos añadido algún filtro personalizado, "Combo", hay que modificar los números del apartado "SetSelectFilter", números que en realidad sólo llaman a la posición del filtro en el listado (no cuenta la palabra "Combos..." ni los separadores "------"). De tal manera que si por ejemplo añadimos un filtro combo personalizado, todos los filtros a partir de él, ocuparán una posición más, y en el código tendrán que tener un número más. Así sucesivamente con tantos personalizados tengamos.
ejemplo:
Ahí la palabra "SCH" ocuparía la posición 8 del listado, número que correspondía a "Bones, así que si no corregimos los números, cuando demos al atajo que teníamos asignado a "Bones", nos seleccionaría "SCH", etc.
Stumble
