[sldev] 3D mesh support, vs lossless compressed sculpts

[Dahlia Trimble]

One advantage sculpts have is they require little or no modifications to the
SL asset storage/distribution model. I'm not sure how other mesh storage
methods would fit into this model, but I suspect some modifications would be
required.
One problem I have with sculpties is the lack of precision for the vertex
elements as a result of quantifying them to 8 bit integers to convert them
to a color. Another is the need for square or rectangular arrays of vertices
which makes some techniques of free form mesh modeling difficult or
impossible as arbitrary polygons cannot be added or deleted.

Still, I am impressed with the cleverness of sculpted prims and although I
do share your desire for more flexible means of designing meshes for SL, I
am grateful that sculpties exist and are being improved upon.

On Thu, Mar 19, 2009 at 4:53 PM, Dale Mahalko <dmahalko at gmail.com> wrote:

> It occurred to me recently that LL's reasoning for not supporting raw 3D
> meshes as a prim type is basically invalid, what with how SL functions right
> now.
>
> The whole premise behind sculpted primitives was the idea that wavelet/JPEG
> lossy compression could be used to store "organic" shapes that don't have a
> very definite shape or form. The lossy wavelet compression of the RGB map
> allows the data size to stay very small on the asset server, and that this
> could not work if applied to storing and rendering mesh data.
>
> However, that whole argument was thrown out the window after people kept
> demanding precision in sculpted shapes, and some time ago someone at LL said
> "Okay, FINE, we will allow the option of lossless compression for RGB
> sculpt-map uploads" and support for this lossless uploading has been added
> into the viewer.
>
>
>
> So, uh, if lossless compression of sculpted primitives is permitted,
> doesn't that mean that there could equally be support for lossless
> compressed 3D mesh uploads, like traditional 3D editors use?
>
> There apparently isn't really any reason to prevent mesh uploads anymore,
> at least as long as the meshes are very small and simple, and the largest
> uploaded mesh byte size is equal to or smaller than the most randomized,
> incompressible compressed sculpt-map.
>
>
>
> Allowing use of small meshes would be more efficient for the 3D renderer
> anyway. Since sculpts have a fixed number of triangles, if your model does
> not need the triangles for detail then they need to be "bunched up" into a
> pile to get them out of the way, possibly tucked inside the model so they
> don't show. But these unnecessary bunched up triangles are still being
> processed by the 3D renderer whether or not they are needed.
>
> LL's own sample sculpt maps demonstrate this problem, like with the
> S-shaped sculpt that has a ton of prims scrunched up on it, and which could
> drop 50% or more of the triangle faces on it and still look good.
>
>  So sculpted prims actually add to 3D scene rendering lag and contribute
> to a lower framerate and poor performance because they do not and cannot
> "turn off" unneeded triangle faces, vs a mesh which just simply would not
> include any more detail triangles than the mesh actually requires.
>
>
>
> But there seems to be major LL heel-dragging against implementing actual 3D
> mesh support and making models a heck of a lot easier to build in external
> editors, vs the arcanary of sculpts that very few people understand or can
> use effectively to reduce prim usage.
>
> So, I am not expecting this post will change anything. But oh well, I
> thought I would bring up this small detail for discussion. The sldev list
> has been pretty quiet lately anyway.. ;-)
>
> - Scalar Tardis / Dale Mahalko
>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090319/377039d8/attachment.htm