Chodai Yoshikawa

Hi everyone, The current head of the 2.58.1 Blender SVN has some welcome changes which may not have made it into 2.58a * Tapple's fix for the Collada armature exporting (bind shape matrix) is now included, however his mod for changing the bone names is commented out as this is a SL uploader issue, not Blender so sadly this bug remains :: https://jira.secondlife.com/browse/CTS-660 * Export Selected for Collada is turned on and seems to work so far. If you look for builds later than r38079 WITH Collada on http://www.graphicall.org/ you will get this.

Another way is to use a single material and texture. But use differing UV mapping per LOD to the same texture. With low LODs you can shrink and overlay UV faces to use small texture swatches tucked away in corners of your single texture as they appear from the distance to be closer to a single colour. This is not effecient for objects with too many faces as the cost goes up with large amount of UV coordinates to transfer.

Hi all, It seems that PE is here to stay with only small possible tweaks after hitting the main grid. Hopefully Drongle's PE calculation posts will help clean up their estimation and reporting code. For normal builds on a sim it appears single sculpty with scripts wins over single mesh even without script. For more complex builds where texture/UV and LOD benefits come into play then mesh looks better ( although probably at higher PE cost slightly , provided not linked with other prim types). Not much we can do about this now if the Lindens are going to implement PE as it currrently is. One area still up for grabs (as far as I know...who knows what the Lindens are cooking) is the attachment cost of mesh vs prims/sculpties. The metric used here is ARC. The Lindens have stated that the ARC is wrong at the moment when wearing mesh and will be changed after the start of main grid operations. Attachments are lower in sim costs due to physics being turned off, but still suffer the transfer/server costs with each asset compared to prims. Multiple sculpy attachements have a higher transfer cost over prims and may or may not be more than the mesh equivilent depending upon design. Viewer rendering costs however can be made lower with properly designed mesh and LODS over prims and sculpts I feel. The Lindens have the opportunity here to present the *actual* costs of sculpty and prim types in conjunction with mesh in the determination of ARC I think. They can't/don't/won't intoduce these costs to sculpties/prims on normal builds as it will break a lot of things. They can here I feel as the effect is less devastating. I hope that they do the following with ARC: * Accurately represent costs of the prim/sculpt/mesh as attachment in the ARC * LIMIT the ARC able to be worn by an avatar to XXXX (ie attempt to wear anything that raises the number over that fails with message) This will level the playing field for mesh in the field of attachements at least, rewarding those who build well and those users that purchase low load attachments.

HI Madellefste, I assume that the designer of the sculpty took into account the knew LOD behaviour of a sculpty and placed the vertices accordingly to reduce the LOD effect. The mesh you made was decomposed by the uploader software which cannot make such decisions as it has no idea about which areas are of importance and which are not. You could make your own LOD for the mesh and this would work quite well, possibly using even fewer vertices than the sculpty with automatic LOD. As discussed at length elsewhere the cost of the mesh will be 2 PE over the 1 for the sculpt, so this is not as good for simple objects. In short unless you make your own LOD for mesh you are at the mercy of a piece of software that has no idea how to keep important features. Cheers

Also using the Develop-> Render Metadata-> Update Type shows the shapes belonging to these normal ghosts as well. Ahhh finally see what is happening here........ these are ghosts from the next door sim!!!!! Picture below shows the view from MSB#3 looking at Mesh HQ1 .. Notice inthe forground the ghosts in blue and in the background, on MeshHQ1 the real objects. Ghosts in view are mapped from other sims that you can see in normal view. Couldnt find the related JIRA Dongle mentioned but added :: https://jira.secondlife.com/browse/CTS-665

Ah perhaps they are.. I don't rig much ...still learning, but a lot of these things are defaults for 2.49b exporter/rigging so I have to learn when and why they need to be pressed in 2.58 rather than relying on default settings. Other newbies like myself might like a checklist

Hi all, You may see strange shadows that move across your objects cast from nothing that can be found using the show Physics shapes/Normals/Bounding boxes. You may also see many items in the Normals display mode that do not appear in any other way. What are these ghosts? The image is on Mesh#3 sim with two brown rooves that are real and the rest are normals of "ghosts" on the sim. These "normal ghosts" are not interactable...but do get in the way when trying to debug my own meshes. Can they be removed somehow?

I *think* in this case that the red represets parts of the mesh that are too small for physics use. There is a lower limit on Physics shapes (can't find where this was documented) can have before only allowing Convex Hull representation. I can't see from this if the red objects in this mesh are in the same mesh as the rest of the tree or the uploader is just picking on parts which will not be effective in the Havok engine. Unless you intend to climb the tree and sit on the outer branches this physics is too complex and will cost a lot of prims when rezzed. Ideally you should represnt the physics by a series of cylinders to replace the larger trunk/branches and perhaps use some ribbons of mesh if you must have the finer branches climabale/sittable without scripted sits/climbs.

Hi, Things I have found so far with this patch:: 1. You only need Vertex deformations ....turn off Bone Envelopes in the Armature modifier 1. You must apply the modifier before Collada Export as the current exporter only exports the base object 2. Make sure that the object you are rigging is parented to the avatar Armature not the Object otherwise the rigging will not work. 3. You have to make a weight entry for all vertices even if its 0. Otherwise vertices/faces will not show up. Weight your object to the mPelvis completely before you start weighting other joints to get all the vertices lined up for export. There is likely is a better way to do this in blender 2.58 but this is only way I can get anything to export in a resonsble fashion. Still having problems with complex objects being rigged and able to be uploaded to SL. The preview window works and shows the object in its correct position but fails silently to upload. After this happens trying to quit SL fails and it locks up.

Hi Nyx et al, Indeed this is what I am trying to do, use one or two meshes with super low LOD0/LOD1 meshes that appear to show the av wearing something but gracefully snap into 3d as you move closer. Hopefully lowering the cost to the viewer/server in doing so. With shadows being so resource hungry on older hardware any little bit of dropping rendering costs but still allowing users to dress their avvies well is a bonus. Hopefully the scaling of the ARC cost as a metric will happen soon and favour implementers that make effort to reduce prim costs of worn items significantly. Perhaps then ARC can be used as a marketing tool to show up product differences. ie: Use the ARC to push attachement makers to make more efficient and better objects with lower rendering and server costs to benifit all, rather than the prim inflation happening now with such items. On Nano prims I agree their use is limited due to cost and rightly so. Jewelers kits of single prims will have to be replaced with out world tools such as blender with python scripts to create the mesh using simple mesh primitives. The tool then combines the objects into single mesh for import to SL. LOD generation and optimisation is an issue here and unless the scripts are very, very good the user will have to put in effort to make LOD0/LOD1/LOD2 look good and use very little vertexes and re-use UVmaps/textures to lower cost. Cho

Hi all, Good news indeed. Better news is that they have assigned a GSOC student to look at the COLLADA export issues raised by many in regard to armatures (NODE-JOINT in COLLADA speak). If anything comes of that is another question :-) On 1.41 vs 1.4 ..the press release from Khronos contains this "July 05, 2006 COLLADA 1.4.1 is an update to the COLLADA 1.4.0 XML Schema namespace. The update fixes issues reported by users without adding new features and is backward compatible with the existing 1.4.0 schema..." So in theory they should be compatible. Normal mesh seems fine so far when exported from Blender2.58. I think the rigging issues come from how blender interprets the armature when converting. The older 2.49b exporter seems to export armatures with NO rotations in the avatar description. ie: Uses translations only to describe the NODES of the skeleton. Blender 2.5x seems to export with rotations as if each node is a vector that has to be pointed in the right direction explicitly. Cho

Hii Rusalka, Yes it is a bit much these days.... I was hoping mesh might bring some sanity to the overuse of tiny prims now on the main grid. With mesh we can control LOD and use very low prim representations, mostly 2D ribbons with texture, for long/mid distance at low overall cost to server/sim/viewer. It appears at the moment that mesh can drop ARC shown in recent viewers significantly compared to the same object built from prims/sculpties. How the Lindens will scale this in the future is uncertain as revealed in the last mesh meeting when it was stated it will not be decided until introduced to the main grid :-(.; Cho.

Hi Marcthur, Yes I see what you mean, you can make them small using transparency on a base to get your minimum size. There was similar cheat I recall with small spheres being the hollow of a sphere with trans outside and a reversed texture mapped onto the inside of the holllow. The image below is of 1mm items against the minimum prim size of 10x10x10mm I'm sure similar things can be made for a variety of shapes. Prim cost is at least 1 to 2 depending on faces and LOD settings. How well the transparency works against other trans textures is still uncertain. It is possible... could easily get smaller. What is the minimum size used now with normals prims/sculpties? Cho.

Hi Marcthur, et al, I am making jewelery using mesh and the results so far are promising. You can get quite small mesh objects. The picture below is a string of about 80 x 8mm pearls (10x10x10mm cube for scale). The LOD3 mesh is about 7200 vertices. With appropriate LOD2 and very simple LOD1/0/Phys I managed to get the prim cost down to 1 when worn using 233252 build. (Although streaming cost still said 3.6??) [[ when rezzed on the ground cost is 4.0]] The ARC for this when worn is only about 20 compared to much higher numbers 100's when using sphere prims to make the equivilent object. Depending on what the Lindens do to ARC estimation with mesh this looks like reducing the viewer loads for some of the very complex attachments being worn these days. Hair is next . :-) Cho.

Hi all, Just discovered this after many hours of frustration. If you have been editing mesh in Blender , moving vertices, creating new ones and making faces with them you may observe in the edit mode that the Face normals can get wonky. To clear this when you have finished editing the mesh before you export, in OBJ mode CTRL-A and apply LOC/ROT/SCALE to the mesh to make the face normals actually be at right angles to your faces. (In EDIT mode -"N" to get the Properties and then Mesh Display -> Normals ->Face) This can cause problems when uploading mesh if not corrected. Some random things happen...for example a low poly L0/Phys mesh was uploaded and rezzed by itself fine. If it was uploaded as the L2/L1/L0 or Phys mesh of a more complex L3 model it showed up in the preview and world as lopsided and tilted. This may may have been because all the Face normals were biased toward one side. Why it uploaded fine by itself is a mystery. I hope you find this useful ^_^