Can't upload in the new viewer

[Kwakkelde Kwak]

Grrr... anyone else having problems uploading with the new viewer?  (Second Life 3.1.0 (243176) Oct 16 2011 12:16:07 (Second Life Release))

I have green checkmarks for everything, including "Ship it", but the "Calculate weights & fee" button is greyed out.

It happens when I set the physical shape to something with different Texture IDs than the model it seems. That never was a problem before.

[Drongle McMahon]

Yes. It seems there are one or more problems with the calculate button getting greyed out. In my case it is a particular mesh in the low LOD slot that does it, although this mesh is ok in different slots and there is no error in triangle/vertex counts. Bizarre. It will take some time to mek a reproducible case for a jira, I think. Worse than that, when you replace the mesh with another that did work, the greyed button doesn't cfome back on.

[Kwakkelde Kwak]

yes, close and reopen is the only way to fix it...it's buggy this new one, to say the least. Filed a jira on the other issue with the LOD changes... very hard to make a sensible jira for that with all the variables.

[Sabanco]

Ok. After a few tests today, I got also the same problems as you have. Also another problem coming up: when I try checking skin weights on the right side (not on the left) SL is always crashing. Ive also tried with a few other models. I does always crash. After that crash Im not able anymore to check skinweights(left side) for a simple box model that i uploaded and wearing since yesterday. oh boy.

[Kwakkelde Kwak]

grrrr...JIRA time! ..so many issues with this latest miracle, I'm back to V3.0 I think....

[Charlar Linden]

Kwakkelde - please let me know when you get the jira in.

 

Charlar

[Kwakkelde Kwak]

Done..

VWR-27217

[Drongle McMahon]

Oh dear. This is much worse than I thought. I have found a whole lot of meshes that used to upload but that suffer from this. I will add a couple to the jira.

[Hatchet Vernon]

Listen up. I have noticed 'bugs' with uploading as well. This isn't a cause to start running around like a chicken with its head cut off. Perhaps there are some more variables to consider that safeguard or refine the process, so maybe you should all try something before you start shouting and waving picket signs at the creators of Second Life.

 

The issue I have had is that my calculate button is grayed out despite green checks across the board.  I tried restarting the upload window without making any changes to my files (all LOD's were loaded from files), and this didn't work. The failure occured after loading LOD1 (second from lowest), which made it clear to me that recent changes I made to LOD3 and LOD2 were responsible. The changes were edge splits to correct the shading on my model.

 

Apparently, I have reduced the problem to one of two things: either the edge splits were changing the recognized properties of the mesh and causing inconsistencies that the uploader doesn't like (for good reason), or the uploader has a problem combining files which were saved at dates or times too far apart (seems unlikely).

 

So here's my two cents:

either -The uploader has tightened its restrictions on differences in meshes between levels of detail

or -The uploader has problems loading files with dissimilar times of creation by a certain margin

 

Check your mesh! Make sure there is the same number of texturable faces (both materials and UV layout sections or "islands" in your 3D program,). If this doesn't work, find out when the uploader fails and determine what changed at that point. Post it here or report what you have discovered to help resolve the problem for everyone.

 

Whatever you do, don't make yoru first action screaming and complaining to the creators of the game. If you treat them like idiots, maybe they'll just take it all down and leave you completely screwed.

[Drongle McMahon]

"either -The uploader has tightened its restrictions on differences in meshes between levels of detail"

If this is the case (which it well might be) then (a) the changes should be communicated before it is introduced breaking previously functional dae files (this was common before mesh came out of beta, but should not happen thereafter). (b) there should be an error message indicating the reason for greying out, as there is for the case with different material numbers. Either way, this is reasonably described as bug (i.e. not "bug").

"or -The uploader has problems loading files with dissimilar times of creation by a certain margin"

I very much doubt that time of creation would be a factor. There is no reason to prevent people making modifications to one LOD of an old mesh. So that would also be a bug. However, the software generating the dae files might change significantly between versions in such a way that the outputs became incompatible. That could give the appearance of a date-related incompatibility. In my own case, the same version was used for all dae files, and the problem happens with recently generated sets.

"Post it here"

The wiki now asks us to do this for upload problems. Fortunately Charlar was looking at this thread, and, as he said, the proper thing is to post an issue in the jira with as much detail and as little emotion as possible, which is what Kwak did when requested.

It certainly does appear that there has been a change in the uploader that has caused these problems. My guess would be that this is a side effect of ceither changes to make it work with Collada 1.4.1, or changes to make it take account of material names/IDs in associatinmg materials with triangle lists at different LODs. That's pure gtuesswork thpough. I don't know even which of these they may be working on.

I would like to know where you got the idea that there had to be equal numbers of UV islands. This was never the case in the past. However, I tested it by making a LOD set with all one island and then splitting into two islands for a couple pof the meshes. As you suggest, this does now cause the greying of the upload button. However, it is not the only cause as (at least one of) the examples I added to the jira (ltst_cyl) has equal UV islands at each LOD.

ETA: Ah. That was just a sidetrack. The number of UV islands doesn't matter. See post below.

I will add the UV island examples to the jira.

Requiring the same number of islands at each LOD would be a very retrograde step. For example, many people are using billboards with as little as one triangle for their lowest LOD, but require many islands for proper texturing at higher LODs. (I just tested a skylight used in my gallery .... sure enough it is now impossible to upload.).

None of the examples I used had edge splits. Not working with edge splits would be even more destructive than requiring equal UV islands.

[Drongle McMahon]

Wrong again Drongle!

More thorough investigation. using the last Mesh Project viewer I have, there is an arror message with what I assume to be most of these problem uploads. It says something like "materials not a subset of higher LOD". Assuming the bug in the present production viewer is the omission of this error message, that sheds some ight.

The way I made one of my test LOD mesh sets meant that I created a new material index in Blender for each mesh. That gives them different names and IDs in the Collada file. These files gave the greying out of the calculate button. When I changed the names and IDs to be identical in each file, the problem disappeared.

Different names and IDs used to be perfectly alright, as the uploader ignored these and instead used the order of the triangle lists in the geometry tag (each material appears as a separate triangle list) to decide which material was which. This led to some problems with people who didn't know that and ended up with wrong textures on the wrong faces at lower LODs.

It would appear the developers have decided to change this. They are clearly now using either the name or the ID to control which texture goes on which face. Given that the error message says "not a subset", it would appear further that they will relax the requirement for the same number of materials for each LOD mesh as long as the lower has a subset of the materials of the higher..

So. my guess is that we will be told the "bug" is expected behaviour. It would be more accurate to say that the bug is the failure to show the error message. Also a change as drastic as this should most certainly have been announced and explained in the blog, or here, or somewhere. For new users of mesh uploads, this is probably a positive step. For myself, and probably others, it has broken hundreds of dae files.

I did try the variation in the number of UV islands again, after editing the names and IDs. It no longer had any effect. So that was a mis-impression given by the fact that the files with different numbers of islands had different material names. It does not matter how many UV islands there are in the different LOD meshes. Thanks be for that small mercy.

 

[Funk Schnook]

I'm having the same problem, although my button is graying out only after I upload the physics shape (I usually just use a box).

My physics shape has only 1 material... I wonder if the new client expects the same materials on the phys shape as the lods? (That would be a bad idea btw)

[Kwakkelde Kwak]

@Funk..yes with me it's also the physcal shape causing issues (and I usually use a box aswell, if not smaller). By the sound of things this isn't the only issue though.

I could try it with Texture IDs set for the box, but that's a lot of work for nothing, it doesn't make sense the physical shape needs texture IDs.

[Kwakkelde Kwak]

I'm not screaming and acting like a chicken, head or no head.... Things I could upload without any problems before I can't upload now. Nothing changed, nothing at all...Oh, besides the viewer I was using....now maybe just maybe that is the thing to suspect then. I could sit in a corner and redo all my models, I have no doubt I could upload every single one of them with enough fiddling and trial and error... That wouldn't solve the problem though, a problem that clearly exsists. I'd say posting it on the forum is the first step then...and when a Linden asks me to write a JIRA....well, then I write a JIRA.

 

btw, there's a difference between sarcasm and screaming...maybe I wasn't clear enough, maybe you missed it..I dunno.

[Drongle McMahon]

"My physics shape has only 1 material... I wonder if the new client expects the same materials on the phys shape as the lods? (That would be a bad idea btw)"

Yes. Very bad. Materials should be completely irrelevant for the physics shape.

[Drongle McMahon]

I tested it. It's true. Having a different material name/ID in the physics shape file causes the button to grey!!! That's really a bit mind-boggling. Now to see if the error message comes up with the project viewer and then another jira comment.

No. In the project viewer* I have, it does not grey out the calculate button and it allows upload with a different material name/ID in the physcs shape mesh file. Hmm.

*Second Life 3.0.6 (242181) Oct  3 2011

[Drongle McMahon]

I looked this up in the source code. There is now a function in llmodel.cpp called LLModel::matchMaterialOrder, which has changed the way lower LOD materials are allocated to face indices.

The old way was simply to allocate the materials from the high (reference) LOD to the lower LOD submesges in the order those appeared in the collada file, taking no notice of the collada's material names or ID attributes. The only restriction was that there had to be the same number of submeshes in the reference and lower LODs. You could actually remove all reference to materials and the system still worked. (Many of my dae files are like that).

Noe, the new funtion compares the material list for each LOD mesh with the reference (high LOD) material list. It is no longer required that the lower LOD meshes have the same number of materials, but all of its materials must have the same name as one of those in the reference list. If they satixfy this condition, buth are not in the same order, the lower LOD list is re-ordered to match the reference order. If not, the return value causes the calculate button to be inactivated, as we have seen.

To quote from the source (copyright LL)...

//Is this a subset?
//LODs cannot currently add new materials, e.g.
//1. ref = a,b,c lod1 = d,e => This is not permitted
//2. ref = a,b,c lod1 = c => This would be permitted

If they are treated the same as object names andIDs, it is the name that takes precedence. (In the Blender 2.49 exporter, name and ID are the same. I don't know about other collada generators ... does anyone know?). I don't know what will happen with my dae files that have the material info removed. I will test that.

In any case, that leaves us with (at least) three bugs: (1) There is no explanatory error message when the subset condition is not met (the message is there in the function, but does not appear). (2) This test should no be applied to the physics shapre mesh. (are they preparing for material physical properties perhaps?). (3) The button is not reactivated when an offending mesh is replaced with a good one, forcing the user to restart the whole upload process.

 

[Clix Akros]

I've had this issue today and I also had to display the debug console to narrow the problem down too. I recommend everyone display the debug console from the develop menu when uploading meshes or collision, as it'll prevent you ripping your hair out and you'll be able to find the source of the problem pretty quickly.

Anyway, I'm using Maya to do my meshes and I solved this problem by exporting the mesh and collision with the same default lambert material. For some reason, it really doesn't like the material on the collision mesh differing from the material on the referenced mesh.

Hope that helps someone!

Russ

[Drongle McMahon]

Well. I tested removal of all material references from the collada....that's <library_effects>, <library_materials>, <bind_material>s from <library_visual_scenes>, AND the materials attribute from the <triangles> tag. If that's done in all the meshes, it works. Putting the material attribute back in the <triangle> tag of one mesh stops it working (calculate button greyed). It appears that at least that has to match.

So then I tried all meshes with materials, but one with a different name/ID in all relevant places. That fails, but if I changed ONLY the material attribute in the <triangle> tag back to agreeing with the reference mesh, it worked! I think that shows that it is only using that attribute for constructing the material list for each LOD/physics mesh. The actual name/ID and data in the <library_effects> and <library_materials> seem to be irrelevant for this validation, although they are obviously used to make the high LOD materials.

 

[Van Auster]

As an aside, I read through the posts and have not seen this mentioned:  with Viewer 3.1.0.43176:  

Uploading a unique physics file/"calculate weights & fees" works as expected on Aditi.  On Agni "Calculate weights & fees" grays out and upload becomes inoperable. Not that this helps.  I just find it interesting.

[Drongle McMahon]

I was asked tyo make a simple conclusion saying how to get around the physics mesh version of the problem. What you need to do is have at least one of the high LOD mesh materials assigned to the whole of the physics mesh. That should make it pass the validation check.

If that doesn't work, or you are more adventurous, you can look in the collada files and find the <triangle> tags in the physics mesh file. They look like ' <triangles count="123" material="material_name"> '. If the ' material="material name" ' is missing, put in one from the high LOD file. Otherwise, change 'material name' to match one in the high LOD file.

Hopefully, the application of the check to the physics mesh will be removed. For the LOD meshes, it is likely to stay because it was put in to solve other problems. These work-arounds should work for those if, like me, you have a lot of files that have been rendered unusable, although the second one will mess up any texture/materials assignments and you will have to place textures inworld (I do that anyway).

Feedback from users who try this might be helpful, especially for users of programs other than Blender, as my tests were very limited.

[Drongle McMahon]

"Uploading a unique physics file/"calculate weights & fees" works as expected on Aditi.  On Agni "Calculate weights & fees" grays out and upload becomes inoperable."

Oh dear. most of my testing was done on Aditi. If that's right, it could be even more complicated.

[Flea Yatsenko]

This is so annoying, and I couldn't find anything on the Jira talking about it. I'm going to make one now.

Anyways, the best solution is to roll back to a previous version of SL.

 

Here is a download link for 3.0.1 http://download.cnet.com/3001-7540_4-75592526.html?spi=b6626a14dbc626bedf5610e2e91cf9fa

WARNING: It has some sort of crapware cnet downloader. You can probably find a better version to download, but this one works I think. Make sure to turn off automatic updates in preferences.

 

[Drongle McMahon]

"I couldn't find anything on the Jira"

It was moved from VWR to SH (active): SH-2595

[Kwakkelde Kwak]

In 3.1.0 and higher the LOD distance algorithm changed, that's why I rolled back up. I don't want to redo half my work later. The changes are here to stay, at least for now. So be careful with rolling back.