Mesh Usergroup Information

[Bristle Chesnokov]

i tried too.

 

it gave me a violation;

 

Permission Violation

It seems that you have tried to perform an operation which you are not permitted to perform.

If you think this message is wrong, please contact your JIRA administrators.

[Medhue Simoni]

same here.

[Drongle McMahon]

Sorry Gaia an Medhue. It is stuck with the old default retricted visibility settings for the closed beta. I thought I had changed all mine, but must have missed this one. Since they closed the CTS category, I can no longer edit it. I'll put the text here. This was written a long time ago, when everything was different with the uploads. So I'm not sure how much it is still relevant. I guess the ability to invoke physics engine primitives, which are the most efficient for the engine, would be good at least. There are a load of dae files with it. Not sure what to do with those. If you think they would be useful, I could send them to you (assuming I can find them).

---------------------------------------------------------------------------------------------

CTS-176 text

---------------------------------------------------------------------------------------------

We expect that the preferred physics representation for a mesh object in SL will be simple shapes, with the more expensive calculated convex hull or horribly expensive mesh as less desirable options. So far we are led to expect to have to add these separately in SL after upload of the mesh visual geometry.

Collada includes comprehensive facilities for specifying the physics bahaviour of objects, including their shapes, inertia and interaction properties. For the present purpose, we are concerned only with the shape, and thus with only a small subset of relevant tags and attributes. Other (legal) tags and attributes can be ignored (for the time being).

There is quite good correspondence between the physics shape defining provisions in Collada and the proposed scheme in SL. This proposal requests the implementation of upload of the phyics representation in a Collada file. This will allow much simpler maintennance by the content creator. For some authoring tools it will simplify matching the physical representation to the mesh.

As the existing upload dialog allows a separate file for low-LOD and physics representations, for this proposal, the physics is represented in a separate Collada file with a place-holder for the associated mesh. It would be preferred to simply include the physics in the Collada file spcifying the high LOD mesh, as this removes the need for the placeholder mechanism (examples of Collada files are priovided for both alternatioves). It might also be possible to include all LOD meshes in the same file, but this will be discussed in a separate proposal.

There is much less than perfect corellation between the Collada/SL physics representation and the facilities available in Blender coupled with the default Collada exporter. In parrticular, Blender+exporter do not **Only uploaded images may be used in postings**s://jira.secondlife.com/images/icons/emoticons/help_16.gif" border="0" alt="" width="16" height="16" align="absmiddle" /> provide for the association of multiple physics shapes with a single visual mesh, and transformations and dimensions of the physics shapes are attached to their visual rather than phyics definitions. While Collada extension (<extra> tags) could be used to circumvent these differences, an approach independent of authoring tool and avoiding extensions is preferred. An accompanying document will discuss methods for making the appropriate files using Blender and it's exporter (BlenderHowTo.rtf).

Since neither Collada nor SL physics primitives can be stretched unequally along different axes of the bounding box (e.g. the sphere has only one radius; the box cannot be skewed), the effects of anisotropic stretching of a model with linked physics representation is not yet defined. It is likely, and will be assumed here, that it will be necessary to restrict stretching of such models to be isotropic (as for whole linksets presently).

Summary of proposal: separate files for visual and physics

1. Each object to have a physics representation in SL is represented as <node> in the <visual_scene>. The details are ignored so that it may be an empty object. It must have the same id as the object in the collada file defining its visual appearance.

2. The physics representation of each visual object is defined in an <instance_rigid_body> tag in a single <instance_physics_model> in a single <physics_scene> tag. The target attribute of the <instance_rigid_body> must contain the id of the corresponding visual <node>. The body parameter must contain the id of a <rigid_body> defining the physics representation as below.

3. There must be one <physics_model> containing the <rigid_body> tag(s) for each object that has a physical representation. Each <rigid_body> must contain one or more <shape> tags defining the physics representation.

4. These <shape> tags must contain one of the valid shape tags (5), and may contain one or more <translate> and <rotate> tags that locate the shapes in the scene to place in in correct correspondence to the visual object. All other tags will be ignored.

5. Valid <shape> contents (one in each shape) are <box>, <sphere>, <cylinder>, <capsule> or <instance_geometry>. Each of the first four must have the sub tags required to define it's size (box:half_extents; sphere: radius; cylinder/capsule:radius & height). An <instance_geometry> tag must have a url attribute that refers to a <geometry> tag in the same file which contains a <convex_mesh> tage with a convex_hull_of attribute specifying a fully specified <geometry> in the same file. SL will calculate the convex hull.
{ <shape><instance_geometry url="#geom1"....} ---> { <geometry id="geom1"><convex_mesh convex_hull_of="#geom2" ....} ----> { <geometry id="geom2" .... }

Summary of proposal: visual and physics in same file

6. The need for placeholder nodes in the visual scene and the need to ensure these have the same id as in the file specifying visual properties are non-standard and error-prone. They would be removed if the physical representation was included in the same file as the hi-LOD visual representation. Other parts of the current prposal would be unaltered.

Attached files

BlenderHowTo.rtf - possible workflows in Blender to produce Collada files with physics in
GeneralIdea.rtf - simple layout for relevant parts of collada file

Example files.

These files have been produced using the Blender workflow. The ones containing visible objects have been tested by uploading (automatic LOD only - terrible, but it doesn't matter here). There is no way of testing the accuracy of the physical representations as the mechanism for importing them does not yet exist (and may never exist). The original exported files have both the visual components and physical representation components present as separate visible objects. The prcocessed files have only the visual objects and/or the physical representations connected to them.

A. Doorway - a simple three piece doorway. The physical shape is made of three boxes, post1, post2 and lintel. This is a very simple case using only one kind of physical primitive. These files have comments showing how they were processed. No materials.

doorframe_test_commented.dae - original exported file with annotation indication pending edits.
doorframe_test_combined.dae - processed file containing both visual and physical representations.
doorframe_test_visonly.dae - processed file, visual representation only.
doorframe_test_physonly - processed file, physics only, placeholder for visual object.

B. Gazebo - a more complex model. It contains two visual object (to illustrate the requirements of mltiple objects) and has all four types of physical representation objects. Several materials. No comments.

gazebo_test.dae - original exported file
gazebo_test_combined.dae - processed file containing both visual and physical representations.
gazebo_test_visonly.dae - processed file, visual representation only.
gazebo_test_physonly - processed file, physics only, placeholders for visual objects.

 

[Drongle McMahon]

Here is BlenderHowTo.rtf and GeneralIdea.rtf

--------------------------------

BlenderHowTo.rtf

--------------------------------

Physics primitives Blender - SL

This document is an addendum to a proposal for specifying the physical representation of physics/collision shapes in a Collada file. It outlines one way of obtaining suitable files using Blender features and editing the exported Collada file. It should be read only after reading the proposal to which it refers.

Blender provides the facility to set the 'collision bounds type' of an object using the Bounds button the Logic button panel (F4). The available types that correspond to proposed SL physical prim types are Box, Cylinder, Sphere and Convex Hull (no capsule).  Below that is an Add Parameter button that may be used to insert addtional data of various types. The exporter will include this information in the physical_scene related parts of the exported Collada file (provided the Disable Physics button is not checked).

There are important differences between the way the data is exported from Blender and the way the proposal suggests it should be presented to the SL importer. One of the purposes of this document is to indicate these and suggest means to reconcile them. The second purpose is to provide contraints that need to be observed in Blender for that to work effectively.

There are four ways that this reconciling might be achieved....

1. Manual editing of the exported Collada file. This has been done for two cases to provide examples. It is tedious abnd error prone and therefore unsuitable for serious work should the physics representation import mechanism be provided.

2. Automatic processing of exported Collada file. This would be the simplest practical solution, and not too difficult.

3. An SL-specific Collada exporter. The ideal solution. Could be combined with capsules and other assiting automations. Requires high level of Blender and Python skills. (Domino, where are you?).

4. A converter built in to the SL importer. A bad idea. This should not have modelling-tool specific code if it can be avoided.

The basic Blender process suggested is to construct the desired visual objects and then to add to the scene additional objects that represent their physics representations, stricly constrained editing to superimpose them to achieve the desired effect. These objects are conveniently placed on a different layer so that superimposition can be toggled. There are severe constraints on what can be done that must be followed to ensure compatability with the SL physics primitives and to enable the necessary conversion of the exported file, depending on the object collision type....

1. Box.
    Must be inserted as the default unit cube mesh.
    May be edited ONLY at the Object level.
    Can be rotated and translated.
    Can be stretched (scaled) ONLY along its natural axes. No skewing.

2. Cylinder.
    Must be inserted as the default unit cylinder mesh.
    May be edited ONLY at the Object level.
    Can be rotated and translated.
    Can be stretched ONLY in ways that maintain circular cross section.

3. Sphere.
    Must be inserted as the defualt uvsphere or icosphere.
    May be edited ONLY at the Object level.
    Can be translated; rotation is futile.
    Can be stretched ONLY equally on all axes so that it remains spherical.

The restrictions on stretching are to maintain compatability with SL physics primitives. Collada allows more variation including cylinders with elliptical cross section and tapered cylinders, but these should not be used. The prohibition of Edit level changes is to isolate the transformation information to a predictable location in the exported Collada file (a custom exporter or script could probably relax this constraint).

4. Convex Hull.
    Any mesh, including the visual object meshes, can be used. The Collada file only tells the reader to calculate the convex hull. (If you want to see the convex hull before uploading it, and use that, you can find a convex hull function at blender.org). The editing restriction here is the opposite of that with the primitives. Collada allows rotation and translation but not scaling of the mesh in the physics part of the file. Therefore it is necessary to keep the Object scaling (Transform Properties floater) to 1,1,1. If you do stretch at the Object level, changing this, the you should reset it and apply the scling in Edit mode instead.

5. All
    Use Add Parameter button to add a parameter: Type=string; Name=sl_node; Value=name of represented visual object.
Why?
    The Blender collision properties belong only to the visual objects we made to superimpose them on the physical objects. We don't want those visible objects. Instead we want the (possible multiple) physical representations to be associated with our separate visble objects. However, both visual and physical properties of both kinds of objects are exported to the Collada file. The exported Collada file associates (through the <instance_rigid_body> target attribute) with a node (object) in the visual scene.

We will have to remove the visual rpresentations of the objects intended to become SL physical prims and replace the physical representations of our visible objects (the mesh itself by default) with those of the objects made to nrepresent the physical shapes. In case there are more than one visual object in the file, this requires that each physical rpresentation object be tagged to indicate which visual object it is to be associated with.

This can be done using the Add Parameter button to insert a string parameter named 'sl_node' and containing the name of the target object. This then appears as an <extra> tag in the exported file which can be matched with ID of the objects <node> tag in the Collada file, which is also derived from the Blender object name. The <extra> tags do not appear in the processed file for upload, maintaining the objective of avoiding non-standard features. (The example files were made without this aid, but it would be required for automated conversion. It also serves to identify to a scrip which objects are supposed to be only parts of the physical representation).

Unfortunately, the exporter places all the transformation information in the <node> representing the visual objects that we will remove. There are therefore two main steps in conversion of the file. First, the <shape>...</shape> of the <rigid_body> definitions of the genuine visible objects are replaced with the <shape>...<shape> of all the associated physical representation objects, one after the other. Secondly, the transformations from the <nodes> of the physical representation objects are used either directly or in the dimension contents of these moved <shape> tags. The exact way of doing this depends on the collision type...

1. All: insert <translate> and <rotate> tags at the end of the corresponsing <shape> tag (i.e. before </shape>).

2. Box: replace the contents of <half_extents> tag with the contents of the node's <scale> tag.

3. Sphere: replace the content of <radius> with the one of the three (identical) numbers in the node's <scale>.

4. Cylinder: replace the contents of the <radius> tag with the first two (x,y, identical) numbers in the node's <scale>. Replace the content of the <height> tag with the third number (z) from the node's <scale>.

(No scale-like parameters for the convex mesh. That's why you can't scale it at the Object level.)

The remainder is cleaning up by removing redundant parts. The <geometry>, <node>, <rigid_body> and <instance_rigid_body> for the physical representation objects must be reomoved, EXCEPT that the <geometry> of the convex hull objects MUST be left there - they are referenced by the <shape>! I also removed the whole <library_physical_materials> section and references to it, although it's not impossible that that may be used in he future.

Example files.

These files have been produced to illustrate the processes escribed here. The ones containing visible objects have been tested by uploading (automatic LOD only - terrible, but it doesn't matter here). There is no way of testing the accuracy of the physical representations as the mechanism for importing them does not yet exist (and may never exist). The original exported files have the physical representations present as visible objects. They only have the high-LOD visible stuff.

A. Doorway - a simple three piece doorway. The physical shape is made of three boxes, post1, post2 and lintel. This is a very simple case using only one kind of physical primitive. These files have comments showing how they were processed. No materials.

doorframe_test_commented.dae - original exported file with annotation indication pending edits.
doorframe_test_combined.dae - processed file containing both visual and physical representations.
doorframe_test_visonly.dae - processed file, visual representation only.
doorframe_test_physonly - processed file, physics only, placeholder for visual object.

B. Gazebo - a more complex model. It contains two visual object (to illustrate the requirements of mltiple objects) and has all four types of physical representation objects. Several materials. No comments.

gazebo_test.dae - original exported file
gazebo_test_combined.dae - processed file containing both visual and physical representations.
gazebo_test_visonly.dae - processed file, visual representation only.
gazebo_test_physonly - processed file, physics only, placeholders for visual objects.

--------------------------------

Generalidea.rtf

--------------------------------

....
<library_geometries>

    <geometry id="amesh">
        <mesh>
            .................
        </mesh>
    </geometry>

    <geometry id="aconvexmesh">
        <convex_mesh convex_hull_of="#amesh"/>
    </geometry>

<library_visual_scenes>
    <visual_scene id="vscene">
        <node id="object1"/>
        <node id="object2"/>
    </visual_scene>
</library_visual_scenes>

<library_physics_models>
    <physics_model id="aphysicsmodel">
        <rigid_body sid="rigidbody1">
            <technique_common>
                <shape>
                    <box>
                        <half_extents> 1.00000 2.00000 1.00000 </half_extents>
                    </box>
                    <translate> 0.60000 0.10000 2.80000 </translate>
                    <rotate> 0 1 0 90.00000 </rotate>
                    <rotate> 0 0 1 30.00000 </rotate>
                </shape>
                <shape>
                    <sphere>
                        <radius> 2.50000 </radius>
                    </sphere>
                    <translate> 0.60000 0.10000 2.00000 </translate>
                </shape>
            </technique_common>
        </rigid_body>
        <rigid_body sid="rigidbody2">
            <technique_common>
                <shape>
                  .........
                </shape>
            </technique_common>
        </rigid_body>
    </physics_model>
</library_physics_model>
<library_physics_scenes>
    <physics_scene id="pscene">
        <instance_physics_model url="#aphysicsmodel">
            <instance_rigid_body body="rigidbody1" target="#object1"/>
            <instance_rigid_body body="rigidbody2" target="#object2"/>
        </instance_physics_model>
    </physics_scene>
</library_physics_scenes>
<scene>
    <instance_physics_scene url="#pscene"/>
    <instance_visual_scene  url="#vscene"/>
</scene>       

[Charlar Linden]

I'm going to move it to VWR, I just needed to check and make sure there weren't any sekrits (like proprietary .dae models, etc.).

 

Charlar

[Drongle McMahon]

One Sekrit now removed (as detailed in email). The models are out-of-date with respect to present day weight optimisation. I am happy for anything else there that might be useful to be made public.

Perhaps the most important issue is not the inclusion of the physics in the collada file, but the ability to use that mechanism to use havok primitives. Davido posted a link here that confirms the substantial benefit of using these as far as performance goes. This is reflected in the physics weight calculation in the wiki. I am pretty sure that when suitably undistorted invisible prim boxes, cylinders and spheres are used as the physics shape by linking and setting the mesh physics shape type to None, the server recognises them, uses the primitives and reduces the physics weight accordingly. The weight of a perfect sphere is especially very much lower than that of it's convex hull. However, a couple of experiments suggest that these shapes are not recognised when they are used as part of the physics shape uploaded with a model. That loses a very good opportunity for performance and physics weight optimisations. Directly specifying these primitives in the collada file would reopen that opportunity. It could also make available the very havok-efficient capsule physics primitive, which is not available as a standard linked prim.

[Charlar Linden]

Meeting is Noon SLT, for location and to add agenda items, go here: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import_User_Group

 

See ya

Charlar

[Charlar Linden]

Meeting Notes: https://wiki.secondlife.com/wiki/Mesh/Archive/2012-02-13

Thanks everyone who attended and took part in the conversations.

 

Usergroup page: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import_User_Group

For next weeks meeting, please add agenda items before meeting if possible.

 

Cheers, Charlar

[Toysoldier Thor]

So being new to this MESH forum.... tonight I was reading this thread and weekly usergroup meetings.between LL staff and the community.  I actually read thru today's released minutes from todays meeting at noon.

A couple observations came to mind as I was reading this:

 

1. What a shockingly different interaction than what all the SL Merchants (which I am) have to endure when trying to get ANYTHING from the LL Commerce Team.  I have been heavily involved in the SL Commerce Forums for over three years and except for a few rare moments in the history of the LL Merchant / Commerce teams that have come and gone, we get nothing close to the interaction that this portion of the LL staff provide the MESH Community.  Nice to see - sad that the LL Commerce Team doesnt have the same respect for their respective community that I see here.
2. When reading through the transcripts, read several wishes expressed from the mesh attendees on changes and improvements for LL to consider implementing.  And although no promises, I read the Lindens like Nyx and Charlar say "if a JIRA was created - its the only way to make the wish for a new feature be considered for development".
   
   That is great but what frustrated me as I was reading this was how LL Staff are actually considering all these new features, and yet there are JIRA's of actual proven Grid bugs that are over 4 years old (like the one I have been wanting LL to finally fix SH-2947 ) that just seem to sit and rot in LL's Jira system because LL doesnt want to work on bugs.. 
   
   So LL developers are hoping new Jira's get generated so they can be scheduled and worked on... but old existing bugs get ignored.
   
   So my question to Nyx Linden.... how can a JIRA like the one I pointed out sit in your queues for over 4 years to be worked on but your teams seems to have enough resources to work on countless new enhancements?  I really would like to know the logic to this?

Anyway.... generally, nice to see that Lindens actually talk to their respective community here.  Can you show the LL Commerce Team how you do this?

[Charlar Linden]

No User Group meetings tomorrow. It's a national holiday in the US and our offices are closed.

 

Charlar

[Charlar Linden]

Usergroup notes: https://wiki.secondlife.com/wiki/Mesh/Archive/2012-02-27

 

Meeting information for next week: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import_User_Group

 

thanks everyone for taking part

 

Charlar

[Pamela Galli]

Is there any chance at all of reducing the mesh script penalty?  It really puts mesh at a disadvantage compared to, say, sculpts -- and in fact this is one of the reasons I heard for not adopting mesh in the thread I started in GD: sculpts are just as low prim, if not lower.  No one realizes that a mesh item can be very low prim -- until a script is added. This penalty seems the sort of thing one would want to do to discourage, not encourage, adoption.

[Toysoldier Thor]

---

Pamela Galli wrote:

Is there any chance at all of reducing the mesh script penalty?  It really puts mesh at a disadvantage compared to, say, sculpts -- and in fact this is one of the reasons I heard for not adopting mesh in the thread I started in GD: sculpts are just as low prim, if not lower.  No one realizes that a mesh item can be very low prim -- until a script is added. This penalty seems the sort of thing one would want to do to discourage, not encourage, adoption.

I fully back your statement Pamela....  It is one of several reasons why I am not making MESH terrains and sticking with Sculpties.  Try to make an water texture flowing large sim waterfall for 1 prim when you add an animation script to boot.

Mesh LI is already penalized over all other prims.... then it gets a major additional kick that no other prims has to deal with when you drop a script in a mesh.  Same script in any prim.... NO PENALTY.

Ohh well... the mesh penalty has been set by LL and creators and merchant make decisions if they use and sell mesh based on it.

But it sure would be nice if LL compromised when it comes to mesh and gives it a fighting chance against prims/sculpties.  I might even consider experimenting with a mesh landscape pack if that were the case.

[Pamela Galli]

Well even without a script, there is a significant size penalty as well. I just don't understand why, if LL wants to encourage mesh adoption. Everyone knows you get more of whatever you subsidize and less of whatever you tax.

[Toysoldier Thor]

again I agree with you.  Even though I have made a few very low poly count natural shaped analog shaped mesh, as soon as i size the mesh to 15 or 20 meters the LI starts to fly up.

The problem is that the LL Mesh Team is as technical PURIST in solving all the inworld's Lag woes onto the backs of only one type of object in SL... the MESH.  They are not will to compromise in order to try to further encourage the use of mesh over prims and sculpties which they keep harping to everyone is a lag fest.  Well if the prims and sculpties are so laggy and undesirable... then its absolutely poor strategy to only place heavy penalties on the one shape they want to encourage.

I am in no rush to overhaul my suclpty products with mesh versions.

But this is a fundamental problem with LL staff and management... their culture is not business its a culture of techies and so to them the purity of making sure MESH will not make the same technical mistakes of sculpties and prims is the #1 priority - even if it means a much slower adoption of mesh while the laggy but much lower LI rez costs of script loaded mega prims continue to thrive.

Ohh well, at least it gives me more time to learn mesh to make art statues and small items.  Its fun to make Mesh art - its a fun thing to play with in SL until LL someday levels the playing field.

[Kwakkelde Kwak]

---

Toysoldier Thor wrote:

Try to make an water texture flowing large sim waterfall for 1 prim when you add an animation script to boot.

---

Can you give an actual example, something we can see, where adding a script to a large object will increase the LI? I honestly have a very hard time believing it will be the server weight which goes from 0.5 to 1.0 that will make the LI go over 1.0.

I have seen several objects that have a relatively high LI because of the server weight, some because they were simply built the wrong way, some because the object needed subobjects (child objects) for scripting purposes. Those were all linksets with very small and simple objects. In a big object it will be either the download weight or the physics weight determining the LI.

Or am I missing something obvious?

[Toysoldier Thor]

When I get a chance to create an example I surely will.  I have been heads down working on a MESH Artwork submission for the UWA monthly challenge that has a deadline of this Thursday and I still have about 10 more models to create for my submission.

You are a lot smarter in mesh that I so maybe there is a trick on how to apply a script to a mesh with little penalty.  A couple quick things I tried with poor results was linking a mesh with a sculpty - Eeek - the LI flew up (I want to place one of my mesh statues on one of my Sculpty Rocks and link them but it was better to just keep them non-linked).  I havent tried linking an alpha prim to a mesh object and see if the LI is different than if I just put the script in the mesh.

So far the biggest impact on Mesh LI penalties is scale of the object.  LI does not go up linearly with size - it seems to go up exponential.  But right now I have only done some minor experiments and not sat on the Beta grid for an hour trying different scenarios out.

Maybe next week.

 

[Medhue Simoni]

---

Pamela Galli wrote:

Is there any chance at all of reducing the mesh script penalty?  It really puts mesh at a disadvantage compared to, say, sculpts -- and in fact this is one of the reasons I heard for not adopting mesh in the thread I started in GD: sculpts are just as low prim, if not lower.  No one realizes that a mesh item can be very low prim -- until a script is added. This penalty seems the sort of thing one would want to do to discourage, not encourage, adoption.

---

Well, I doubt they are gonna change things at this point. If you still think the script penalty is too much, I would suggest starting a thread to see just how many creators feel the same. Considering that I started the first thread complaining about script penalties, I agree with you, but have accepted dealing with it. The penalties are much more reasonable from what we had when I first complained.

[Pamela Galli]

Okay.

[CashMoneyMan]

Meeting notes seem to be missing from 2012-03-05

[Toysoldier Thor]

Who is taking over for Charlar on these Usergroup meetings and Mesh?

[Drongle McMahon]

The user group wiki page has been updated and now identifies Nyx and Runitai as the core team, with occasional contributions from other Lindens.

[Ashasekayi Ra]

Since the Content Creation User Group page is still active and updated, does that mean LL will continue to have this user group? At the last meeting, there was a sign that stated the group would by closed.

[CashMoneyMan]

Logs from last two weeks are missing.

[Mikki Miles]

Nyx knows, he promised to load them up...