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

Luis Ibanez luis.ibanez at kitware.com
Thu Mar 19 20:09:16 PDT 2009


Hi Dale,

I agree with you on this point.

It is currently the case that due to the lack of support for raw meshes,
users have to go about composing complex shapes by combining many prims,
most of which end up being obscured inside others just to get the final
form as the envelop of the group. The final result is that the client
has to render a large amount of triangles, many of which are simply not
visible.

I can see as well, that there is a point in limiting the size of meshes
that users can upload, and as you suggest, a mesh that has storage cost
and a rendering cost similar to current images should be allowed since
it doesn't diminish the performance of the client or the server.

This may be a situation where it is not possible to find a "one size fit
all" solution. For example, Avatars probably shouldn't be allowed to
carry meshes that are too large or complicated. While owners of regions
should be allowed, (and allowed to authorize others) to place complex
meshes in their local sites. For example, I can imagine a University
Campus that has an anatomical display, wanting to use raw meshes for
rendering livers, hearts, lungs, arteries... etc.

If the extra complexity of the meshes actually result in a higher server
and storage cost, this should be then offered as an option to the region
owners (for a price). Many may not need this features, but for others
they are vital.

As an example, I was visiting recently an educational display where a
Heart model is shown cut open. The heart was made out of prims (a lot of
work, and very well done), but it could have made with less effort and
better looking by using a raw mesh.


     Luis


------------------
Dale Mahalko 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


More information about the SLDev mailing list