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

[Teravus Ovares]

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 <luis.ibanez at kitware.com> 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
>