How to avoid LOD mixups in multi part mesh uploads ?

[Gaia Clary]

Hi. I have an object here which is made of 4 parts:

• Braceteat (at the top) (using 3 materials)
• Handle(dark redish polished wood) (using 2 materials)
• The guard (using 2 materials)
• The Blade (using 1 material)

I made it of 4 parts because i want to provide a few different blades, some different guards, handles, and top decorations for creating many different looks which can be combined in world.

The good news is: Its PE is 4 when linked to a linkset. So it is equal in costs compared to a sculpted prim object (made of 4 sculpties)

Each of the 4 parts has got 4 different LOD meshes (high to low going from left to right:

Now i want to upload this sword in one chunk (uploading the 4 parts one by one costs about 650 L$).

But when i try to do that, I face one big problem with the associations of the LOD-meshes to the high LOD mesh:

Look how the 4 LODS are shown in the previewer:

You can see that the braceteat (the coin at the top of the handle) and the guard get exchanged on LOD2 and remain exchanged. Furthermore the handle on LOD2 and LOD0 looks like a cylinder, while it should be more like a coil (as seen in LOD3 and LOD1). the only part which looks right to me is the blade.

How can the wrong association of the submeshes to their LOD be explained ?
How can that be avoided ?
How can the distortion of the handle be explained ?

To be clear: I have uploaded all 4 parts of the sword one by one and the LOD behaviour for all 4 parts is correct and no distortions can be seen apart from what is expected due to LOD.

[Nix Manx]

Do the swords LODs ingame also relate to the LODs in the previewer? Looks like a bug to me. LOD 2 looks worse than LOD 0

[Gaia Clary]

yes, the previewer shows what i actually get when i upload the sword in one chunk. So the problem may be located in the DAE. I want to check if i made a mistake before i add a jira for it. What i do during exporting was:

for each LOD i selected the 4 parts in the exact same order (starting from top to bottom),

then exported the selection as Collada-1.4 (i used Blender 2.49b for that)

 

[Drongle McMahon]

As a complete guess, I would look at the order of the <geometry> sections for each part and the order they appear in the <node>s in the <visual_scene> in the Collada file. If it's like the materials in a single objects, it is the order that determines which goes with which (for materials it's the order of <triangles> or <polys> sections inside the <geometry>).  If they are not already, edit the file so that it goes top->handle->guard->blade in both places and see if that makes a difference. I would also make sure the parts have the same object names, although if it is like materials that won't matter. How you can make Blender put them in the right order, I don't know. For the materials it's the order of material indexes, but I don't see an equivalent for objects. Maybe moving them around in the outline view? (Of course the importer should be able to do it by object name.)

[Gaia Clary]

Drongle, i think you have put me on the right track ;-) I remember that i originally had 5 objects. Later i joined 2 of them into one single object. And it appears to me that this may explain very well, what causes the problem...

I will take a look at the dae files now.

thanks for the hint !!!

[Drongle McMahon]

You provoked me into a few tests. It is the order of the <geometry> sections. The order of the <node> sections doesn't affect it. So then I tried to see how that order was controlled in Blender. I couldn't solve that. The outliner view is alphabetical and you can't move stuff, and it doesn't control the order anyway. The only thing I found is that the last selected object will get put first, but after than I could not control the order. I tried alphabetical, order of selection, position and creation order, but none of those changed the order of the other objects. Aarrgghh!

Meahwhile, you drew my attention to the upload fee - so I uploaded 64 spheres for L$221, when they cost L$151 each on their own, and that's even if they are all different. The data requirements must be exactly the same whether I upload them all and unlink them or upload them individually, but they are going to charge me L$221 for the first and L$9664 for the second, 43 times as much! That is completely ridiculous.

[TANAKAAKIO Inshan]

Drongle McMahon,  you are quite right.

I think fixed cost(fee) 150L$ is too high, meanwhile variable cost is too low for each upload.

I experimented.
  1) Uploaded a simple cube having only 4 faces in Blender. It is 151L$.
  2) Uploaded avatar's meshes consisting of three parts having 7186 faces in Blender in one chunk. It is 164L$.
  3) Uploaded the same avatar's meshes separately. It is 462L$( head:153L$, upper_body:156L$ and lower_body:153L$).

There is a lack of balance.
I think upload fees should be reviewed.

It seems that uploads in one chunk often brew up unexpected results, so is not recommended for mesh geometries at present.

However, if uploaded individually, fees come at a price and we must assemble  complex meshes by hand painstakingly in world.

[arton Rotaru]

I have the same problem but only for the multi physics shapes file. It works if I have not to many objects in the scene. Lod's work ok for me, as long as the viewer doesn't crash when loading a scene. :matte-motes-mad:

[Gaia Clary]

---

TANAKAAKIO Inshan wrote:

There is a lack of balance.

I think upload fees should be reviewed.

 

It seems that uploads in one chunk often brew up unexpected results, so is not recommended for mesh geometries at present.

 

However, if uploaded individually, fees come at a price and we must assemble  complex meshes by hand painstakingly in world.

---

The related Jira to exactly this question has been closed. Mabe we should reopen a new jira for that ? I am not sure if comments on closed jiras are read at all by LL ...

[Gaia Clary]

---

Drongle McMahon wrote:

So then I tried to see how that order was controlled in Blender. I couldn't solve that.

---

That means that we need some sort of convention to order the objects included in an upload ? Would it be feasible to simply use the object names to sort them in alphabetical order for example ? Maybe a name convention could be used like this:

 

 

• braceteat_lod3
• braceteat_lod2
• braceteat_lod1
• braceteat_lod0
• braceteat_phys
• ...
• blade_lod1
• blade_lod0
• blade_phys

This convention would allow me to keep my different LOD versions in one file. And this name convention won't break the alphabetical order in the 4 lod files:

So in the high LOD file i have the objects:

 

 

• blade_lod3
• braceteat_lod3
• guard_lod3
• handle_lod3

and for the medium LOD file i have:

 

 

• blade_lod2
• braceteat_lod2
• guard_lod2
• handle_lod2

and in the physics file i would have:

 

• blade_phys
• braceteat_phys
• guard_phys
• handle_phys

This means that we have to take care that the name conventions are kept intact in our own editor (which would make sense anyways).

If Linden Labs can not solve (or does not want to solve) this problem, then i can imagine that we are able to provide a simple tool which could be based on such a name convention. This tool could reorder the Collada file so that the importer now imports correcly. Does that make sense ? If LL states they will not provide a solution for a multi part import other than what they have now, then i would immediately start working on such a tool and i guess i would try to make it tool independent, maybe even web based ;-)

---

Drongle McMahon wrote:

Meahwhile, you drew my attention to the upload fee - so I uploaded 64 spheres for L$221, when they cost L$151 each on their own, and that's even if they are all different. The data requirements must be exactly the same whether I upload them all and unlink them or upload them individually, but they are going to charge me L$221 for the first and L$9664 for the second, 43 times as much! That is completely ridiculous.

---

Maybe we should realy keep on creating jiras, especially when looking at the close statement of CTS-691:

 

Charlar Linden added a comment - 12/Jul/11 11:34 AM

Other upload methods (texture/image/sculptie map) do not take into account overhead associated with the file. The more complex the file, the more it costs.

Please note: We're still tweaking these calcs prior to mesh release and welcome the feedback.

[Drongle McMahon]

The tool could be even simpler, and could be implemented by editing the exporter script (as we all did already for units etc.). It would just have to override the putting the last-selected <geometry> firs, and then do the rest in alpahbetical order. Then you can still have the LODs in the same file (I always do) and simply select the right sets of objects for export and they would always be in the same order provided they were names in a way something linke what you describe. That bwould make the need for a specific LOD-related naming convention unnecessary

[Zalandria Zaius]

Nameing them with numbers can get weird when you get into double digits. Systems will like to go 1, 11, 12, 13, 2, 3, 4  so watch out for that.

[Gaia Clary]

We would only need the numbers 1,2,3,4 anyways. But like Drongle metioned earlier, the numbers are not realy needed. So however it is done, it will work ;-)

[Gaia Clary]

I now added a bug report ( CTS-694 ) and a feature request ( CTS-695 ) about this issue.

[Drongle McMahon]

I made the following changes in translator.py which seem to work. Result is that <geometry> tags are now in alphabetical order. So using a naming scheme like Gaia's should work. I uploaded a file exported with this, and it looked ok.

Do not try this unless (a) you are happy to play with your Blender scripts (b) you have made a backup copy of translator.py to rescue it if something goes wrong. There are no guarantees with this. It might have damaging side effects. Parhaps a Blender python guru could comment?

WARNING: the is an issue that causes a viewer crash if you change the order of <geometry> sections in a LOD mesh file. The crash happens as soon as you select the file. This may happen (a) when you first use the sorting patch for an existing model you have an slm file for. (b) if you have an slm file made with the sorting patch and you change an object name so that the sort order is changed. The way to avoid the crash is to delete the slm file and/or to set meshImportUseSLM to FALSE in Advanced->Show Debug Settings. The slm file is in the same directory as the collada file, with the same name, but with extension slm instead of dae.

1) at the end of the file add the following lines...

# this function is for Drongle LOD sort patchdef daeGeometryKey(daeGeometry):	return daeGeometry.name

 

2) Somwhere around line 450, there is this ...

		Blender.Window.DrawProgressBar(0.98, 'Saving file to disk...')				self.colladaDocument.SaveDocumentToFile(fileName)

 insert the extra line so this becomes...

		Blender.Window.DrawProgressBar(0.98, 'Saving file to disk...')				self.colladaDocument.geometriesLibrary.items.sort(key = daeGeometryKey) # Drongle LOD sort patch		self.colladaDocument.SaveDocumentToFile(fileName)

Anyone is free to use these alterations. They may be considered to be in the public domain.

The two lines from the original translator.py are copyright: "Copyright © 2006: Illusoft - colladablender@illusoft.com" and contains the following license statement..

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version.

 

[Gaia Clary]

Thank you ;-)))

However this will work only for Blender-.2.4 Since Blender-2.5 uses no longer a python based Collada exporter, it will become more complicated to add a patch ;-(

One more question: It appears to me that this patch sorts all included objects by name. That may make a difference when it comes to controlling which of the objects takes the part of the linkset root in SL ... I still have to test and upload my 4 parts object. i currently do not know which of the parts will become the root of the linkset. I suspect it will be the first object which appears in the file ?

 

[Drongle McMahon]

"Blender-2.5 uses no longer a python based Collada exporter"

OMG. Why not. That's terrible. And stupid. Can you still use the python one? Or has the Blender document model changed too much? What about the units, hiding identity-revealing paths etc? I guess I will certainly keep clear of 2.5. I suppose you could import the 2.5 output into 2.49 and re-export it?

I didn't test the root asssignment. I was not really interested in linksets, just saving upload fees. Your guess is probably right. Since the default seems to be that the last-selected is the first, it should not be too difficult to modify this to leave that one out of the sort. But anyway, you can just unlink the one you want as root, then select the rest follwed by the unlinked one and relink. That would do it, wouldn't it?

Why could you not export your four piece thing?

[Gaia Clary]

---

Drongle McMahon wrote:

"Blender-2.5 uses no longer a python based Collada exporter"

OMG. Why not. That's terrible. And stupid. Can you still use the python one? Or has the Blender document model changed too much? What about the units, hiding identity-revealing paths etc? I guess I will certainly keep clear of 2.5. I suppose you could import the 2.5 output into 2.49 and re-export it?

I didn't test the root asssignment. I was not really interested in linksets, just saving upload fees. Your guess is probably right. Since the default seems to be that the last-selected is the first, it should not be too difficult to modify this to leave that one out of the sort. But anyway, you can just unlink the one you want as root, then select the rest follwed by the unlinked one and relink. That would do it, wouldn't it?

Why could you not export your four piece thing?

---

Yes, this is the typical workflow nowadays (even for sculpted prims ;-)

 

1. Create and model in Blender 2.5
2. save your model in a blend file
3. start blender-2.4
4. try to read the blend file (works in most cases, but always gives a warning message)
5. export as Collada, or export LSL (for multi part sculpties)

If 4.) fails, you always can use File -> Link. And IMHO this is the better way to do because you can not unintentionally break your Blender-2.5 model when you only do a Link from 2.4

I meanwhile started testing.

my very first result is: i could upload my 4 part object once but after doing a small modification in one of the LOD meshes and reexport that LOD only to Collada, a secnd upload failed massively and also crashed the viewer again. However i could later upload with success after i removed the slm file. And this points IMHO to yet another bug in the meshimporter.

I can not verify that the first object in the upload will become the link target. At the moment it appears to me random. But i have not tested in depth.

In general it would be nice to see in the previewer which of the parts will be assigned as root element. I will make a feature request for that ;-)

In Which way do you mean your last question ?

I could export my 4 part piece as a single mesh object with 4 submeshes.

But:

1. I wanted to make a set of swords with varying elements, think of having 4 different blade types, 4 different handles, etc... When i make them as 4 separate objects, i can later combine them as i want.
2. I wanted to compare a sculpty sword made of 4 parts with an equivalent mesh sword. If i had collapsed the 4 sculpty meshes to one mesh mesh ;-) that would have been a very unfair competition, no ? I could easily make this sword with a PE of 2 and sculpties could only compete when i made the sworad out of one sculpty-mesh. Which i did not want to do because of texturing issues and LOD behaviour...

 

[Drongle McMahon]

Sorry. Last question was me misreading your post. I thought you said it didn't work, but you just said you hadn't tested.

I turned slm off after having problems with it. I don't really find it useful.

[Mikki Miles]

mh, my viewer crashes instantly when I select the medium LoD-model, using that modification. (I checked the .py file twice...)

[Gaia Clary]

That happened to me too with LOD0. I solved it by removing the slm file, restarting the viewer and then it worked for me. Also have you ensured that the object names are created such that they will yield the same sort order in all thee files ?

[Mikki Miles]

I'm a bit confused now. "Object Names" means submeshes?

Anyway, removing the slm-file didn't help

 

Edit:

I am only able to upload custom LoDs when I join the submeshes before exporting, the other way messes up everything, at least it feels like ;-)

[Gaia Clary]

• You can either have a bunch of unconnected submeshes in ONE object,
• or you can have a bunch of individual objects, each having 1 or more unconnected meshes.

The LOD mixup happens only when you try to import multiple OBJECTS. That means, once you have uploaded your stuff, then you see that it is indeed a linkset and you can separate the parts in the SL editor and relink them as you like.

The mixup does NOT happen when you upload one OBJECT with many submeshes. In that case you can not break the object into parts within the SL viewer.

 

[Mikki Miles]

that's exactly what I'm struggling with.

Uploading as one object with submeshes works fine, but I'd like to upload objects with more than 8 materials or so...

[Gaia Clary]

For Blender:

 

• When you add more meshes in edit mode, then you create submeshes within the current object. the number of materials can not exceed 8 for this construction.
• When you add more meshes in object mode, you actually create more independent objects, each of them can have up to 8 materials.

When you export to Collada, you go to object mode, then you select all objects which you want to see in the dae file. And later you import that dae file to SL.

Only when you create other LOD files for your work, then you must ensure that the order of the exported objects is exactly the same in all files. Drongle's patch ensures that the order of exporting is dependent of the object name. Previously it was unknown how the export order was determined. Hence i found mixup in the LOD's because every LOD file had different order of objects.