G-Blender

Estoy trabajando en diferentes objetos en blender, había hecho una vieja mesa en cycles, he marcado las costuras y he subido una imagen de Internet a la "imagen de lienzo" de la nueva textura. Hay un espacio exterior más allá del límite del espacio UV, creo que es normal, creo que es correcto también, pero que el espacio es píxeles después de todo? Creo que Unity o Unreal o algún motor acaba de leer la información en píxeles para las coordenadas UV que he marcado en blender .... y no para aquellos que ve ve en esta imagen.

¿ el espacio por fuera de las UV? ¿tiene validez? , es decir sea png o jpg esta "textures" se cuenta como valor de pixel?

validez me refiero a lectura computacional (kb,megabytes,etc).

pd: tengo pensado llevar los "assets" que estoy haciendo a un motor como unity, pero como se algo de programacion ,me surgio la duda de que si ese espacio por fuera de las UV ,sea en png o jpg tiene un "coste computacional" en tiempo real....dado que si creo un objeto 3D y uso "polimorfismo" ,etc ,etc , la llamada al objeto tambien llamara la texelacion de la textura en tiempo de ejecucion.

Generalmente solo te preocupas de eso si son modelos para un videojugo. Y si es para un videojuego creo que deberias de usar internal, pero no estoy seguro.
Pero para responder tu pregunta: No, los pixeles no usados en el mapa UV no serán renderizados, pero sí cargados en la memoria.

de momento uso cycles ,pero despues lo paso al internal para exportarlo tranquilo a Unity.
claro yo lo que deseo saber es que , por ejemplo , no va a ser renderizado ,dado que las coordenadas UV solo se van a restringir su lectura hasta el "margen" o la delimiatacion, el problema que esas texturas asi puestas dejan pixeles que de alguna manera pueden cobrar dinamismo en las iteraciones de un codigo de programacion , supongo.

PD : si hubiese usado "texture paint" solo pintaria las uv sin pasarme, pero como es un "Unwrap" medio currado, algo de "cube proyection para algunas island" y otras "followActive quads" fui armando los unwrap para que todos me den una agradable streching...pero el tema es que cuando uno usa un "Unwrap" con ese tipo de texturas SIN PINTAR sucede que siempre hay esos pixeles de fondo, el jpg pesa menos que el png...pero aun usando png , seria mas pesado el archivo.

Cuando estés creando texturas para juego u otros motores de juego... ni Cycles, ni internal, yo creo que lo mejor es utilizar directamente el Blender Game
La diferencia entre JPG y PNG, no solo es el tamaño; la PNG siempre será de mayor tamaño, si no que entra el alpha en juego, o sea, que la PNG soporta las transparencias, y el jpg NO.
Y lo que importa al cargar una imagen en un juego, es el tamaño de la imagen, no la forma como tengas desarrollado el UV Mapping.

Es mas importante el tamaño? con la "regla de 2" , 1024x 1024, 2048 x 2048 etc?? si lo de formatos lo entiendo , cycles lo uso para experimentar , luego paso al internal, tienes razon quizas sea mejor experimetnar en blender game , pero nunca lo uso .
Claro, objetivamente deseaba saber si ese espacio por fuera de las UV coordiantes vale como carga en la memoria en ejecucion del juego o si conviene ir a un editor como gimp o photoshop y eliminar el espacio sobrante.

No creo que eso cuente, es un simple UV
El tamaño de la textura si, pues carga un poco el juego. Pero claro si hablas de una sola textura no, pero en los juego suele haber bastantes mas texturas que las de un solo modelo, están también los terrenos, etc...
Las texturas si van a ser muy cercanas o en pantallas grandes, pues de mayor tamaño, pero si es para un móvil por ejemplo con 512 te sobra.

Estoy viendo de acomdar bien las uv coordinates para mejorar la densidad de teselacion, que queden el "color grid" que estoy haciendo el test prolijo....asi cuando baje la resolucion de la textura a 512x512 por ejemplo la densidad de pixel se vea bien, lo que pasa que este es un juego donde trasncurre todo en una mesa!! y esa mesa esta dentro de un cuarto de una casa, no es un juego de muchos poligonos, es mas seran 12 assets en total y 4 personajes principales.