¿Qué pasó con las texturas generadas procesalmente? [cerrado]

23

Recuerdo hace algún tiempo que las texturas generadas por procedimientos se estaban convirtiendo en un gran problema en el que muchas personas / empresas estaban realmente interesadas con algunos beneficios serios (implementaciones más pequeñas, carga potencialmente más rápida, mayor calidad, texturas escalables, potencialmente más baratas de producir, etc. )

Por lo que puedo decir, el zumbido está muerto y ningún juego en mi radar los está usando. ¿Que pasó?

Esperaba ver texturas de procedimiento como las de NaturalMotion (adopción lenta pero constante).

textures procedural-generation Steven Evers
fuente

Respuestas:

14

Las herramientas de creación de contenido para texturas de procedimiento han sido el mayor obstáculo. Los artistas son muy rápidos al juntar las cosas en Photoshop y las ganancias potenciales con texturas de procedimiento no han superado el aumento del tiempo de creación de contenido.

Allegorithmic ( http://www.allegorithmic.com/ ) tiene algunas herramientas interesantes que han desarrollado para probar y hacer que las opciones de procedimiento sean más fáciles de usar. Sin embargo, no he jugado con ellos lo suficiente como para comentar realmente su usabilidad.

Wkerslake
fuente
1
Allegorithmic fue la compañía de la que originalmente escuché por primera vez cuando la bomba estalló y su lista de clientes tiene algunos jugadores importantes, pero, considerando que han estado en el negocio durante mucho tiempo, todavía es bastante pequeña.
Steven Evers
1
Los productos Sustancia de Allegorithmic se ven REALMENTE MUY buenos. Si echas un vistazo a los videos que se encuentran aquí: allegorithmic.com/?PAGE=PRODUCTS.designer
Nailer
4

La pérdida de control artístico y el aumento de tamaño de las opciones de almacenamiento han hecho que esto sea difícil de vender. Eso, además, tendrías que volver a capacitar a los artistas, mientras los contrataste para lo que eran buenos en texturas tradicionales. A menos que el tamaño o las texturas únicas sean realmente un problema, existe un pequeño deseo general de seguir el camino del procedimiento.

Kaj
fuente
3

Básicamente, las grandes armas no lo soportan, por lo que no se usa mucho. Ha habido cosas geniales (aunque un poco viejas), como .kkrieger, pero el tiempo de carga en eso (en el día) fue realmente lento, ya que tenía que generar todas las texturas en el momento de la carga.

Es posible que veamos algo u otro en los motores de próxima generación (Unreal 4, etc.), pero no creo que la ganancia frente al desarrollo sea lo suficientemente grande.

Hay ejemplos en el mundo AAA, por ejemplo, Spore ha generado texturas y animaciones procesales para las criaturas que ha creado.

Ólafur Waage
fuente
3

La textura de procedimiento adolece del problema de que un Director de Arte no puede señalar de manera confiable el trabajo de un Artista y decir "por favor, haga que esa parte sea un poco más X". porque el sistema de sombreado de procedimiento puede no admitir X a bajo precio o en absoluto.

Por ejemplo, un sombreador de ladrillo puede soportar ladrillo marrón limpio, pero puede no soportar el ladrillo que fue pintado con un anuncio hace 80 años y graffiti hace 10 años. O puede no ser compatible con tener un ladrillo morado de 1,000 ladrillos marrones. Exactamente en ese lugar, porque ese lugar atrae el gusto del Director de Arte.

Una textura real puede soportar todas estas cosas, por supuesto, y en este sentido una textura real es superior a una textura de procedimiento.

La textura procesal ejerce control artístico en virtud de su preferencia por ciertos casos de uso sobre otros. Una textura real ejerce poco ese control.

Sin embargo, el hardware de la GPU tiene una fuerte preferencia por el procesalismo, porque la memoria de textura está a muchos ciclos de las unidades ALU que hacen el sombreado.

bmcnett
fuente
Me resulta difícil de tragar. No es una limitación de las texturas de procedimiento que un ladrillo no pueda ser de un color diferente al resto, es una limitación de la tecnología de implementación. Claro, podría estar de acuerdo en que, en algún momento, ser demasiado específico superaría los beneficios de hacer algo de forma continua, pero eso no viene al caso.
Kevin Peno
Un ladrillo podría haber sido un mal ejemplo, pero sus otros ejemplos son válidos. Es muy complejo y requiere mucho tiempo definir un nuevo algoritmo para un ligero cambio en la "sensación" de una textura, pero es muy barato y fácil para un artista hacer el cambio. Tenga en cuenta que los ingenieros generalmente reciben un pago muuuuucho más que los artistas, por lo que el tiempo de ingeniero dedicado a hacer lo que un artista puede hacer más rápido es una tontería.
Sean Middleditch
@SeanMiddleditch, a los ingenieros se les puede pagar más que a los artistas, pero la diferencia es que, una vez que un ingeniero ha escrito el código, puede reutilizarse para siempre, sin ningún gasto adicional. Por lo tanto, aunque podría llevar tiempo desarrollar un generador de procedimientos que pueda modificarse, hasta el nivel de ladrillo individual; una vez hecho, sería de uso gratuito. Si una empresa paga a artistas por cambios individuales, tendrán que seguir haciéndolo para cada nuevo requisito de cambio que surja, a diferencia de una solución automatizada.
Cíclope
2
@ Cyclops: buena suerte con ese súper procedimiento mágico que te permite hacer los detalles intencionales exactos que puede hacer un artista. Espero con interés leer su innovador trabajo de investigación cuando se lance y, finalmente, otorgar licencias a su tecnología über obsoleta para artistas. :)
Sean Middleditch
1

Bueno, todavía parece una gran idea especialmente para los juegos. Ya que podrías generar texturas de forma procesada sobre la marcha para que el mundo alrededor del jugador se vea más natural. No se necesitan grandes datos. Se puede usar con seguridad para aumentar incluso la resolución

ene
fuente
0

Tienes el típico intercambio de memoria de tiempo . Bueno, nos guste o no, la generación de procedimientos cambia el tiempo de CPU para la conservación de la memoria. En realidad, a medida que el almacenamiento se vuelve más barato y la gente siempre quiere tiempos de carga más cortos, la tendencia es a la inversa: los activos pregenerados o fotografiados consumen memoria a cambio de velocidad.

¿Se carga un jpg más rápido que una versión generada por procedimientos? Lo más probable es que sí . Si el jpg es de 2 MB y lo carga una vez, ¿por qué debería molestarse con el procedimiento? En tiempo de ejecución, la textura toma la misma cantidad de RAM de todos modos (sin comprimir y cargada en la memoria de la GPU)

bobobobo
fuente
Es poco probable que JPEG se cargue más rápido que la mayoría de los algoritmos de textura de procedimiento. Los tiempos de acceso al disco superan con creces el tiempo de procesamiento de la CPU / GPU, y dado que nadie en su sano juicio usa JPEG para texturas y utiliza texturas comprimidas más grandes pero optimizadas para GPU con capas de mapa MIP precalculadas, el tiempo de carga del disco es aún peor para las texturas reales. Hay razones por las que las texturas de procedimiento son malas (mencionadas en otras respuestas), pero el tiempo de carga generalmente no es una de ellas. Estoy seguro de que existen excepciones para algoritmos particularmente complicados o ineficientes, por supuesto.
Sean Middleditch
Sí, como .dds. Acabo de usar JPG como ejemplo. Mi punto es que es la generación procesal de adoquines, agua o árboles en un bosque que usan sistemas L o lo que sea que lleve eones más tiempo (¡pero encaja en 96k!) Que simplemente cargar contenido en el disco, entonces nadie querrá ir a eso ruta, simplemente para reducir los tiempos de carga.
bobobobo