Another thought here is.. at least with sculpted prim there are a few things.. as far as the renderer.
There is a known number of vertices and you can index them by texture UUID so you only have to keep 1 copy around per texture in memory. Making sculpted prim is somewhat hard. This reduces the number of them out there thereby keeping a good relation between the scene complexity and 'user work required to make the scene complex'.. which is important for worlds with user created content. There are quite a few number of formats for 3d mesh. Some, very convoluted to implement. Some not so. A couple of other concepts that one must think about when dealing with this is, Bones? Skinning? morphs? Normals? binormals? Object heirarchy---> Linkset conversion?. These are all pretty simple for Sculpted prim. Now that I got that out of the way... gimme gimme support for 3d meshes! Regards Teravus On 3/19/09, Luis Ibanez <[email protected]> wrote: > > 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 > _______________________________________________ > 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
