Memoria alocada allocation memory

[Jose M.]

Buenas. Quería plantear este problema típico de Vray (y de otros motores que no son Vray). Para ver si saco alguna conclusión que me pueda servir para solucionar problemas actuales y futuros.

A mí me pasa con Vray. Y el mensaje que da viene a decir que hay una petición de una serie de bytes, que ya están ocupados con otra información o algo así. ¿es eso? Como si esos bytes donde quiere Vray almacenar nuevos datos, ya estáuviesen llenos. Y digo yo, ¿por qué no busca otros vacíos? O por que no página esos datos en la memoria virtual? Todo menos petarte un render.

El caso es que, actualmente tengo un equipo nuevo, con 4 gigas de Ram, y también he probado con 6 gigas, porque tengo un juego de 2x2 libre por el momento y le pongo un sim adicional a cada máquina. Con lo que se supone que en un render de 4 o 5 gigas no debería tener problema, y lo tengo. Me da ese error. Yo no lo entiendo. ¿esta mal mi memoria?
Esos errores de memoria cuando trabajas con recursos limitados, podría entenderlos. Pero con un Quad y 6 gigas de Ram ni idea.

[Mario]

Voy a decir algo por probar. Quizá el problema no es que Vray(o el que sea) no sea capaz de buscar otra posición de memoria, sino que el sistema operativo da un timeout en una posición y se jodido el invento.

Por eso yo creo que no es un problema de la memoria (hw), sino de la forma en que el so (ahora empezaremos con la guerra Windows y su administración de memoria) reparte y organiza la información en las posiciones de memoria.

Igual que se fragmenta el disco duro.

Pero vamos, que es una idea.

[TBC3D]

Suerte, cógete un par de barritas energéticas.

[Jose M.]

Voy a decir algo por probar. Quizá el problema no es que Vray(o el que sea) no sea capaz de buscar otra posición de memoria, sino que el sistema operativo da un timeout en una posición y se jodido el invento.

Por eso yo creo que no es un problema de la memoria (hw), sino de la forma en que el so (ahora empezaremos con la guerra Windows y su administración de memoria) reparte y organiza la información en las posiciones de memoria.

Igual que se fragmenta el disco duro.

Pero vamos, que es una idea.

Mario. Algo de eso puede haber. Quizás por eso he leído en alguna parte que a veces funciona poner la prioridad del fichero max en Low, aunque a mí en este caso concreto no me solucionó el problema.

También he leído que otro camino para avitarlo, es optimizar al máximo todos los materiales. Yo en la escena que me da el error, pongo un material gris a toda la escena, seleccionando todo y asignando un default, y el error no se produce.

Pero claro, si tienes muchas texturas grandes en la escena, que puedes hacer? Hay alguna manera de saber que resolución será suficiente para renderizar la textura de un objeto, por ejemplo, en animación, a 720 píxeles? O a cualquier otra resolución.

Y en qué formato sería más recomendable tener las texturas?
Yo he leído por aquí que el jg hace trabajar más a la CPU, por la cosa de la compresión.

[Mario]

Eso ya se me escapa. Hace un tiempo leí por ahí (a saber donde) que la resolución de la textura debía ser justo el doble de la resolución de salida, es un recuerdo que tengo, aunque no sé si será verdad.

Respecto a lo del (*.jpg) me parece que es hilar muy fino. Si pones las imágenes en, bmp (por ejemplo) para evitarte la compresión, tendrás archivos enormes que te comerán la memoria. En cualquier caso, no creo que la diferencia de tener que descomprimir esas imágenes sea apreciable.

[Jose M.]

Mario me imagino que te refieres, a cuando sacas un render completo de una sola textura, por ejemplo, un primer planod e un suelo en el que solo se vea ese suelo. Y claro, siempre y cuando el suelo sea una textura completa y no tileada.

Pero por eso lo decía. Cuando haces un render, ¿cómo puedes calcular que calidad va a necesitar tu textura si su parcela de representación será super pequeña. Si una casa ya se ve a lo lejos, y el mapping esta a 100, 1 metro, lo que veras en la escena de esa textura, si la salida es, por ejemplo, 2000 por 1500 probablemente no llegue ni a 100 por 100. Aunque apuesto a que si le das 100 por 100 pierdes nitidez en esas paredes. Debe haber un punto, una regla, o alguna manera de calcularlo.

Siguiendo con la memoria alocada, y haciendo pruebas y leyendo cosas, el render que no me pasaba, al final he conseguido que pase. Yo lo hice de la siguiente forma:
Me fui a system de Vray, y cambié el valor max tree depth por defecto en 60 y lo puse en 30. Probablemente he perdido algo de velocidad en el render, pero no me ha dado el error.

Edito y aclaro algo en este punto: he probado ahora a ponerlo en 50. Y tampoco me ha dado el error. Y de 16 minutos con 3 segundos que me tardaba el render con 30, ahora me ha tardado 12 minutos con 29 segundos en 50. Cuanto podría ganar poniéndolo a 100 y que pena no poder ponerlo ni a 60.

De todas formas, teniendo 6 gigas de Ram, habida cuenta de que durante ese render no llegamos ni a los 4,5 gigas de Ram, no debería tener problemas ni siquiera subiendo ese valor al tope, 100, donde ganaría velocidad y aún me sobraría con mis 6 gigas.

Por eso como decía al principio del hilo, por que se producen esos errores de memoria cuando aún te sobran recursos? Es difícilmente comprensible. Ya me costaría entenderlo porque acabada la Ram, está la paginación de disco duro que debería resolver la papeleta, pero si encima aún sobra mucha RAM.

Otra cosa, con los 6 gigas, he desactivado el archivo de paginación. Es esto aconsejable? Lo he hecho porque nunca rebaso mis 6 gigas y veía un poco absurdo tenerlo. ¿he hecho bien o me puede dar más problemas? Y si pongo archivod e paginación teniendo 6 gigas de Ram, que proboolean serían aconsejables para mínimo y máximo? Saludos.

Posdata: por cierto, que yo parto de la base de que descarto problemas de hardware. Primero porque hago pruebas en dos equipos similares, y el error se produce en el mismo punto. Sería mucha hola. La memoria parece estar bien y no producir incompatibilidad, y es el mismo error que se producía en mí antiguo equipo Core 2 Duo. Y tampoco creo que sea overheat de los quads, porque en todo momento los mantengo a 58-60 grados, y puntualmente pueden alcancar 62-63 en algún segundo. Además, si el problema fuese ese supongo que, el punto del error no estaría tan localizado.

Por cierto, primero retrasé el punto del error (salía casi al principio del render final) cambiando el antialiasing de adaptative a Quasi Monte Carlo (con lo que el error se empezó a producir justo al final del render). Y luego como digo hice desaparecer el error con el cambio en el system.

[kaox]

Yo sobre ese tema se poco la verdad lo último que me ha pasado es que, al llegar un punto de un render me da un error y se cierra el max me ha pasado en dos ordenadores diferentes, supongo que, será algo que tengo mal confiugrado en la escena, algún RPC, hice copias no sé si será aconsejable, también tire el mpa de irradiance en Catmull y luego renderice en área con ese Irradiance Map, no sé si eso será valido. Una pregunta que es lo de paginar y donde se activa o desactiva, y para qué sirve, gracias.

[acortes]

A mí también me suele pasar eso de la memoria allocada. Es bueno saber lo del maxtre para salir de un apuro, pero debe haber algo que esté mal configurado, o alguna solución. Yo tengo un Quad también con 4 Gb de Ram y me da ese error.

Kaox, la paginación está en preferencias-->rendering, abajo a la derecha. Y si te digo la verdad no tengo del todo claro que parámetros poner. Sirve para liberar la Ram de memoria paginando en el disco duro.

[Vicent]

Puede que no tenga nada que ver e igual ya lo probaste, pero por si acaso lo comento. Con 4 Gb de Ram a mí se me colgaba directamente sin ningún aviso con escenas con VrayFur y también con gran cantidad de Vray Proxys.

Leí que independientemente del tipo de geometría que tengamos en default geometry los proxys y el Fur siempre generan geometría dinámica.

Aumenté el valor de dynamic memory limit y por el momento ya no he tenido más problemas. Saludos.

[acortes]

También probé eso, aumenté de 400 Mb a 800 Mb y el problema persistía. Ya digo, el origen de todo el problema eran los objetos a los que había cambiado el visibility en propiedades.

De todas formas, muchas gracias Vicente.