Jira vote: Mesh import vs In-world sculpt tools

Qarl has set up a little jira voting thing, to prioritize effort between supporting mesh representation imported from external tools, and improving in-world tools for sculpties. (Some may guess which I favor, but I'm trying to just point out that the issue is available for voting.)

See:

http://jira.secondlife.com/browse/MISC-1494 - vote to favor importable meshes

http://jira.secondlife.com/browse/MISC-1495 - vote to favor in-world sculpty tools

(Sorry if this is a repeat thread, but I didn't find this mentioned in a cursory glance through active threads here.)

I'm all for meshes. I also want .obj support. I've seen a few people shout for collada support, but many modeling programs still don't support collada. When the time comes for adding fancy features like animation then collada support could easily be added.

Why mesh support?:

Inworld building tools give the illusion of being able to build rapidly but in reality they're very slow and cumbersome. and I can't ever see Linden Lab creating inworld tools that can match professional modeling programs like Maya and ZBrush etc.

The only positive thing I can say for primitives is that they download quickly. Oh and it used to be great fun building with primitives in the sandboxes alongside geeky creative people. But those days are long gone. All the kids and the barbie dolls have scared the grown ups away. So now we all build on secret platforms in the sky.

I'll probably still use lossy sculpties for a lot of stuff even if we do get mesh support.

Let's just hope LL can unclog the asset server before they bring in meshes. The content delivery rate was really poor last time I checked. Maybe they could allow us to host our meshes on our own super fast web spaces?. Oooh controversial!!...

Hey, That's great to see.

In first place i personally would always vote for supporting of meshes, because this will certainly add new possibilities for creators, while supporting inworld sculptie tools again goes into the direction of a "monolythic one fits all thing". But the decision "in world sculptie tools vs. mesh support" is a bit like comparing apples with pears to me.

My viewpoint on this topic is slightly different:
if meshes are going to suffer from all kinds of problems (which i don't know of, since i don't know, how meshes would be implemented at the end), i'd rather like to see sculpted prims be optimized instead. I'd rather like to see things like this: "make animated sculpties, solve current inconveniences,allow more precise sculptie meshes..."
But this is not asked for in this vote

If the votes where:

"enhance sculpties" vs. "make in world editors" (i'd vote for enhance sculpties)
"enhance sculpties" vs. "support for meshes" (i'd ask for more details, see below)

So, in order to vote for meshes, it would it be interesting to know, where we can find more detailed informations about the anticipated results, so we can back our decision with (even weak) facts?

things like:

will mesh-support be more or less resource consuming compared to sculpties?
will mesh-support also handle animated meshes ?
will mesh-support include texturizing support ?
will mesh suport also mean, we can EXPORT meshed from SL to out tools ?
will mesh support make sculpties obsolete ?
How would sculptie tools look like ? any phantasie about how that could be ?

It would be great to see a matrix with pros and cons for sculpties/meshes...
Then sort of a decision could be made, whether it makes sense to vote for meshes.

But since all that probably won't be available (sigh), i rely on my stomach now, and it tells me (without knowing any facts at all): Vote for meshes (and hope for a .OBJ importer)

Would imported meshes be phantom?

Phantom... I would guess...

Qarl Linden says they have been discussing meshes for some time (/8/9a/278017/2.html#post2125866). Finding that information is difficult. But the search does reveal some interesting sites.

http://www.massively.com/tag/qarl-linden/
Good information

http://gwynethllewelyn.net/2008/08/29/no-more-limits/
Great aritlcle on the limitations imposed by Lindens.

https://jira.secondlife.com/browse/VWR-5647
SL residents on scultpies.

http://nwn.blogs.com/nwn/2008/08/survey-results.html
Pro's vs Everyday Creators - Mesh Import Effect
But I have yet to find Qarl's information.

I would also like LL not to place heavy restrictions on the vertex count. Programs like ZBrush and Mudbox aren't really designed to deal with multi part objects. Working with multi part objects in these programs can be incredibly tedious. It also results in unsightly seams everywhere.

3D modeling programs offer great features and yet many of those features will go to waste if vertex restrictions are imposed by LL. Yet if people want a detailed model then they're going to upload one regardless. So why not have a detailed model made from a single mesh instead of 40 smaller meshes with nasty seams?.

But I can see how from a programming point of view it's going to be easier to impose restrictions if meshes are limited to 1024 vertices like primitives.

Simple option is to have a prim weight in vertices. So a model with 3500 vertices could count as 4 prims.

I read the choices in the vote not as an "either or", but as a "which do we do first". On that basis I voted for prim modeling as the benefits of having the normal prim editing options available on sculpties are quite compelling.

Yep, I'm all for this approach!.

It could work with sculpties with just the enabling of prim end and profile cuts in the editor.

http://jira.secondlife.com/browse/MISC-1495?focusedCommentId=75441#action_75441

It gives a lot of the benefit of meshes with minimal coding.. Hence my vote going for do this first.

Why prim end and profile cuts?. Why not use sculpty planes?.

Would it solve the problem of seams between sculpties?.

I don't think it's possible to map a complex non convex mesh onto a single oversized sculptmap via software alone. A builder would need to be very sculpty aware.

It gives more control over the exact number of vertices and the LOD changes. Use the cuts to isolate a 64 x 8 section of the map to get LODS of 32 x 4, 32 x 4, 16 x 4, 9 x 4 for example. The other advantage is for animated sculpties, as these can then be done from a single sculpt map by updating the cut positions, thus reducing texture requests to the asset servers to one per animated sculptie, rather than one per frame.



At the least it offers the possibility of a very simple solution to it. If two prims in the same linkset use the same sculptie map, then if prim 1's End Cut equals prim 2's Start Cut there is a seam. Exactly how best to handle that seam is open for suggestions, moving both to the midpoints actually gives interesting animation possibilities from moving the seperate parts.. But I suspect for the shading engine that they are in the same vertex space is enough, so maybe nothing else would need to be done.



Me neither which is why I think meshes should stay on the agenda as well. It's just the prim editing offers a lot of extra functionality for significantly less coding so I think it should be done first

Does anyone know for sure whether the mesh option would include collision detection with the mesh rather than a simple bounding box? In my view, this is the most annoying thing about sculpties. You can't poke your legs under a sculpty table unless it's phantom, and then you can't stand on it. Invisible extra prims are only a partial solution. This question would determine the choice for me.

I don't believe the discussion outside LL has gotten this far.

Qarl seems to have said his only big reason for not implementing sculpted physics (YET) is that everything else about sculpties was quick to slip into the framework of SL. Sims DON'T read texture files, so they can't treat sculpties as sculpties (yet). By the time they've implemented a whole new filetype, they'll probably have made that filetype perfectly readable by the sim.


From all I hear, the issue of physics is just a distraction from the real matter, and even rendering issues like polygon count don't quite cut to the heart of it – it's what we can STREAM. When and where a new mesh format can send the same-looking shape faster, that's where it's clear we need it.

Maybe it's just my love of math, but personally I've always admired the way Second Life becomes a grand display of shapes neatly assembled from (mostly) parametric building blocks. We have sculpties now, but at least they're pretty efficient for 32x32 meshes (and in my mind it's fairly neat and tidy how they're fully describable by a single, small, rectangular image). My hope is that whatever direction SL heads in, they continue to heavily promote the development of modeling based on somewhat tidy, highly-streamable math.