Pixar libera RenderMan

**saucjedi** · 09/06/2014, 18:45

Iniciado por dj syto

y si se junta que un autodidacta de esos tambien tiene una carrera, ya es el no va mas!

Si la ha aprovechado y ha seguido siendo autodidacta durante la carrera... tiene papeletas para destacar.

-----Actualizado-----

Iniciado por dardo

Discrepo, con el ágebra de Informática y cautro cosa más ya se puede hacer un motor de raytracing sencillo si hay un poco de curiosidad, pero la universidad está llena de patanes que no saben ni que es la informática en plan "Para que necesito el cálculo, el álgebra, la estadística, el anñalisis matemático y el electromagnetismo, eso en informática sobra". Pues no señores, no sobra, si quieres picar código en plan FP igual si que sobra.

Sabiendo un poco de matemáticas y sabiendo programar se pueden hacer grandes cosas que no se pueden hacer sabiendo siempre programar.

Programar es lo de menos, sólo necesitas una mente lógica, ordenada y capaz de abstraer. Es como escribir, que sabemos todos, pero no todos pueden escribir una novela y no diga ya que ésta sea un novelón.

**swapd0** · 09/06/2014, 22:51

Iniciado por Drumpi

Esa es la parte simple, pero antes, para pintar un triángulo necesitabas tener la info de tres puntos, convertirlos a coordenadas 2d, dibujar las aristas, calcular la iluminación y rellenarlo con una textura, todo a mano. Luego salieron los mtores que con darle los tres puntos y la textura ya te hacían eso sólos, incluso usando una única textura para varios polígonos.
Y hoy día existen funciones hardware que te permiten dibujar en pantalla una esfera texturizada como si fuera un comando en lugar de una función, y lo mismo que digo esferas, digo conos, cilindros y muchos poliedros básicos. Lo dicho, con una sóla instrucción (y ese HW lo ha tenido que diseñar alguien que conozca los algoritmos y sepa electrónica).
Y esto es sólo un ejemplo HW, no quiero ni imaginar lo que existirá en la capa software tanto en alto como en bajo nivel.

A lo que voy es que lo que antes se hacía escribiendo 3000 líneas de código y varias iteraciones, hoy se puede hacer con una sóla línea y sin bucles de por medio... y aun así debes valorar si te conviene o no, o si existen funciones que te ahorran trabajo, o si existe un algoritmo que puedas crear y que te haga varias cosas a la vez.
Pero a ver si explico mi idea: dices que pintar un triángulo es trivial, pero a lo mejor hay un algoritmo que, con el mismo coste computacional y el mismo HW, te permite dibujar 4 a la vez porque existe una transformada matemática que trasladada a las 6 dimensiones convierte las multiplicaciones en coma flotante en sumas y restas que se pueden paralelizar. Y lo gracioso es que me suena que existe algo así. Y a menos que seas un matemático digno de Einstein, no lo vas a ver en tu vida :P

No te creas.
En general, creas una matriz de 4x4 para transformar los puntos, otra para pasar los puntos transformados a pantalla y ya esta. Eso ha sido desde los inicios hasta ahora.

La diferencia es que con el nivel de integración HW puedes meter una burrada de circuitos para hacer un montón de operaciones, ademas la ventaja de los algoritmos gráficos es que son muy paralelizables. Solo tienes que mirar libros antiguos de algoritmos gráficos y te dicen que el Zbuffer es una forma sencilla para resolver el problema de dibujar superficies ocultas, pero que ocupa mucha memoria y por eso te recomendaban que lo implementaras scanline a scanline. Pasan los años y desde las primeras aceleradoras ya lo implementaban por hardware y no la version por scanlines, el algoritmo es el mismo (bueno desde hace años muchas implementa el zbuffer jerárquico) lo único que ha cambiado es el proceso de fabricación de chips que te permite meter mas cosas.

**lemure_siz** · 10/06/2014, 17:40

Como os vais un poco por las ramas con la programacion, y os olvidais de lo que es Renderman: un generador de imagenes...pues aqui un video para enseñar las cosas que hace este soft junto con Maya, que es el software anfitrion.
Aviso, no es nada amazing, pero es que hoy en dia hay muchos programas que hacen lo mismo que renderman, incluso los motores 3d de videojuegos hacen cosas parecidas.

**Drumpi** · 12/06/2014, 15:30

Iniciado por ^MiSaTo^

Por supuesto de acuerdo con ambas. Sólo me refería a que por no tener carrera no significa que no puedas hacer ciertas cosas (no todo el mundo vale para ello tampoco claro)

Ni que la carrera tampoco es la panacea y por tenerla ya directamente eres capaz de hacer el nuevo CryEngine. Porque eso no es el mundo real

Yo estoy en ese punto en que no tengo experiencia para que me contraten ni papeles que me abran puertas

Y muchas veces, la experiencia por cuenta propia no cuenta en las empresas, sólo te miran la experiencia profesional, y particularmente a mi lo que me miran más es la experiencia en testing, que fue mi primer empleo "serio" en lugar de la experiencia en desarrollo, que tengo como 20 veces más de tiempo.

Y obviamente, ni la carrera te da todos los conocimientos, ni la experiencia es despreciable (aunque se dan casos de coger "malas costumbres" que son difíciles de corregir). Yo mismo soy un ejemplo, porque conozco cosas sobre electrónica y las bases de la programación, y luego meto la pata hablando de consolas ¿por qué? porque conozco las bases, pero no los estándares que se han creado a partir de ellos, las distintas evoluciones... Vamos, como lo de no saber los distintos modos de trabajo de las CPU de MD y SNES.
Tienes una base, con eso puedes coger cualquier tocho y aprender lo que sea, pero no sabes.

Iniciado por swapd0

No te creas.
En general, creas una matriz de 4x4 para transformar los puntos, otra para pasar los puntos transformados a pantalla y ya esta. Eso ha sido desde los inicios hasta ahora.

La diferencia es que con el nivel de integración HW puedes meter una burrada de circuitos para hacer un montón de operaciones, ademas la ventaja de los algoritmos gráficos es que son muy paralelizables. Solo tienes que mirar libros antiguos de algoritmos gráficos y te dicen que el Zbuffer es una forma sencilla para resolver el problema de dibujar superficies ocultas, pero que ocupa mucha memoria y por eso te recomendaban que lo implementaras scanline a scanline. Pasan los años y desde las primeras aceleradoras ya lo implementaban por hardware y no la version por scanlines, el algoritmo es el mismo (bueno desde hace años muchas implementa el zbuffer jerárquico) lo único que ha cambiado es el proceso de fabricación de chips que te permite meter mas cosas.

Pero no siempre, el método usado hasta la fecha es el mejor. Se podrían haber creado memorias capaces de almacenar más datos o de reproducir archivos Wav de forma más eficiente, pero un día alguien creo el algoritmo de compresión MP3 y todo cambió. Hoy existe HW que te decodifica MP3, MP4, H264 u OGG, y se seguirán creando a medida que aparezcan nuevos algoritmos de compresión.
Lo mismo pasa a la hora de pasar figuras 3D a la pantalla. Quién sabe si mañana no se puede integrar el ZBuffer con el algoritmo de rellenado de caras, o si se suprime porque si se pasa todo el proceso a una cuarta dimensión se puede realizar todo en la décima parte del tiempo (y se diseña un HW específico).

Es a eso a lo que me refiero: el MP3 revolucionó la reproducción de audio, pero se necesitó de un complejo estudio matemático que no se estudiaba en la informática tradicional. Y hoy día el nivel de complejidad es tal que es imposible hacer las cosas uno sólo: se necesitan estudios y un equipo.
Hoy las empresas usan .NET o Java para sus aplicaciones, pero ten en cuenta la de gente que ha trabajado por debajo: la que ha hecho el SO, el lenguaje C y su compilador, la que ha creado .NEt o Java, la máquina virtual, y luego todas las librerías. Todo eso hay que contarlo para crear un programa, no basta decir "he hecho esta aplicación de consulta de BD yo sólo en tres días", porque entonces te podría poner en MS-DOS a picar código a ver lo que se tarda en conseguir lo mismo.

**swapd0** · 12/06/2014, 20:52

Si, el mp3 y el ogg (creo) ya estaban en la época del 486, problema es que con un 486 no puedes "escuchar" un mp3 porque no da tiempo a descomprimirlo, con la llegada de los pentiums se popularizo. Lo mismo pasa con el MP4, H264, comprimen mas que los CODEC anteriores y es tienen un enfoque distinto pero es gracias a que los procesadores corren mas y se puede hacer eso. Nadie en la época de los 8/16bits a nadie se le ocurriría hacer un juego en 3D con texturas, iluminación y bummaping aunque ya estaban inventados porque no corrían lo bastante.

Asi que aunque se invente un algoritmo que sea la repanocha necesitaras mucha potencia de calculo para implementarlo. No creas que en un Z80 podrás hacer el crysis.

Por eso digo que pero la mayoría de los avances es gracias al hardware, este te pone un limite (MIPS, ancho de banda con memoria, etc...) y no lo vas a superar a no ser de que uses un procesador mas moderno.

**Drumpi** · 12/06/2014, 22:55

Precisamente las limitaciones de HW, en muchas ocasiones, han dado lugar a mejores algoritmos y nuevos inventos en el apartado software. Por ejemplo, no se podían hacer juegos 3D, pero sí que se popularizaron los juegos en vista isométrica, y no usaban tiles isométricos, que habrían consumido mucho cálculo a la hora de ordenar las Z, dibujarlos, etc... Te tienes que abstraer a cómo funciona globalmente el sistema y buscar formas de englobar objetos. No sirve como ejemplo de que hay que aprender otras disciplinas para aplicarlo al campo de mejorar, pero ahí está.

Otro ejemplo: SNES. La CPU no podía mover entornos 3D, pero sí que pudieron diseñar una aproximación simple para modificar una textura, el famoso modo7. Puedes rotarla en cualquiera de los 3 ejes o escalarla, pero sólo a una única imágen, porque alguien se molestó en conocer las matemáticas de esas transformaciones, convertirlas a algoritmo, y de ahí a hardware. No te sirve para mover polígonos, pero es una simplificación eficiente para lo que existía en su momento. Sin tener esas tres disciplinas, era imposible que se hiciera en su momento.