There must be some support for skeleton or morph animation of meshes in the viewer as the avatars use those techniques. I have no idea if they could be applied to other meshes.
On Thu, Mar 19, 2009 at 5:54 PM, SignpostMarv Martin <[email protected]>wrote: > 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 <[email protected]<mailto: >> [email protected]>> 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 >> >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
