Jump to content

Drongle McMahon

  • Content Count

  • Joined

  • Last visited

Community Reputation

592 Excellent


About Drongle McMahon

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Here's an example of what I was trying to describe. This is a bowl with a very concave base and a double surface. Where you are looking through the outside and the base, there are thus up to eight surfaces you are looking through, but half always have their normals pointing away and are not rendered. So in effect we are looking through up to four rendered surfaces. The versions on the left were all exported without triangulation, while those on the right were triangulated by the exporter. At the bottom, all the surfaces are a single material. In the middle, the inside and the outside are each
  2. With surfaces that convoluted, it may be impossible to arrange materials so that none overlap themselves from all points ov view. If you are using Blender, you might achieve some improvement by deselecting the "Triangulate" option in the colladaexport options, letting the oploader do the triangulation. (It seems that the Blender triangulation puts half of each quad in different halves of the triangle list.) That's not likely to remove the problem entirely though. Do you really need inside andoutside for this mesh? It looks to me as if you only ever see it from the outside.
  3. The limit for the hi-poly secret extra material effect is 21844 triangles. So you have exceeded that by far. With 47106 triangles, you will have three materials instead on one, if they start out as one material. The limit applies per-material. So it is possible to exceed it for the whole model, but only if you have less than 21844 triangles assigned to each material. Try reducing it to below 21844 per material and see what happens.
  4. What you describe - different selectable faces reverting to texture and colour of a dominant one - sounds like a phenomenon that happens when the relevant meterials in SL have the same name. There are at least two known causes. First, when the names in the Collada file are actually the same, or they get truncated by the uploader at included spaces so that they become the same. Second. when a material/submesh has more than 21844 triangles the uploader creates an additional face that has the same name. As far as I know, the Blender excludes duplicate names and the Blender exporter replaces space
  5. I have to agree that those wiki pages are not as clear as they might be. Reading both your answers, I think some of your problems with the SL lighting is because of the differences in SL between specular reflection and the very simplified environmental lighting. I will try to explain how these seem to work, at least as far as I understand them. Environmental reflection is very simplified. The environmental light map (in effect - I don't know if it exists as such at all) takes account only of the sun/moon and the sky. It ignores other light sources, and it ignores secondary reflections and sha
  6. You might try reading the following wiki pages, which together try explain the SL advanced lighting rendering system... Second_Life's_light_model_for_materials Alpha_Modes_Do's_and_Don'ts Material_Data Then play around with a cube and a sphere using all the maps and settings to get a complete understanding of how they interact. There may be useful correspondences between maps generated by substance painter and those used by SL, despite the fact that they aren't exact equivalents. Sometimes you will have to invert of otherwise edit alpha channels separately, and maybe RGBs too. I once spent
  7. Oh dear. The order you get with singularity is just the order the polylists appear in your file. So it seems that viewer is still using the old system. How old is it? I think you would have to contact the developer(s) to clarify whether it has the new code in in that I mentioned. I'll see if I can find their code. Had a look. Model.cpp is hugely different. The sorting stuff isn't there. So I think it's clear that Singularity is using the old method of face numbers, which is just the order the assigned geometry (polylists) appear in the dae file. If so, that's a definate incompatability with th
  8. Here's another test. Used Cathy's dae, first as it is, then with "lambert8SG" replaced by "lambert08SG" and "lambert9SG" by "lambert09SG". That changes the alphabetic order to be the same as the numeric order. Here are the reports of a script that gives the face colours in face-number-order...  ETA: the material names were added by hand, not available to the script.
  9. "... should we also export materials in alphabetical order?" My conclusion that the materials, and thus the faces, are sorted by name came from both inspecting the code of the current release viewer and doing some tests, also with that viewer (i.e. Firestorm etc. could be different). I am fairly confident that is right, although it would be good if somebody else could do an independent test. If I am right, then sorting the materials in the collada (it would have to be the polylist order, for the uploader to notice - the material or effect tag orders don't seem to matter) would not make any d
  10. To make the distinction clear, here are the links for a material called "A" exported from Blender. The name used by the uploader is now "A-material". It has "-material" tacked on the end, but since the name is still there in front, its alphabetic order will still determine its face number. Thus in Blender the face numbers can be controlled by the material names. 
  11. Here's some extracts from your collada file. The links I mentioned are shown by colours and arrows. You can see here where the problem comes from. The last two links use the given material name "A", but the one the importer uses, the material attribute in the top box, is different. It's "Lambert8SG". At the bottom you can see the other ploylists with similar material attributes (except for the last one which isn't used and will therefore be ignored by the SL uploader). It's the order of these names that will determine the face numbers. So now we need to solve the question of where these names
  12. It would be interesting to look at your collada file for a simple object to see if we can work out what's going on with the names. I guess we would need to know the material names in Maya too.
  13. Some time ago, there was an important change to the situation described in the link referred to a couple of times here. Before, when the older thread took place, the order of the face numbers was decided only by the order of appearance of the <polylist> in the geometry, with no effect of the material names. This was changed when material matching across LODs was changed to depend on material names. Now the faces are sorted according to the material names. The first in alphabetical order is face 0, the next id face 1, etc. In Blender, this means that the order of materials in the material
  14. Drongle McMahon

    Uploading a mesh model

    Concerning the "strict naming" of "custom LOD files". This paragraph appears to be inaccurate and/or superceded by code changes* in two ways. First, I recall that it was the naming of the objects in the file that had the strict suffix requirements, not the naming of the files. Second, this requirement seems to have been relaxed, even with ImporterLegacyNaming set to False. Thus the file combinations listed in BUG-8996 are uploaded successfully whether ImporterLegacyNaming is True or False. Neither the file names, nor the object names in those files have the prescribed suffi
  15. I made an important change as detailed in the edited ETA of the instruction post. You do need to activate auto-smooth on the recipient object. Otherwise the transferred normals appear in Blender, but don't get exported. (Is this a bug?).
  • Create New...