Mesh UserGroup expanding to cover wider Content Creation agenda - input needed

[Charlar Linden]

Now that the Mesh project is in maintenance mode, we want to morph the focus to be more general. 

I'm interested in everyone's feedback on what aspects of content creation we should cover, with the assumption that the full range all possible topics might be too much to handle in one meeting.

This is to get the conversation started. 

thanks!

Charlar

[Gaia Clary]

I am not sure if i understand your request correctly. But here are some topics which came up in my mind instantly. Maybe they are already on the Agenda:

 

• For me the most natural expansion would be to cover mixed content building with regular prims, sculpted prims and meshes.
• Access from third party tools is a big issue too. This would cover how we can add our tools for  importing mixed builds. There is a lot on my wish list here
• I think also exporting may be a topic. I wonder if some day we will see some sort of official Second Life supported Backup/restore format which would allow us to maintain our SIM builds locally instead of relying on the backupsystem of Linden Labs (and which would also cover all these permission issues...)
• I am sure animation will be important including animated (rigged) objects and all about custom bones.. but that is already on the agenda, isn't it ?
• As well as texturing and materials
• Documentation "how to generate content for Second Life"...

Just my 2 cents for now.

[Jenni Darkwatch]

I'd kinda like to see some simple way of creating mesh in SL. Long shot, I know. But the ability to create most content _in_ SL is, I think, what made SL more or less successful. Nothing fancy, just some basic functionality.

[Alisha Matova]

Here are some things that desperately need attention.

 

First agenda: put the local/world/reference dial Back in the edit window. Please. Or give us a keystroke option. =). I know it sounds minor, but hiding it in the options window is a Giant workflow killer. Please put it back.

 

Second agenda: extending permissions for full perms sellers. We have next user perms now. What we really need is next-next owner permissions. This way FP creators can control the permissions of their creations after they are transferred to the end user. Ie: full perms kit is sold to inworld creator> inworld creator builds and sells item with full perm parts> when item transfers to end user "next next owner perms" kick in.

This will help protect FP creators across the grid. Textures, sculpts, animations, mesh, etc.

 

Third, and out of the scope of creation, in a way. Please give us an option of using the old pie menu. Once learned, pie is 100 times more efficient to use. Also, unlike the new file menu, it actually pops up under ones mouse. Where as the file menu pops up where ever it feels like(due to where you right click).

 

Forth: and extremely important. Bring back the ability to "mouse hover change" the tabs in the edit window. Ie: I should be able to drag something to the contence(or texture)of the edit window, and automagically change the active tab by briefly hovering mouse over that tab. Another huge workflow killer that drove in with v2.

 

ETA: once the above are addressed, I'd love to see, materials, normal maps, bump, object rigging, etc. added to mesh. And.. someone should look at Qarl's magic prim alignment code.

[Drongle McMahon]

I still need to think more about this, but here it is for now: One of the earliest recognised problems with the introduction of mesh was the feeling that it would create two classes of creator, those who copuld use it and those who could not. Many who did not feel able to tackle external 3D software, or who simply wanted to do all their building in-world, felt excluded by the appearance of an elite class of mesh builders who would have too great an advantage and diminish the satisfaction they could get from thier own building. This is, of course, directly contrary to the shared creative potential that has been an important part of SL's appeal.

So making sure that mesh brings nnew creative potential to these residents is an important objective. This is helped to some extent by mesh-enabled creators who are making building components which can expand the possibilities for others. However, these lack the level of manipulation available with standard prims, which is essential to ythe ejoyment people get from using them. So the proposal here is to anable the generation of a new kind of parameterised mesh that will exploit the code already written and produce a whole nes range of highly manipulable objects for people to build with. Of course the standar prims are already parameterised meshes, but they are not generalisable and creators cannot make nes ones. Changing their parameters (toturing) often makes gross changes to their geometry, taking the out of the scope of existing mesh code.

I have considered three knids of implementation, but will not go into details here. Basically they are (a) vertex group definition and simple transformations thereon, (b) morph targets (which would be a superset of vertex group transformations and © arbitrary skeleton rigging. In view of discussions of the potential of arbitrary skeletons for  animation of mesh, the latter would likely be preferred as it would exploit the same code. I am not sure it can deliver all the functionality required, and might be profiotably combined with some other adjustable transformations.

Whichever approach might be chosen, the important thing will be the interfaces, first to the creator, and then to the user. For the former, it should be essential that the specification of the mutability of mesh is such that it can be done with standard Collada contructs. For the latter, the ideal would be a direct manipulation interface, for which the stretching of bones would seem to be ideally suited. The bone and other parameters could be maniplulated by renamable parameters in place of the existing edit dialog spinners. An interface to LSL would also be essential to allow scripted adjustment interfaces.

 

 

[Medhue Simoni]

@Drongle - WHAT! JK, I kinda think I know what you are talking about, but probably not.:smileytongue:

Ok, here is what I think. Basically, I think the group should change from all about mesh, to all about what those objects do. Let's be honest here, when we talk about objects, we are talking about mesh, most of the time. IMHO, we need to have a wider talk about what we can do with these objects and how LL can make things simpler for creators and users. Plus, we could talk about the problems that we as creators see in the current ways of doing things. More best practices forums, wikis and KB would help also. Changing the group discussion will also change the nature of how things are discussed and agenda items would be more discussion oriented, rather than the more Q&A type of format we have now.

What I would like to hear more discussion on is what is next for developement? What are the priorities? IMHO, custom attached bones should be of the highest priority as it can bring the most bang for the buck. Right now, avatar creators are spending incredible amounts of time trying to figure out ways to make their avatars more engaging. This usually results in the use of scripting to accomplish this. Attached custom bones can solve almost all these issues, plus add tons of versatility to mesh objects that are not worn. I would not really be for completely custom avatar rigs, as I see this as dividing content more, instead of allowing items to work together. Simply attaching a new bone set will keep older content still viable but give creators everything they need to do just about anything possible. Imagine attaching a custom rigged head with bones to change the face into any facial expressions, or attaching a custom set of bones for fingers.

Just my thoughts!

 

 

[Medhue Simoni]

Just a thought, but, what if LL allowed us to adjust the size of every SL face, individually? So if I make a mesh, and I create separate SL faces for every major section of the mesh, then in SL, I could adjust the size of each SL face individually.

[Maeve Balfour]

I think some sort of centralised, easy to find, and extensive information database/wiki regarding mesh and mesh creation is needed badly.

So many times myself and other mesh creators have seen other residents who are totally perplexed by mesh as a concept, and unfortunately many misconceptions arise as such. These misunderstandings tend to make many residents hesitant to even try using mesh, let alone learn how to create it, which is a pity since we know how wonderful mesh is.

Especially something covering the generic basic concepts of mesh itself and the steps towards creating it - I would presume that most residents don't understand the standard workflows in creating mesh, and are no doubt perplexed by it all. Some kind of overview explaining the basic steps would at least help address this, and allow them to learn the necessary skills without being overwhelmed by information overload. (ie: Mesh creation / UV-mapping / Texturing / Materials / Rigging). With these basic skillsets in place, residents would then be able to get an easier grasp on the specifics required for SL.... and from there gradually expand on their 3D skillsets with more specialised aspects such as texture baking and such.

As an additional aside - Some thorough information on OPTIMISING mesh for SL usage is sorely needed as well. I have seen some wonderful mesh examples inworld, but sadly it is often evident the creators don't understand the NEED for mesh efficiency to help with realtime performance. This tends to happen a lot with AV attachments, where the PE is often totally disregarded (I'm talking in the realms of 100PE to 220PE and higher for individual clothing meshes etc, usually insane triangle counts with full detail for every LOD, which equates to huge render hits). Information on WHY mesh optimisation is important would hopefully help reduce this, at least for residents/merchants who care about the quality of their products.

...

I understand that something like this is already on LL's wishlist, and that resources are stretched. I know that it will definitely be appreciated by many once it is implemented.

Just my 2c worth :matte-motes-smile:

[Drongle McMahon]

I thought about using the vertex groups for faces for applying independent transformations to, but I think it doesn't generally work sensibly. I'm going to add a couple of simple example parameshes that might make the idea clearer. First will be a bevelled box. Now, the groups of vertices you need to move together for that when it's stretched are overlapping for each direction. So that doesn't fit with materials. Struggling to see if I can use bones for them just now (in Blender). I think something like bone moving would provide the most intuitive interface.

[Claudia Dryke]

About knitted clothes:    The clothes should fit perfectly into any sized avatar. (this should already be on the agenda). Just pointed to scare our ghosts. heheh



[Pamela Galli]

---

Maeve Balfour wrote:

I think some sort of centralised,

easy to find

, and extensive information database/wiki regarding mesh and mesh creation is needed badly.

So many times myself and other mesh creators have seen other residents who are totally perplexed by mesh as a concept, and unfortunately many misconceptions arise as such. These misunderstandings tend to make many residents hesitant to even try using mesh, let alone learn how to create it, which is a pity since we know how wonderful mesh is.

Especially something covering the generic basic concepts of mesh itself and the steps towards creating it - I would presume that most residents don't understand the standard workflows in creating mesh, and are no doubt perplexed by it all. Some kind of overview explaining the basic steps would at least help address this, and allow them to learn the necessary skills without being overwhelmed by information overload. (ie: Mesh creation / UV-mapping / Texturing / Materials / Rigging). With these basic skillsets in place, residents would then be able to get an easier grasp on the specifics required for SL.... and from there gradually expand on their 3D skillsets with more specialised aspects such as texture baking and such.

As an additional aside - Some thorough information on OPTIMISING mesh for SL usage is sorely needed as well. I have seen some wonderful mesh examples inworld, but sadly it is often evident the creators don't understand the NEED for mesh efficiency to help with realtime performance. This tends to happen a lot with AV attachments, where the PE is often totally disregarded (I'm talking in the realms of 100PE to 220PE and higher for individual clothing meshes etc, usually insane triangle counts with full detail for every LOD, which equates to huge render hits). Information on WHY mesh optimisation is important would hopefully help reduce this, at least for residents/merchants who care about the quality of their products.

...

I understand that something like this is already on LL's wishlist, and that resources are stretched. I know that it will definitely be appreciated by many once it is implemented.

Just my 2c worth :matte-motes-smile:

---

Agree with the above, esp. wrt the SL Specific information about optimization and uploading, etc. 

For example, I had a chair that went from 5 PE to 9 PE when I added a script, but in this forum I got information that enabled me to get the PE back down to 5. (Still a bit fuzzy on why it worked, tho.)

 

[Drongle McMahon]

Here are some pictures of what a very simple kind of parametric mesh, a bevelled box, could be like. The first shows the shapes it could be, varying the bevel amount, at the top, and stretching, below. You can see that the stretching has to preserve the size of the bevel, which requires overriding the normal stretch behaviour*. The stretchable extent also has to be limited so the bevels don't overlap. In general, parameters will need limits like this. This has three stretch parameters and one for bevel size. It could be parameterised in different ways, for example with a separate bevel extent in each dimension - that would be easier do with the bone-like interface, and could avoid the need for overriding stretch behaviour.

The second picture shows a couple of meshes that could be made this way as they would appear in SL. These are about 2.5m cubed and have LI=1 at this size (although we could expect the extra parameter data overhead to increase download weight slightly). The difference is in the material mapping.

One problem that has to be considered is the effect of a fixed UV map when changing parameters scales different parts differently. For example, with the version on the right, with 6 cube-like materials, the part of the texture on the bevel part of the faces would get squished when the bevel is decreased, and vice-versa, while the central part is unchanged. I don't imagine dynamic UV mapping would be sensible, resource-wise. So creators would have to pay careful attention to this kind of effect. The one on the left, with extra materials for the edges and corners, doesn't have this problem, but it has others. The possibilities for different UV mappings for something even this simple are extremely varied, with different maps being better for different applications. This may be a limiting factor for how generally useful a particular paramesh could be.

*this is the same problem you get with using hollowed box prims to make non-square picture frames. Frames without that problem would be another early candidate for a simple paramesh.

[Drongle McMahon]

So, as a test of principle, here is a set of three frames which are from the same mesh manipulated with two bones and ordinary scaling (there is a third bone that's just there to balance weights and must not mpove). Of course, that maniplulation was in Blender, but this points top the sort of thing possible with parametric meshes. All we need is the import of bones for static mesh (already on the table as an animation mechanism) and a guim interface to move and stretch the bones, plus another scale factor in the edit box. Then a single object can be manipulated into frames with constant frame widths by users with no knowlege of external 3D software. Not only would this sort of thing bring new opportunities to those builders, but it would also lead to savings in asset downloads and storage as we would otherwise be making different meshes for each version needed (here, each aspect ration and frame width combination).

[Drongle McMahon]

More on the bone-mediated para,etric mesh: I guess the increased download costs would be greter than I thought at first because there has to be a complete set of vertex weights even if they are all the same. So, for example. here is a picture of some manipulations of a frame with four bones. All the vertices are weighted to two bones with 0.5 to each. So that one number, 0.5, gets repeated endlessly. Maybe compression would reduce that?

The other thing is that it could be regarded as overkill. This frame reall only needs two parameters, x and y, and maybe a third for frame thickness (although you can do this with normal in-world scaling together with the two parameters). I gave it four bones to make it more symetrical than the three-bone version. Now four bones actually gives you 36 parameters, three each for position, stretch and rotation, or nine for each bone. The result is that the simple frame (top left) can be distorted in many more ways than intended for it's originally intended use.

That is a tiny sample, all except one have one parameter changed only. Imagine all possible combinations.Note that some of these are potentiall useful.... think walls with windows, for example.

So the bone solution is definately overkill. Does that matter? Can the creator of such a paramesh apply constraints to keep it's behaviour within useful ranges. Can those be specified in authoring programs and exported in Collada along with the mesh and skeleton, or would it need a custom constraint interface in the uploader? Should any such constraints be editable after upload?

[Nalates Urriah]

We talked about creating White Papers for mesh creation, a best practices sort of thing. The mesh developement team is best kept busy coding things rather than writing about mesh. One big reason is residents at this point know about using mesh than the developement team. Resies will likely do a better job. And there is the time issue. There are only a couple of 3 Lindens working on doumenation and AFAIK they are not expert mesh builders.

So, for now it is up to the community. Including building documentation in the CMUG would seem a reasonable topic for the group.

[Nalates Urriah]

There is a tendancy for topics best handled by different teams to try and sneek into the CMUG. I don't see that as a problem. It human nature. So, it seems reasonable to have a plan for those topics. Answering we don't discuss that here is not a customer service oriented response. So, while some groups do that, I think it increases pressure and resident blowback.

We have no way to communicate with the Realms or Viewer teams. Without some group to handle those issues there will be a continual pressure to handle them in other groups. Viewer changes were coming up in the last CMUG meeting, basically out numbering agenda items.

Scripting creeps into all content creation discussions. They seem woven together. We have excellent scripting groups. Pulling Kelly, Andrew, or Simon for another meeting seems counter productive. But, the subject is so interelated to content creation I'm not sure how effectively it can be separated.

Since we know thiese thigs are going to come up, some plan for handling them would be a good thing to have. Just knowing where to send which questions would be adiquite. A problem with that is where to send viewer issues. Oskar won't handle SL Viewer issues in the TPV group (open source). There is no other viewer group.

The Realms people are still working in secret. It seems they want no one jiggling their elbows. They may to have severally blunder before they learn... relearn the Viewer 2 lesson. We know there are security issues and possible cost issues related to the new tools. I can understand the Lab wanting to resolve those prior to going public. Plus things in prototyping are seldom discussed by the Lab. A company does not want the competition stealing their ideas. Does LL have any competition?

But, at some point the expert bulders need to provide the Realms nubies some clues.

How all this gets done is probably beyond the scope of CMUG. But, if SL issues are not handled, they may be an ongoing problem for other groups.

So, no Viewer Dev topics in CMUG.

No Realms topics in CMUG.

Limited (?) scripting topics in CMUG.

Your ideas...

[Branquinha Cyberstar]

Able to create tiny pieces would be fantastic, creative shoes, feet, nails would be happy tocreate with the size nails Necessary, if we can create nano sculpt nails, we could create nano nails mesh.

[Voodoo Radek]

---

Pamela Galli wrote

---

Agree with the above, esp. wrt the SL Specific information about optimization and uploading, etc. 

For example, I had a chair that went from 5 PE to 9 PE when I added a script, but in this forum I got information that enabled me to get the PE back down to 5. (Still a bit fuzzy on why it worked, tho.)

 

---

Sorry for the offtopic, but could i have that info? i cant find it.

 

Ontopic again: if the wiki is clean some day.. would be nice have a direct visible button to take you directly to the wiki. Is very easy to find the marketplace now.. but is not that easy find the wiki. Is good to have buyers, but its even better have a good niche of creators, because when you have good stuff to sell, buyers will come to you. Yeah i know, its a viewer request, so its not on topic ;].

[Charlar Linden]

Nal,

Definitely agree that saying "we don't talk about there here" is not ideal, but having duplication of topics is also problematic; we should try to be as clear as possible as to the range of topics and help people find where they can mostly likely get information. Obviously, having a single 1 hour UG that covers everything related to content creation is impractical, and lining them all up one after another would make for a long day for participants.

I think scripting questions of any complexity really should be redirected to the scripting UG (http://wiki.secondlife.com/wiki/Content_Creation/Scripting_User_Group) or Sim UG (http://wiki.secondlife.com/wiki/Server/Sim/Scripting_User_Group). We can try to answer straightforward ones in the CCUG (content creation user group), but we may not have the right people people present; by 'right people' I am including the scripting greybeards that regularly attend those UGs.

Regarding general viewer items, I'm talking with the team about how to handle that.

As for Realms, we won't have a UG for that project. We are taking what we've learned and will be addressing individual functionality in the the scripting and/or CCUG. Right now the answer will be 'no comment' on most of it because we're not ready -yet- to talk about the prototypes. 

Happy New Year

Charlar