More than eight materials per mesh object now?

[Drongle McMahon]

ETA: it seems this is all caused by object naming effects - see post below

I think there's something more subtle going on here. First, using the ten-pillar model, I noticed that with the capped physics. which does upload, the root of the linkset is the mesh with the last two materials, while with the uncapped physics, the root is the six first materials.When both visible and physics were uncapped, the model ulpoaded properly. With the fully capped models, the first eight pillars had a physics weight of 7.3 (i.e less than 1 each), but the two others had a physics weight of 46 (23 each - orange in physcics display).(Actually. given previous knowledge about triangle-based physics weights, that discrepancy isn't very unusual).

I didn't complete the upload of the next ones, but judging by whether the preview showed the physics, any (partially) uncapped visible model model would work properly with any (partially) uncapped physics model, but not with the fully capped physiocs model!

Then I tried with a different model - two six-sided cylinders with eight materials on the first and the ninth material on all faces of the second. That uploaded without any problems whether the physics cylinders were both capped, if either was uncapped at one end, or if all the caps were deleted. In other words, it didn't exhibt the problem at all.

Note, these were all with "use LOD above" in all LOD slots - so it's nothing to do with decimation. MeshUmportUseSLM was always off (I hate slm).

It's may be difficult to make a repro for a jira that ties down the circumstances where this happens.

 

[ChinRey]

---

Chic Aeon wrote:

Well according to the TOS of August 2013 and not changed in any manner I have heard of since then

open source is not supposed to be uploaded

as the uploading person in this case does NOT hold the copyright

.

---

In other words, if it wasn't for that physical center bug this feature would only have been useful for people to violate Linden Lab's TOS. Didn't think about that but you're right of course. (I probably should have added an emoticon here but I'm not sure which would be the most appropriate.)

 

---

Chic Aeon wrote:

As I was working on a fairly complex object in Blender cycles today I noted that if you want to use the full extent (well, as much as I know anyway) of Cycles then there could certainly be occassions when you would need more than eight materials. You can of course work around that and I have,

---

I suppose the workaround is to map several Blender materials onto a single UV map/texture. That would make sense.

 

---

Chic Aeon wrote:

I will keep it to eight though and just upload in pieces as I have before. Enough new stuff in this project as it is.

---

It shouldn't be that much of a problem I hope. Remember that weight balancing is one of the most important tools we have to keep LI down and that means it rarely make sense to combine so many materials into a single mesh anyway. Of course, one important exception would be if you have a moving part that needs more than eight faces and should be linked to a static object. I suppose rez boxes still have their place in modern SL building.

[Chic Aeon]

I don't think the materials limit will be an issue for most folks. It is the cycles "need" that makes it complex. If you are "making" your comined textures using Blender rather than a graphics program and doing anything fancy then I can see how it could be tricky.

I have in the past mapped and baked textures and then pasted them all together in graphics and eliminated some materials. That is doable but not handy.   This BIG window came in at 2.3 in SL and I am very happy with that. I normally can go overboard with fine grained texturing so I got all the window on one texture plane and I was happy with that.

 

MOST things won't be an issue, but if you are adding light or glow or color change ability you do need those different material faces.

 

And yes, it is a bit puzzling as to the WHY of this change unless it has something to do with how Sansar will work and we are the test bed and recipient of early "goodness". (Some new improvements have been great; not sure this is one though ). 

 

I made the walls for this last night and they came out beautifully the first time (whew) so I will see what the difference in upload will be if I put the window IN the wall and upload that way. Walls are .5 at this point so either way will work.

 

Later note: The window with walls (inside and outside separate in this case) came in at 3 when uploaded separately and almost 7 when uploade as a joined object. Same uploading perameters, same mesh, same number of materials (in all).  I didn't really expect THAT much difference . So single upload it will be.

 

 

 



[Drongle McMahon]

Ah. It seems that my variations were all because this is in fact a consequence of the object naming. The uncapped variants were exported from a duplicated model in which the object name was different (Blender doesn't allow duplicate names) although the material names were identical. Trying this out with the same model geometry, but with only eight materials, there was no problem using an object called "Cube" for the visible LODs and one called "Dube" for the physics, irrespective of whether or not caps were removed. Furthermore, "Dube" could also be used as a lower LOD mesh for "Cube".

However, with the ten materials, if I used "Dube" as a LOD mesh, then the upload failed with the error message that says materials are mismatched (which isn't true, of course - it's only the object names that differ). If I used "Dube" as the physics mesh, it was simply ignored, so that there was no Prim-type shape and no physics in the preview. There was no error message and the model could be uploaded (as Aquila reported).

After renaming "Dube" to "Cube_PHYS", according to the official naming convention, it now worked as the physics mesh for "Cube".. Also, to my surprise, it also worked as a lower LOD visible mesh. Indeed, the identical mesh named as "Cube_LOD2" also worked as either LOD or physics mesh for "Cube". So did "Cube_LOD6", "Cube_LODn" and  "Cube_LOD". but not "Cube_LO" or "Cube_PHY".

So it appears that the the fall-back to use legacy model association, which seems to work with multi-mesh models when they all have less than 8 materials, does not work fully when a mesh gets subdivided because it has more than 8 materials. Using the new naming convention, the same meshes will work, and there is some relaxation of the requirements.

So if you want to avoid this problem with meshes having more than ten materials, you have either to make the object names all the same in the visible and physics model, or use the new naming convention.

Now I will drive myself insane looking at the source code to see where this happens... :matte-motes-confused:

Note: The anomalously high  triangle-based physics weights were still there with all successful ten-material uploads.

 

[iOthman]

I wasted 3 days trying to figure out what was wrong with my rigged mesh because it never acted so strange before. I went back and forth chaging UV maps, unlinking stuff and what not in hopes to make it work to no avail... 

The "root" face texture overtakes all other faces.

so for example when I apply different textures to face 1, 2 and 3 then apply a texture to face 0 it get applied to all other faces as well overriding the others.

I reverted back to previous firestorm version till this is resolved.

Why don't they notify creators about this with the release.

[Whirly Fizzle]

Do your material names have spaces?

Theres's a bug where material names with spaces get truncated and it can cause your symptoms when texturing - see https://jira.secondlife.com/browse/BUG-10434

[iOthman]

No they don't have spaces.

Must be the new update. 

AFTER reading this post, Reverting to the previous viewer version solved the problem.

[Whirly Fizzle]

---

iOthman wrote:

No they don't have spaces.

Must be the new update. 

AFTER reading this post, Reverting to the previous viewer version solved the problem.

---

If you think it's a bug with the new importer code, can you file a JIRA issue for it? If it doesn't get reported it won't get fixed.

If the bug also repoduces on the current LL viewer, file a LL JIRA issue.

If it only reproduces on Firestorm, can you file a Firestorm JIRA issue.

You'll need to attach a dae that reproduces the problem to the JIRA.

Ta!

[iOthman]

I'm waiting to see if anyone else has the same problem, to see if it's on my end, or other minor problems.

I didn't have enough time to investigate it thouroughly, but I'm planning on it, when I do I will definitely file a JIRA issue

Can anyone else do a test?:

upload a simple mesh with multiple faces/materials (not linked meshes), texture or color the faces, then re-texture/color face 0 to see if it overwites other faces.

 

 

[Chic Aeon]

I read that there were lots of issues with rigged mesh and the new version of Firestorm (and you would think the code that was adopted from LL? so perhaps before for some folks).

 

I didn't update and I don't plan to. Too many people having issues.

 

I suspect there is somewhere to know about newness like using the pre release "alpha" version of the Ll viewer for one.  There are a few odd things going on over on the beta grid but hopefully they will figure out the issues before bringing things into mainstream --- or not.

Welcome to the adventure.

 

 

[Chic Aeon]

Just an off the wall comment as this issue was reminiscent of a problem maybe seven years ago with prims. For me, when I textured a whole prim (let's say cube) the bottom face (forgot which one that is now) NEVER textured. So I would have to do that by using select face. Long story a few others with the issue (there was a bug tracker then, not a JIRA) and about a YEAR later they figured out it was the firmware on my modem (not wifi).

 

So if you have access to another internet connection or a friend with an SL viewer you might want to check that. It is likely that it is a bug, but it "could" be you LOL.

 

Good luck.

 

OH, and you could also try using a different viewer like Singularity to see if it is YOU .

[Drongle McMahon]

You might want to look at this thread to see if there's any clues there. The sort of behaviour you describe seems to arise when materials end up with the same names, in one way or another. The general observation doesn't just apply to the latest viewer, but the internal assignment and treatment of material names might have changed. If your effect is the same phenomenon, then you would find that the changes you make to faces other than the "master" face (face 0, I think) revert to the master face properties if you log out and back in. It might be informative to do that test.

[Whirly Fizzle]

---

Chic Aeon wrote:

I read that there were lots of issues with rigged mesh and the new version of Firestorm (and you would think the code that was adopted from LL? so perhaps before for some folks).

 

I didn't update and I don't plan to. Too many people having issues.

 

---

If you mean new bugs with rendering some rigged mesh correctly then yeah, there's a nasty new bug on Firestorm 4.7.5 which will cause some rigged mesh (ones using zero weighting) to render with spiky bits sticking out of it.

This isn't specific to Firestorm 4.7.5 though, the same bug is in the current LL viewer - see https://jira.secondlife.com/browse/BUG-10747

 

If you mean problems uploading meshes on Firestorm 4.7.5 with the new importer code then so far we don't know of any bugs which don't also occur on the current LL viewer .

The main 3 problems (only one of which is actually a bug) tripping people up on 4.7.5/any viewer with the new importer code are:

 

• BUG-10434 - Unable to texture meshes with spaces in the material names on the Importer viewer.

This one's a bug & caused by materials with spaces in the name getting truncated so you may end up with several materials having the same name, which will mess up texturing those meshes.

 

• Ref: BUG-10326 - Latest Importer viewer buggy on uploading, and retaining material group order

 Material names are now sorted alphabetically when importing a mesh model and may not retain the order they had in the original model imported with the old importer. This is expected behaviour and If material order is important to your model, you must name them accordingly.

 

• Not following the new naming convention for LOD files.

 

If anyone spots a bug with the mesh importer that's specific to Firestorm on 4.7.5 only, please file a Firestorm JIRA issue

If the bug also reproduces on the current LL viewer, then it's best to file it straight on the LL JIRA

 

 

 

 

[Drongle McMahon]

"Not following the new naming convention for LOD files."

Just to reiterate from my comment on that KB article, to avoid confusion: The article says the naming convention applies to the names of files for LOD and physics. It doesn't. It applies to the names of the objects in the LOD and physics files. The file names don't matter at all.

[Lexbot Sinister]

---

iOthman wrote:

No they don't have spaces.

Must be the new update. 

AFTER reading this post, Reverting to the previous viewer version solved the problem.

---

Had this problem with a beta version of Firestorm not too long ago (my friend uploading my mesh).

For us it went as far as the person changing the textures on faces would see them correctly for a moment, then they would revert after a while, or when the object was copied. The mesh wasn't rigged.

Tried to ask about it in the firestorm help group, but after a snippy answer about betas being tested at own risk etc etc, i got pretty fed up and didn't jira it either.

 

Worked just fine to upload on older versions of firestorm & newest LL viewer.

[Whirly Fizzle]

Does that mesh import okay on Firestorm 4.7.5?

The old Firestorm beta (4.7.1) was released in May & does not have the new importer code.

 

[Lexbot Sinister]

 

---

Whirly Fizzle wrote:

Does that mesh import okay on Firestorm 4.7.5?

The old Firestorm beta (4.7.1) was released in May & does not have the new importer code.

 

---

 

It was in 4.7.5.47888

Haven't tried 4.7.5, after the hours of trying to troubleshoot the mesh and yanking my hair out, i decided to stick to what i know works. Uploaded the mesh with older firestorm without a hitch.

[Whirly Fizzle]

4.7.5.47888 was an old nightly build & still had a lot of unfixed bugs.

Firestorm 4.7.5.47975 is the current release build.