Drongle McMahon

Is the pattern fixed, or does it change as you move the wings or camera? If it changes, it's nothing to do with triangles. Does the pattern of patches correspond with some property or colour value of the normal and/or specular maps (including their alpha channels)? (Maybe you can see by applying them as diffuse textures without n&s maps). If so, that might give a clue as to the source of the effect.

"inadvertantly checking and unchecking boxes" It's a good way to learn though, if you can keep track of the checks!

Well, certainly not too many triangles there, but then it's hard to understand the tiny fragmentation of effect in the picture you posted before. Any chance you have a sundivision modifier (or equivalent - don't know what software you are using) that comes into effect between this latest picture and the exported mesh?

"select object,Object options(box looking icon close to modifiers),display,untic Wire checkbox" ...and/or uncheck "Draw all Edges"?

The pattern of shading differences you see looks like the sort of effect you get when you get hidden extra materials because you have more than 21844 triangles. So, in case that's the problem, how many triangles do your wings have (per material)? If it's more than 21844, the try reducing it and see if that has any effect. Of course, it may be something completely different. There were various bad interactions with materials and transparency reprted in the jira, but I haven't kept up with them. I am assuming your bumpiness is a normal map, not traditional bumpiness. Traditional bumpiness doesn't work with materials.

You can use the beta grid. Aditi, for testing mesh uploads. You have to take the quiz again first. Then you get free L$ on Aditi only. From what you say (guessing, as no pictures) one possibility seems to be that you might have uploaded the model before you did the UV unwrap. In that case, the dae file cintains no UV map, and you get a random map (actually, uninitialised data) that can have all sorts of strange effects. If that's the cause, you need to export the dae again after you have done the unwrapping. Another common source of problems is when the Blender model has multiple UV maps. These all get into the exported dae file, but only one is used by the uploader. If it's the wrong one, the texture mapping will be wrong. Also, you didn't mention what sort of image you exported from Gimp.

Looks like the same situation I have. Neighbour's security system sends he ejection message every five seconds to me or anyone else on my land, up to a range of >40m inside my land. Of course, it can't actually do the ejection. I can mute it, but that still leaves anyone else on my land being deluged with threatening popups (checked with alt). Since I welcome visitors, that is not acceptable. Of course there is no response to IM politely requesting adjustment. Some people just don't care. I can't locate the offending object. So I can't AR it even if I was inclined to. I think it may be a script in the house.

People have very different interpretations of the term "UV map". The essential map is really just a list of numbers saying which texture coordinates have to be associated with each vertex for each polygon in the mesh. It usually ends up being represented as an image that can be used to guide the contruction of textures that will be displated on the mesh surface. There is a great variety of ways this image can be made, from those with just the vertices (and interpolated edges) of the polygons, to those with a texture that might be already suitable for use as it is. Without seeing it, I am guessing that the map should be used as a separate layer to guide the making of your texture and should not be included at all in your exported image, in which case.... 1. Make a new image with the same dimensions as the map 2. Add a new layer and paste the map into it 3. Change the opacity of the new layers to as low as possible while you can still see the map 4. Switch back to the original layer and do your painting, turning the map layer on and off with the eye icon as needed. 5. Add more layers as needed, but keeping the map layer on top. 6. Turn the map layer off with the eye icon on the laft og the layer panel. 7. Export the images (png or tga) 8. Save the native GIMP file if you want to be able to continue editing later.

"The viewer is still rendering each copy of the mesh separately ...However it only has to load the data once" I am pretty sure that's right. The mesh geometry data loading is handled by part of the viewer code called the mesh repository. Each mesh asset one has a uuid. The actual mesh objects are handled by a class called vovolume, which includes all prims, sculpties and meshes (I guess the vo = vertex object). The vovolume code treats mesh objects as special types of sculpties (!! for historical reasons, mesh was implemented as a new sculpt type!!). It vovolume knows the uuid of its mesh asset and asks the repository for the data when it needs it for rendering. It follows that multiple objects can use the same mesh uuid, and that they then don't have to download the data again when the repository already has it. This mechanism is kept inaccessible to the user (and scripts) delibrerately to prevent use in animation because similar use of sculpt maps has very bad effects on performance. So the only way to get multiple objects using the same mesh asset is by copying the originally uploaded object.

"Drongle made a graph about size and influence on LI a long time ago, if he reads this, I'm sure he can provide a link." Here it is

The high LOD prim torus has 1152 triangles. It is so high because it has to keep an acceptable profile with all possible ratios of outer and inner radii. Thus it has 24 segments around the perimeter and 24 around the tube (24x24x2=1152). When you have a thin tube, as in your example, the 24 segmnts around it vare wasted. Here is a couple of pictures of torusesm rendered first and wireframe second. They all have 24 segments around the perimeter, but fewer around the tube as you go downwards, 24, 12 (every other one removed), 8 (2/3 removed) and 6 (3/4 removed). So the toruses have 1152, 576, 384 and 288 triangles. While the efffect of removal is fairly obvious with the fat torus on the left, it is barely noticeable with the thin torus on the right. It's important to use smooth shading to get the advantage of reduction without obvious faceting.

"is there a limit to the amount of hit-boxes you can have? " Not sure what you mean. Maybe the number of hulls in the physics shape? If so, I don't know of any limit, but the land impact will increase and the lag effect on the region physics engine will increase. So you should always keep it to the minimum really needed to get the collision behaviour you need. Thus my last bridge shape - assuming you need a good walkable surface on top, but don't need the same accuracy underneath.

"Does it work in Blender's .DAE though?" Yes, it does. I tested it before posting the answer. Still, you don't need to use Blender now that you have Arton's answer. :matte-motes-big-grin:

Ah. That's a new and interesting one. In your bridge1.dae file, the "Walkways" has an uppercase "W", while in the posts.dae file, it hasd a lowercase "w". "post" has a lowercase "p" in both files. Now the ascii codes (or unicode) for uppercase letters (65-90) are all lower than the ascii codes for the lowercase letters (97-122). So "W" is before "p" in a simple ascii-based sort. If you change the "W" to "w", then they come out of the exporter in the right order, as "p" is less than "w" in ascii. I would call that a bug. Alphabetic sorting is generally expected to treat "W" and "w" as equal. If I can work out how, I will submit this as a bug in Blender. ETA: by the way, your files have cameras and lights in, which are uneccessary (although I think the ulpoader will just ignore them). If you deselect everything (A) and then just select the meshes (B, then drag around them; or just rightclick on each) then the camera and lights will be left out. ETA2: I don't think I will submit as a bug. I found a code snippet that shows the names are std::string, and a bit of reading suggests it's complicated to do case-insensitive sort for that (unless they already use a library with case insensitive comparisons in it). Is Gaia here?

If you can make the dae files (for the simplified example) accessible somehow, I'll take a look and see if i can work out what's going on.

Well, hopefully it will just be import->Export(with sort by object name); maybe check names too. No need to get involved with the rest of Blender.

I hope someone who knows 3DMax will join with the answers for you. The sorting of the heirarchy may be just a convenience. The export order could depend on the order of creation, selection, or just about anything. You might be able to find something in the documentation, but I wouldn't bet on it. The fbx format doesn't even have a public definition. I suppose you could try importing the model into Blender (it has fbx, obj and 3ds importers, but I don't know how well they preserve anything) and then use the Blender exporter. At least that wouldn't cost anything to try.

"I have named things accordingly so that the mesh post is A, the walkway is B, the physics post is 1 and the physics walkway is 2." That only works if your exporter puts them in alphabetical order, which the Blender exporter does ONLY if you select that option in the exporter screen options panel. I don't think it works in other software. I have no idea how they determine the order, or whether you can change it. In Blender, I use a scheme like "pillar_hi", "pillar_lo" ... "pillar_ph", and so on, with the LOD/physics as a suffix so that alphabetical order is guaranteed.

The problem here is that you have two mesh onjects in each dae file, the visible and the physics, but the wrong physics is being associated with each visible mesh. So the box, intended for the pillar, is being stretched to fit the bridge span's bonding box, while the curved thing, intende to fit the span, is being squashed into the pillar's bounding box. Which gets associated with which depends on the order the objects appear in the two dae files. So they must ve in the opposite order here. I don't think I know what modelling software you are using. In Blender, the solution is easy, because you can select "Sort by Object Name" in the exporter. Then a suitable naming scheme ensures the right order. I don't know how to control the order in different software. Of course you can do it by editing the dae file with a text file editor, but you need to know a lot of detail for that. There is another problem you are going to encounter here. You have triangle-based physics shapes because you have not clicked "Analyze". The physics weights (and thus LI) of triangle-based shapes is greatly increases by narrow triangles like those you have around the edges of the curved part. If you do use this kind of shape, you should delete the faces connecting the upper and lower curves. In fact, you probably only need one of the curves at most. Even if you use a hull-based shape (by clicking "Analyze") the curved part will still have a high physics weight, because many hulls will be needed to preserve the shape. Also, if you separate in into the nine convex blocks before uploading, the "Analyze" will work better. Here are some possible shapes for uploading after "Analyze". At the bottom is the basic shape. It's physics weight is 3.5. The next one separates the boxes into convex boxes. It's weight is 3.2, because the "Analyze" works better. The next one is sinplkified to reduce the hulls. It's weight is 1.08, but it dosn't keep the nicely curved shape. The last one has the same number of convex boxes and vertices, but does keep the upper curve, so it still has weight 1.08! By the way - don't take any notice of the physics weight shown after you click the "Calculate.." button. That is for the default convex hull that's used if you set physics shape type to "Convex hull", not the shape you have uploaded, for which you have to set the type to "Prim".

Here's a dae file opened in notepad++ free text editor. The advantage of an editor like this is that you can tell it it's XML (which dae is) with the language menu. Then it will let you collapse sections as I have done here, and do the proper syntax highlighting. It's also guaranteed to save only on proper text format. This is produced by Blender, and the red and green boxes are the <polylist> sections for each of the two materials in this mesh. It is the order of these sections that determines the face numbers (at least, it used to be!). So swapping these two should invert their face numbers. They will always appear between <mesh> and </mesh>, and those (there may be multiple sets if there are multiple meshes) with always appear inside <library geometries> and </library geometries> at the outermost level. There is a whole lot of other stuff defining the materials and a series of indirect links from here to that (via the material= here), but none of that matters - only the order here matters. Maya may use one of the alternatives instead of <polylist>, such as <triangles> or <polygons>, but the arrangement and effect on ordering of face numbers should be the same. It may also use a whole lot of <extra>, forMaya-specific information, tags making the arrangement less obvious.

Sounds like you need to join the pieces into one (or a few) mesh. That may reduce your LI substantially. If you show us a picture of the bridge mesh, we might be able to see if that's going to be better.

This sort of thing does happen if you have split edges when you apply subsurf - that is a sequence of edges where the vertices attached to either side of them are actually two separate vertices. The superimposed vertices get pulled apart by the subsurf. It can happen in variou ways without applying the edge split modifier, such as explicitly splitting the edsges, separating and rejoining etc. You can check by selecting the relevant vertices in vertex view mode and seeing if the count is what it should be. If the duplicated vertices are near enough or exactly superimposed, you can merge them with Remove doubles, providing the normals are matched up (Ithink that's required - not certain).

"Drongle like Google knows "almost" everything." Ha! Do you know the saying "The more you know, the more you know how much you don't know"? I don't think Google knows anything itself. I think it just tells you who it thinks does? Anyway, this is one bug I never came across. So consequently I know absolutely nothing about it! :matte-motes-confused:

"upload at 0.250 use 2.34/upload at 1.000 use 7.54" In case you like horrible complicated answers... This is expected when the parameter determining the LI is the "download weight". That depends in a complex way on the complexity of the main and the lower LOD meashes, and on size. It always imcreases with size unless the same mesh is used at all LODs. The reason is that the higher detail mesh is visible from longer distances as it gets bigger, and that means more data gets downloaded and the graphics processor has to do more work. If the physics weight is higher than the download weight, then that will set the LI instead. The effect of size then depends on the kind of physics shape. If it is type Convex hull, it should not vary with size. If it's type Prim, then if it is "Analyze"d (hull based), it should not change with size, but if it isn't "Analyze"d (triangle-based), it will decrease as size increases. Sometimes it will switch between being set by download weight and by physics weight as the size changes! Simple isn't it? :matte-motes-agape:

"is it Vertices or triangles that are counted for the limit ?" It is supposed to be vertices, but because of the bug that is never tested, and it is triangles instead. " 174752 tris is alot more than 65536 or am i misunderstanding something here" 174752 = 21844 x 8. This comes from a long time ago, when the Blender exporter used only <triangle> tags in the collada file. Whenever the triangle count reached 21844 (which is always before the 64k vertex limit is reached), a new material started.In that process, vertex counter was reset to 0. Consequently, the vertex limit was never checked and the uploader went on adding triangles and new materials. I don't know whether it eventuall stopped for some other reason, but it certainly went on until more than 8 materials had been started. Then when it did the eventual upload, it simply ignored everything belonging to the 9th or subsequent materials, leaving the holes. If you model had only one material, the triangle count was therefore always capped at 8 x 21544. If you had some materials with fewer triangles, and those were uploaded first, then the limit would be lower because the initiall used up mmaterials had fewer than 21844 triangle. Now the Blender exporter uses <polylist> tags, and the polygons might be triangles or quads. The part of the code with the 21844 trap is different for <polylist>, so that the numbers are more difficult to work out. However essentially the same sort of effect still happens, with the 64k limit never being applied. I used to check this regularly, so that I could make sure the jira was updated if ut gor fixed, but I got too bored with waiting about a year ago. So I can't say definately whether it's been fixed. It's easy enough to test - just make any mesh out of quads and subdivide it until the face count is more than 87376 and then triangulate (should be >174752 tris). Then export and try opening in the uploader. If the bug is still there, the triangle count will br stuck on 174752, and if you succeed in uploading it, it will have holes in (small holes - look closely. There will be n-174752 hole where n is your real triangle count.) Anyone who is making mesh with more than 21844 triangles per material is almost certainly already making mesh that will waste gpu resources. So the motivation to fix this might be very low. I suspect the main reason people do this is because they don't know that they should use smooth shading and use ridiculous levels of sudicision to achieve smoothness instead,