I agree. I hope there will be grid wide option how to disable the large textures if it will be once possible. I see no reasons why create such a large assets.
I would prefer users rather produce more prims than big textures on megaprims. Thats why they have 35.000 prim limit on our sims. Bo On Monday 07 of November 2011 15:50:04 Melanie wrote: > You are disregarding a number of factors. > > First, OpenGL just doesn't seem to be capable of it. > Second, OS content is created by amateurs who think bigger is > better, as evidenced by existing creations. > > For social, SL-like grids, this certainly must remain disabled even > if a way is found to implement it. > > Melanie > > On 07/11/2011 15:02, David Kaplan wrote: > > I whole-heartedly support this proposal in whatever the solution may > > be - regardless if it's an issue with the viewers or the server. I > > don't see that have larger textures will create appreciably > > significant performance issues because, much like web designers, > > people who are competent in building on OS are aware of bandwidth > > and optimization concerns when it comes file size. If they aren't, > > awareness will have be raised on this issue but I don't think a lack > > of awareness should impede creativity. OS has a lot of competing > > products out there (e.g., Unity, etc) and they all manage to do the > > job well while also allowing for robust textured graphics. I > > understand software like Unity is implemented differently but there > > is little reason why this issue should different. > > > > My two cent. > > > > On 11/7/2011 12:06 AM, Nebadon Izumi wrote: > >> Lani > >> > >> This is a viewer issue and not really an OpenSimulator issue per > >> say, it would be better taken up with the viewer devs, there are > >> really no limitations on the server side for that limit the size > >> of any texture, in fact the viewer also has no problem displaying > >> larger textures, i have several 2048x2048 texture in SL, i believe > >> they were uploaded with a special LibOMV client back in the day > >> before LL closed some holes. Technically the only place that > >> limits the size of the texture is when the viewer converts the > >> image to a jp2 image before it sends it to OpenSimulator, if this > >> can be modified then we could upload larger textures, though there > >> may be some other good reasons we would not allow this, such as > >> performance and such, the files could be quite large, and having > >> to download lots of these large textures could really cripple > >> things, we would need to do some tests to be sure, there may also > >> be other difficulties involved for TPVs with the Terms of Service > >> of secondlife and making such modifications to the viewers, this > >> really needs to be taken up with the Viewer Developers to see what > >> they think. > >> > >> On Sun, Nov 6, 2011 at 9:53 PM, Amy Smith <[email protected] > >> > >> <mailto:[email protected]>> 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 > >> [email protected] <mailto:[email protected]> > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> [email protected] > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
