Blender 2.57 release y avances

[SamCameron]

Vaya velocidad, me ha encantado esta versión, en la anterior con CPU solamente en mí escena de prueba obtenía 14 segundos, en esta nueva versión con CPU obtengo 9.5 segundos aproximadamente (lo cual se ve que ha mejorado también la velocidad de cálculo a través de CPU también), pero lo bueno viene cuando lo pongo en modo GPU, con mi GTX460 me tarda 1.20 segundos aproximadamente, y eso que estoy ejecutando esta versión de 32 en un Windows de 64 bits, por lo cual cuando salga una versión nativa espero alguna que otra mejora, por otro lado, en unos días me llega otra GTX460, así que, probaré a ver si funcionan las dos a la vez y si encuentro alguna mejora en cuanto a tiempos.

[renderiche]

Qué requerimientos se necesitan para que chute Cycles? Yo uso Ubuntu 10.04 pero no tengo ninguna tarjeta de ésas molonas, no sé si será por eso que el visor se me queda negro. Sin embargo, pensaba que también se usaba CPU, al estilo del interactive render de thea. Gracias de antemano.

[V1k1ngo]

Renderiche, si no tienes tarjetas con Cuda, lo máximo que te puede pasar es que no te deje elegir el modo, pero debería renderizar, estas iluminando con mesh lights o con el background? Recuerda que Cycles todavía no acepta las lámparas clásicas de Blender, si esto no sirve, revisa si no dice algo tu consola.

Sancameron, me interesaría ver tu escena de pruebas, o por lo menos que comentes tus settings (materiales, iluminación, número de passes, bounces), está bien que yo tengo máquina más bien discretea, pero no puedo ni soñar con tiempos tan espectaculares, de todos modos, para probar el motor configuré la escena por defecto con materiales Glossy para los tres elementos (monos y piso), una textura de mediana resolución en el plano de suelo e iluminación HDR. A 1920 por 1080, con 100 passes, 64 bounces max y 8 min, estoy logrando completar el render por CPU en 11 munutos y monedas, mientras por GPU baja apenas los 6, lo que me desagrada, es que, ahora en comparación con otros motores unbiased (hice Maxwell recién, misma escena, con settings parecidos) no me está dejando tan bien parado en su versión cpu: hice en 12 minutos de Maxwell, una escena similar en ruido (prácticamente nada), y que ha decir verdad, se ve mejor, de todos modos, tengo que aceptar que me cuesta encontrar equilibrio a estos materiales de Cycles, ahora voy a tratar de configurar una escena similar en LuxRender e Iray, para seguir comparando resultados.

[SamCameron]

Yo he hecho una comparativa entre CPU y GPU de un Cornell box que publicaron en blenderartists y me da lo siguiente:

Cpu : 4300 passes, min 3, max 32, 500 por 500 píxeles, procesador Athlon i x4 635, 4 Cores de 2901 Mhz cada uno, tiempo de render: 1 hora.

Gpu : mismos parámetros,gtx460, tiempo de render: 9 minutos 50 segundos.
Por lo que yo noto una diferencia tremenda, y no solo al renderizar escenas de bastantes minutos, sino al previsualizar tengo feedbak casi instantáneo, se limpia la escena muy rápidamente, en esa escena el usuario original dejo la configuración en 4300, pero llegando a 1800 ya estaba casi limpia y me había tardado como unos 4 minutos más o menos. Cosas a tener en cuenta: la versión que he utilizado es una versión de 32 bits, mi sistema operativo es w7 64 bits por lo que debería mejorar el rendimiento con una versión nativa, más cosas, algunos de los prorgamas que mencionas usan un filtro de post-procesado para limpiar el grano, no es que sean mucho más rápidos sino que a veces hacen trampa por así decirlo, y finalmente, yo no suelo meter tantos rebotes como en esa escena, generalmente uso mínimo 1 y máximo 3 o 5, según si la escena tiene materiales más complejos pues le subo a 15 o un poco más si es necesario, por lo general he de decir que es bastante rápido este motor, sobre todo para estar en un estado tan inicial. Yo habitualmente trabajo con Octane render, pero es que, en cuanto mejore un poco más Cycles me olvido de Octane por completo, porque Blender con este motor de render me ofrece una flexibilidad de trabajo increíble, ya no necesitaría de programas externo como Octane, ni exportar ni s raros, todo desde mi querido Blender.

[V1k1ngo]

Trampa técnica o no trampa, Maxwell es tradicionalmente de los lentos, si Cycles se proclama como un super veloz, va a tener que dejar atrás estos tiempos, seguramente la cantidad de bounces que usé es excesiva (de hecho, al trabajar muchísimo en Maxwell ya me había olvidado de que eran =p), pero debería ello redundar en una imagen mejor, y si a mismo tiempo, peor calidad visual (hecha la salvedad que aún me encuentro en etapa de adaptación a Cycles), me fastidia tanto bombo y platillo. No obstante esto es solo en CPU, la magia está en la GPU.

Voy a probar la escena test, y actualizaré resultados.

[Neo_one]

¿No iba a funcionar mediante OpenCL, entones si tienes una Ati no puedes renderizar con cycles?

[Crisart]

Donde se escoge para renderizar con GPU?

[renderiche]

Renderiche, si no tienes tarjetas con Cuda, lo máximo que te puede pasar es que no te deje elegir el modo, pero debería renderizar, estas iluminando con mesh lights o con el background? Recuerda que Cycles todavía no acepta las lámparas clásicas de Blender, si esto no sirve, revisa si no dice algo tu consola.

Bueno, pues efectivamente, se trata de dependencias que faltan, pero con la actual versión de Ubuntu parece complicado satisfacerlas, maldita versión lts. Gracias por tu respuesta.

Edito: ya he conseguido instalar las dependencias que me faltaban, para el que tenga Ubuntu 10.04 https://launchpad.net/~frefilesync/+...ildjob/1965920.

Tiene muy buena pinta este motor.

[SamCameron]

V1k1ngo, no solo puedes iluminar con Mesh lighting, también puedes iluminar con luces tipo Sun.
@balex, tienes que, actualizar tus drivers, si no te sale la opción de selección entre CPU y GPU.

[Crisart]

Gracias samcameron, ya actualice y ahora si sale la opción.

[Caronte]

Solo he podido probarlo por CPU (hasta que pongan una build de OS X) y ya estoy flipando en colores, esta mucho más maduro de lo que me imaginaba y es rapidísimo (sobre todo en exteriores o interiores con mucha luz directa).

Estoy encantado, aunque me da pena por el resto de motores, porque como no se pongan las pilas, lo van a tener crudo.

[renderiche]

Solo he podido probarlo por CPU (hasta que pongan una build de OS X) y ya estoy flipando en colores, esta mucho más maduro de lo que me imaginaba y es rapidísimo (sobre todo en exteriores o interiores con mucha luz directa).

Estoy encantado, aunque me da pena por el resto de motores, porque como no se pongan las pilas, lo van a tener crudo.

Pienso un poco lo mismo, me esperaba algo mucho más pelado y me he quedado de piedra, para mear y no echar gota.

Ahora que iba con thea a muerte, veremos adonde nos lleva esta batalla de motores.

[Slash148]

Hola, alguien ha podido hacer funcionar el Blender 2.57 con Yafray integrado? El que usa el Python 3.2, no he podido hacerlo correr, he compilado el Python desde las fuentes, lo he instalado desde repues y me sigue mandando el error de que no puede iniciar porque falta libpython3.2, la cual tengo instalada según synaptic. Tengo el Ubuntu 11.04 a 64 bits.

[e1000i]

Yo he hecho una comparativa entre CPU y GPU de un Cornell box que publicaron en blenderartists y me da lo siguiente:

Cpu : 4300 passes, min 3, max 32, 500 por 500 píxeles, procesador Athlon i x4 635, 4 Cores de 2901 Mhz cada uno, tiempo de render: 1 hora.

Gpu : mismos parámetros,gtx460, tiempo de render: 9 minutos 50 segundos.
Por lo que yo noto una diferencia tremenda, y no solo al renderizar escenas de bastantes minutos, sino al previsualizar tengo feedbak casi instantáneo, se limpia la escena muy rápidamente, en esa escena el usuario original dejo la configuración en 4300, pero llegando a 1800 ya estaba casi limpia y me había tardado como unos 4 minutos más o menos. Cosas a tener en cuenta: la versión que he utilizado es una versión de 32 bits, mi sistema operativo es w7 64 bits por lo que debería mejorar el rendimiento con una versión nativa, más cosas, algunos de los prorgamas que mencionas usan un filtro de post-procesado para limpiar el grano, no es que sean mucho más rápidos sino que a veces hacen trampa por así decirlo, y finalmente, yo no suelo meter tantos rebotes como en esa escena, generalmente uso mínimo 1 y máximo 3 o 5, según si la escena tiene materiales más complejos pues le subo a 15 o un poco más si es necesario, por lo general he de decir que es bastante rápido este motor, sobre todo para estar en un estado tan inicial. Yo habitualmente trabajo con Octane render, pero es que, en cuanto mejore un poco más Cycles me olvido de Octane por completo, porque Blender con este motor de render me ofrece una flexibilidad de trabajo increíble, ya no necesitaría de programas externo como Octane, ni exportar ni s raros, todo desde mi querido Blender.

He hecho la misma prueba que samcameron.

Misma escena y resolución. 4300 passes, bounces min 3 max 32. Procesador Intel Core 2 Duo 2,13 Ghz (2 Cores, 2 hilos) Windows XP 32bit service pack 3. Tarjeta gráfica Nvidia GeForce 9500 GT (32 procesadores Cuda) 60 euros.

Tiempo cpu= 4horas 17 minutos 30 segundos.

Tiempo GPU= 2horas 14 minutos 45 segundos.

Gran diferencia. (en todos los sentidos))))).

[jose.j]

Hola, alguien ha podido hacer funcionar el Blender 2.57 con Yafray integrado? El que usa el Python 3.2, no he podido hacerlo correr, he compilado el Python desde las fuentes, lo he instalado desde repues y me sigue mandando el error de que no puede iniciar porque falta libpython3.2, la cual tengo instalada según synaptic. Tengo el Ubuntu 11.04 a 64 bits.

Hola pues yo lo tengo funcionando en Ubuntu 10.04 lst a 64 bist sin problemas.

Eso si tengo el Yafray compilado usando Python 2.6 (/usr/lib/python2.6/config/libpython2.6.so) y le coloco el add-ons sin problemas. Blender 2.57.1 también compilado. Y como el Python 3.2 no está en los repositorios de la 10.04. Pues lo compile también. Y he tenido muy buenos resultados. Como, por ejemplo: https://foro3d.com/attachments/14559...acorcho004.jpg.

Puede pasar que cuando hicieron el integrado haya usado el Python en una dirección que no es la predeterminado y por eso te arroja el error. Intenta crear un enlace simbólico dónde está el ejecutable de Blender. Saludos.

[Neo_one]

Me autorespondo:
disponible el código fuente y las primeras builds de Cycles, el render con aceleración GPU de Blender viernes, abril 29th, 2011 ya están disponibles el código fuente y las primeras compilaciones de Cycles, el nuevo motor de render basado en GPU de Blender, que está siendo desarrollado por Brecht van lommel.

De momento, la aceleración GPU utiliza las librerías de Cuda, por lo que sólo podrá ser utilizada por tarjetas gráficas con chip Nvidia, pero ton Rosendal confirmó que la versión OpenCL estará disponible en el futuro, ya que tenían algunos problemas técnicos de implementación que solventar.

El código fuente está disponible en la branch Cycles del SVN de Blender:
https://svn, Blender.org/svnrot/Bf-b...anches/Cycles/
En graphicall.org podemos encontrar versiones compiladas de la mencionada branch.

Se avecinan buenos tiempos para los usuarios de Blender. http://www.silicity.com/tag/ati/.

[vleda]

Ya está disponiche un parche del unlimited Clay. http://Farsthary.wordpress.com/2011/...-patch-in-321/.

Muchas gracias por tu trabajo Raúl.

[rhinote]

Solo he podido probarlo por CPU (hasta que pongan una build de OS X) y ya estoy flipando en colores, esta mucho más maduro de lo que me imaginaba y es rapidísimo (sobre todo en exteriores o interiores con mucha luz directa).

Estoy encantado, aunque me da pena por el resto de motores, porque como no se pongan las pilas, lo van a tener crudo.

Según dicen en el foro de LuxRender, la idea de Brecht es crear/abrir una Api para que cualquier motor se pueda integrar de forma tan nativa como Cycles. Me gusta ese espítiru tan colaborativo. http://www.luxrender.net/forum/viewt...88cb907ce44fbe.

[V1k1ngo]

In the morning i gave an interview todo someone from the radio Tux podcast about the both, the open source talks yesterday and the acceptance of os in the industry. Should be published on their site in june.

Cycles was a great thing todo show again, Many people were interested in it. In the afternon, someone from the Foundry talked very long with ton about licensing. They are interested in Cycles and would contribute code, when Cycles would be released under the bsd licence. But we remained sceptical, the Foundry guy was a very nice person, but its unclear how big the actual benefits would be. Bsd licence brings some issues with it (like companies can use the code and sell it, without giving bak their changes todo us, or Even mentioning they use Cycles code at all.) ton wants todo chek on this Stuff, dont worry, we Will clearly think about all pros/cons.

Algunos ya lo habrán visto en ba, no todo el mundo está tan contento con la posibilidad (yo soy uno de los que está bastante escéptico al respecto).

Por cierto, Rhinoceros, Álvaro luna (aka Samo), y la gente de Yafray en general no están tan contentos con todo este asunto de Cycles, de hecho, parece que se sienten bastante frustrados por la falta de colaboración de la Bf, fundamentalmente a la hora de pasar las actualizaciones de la Api y demás. Entiendo que la furia de Samo es tal vez exagerada, pero me resulta totalmente comprensible, de hecho, cuando leí más temprano que la arquitectura de Yafray esta basada (o por lo menos soporta) nodos de materiales, pero que no aparecen en la interfaz de Blender por pregúntenle-a-los-desarrolladores-de-la-Bf me fastidié bastante, dado que para quienes usamos Yafray hace un tiempo, podría a ver sido un plus importante.

[Caronte]

Yo he usado lux, tengo comprado Octane y también thea, pero. Vaya, yo que sé, lo que estoy disfrutando en estos días con Cycles, hacía años que no me ocurría, incluso lo estoy usando para un proyecto real y se está portando como un profesional o incluso mejor, porque el grado de interactividad, es simplemente alucinante.

[Caronte]

No había leído el mensaje de v1k1ngo. Sobre ciertos individuos en particular, no hablo, pero mi opinión es que cuantas más opciones hayan, mejor, aunque repito que superar a Cycles va a ser muy, pero que muy difícil.

[rhinote]

Por cierto, como ya estaba cansado de jugar con los monos del fichero de ejemplo, y como no hay opción de texturas en la compilación de Blender + Cycles, he abierto un dibujo sencillo con texturas, y se me queda la pantalla negra.
¿Me pasa sólo a mí, o es que Cycles no aguanta texturas de ninguna forma, o hay algo que se me escapa?
Además, si selecciono GPU se me cierra directamente Blender.

V1k1ngo: ya he visto el mensaje en el foro en el que Samo llama a Cycles el protege.

Creo que la actitud de los chicos de LuxRender es más sana que la de Samo, no sé, pero tampoco sabemos que pasa dentro de cada uno, ni que tendrá Samo en el debe con la Bf.

En fin, mejor no ahondar en esto.

Y la verdad es que, sí, que Cycles ha salido el último y ya es capaz de superar a los demás. Mucho se van a tener que espabilar los otros motores.

Aunque lo ideal es que les sirva como estímulo, y que Cycles cree competencia.

[V1k1ngo]

Asegúrate de marcar en todos los materiales creados la opción use nodes, lo mismo que en el background, las texturas las puedes cargar desde el editor de nodos de materiales (es esa la gran ventaja de cicles, más, allá de la velocidad).

En cuanto al GPU, no me ha pasado todavía, para su estado pre alpha, me corre como seda.

-- IMÁGENES ADJUNTAS --

[rhinote]

Muchas gracias. La verdad es que es una chulada. Pero sigo con los problemas a la hora de abrir un dibujo creado previamente.

Por ejemplo, este fichero, (con ese nombre tan original).

-- IMÁGENES ADJUNTAS --

[adelmo83]

No tienes activado Cycles, y las texturas se debe asignar nuevamente, me paso lo mismo con esta escena realizada con 2.49.

-- IMÁGENES ADJUNTAS --

[rhinote]

Gracias Adelmo. Bueno, por fin podemos ponerle una pega.

[SamCameron]

Yo he usado lux, tengo comprado Octane y también thea, pero. Vaya, yo que sé, lo que estoy disfrutando en estos días con Cycles, hacía años que no me ocurría, incluso lo estoy usando para un proyecto real y se está portando como un profesional o incluso mejor, porque el grado de interactividad, es simplemente alucinante.

Totalmente de acuerdo, como Caronte uso Octane render habitualmente para casi todos mis proyectos, pero desde que tengo Cycles me encuentro mucho más a gusto, ya no porque sea más o menos igual de bueno y rápido que Octane render, sino porque el sistema de trabajo de Octane (exportar, importar, retocar materiales,) es muy lento, con Cycles puedo hacer todo directamente desde Blender, puedo cambiar todo lo que quiera sin tener que volver a exportar ni líos de esos, tienes un feedbak mucho más directo y mejor que con cualquier otro motor, vamos para mí forma de trabajo no puede haber nada mejor.

En cuanto al tema de Álvaro, hace mucho tiempo ya discutí con el una vez por el descuidado estado de Yafray, comprendo que no es fácil mantener un código como ese, pero también entiendo que otros grupos (LuxRender es un buen ejemplo) les han comido muchoterreno, empezando mucho más tarde que ellos, yo habitualmente usaba Yafray en Blender 2.4x, pero le dije a Álvaro que estaban perdiendo el carro, que muchos motores habían mejorado muchísimo tiempo y que ellos parecían como estancados, y se ofendio muchísimo, la verdad es que, algunos deberían quejarse menos de lo que hacen o tienen que hacer los demás por ellos, y hacer un buen trabajo ellos mismos, y ciertamente parece que al único que le ha molestado bastante el tema de Cycles es a Álvaro, cada uno que saque sus propias conclusiones de porque está así.

Posdata: os dejo my último render en Cycles (sin postproducción, render tal cual Cycles), tiempo de render 3 minutos a 1920 por 1080, con GPU GTX460.

-- IMÁGENES ADJUNTAS --

[StormRider]

Yo no lo veo como un renderer más, ni un protegido. Blender necesitaba un lavado de cara en el internal, y si se hace ahora, lo suyo es que sea lo más moderno posible, como Cycles, por ejemplo.

[jose.j]

Yo no lo veo como un renderer más, ni un protegido. Blender necesitaba un lavado de cara en el internal, y si se hace ahora, lo suyo es que sea lo más moderno posible, como Cycles, por ejemplo.

+1.

[jose.j]

Hola. En este enlace comentan una nueva propiedad del elemento empty. Con el que se pueden poner imágenes. Es muy útil para colocar referencias a la hora de modelar, sin recurrir al background. http://foreverblender.blogspot.com/2...ects.html#more.

[e1000i]

Vaya salido una versión de Cycles con GPU y CPU para Windows 64 bits en graphicall, com. http://www.graphicall.org/173. Saludos.

[ofuscado]

Themes para Blender 2.5: http://blenderartists.org/forum/show...=1#post1818820.

[miguelito08]

Ha salido una versión de Cycles con GPU y CPU para Windows 64 bits en graphicall, com. http://www.graphicall.org/173. Saludos.

Descargada, la probaré cuando llegue a casa. Gracias.

[Caronte]

Probando Cycles en un proyecto real. Muestra de modelo y texturas. Tiempo de render en un Mac Pro (200 y solo por cpu: 42.



https://foro3d.com/attachments/14586...odado-arma.jpg.

Dudo mucho que vuelva a usar otro motor de render, Cycles es la leche.

[MMalkavian]

Apuntad otro a la lista de los que estamos disfrutando como cosacos con el nuevo motor. Me inspiró para hacer este logotipo:


Que no es gran cosa, pero en algo tenía que canalizar mi euforia inmediata.

Y ya que estamos, una pregunta: el aliasing que sale en algunos renders, ¿es porque aún se trata de un versión alfa? ¿o quizás hay que toquetear algún parámetro para disimularlo? Un saludo.

-- IMÁGENES ADJUNTAS --

[SamCameron]

Y ya que estamos, una pregunta: el aliasing que sale en algunos renders, ¿es porque aún se trata de un versión alfa? ¿o quizás hay que toquetear algún parámetro para disimularlo? Un saludo.

Pues que yo sepa no hay antialiasing implementado en Cycles actualmente, a lo mejor alguien habrá retocado las imágenes posteriormente, otra técnica es renderizar la imagen en un tamaño superior al final, y luego reducirlo, y otra manera seria forzar la tarjeta gráfica a usar antialiasing a través del panel de control de la misma tarjeta, todo esto desde la teoría, no te puedo asegurar que funcione porque no lo he probado personalmente.

[jedihe]

Y otra manera seria forzar la tarjeta gráfica a usar antialiasing a través del panel de control de la misma tarjeta, todo esto desde la teoría, no te puedo asegurar que funcione porque no lo he probado personalmente.

El antialiasing de los drivers de video funciona en el pipeline de render de OpenGL, por lo cual no creo que afecte en lo absoluto a una imagen renderizada por un motor de render como Cycles (Cycles no usa el pipeline de render como un todo sino que manipula directamente los mini-procesadores que tiene la GPU).

[V1k1ngo]

Más muestras de los juegos con el nuevo motor, es una captura de pantalla porque no conseguía que en el render me respetara la respuesta de la película que si lograba en el viewport (luego descubrí que hay que cambiar al internar, habilitar color managment, y volver a Cycles para que esto suceda con archivos creados previamente, este de hecho, es un archivo de 2.49, seteado originalmente para Yafray.), a ese tamaño (lo imagen con toda la interfaz recortada es de 1023x650), tardó poco más de dos minutos en llegar a este nivel de limpieza, no está nada mal.

No obstante, para cosas algo más complejas tuve numerosos crasheos, algo esperable por supuesto, pero que pensaba se subsanaría parcialmente con la versión de 64bits, extrañamente tuve problemas en los mismos archivos que la anterior de 32.

Corriendo sobre Windows 7 de 32 bits es otro cantar, ayer lo probé por primera vez en la notebook (Intel Core i3, 3mb Ram DR3, Nvidia GeForce 310m, con 16 núcleos Cuda), no esperaba gran rendimiento, fundamentalmente por la placa de video exigua, pero sí, aunque sea una estabilidad similar a cuando corría en 64 bits. Pero no hubo caso, los crasheos aparecieron incluso al mover la escena por defecto, o peor aún con un solo mono, sé que no es preocupante a este estado, y no lo pienso usar en trabajos reales todavía, salvando tal vez algún render de facultad que no requiere gran esfuerzo, pero me resulta llamativa esta diferencia de estabilidad corriendo la misma versión en dos máquinas distintas.


Por otro lado, y porque no todo es Cycles, hoy encontré este video de smalluxgpu 1.8beta1, renderizado en modo pathgpu2, no sé muy bien de que va esto, me voy a poner a averiguar en algún momento libre durante el día, pero por lo menos, se ve una interesante mejora con respecto a la primer época del slg, se nota el crecimiento del motor, que esperemos esté listo dentro de poco, para tener un buen abanico de posibilidades open source.



-- IMÁGENES ADJUNTAS --

[e1000i]

Hola. Cómo se habilita color management en Cycles? Saludos.

[Caronte]

Te lo acaban de explicar en el anterior mensaje.

[Soliman]

Hay que cambiar a Blender render > render > Shading > color management.

-- IMÁGENES ADJUNTAS --

[Caronte]

En animación, el tipo de ruido que genera en tiempos cortos de render es del tipo estático, por lo que no molesta mucho por fin podemos hacer animación con render avanzado a tiempos asequibles y sin salir de Blender toda una gozada.

-- IMÁGENES ADJUNTAS --

[miguelito08]

En animación, el tipo de ruido que genera en tiempos cortos de render es del tipo estático, por lo que no molesta mucho por fin podemos hacer animación con render avanzado a tiempos asequibles y sin salir de Blender toda una gozada.

Tras ver el video, debo decir, increíble, pero cierto.

Cycles es la bomba.

[Caronte]

Ostias. Flipo, flipo en colores. Se me ha ocurrido abrir un segundo Blender y poner uno de ellos por CPU y el otro por GPU y. Funcionan.

En mi caso puedo hacer render de animaciones el doble de rápido, o sea, que me cuesta prácticamente lo mismo, hacer un frame, que dos.

Vaya, a ver qué motor supera eso.

[SamCameron]

Caronte lo que pasa es que uno de los renders te acabara antes que el otro seguramente ¿no? Porque yo noto una diferencia brutal entre renderizar con CPU y con GPU, y no tengo una mala CPU eh (6 núcleos de 3.3 Ghz), pero con una simple GTX460 obtengo una velocidad 6 o 7 veces superior, y aún tengo otra GTX460 esperando a que activen el multi-GPU. Entonces si que va a ser la ostia.

[fabian4d]

Muy buena el arma Caronte.

[Caronte]

Caronte lo que pasa es que uno de los renders.

Ya hablamos del tema en una ocasión refiriéndonos a Octane y ahora me he dado cuenta de que mi hardware cpu/GPU tiene una potencia similar haciendo render. Yo tengo 8 núcleos overclockeados a 3.2 GHz, pero mi gráfica es una GTX 285 por lo que no hay mucha diferencia entre ambos.

Muy buena el arma Caronte.

Para mí, supone hacer animaciones el doble de rápido, o el doble de largas, pero vamos, que, mayor o menor, para cualquiera va a suponer una mejora.

[SamCameron]

Vaya repaso le están metiendo al bmesh ¿no? Llevan días realizando cambios sin parar y corrigiendo cosas, la cosa pinta muy bien ahora que Campbell puede trabajar junto a Joseph, a ver si le dan un empujón final y vemos el glorioso día acercarse, curiosamente no veo el mismo ritmo ni mucho menos en el desarrollo de Cycles, bretch se está dedicando a realizar tareas de mantenimiento de la rama principal de Blender en lugar de centrarse en Cycles, por lo que a lo mejor no es algo tan prioritario como creemos, quizás hubiera sido genial tener Cycles para ser desarrollado con el GSOC (Google Summer of Code) de este año y así avanzar más y mejor, porque llevo semanas viendo cambios mínimos en el núcleo de Cycles.

[Neo_one]

Yo, siendo todo el percal este, lo que tengo pensado es hacerme un ordenador con un i3 2100 y gastarme más dinero en la gráfica, o directamente comprarme una Apu llano. Por que total, se está viendo que el renderizado por CPU a quedado obsoleto y que con una simple gt220 superas a un i7 970.

[Neo_one]

Vaya repaso le están metiendo al bmesh ¿no? Llevan días realizando cambios sin parar y corrigiendo cosas, la cosa pinta muy bien ahora que Campbell puede trabajar junto a Joseph, a ver si le dan un empujón final y vemos el glorioso día acercarse, curiosamente no veo el mismo ritmo ni mucho menos en el desarrollo de Cycles, bretch se está dedicando a realizar tareas de mantenimiento de la rama principal de Blender en lugar de centrarse en Cycles, por lo que a lo mejor no es algo tan prioritario como creemos, quizás hubiera sido genial tener Cycles para ser desarrollado con el GSOC (Google Summer of Code) de este año y así avanzar más y mejor, porque llevo semanas viendo cambios mínimos en el núcleo de Cycles.

Lo que creo es que se deben estar guardando Cycles para la 2.6 y para la 2.58 y 2.59 corregir bugs y afinar algunas cosas más.