Minimizando las caídas por fallos gráficos

Una de las causas mas comunes que provocan que nuestro visor se cierre sin aviso (crash) y nos desconecte de Second Life u Opensim, son los fallos gráficos, ya sea por bugs en los controladores, bugs en nuestro visor o, principalmente, por saturación de información que recibe nuestra tarjeta gráfica. En este último caso suele ser por acción de los griefers o mal uso del contenido adjunto a un avatar o depositado en el mundo.

¿Qué significa esto?

Objetos creados con exceso de «información» o «detalle» pueden saturar las capacidades de nuestro visor. Sculpts, Mesh, simples objetos creados con prims normales, pueden tener un nivel de detalle muy elevado, que obligan a nuestro visor (y tarjeta gráfica) a exigirse al máximo para poder renderizarlos y mostrarlos en pantalla. Si hablamos de uno, dos o tres objetos con esta característica, quizás no nos demos cuenta, a lo sumo, notaremos que el visor tarda mas de lo habitual en dibujarlos. Pero…. ¿Qué pasa si un sim o un avatar tienen decenas de estos objetos?

La respuesta es simple, en algún momento, si nuestra PC no es lo suficientemente potente para soportar tanta información, este exceso de la misma provocará una saturación en el procesamiento (overflow) con el consiguiente cierre violento de nuestro visor (crash).

Este recurso es muy utilizado por los griefers para provocar caídas masivas en sims muy concurridos (o no). Tarde o temprano, empezamos a notar que nuestro visor responde con lentitud hasta que se cierra sin motivo aparente. A veces, ni siquiera nos da tiempo a notar la lentitud y nos caemos de SL en forma intespectiva, volvemos (al mismo lugar) y se repite la historia.

Ahora que tenemos una noción básica sobre este problema que, seguramente, nos pasa a muchos de nosotros y nos cuesta entender el porqué, la primer pregunta que nos viene a la mente es ¿Y cómo podemos evitarlo?

No se si podemos evitarlo completamente (aunque algunos aseguran que si), lo que si podemos hacer es minimizar el riesgo de tener caídas por este motivo. Para esto, viene en nuestra ayuda lo publicado por el grupoThe Green Lanterns en su blog y que tiene que ver con hacer unas pequeñas modificaciones a algunos valores del visor en las opciones de Depuración del mismo. Les detallo a continuación aquello que podemos tocar:

(En todos los casos debemos ir, según nuestro visor a Mostrar Opciones del depurador, Debug Settings o similar)

Visor Oficial de SecondLife:

RenderAutoHideSurfaceAreaLimit114
RenderAutoMuteSurfaceAreaLimit2100
RenderAttachedLights FALSO


Visor Singularity:

RenderAutoHideSurfaceAreaLimit114
RenderAutoMuteSurfaceAreaLimit2100
RenderAttachedLightsFALSO


Visor Firestorm:

RenderSculptSAThreshold114.000
RenderAutoHideSurfaceAreaLimit114
RenderAutoMuteSurfaceAreaLimit2100
RenderAttachedLightsFALSO


¿Qué significa todo esto?

En todos los casos, estos parámetros indican limitaciones de renderizado o calidad en los objetos que nuestro visor debe mostrar. Ya sea limitando la calidad de los objetos mostrados que superen los límites establecidos en estos parámetros o no mostrando, las luces anexadas al avatar (muchos usarios gustan de caminar por el mundo como arbolitos de navidad).

Una cosa es segura, desde que he configurado estos parámetros, hace ya varios días, he podido notar que no he tenido ninguna caída repentina en las pruebas que he realizado yendo a lugares cargados de prims, avatares y griefers.

Existen otros parámetros que pueden ser modificados también, pero los dejo para otra entrega ya que primero quiero probar cuales pueden ser los valores óptimos a configurar.

SaludOS/2

2 comentarios sobre “Minimizando las caídas por fallos gráficos”

  1. Muy interesante el articulo; ahora en cuestión de la gráfica ya dependerá de que gráfica se use para que esto influya; si usas una gráfica de gama baja sea nvidia o amd probablemente a causa principalmente de su vram y bus de banda esto pueda ocurrir; las gamas bajas manejan una vram 1gb que realmente no aprovechan por tener un bus de banda pequeño (64bits y 128bits) y un chips recortadisimo; aunque existen gamas baja con 2gb de vram esto es solo mercadotecnia porque sino aprovechan un 1gb menos 2gb.

    En gráficas gama medias, medias-altas y altas es difícil que estas puedan saturarse o se vean apretadas en sus procesos y mas en un juego como sl que no es tan exigente gráficamente como un crisys 3, un skyrim con muchos mods o un battlefield 4.

    saluditos

  2. Esto es relativo. Por definición, al ser un software de 32 bits, el cliente de Second Life, limita (capa) la memoria de la gráfica a un máximo de 512MB de RAM (independientemente de la RAM real de la misma), y reserva hasta un máximo de 75% de dicha memoria (384Mb).
    Otro error común que se comete, especialmente por parte de los gamers, es creer que, por la calidad de lo gráficos, SL requiere menos que los juegos potentes cuando esto no es asi. Los juegos tiene gráficos de alta calidad y definición estáticos y simplemente son cargados por la placa de video, en cambio el cliente de SL recibe la información de los objetos y, con ella, debe renderizar cada objeto, avatar, etc. que se encuentra dentro de su campo de visión (también, aunque no lo muestre, renderiza objetos que están fuera de nuestro rango de visión). No es lo mismo mostrar que renderizar. Recordemos que SL es un mundo dinámico, el avatar que vimos ayer, en unas horas cambió su shape, su skin, su ropa, su altura, etc. y nuestro visor debe volver a renderizarlo.

    SaludOS/2

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.