[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