[Opensim-dev] The case for greater than 1024x1024 pixel textures.

[Dahlia Trimble]

I dont believe OpenSimulator restricts texture sizes; these restrictions
are in the uploader in the viewer. There are good reasons for the limits:
oversize textures decrease OpenGL performance dramatically and too many
large textures will quickly drop frame rates to the point where the
application is unusable. Too many unique textures will have similar
effects. If you really need large areas to have higher definition, try
segmenting your large textures and make the area of several prims. This may
actually be a better solution as the viewer will only have to display high
resolution for the prims near the camera and can use a lower resolution
(mipmap) for prims further away.

As far as the avatar goes, the baking process produces textures that are
512x512 for most avatar parts with I believe one exception, the eyes are
256x256. Higher resolution textures for skins and non-prim clothing will be
reduced.


On Sun, Nov 6, 2011 at 8:53 PM, Amy Smith <amy88smith at yahoo.com> wrote:

> This is part of an effort to increase the awareness in
> the developer community of a longstanding need among
> OpenSim content creators and designers of simulator
> environments, for higher resolution pixel textures
> (images greater than current 1024x1024 pixels)
> to be used in stand-alone and/or grid operation of
> sim regions using OpenSimulator.
>
> We are cartoons...
> The present limit of 1024x1024 pixels contributes
> to a "cartoon-like" or sub-optimum look and feel to
> OpenSimulator. If we are to make progress in 21st century
> 3D graphics, higher resolution imagery is needed.
>
> Is it in only in the Viewer?
> Some devs point to the viewer clients being coded to limit
> the image size at upload. Since OpenSimulator project has
> recently changed license and participation method, to provide
> increased interaction between viewer developers and simulator
> developers, perhaps there is a renewed possibility to solve
> this problem in the near future. Some TPV viewers have provided
> compatibility switches in the Grid Manager section for
> use with OpenSimulator.
>
> Is there a SIMULATOR or server-side solution?
> If the only limits are in the viewer UPLOAD, then perhaps
> a method of image insertion at the database level or
> in the simulator console could be provided for higher
> resolution textures.
>
> What should the limit be?It is estimated that increasing the limit to
> at least 4096 x 4096 pixels would suffice for
> most applications. But, for future expansion,
> it should be up to the designer, the sim operator, or
> the grid operator to set such limits (if any).
>
> The areas of design that suffer the most from
> current texture size limits (1024x1024 pixels) are:
>
> 1. AVATARS: Avatar skin and system clothing. (Currently: very blurry! )
> 2. HUGE PRIMS: Large prim objects, such as buildings, environment/ space/
> sky/ backdrops/ backgrounds, etc.
> 3. SCULPTY: Visible texture applied to surface of sculpted objects.
> 4. MESH: Visible texture applied to surface of mesh objects.
> 5. LAND: Teraform, land/ground RAWs, textures, and data maps.
>
> Reproduction of the current situation:
> 1. Upload a 4096x4096 image for use with avatar upper body UV wrapped
> texture for system avatar.
> 2. Observe after upload, that the image has been converted by
> down-sampling and poorly compressing to a resulting 1024x1024 texture.
> 3. Apply the texture to the upper body of the system avatar in the
> opensimulator region.
> 4. Look at the avatar in the opensimulator region, and observe that the
> texture is fuzzy.
> 5. Compare the difference in sharpness of the original design image to the
> fuzziness of the inworld texture.
>
> Respectfully,
> Amy Smith
> aka. Lani Global
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20111106/e4b3fd78/attachment-0001.html>