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

SignpostMarv Martin me at signpostmarv.name
Thu Mar 19 17:54:04 PDT 2009


Didn't I read something about the possibility for sculpties to be 
animated/manipulated with shader language code ?

How would arbitrary meshes be animated/manipulated ?


 ~ Marv.

Dahlia Trimble wrote:
> 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 
> <mailto: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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3244 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090320/897a595a/attachment.bin 


More information about the SLDev mailing list