Drongle McMahon

  • Content count

  • Joined

  • Last visited

Community Reputation

571 Excellent


About Drongle McMahon

  • Rank
    Advanced Member
  1. About Origin of Meshes

    I'vw always wondered why this can work, because the viewer has code that is supposed to eliminate deegenerate triangles before uploading them. It even has an minimum tolerance built in so that vertices don't have to be exactly identical to make a triangle degenerate. It may be similar to the unused first vertex trick. That is, if the degenerate triangle culling only happens after the update of the mesh extents. I'll have to see if I can get motivated to look into the source code again!
  2. Uploader automatically splitting object into additional prims

    Also note that if any of the maximum eight materiasls has more than 21844 triangles in a <polylist> a new material will be silently generated. Then there will be more than eight and the model will be split. This process can be accompanied by several other horrible effects.
  3. help: mesh physics doesnt match mesh model

    Are those black parts of the preview part of the model that you removed in the physics mesh? If so, you need to be aware that the physics model (of each mesh object if there are more than one) gets stretched and/or squashed to fit the bounding box of the high LOD (reference) mesh. To stop that distorting the physics, you need to make sure the physics model has the same bounding box as the main model. In this case, you may have to add back some geometry to bring its height to the same as that of the visual model. Otherwise, if those are parts of the physics, so that the physics is taller than the visual model, there may be some extra geometry up there in the visual model that isn't meant to be there. In some circumstances, this can be invisible in the rendered model (even just a single floating vertex if it's the first in the file). So then you need to check that there is nothing that got left up there by mistake.
  4. Edit cut-off is a bit quick, to say the least.

    Hmm. In the mesh forum we have often had long discussions, lasting several days, that have resulted in notes being added to the earliest replies correcting or extending the adivice there. With the time limit, this will no longer be possible. That will mean users who share the problem having to read thtough the whole long thread to discover the corrections. That is a pity. I suppose I will have to assume the perceived benefits of the time limit, whatever they may be, are worth this negative effect.
  5. No pictures?

    "You need to look more closely Drongle" Oh well, there's hope then. Still, I'm not going to be happy until we can upload images to the forum's own archive. I don't want to have to starty using third party sites. The accumulated images we have posted, especially you, Aquila, comprise a valuable store of guidance that needs to be kep together with the accompanying texts. I also agree with your wish to be able to peruse my own images - that's by far the most effective method I found for locating and linking to old posts. I haven't used a quote here because it's far to large and intrusive. Also, I couldn't delete part of it. I miss the edit-as-html too.
  6. No pictures?

    From my first glance at my own posts in the Mesh Forum, it appears that all pictures have disappeared. That renders most of the more useful posts in that forum completely useless. Anyone know if this is a permanent situation? I see there's an insert "image from url" at the bottom, but apparently no direct upload option, and nothing exists in in the "existing attachments".
  7. Is there a Land impact glitch?

    When you link prims to mesh, they switch from legfacy prim LI accounting to mesh-type LI accounting. In Many cases this will increase the LI. The more you distort the prims, the more the increase is likely to be. Toruses are particularly bad. If you restrict your physics prims, as far as possible, to cubes with no distortion other than stretching, cylinders with only stretching the long axis (ie perfectly circular section), and undistorted spheres, these will use physics engine primitives which are the lowest possible physics weight. As soon as you distort them further, the physics weights will jump. One way of testing, to see which of your prims is making the worst LI contribution, is to unlink them, then add a blank normal or specular map. That also switches them to the new accounting. Make sure they are set to physics shape type "Prim", and click the "More Info" link on the edit dialog to see the separate weights.
  8. Degenerate Triangles???

    Degenerate triangles are triangles with (nearly) zero area. This can be either because two vertices are identical or because all three lie on a straight line. Doesn't have to be exactly zero because the code uses a very small number that it treats as effectively zero. So if you have very small triangles they might be treated as degenerate although they aren't exactly zero. In Blender you can do Mesh->Clean up->Degenerate dissolve, which will eliminate them. An option will appear at the bottom of the toolbox (on the left) where you can set how close vertices have to be to be merged. As long as the problem isn't just that your mesh has far too many triangles anyway, that should help you. PS. You are probably going to get a better response asking this sort of question in the Mesh forum.
  9. science of texture size

    True - you can avoid the alpha problem with the (new) alpha mode settings. But - False - png format can be 24 or 32 bit (i.e. with or without alpha channel. Not sure how you tell photoshop, but in Gimp I just merge image to one layer and remove the alpha channel. Then it automatically exports png as 24 bit without an alpha channel. You can see that both in the export dialog and after import where there's no alpha mode options.
  10. science of texture size

    In addition to the per-file overhead, the multiple texture option also involves more transactions with the database and server. It will also allow finer distribution of avalable texture area between faces according to their sizes (unless you need only fixed size sub-textures. However, there are a couple of considerations that might swing the comparison the other way. You should avoid mixing alpha and non-alpha areas in the same big texture, as doing so will use more data for the latter (32 bit/pixel vs24) and will probably cause alpha sorting artefacts with the textures that don't need alpha channels. Otherwise, it may depend on how your use of the textures is likely to be distributed among multiple objects inworld. You could be downloading multiple redundant texture components in the 1024 if they aren't always going to be used all together. There might also be complications if you want to allow users to change textures (either for you or for the user). Finally, your composite 1024 texture won't be tileable, and tiling small textures can be one way of improving efficiency of resource consumption. Again, that depends on the exact application.
  11. Problem with mesh physics

    Just to add to Aquila's post - one of the 9 materials here is actually only on the back and bottom of the steps. Both these surfaces are hidden and will never be rendered (unless you turn the whole thing upside-down). So you can safely delete these faces, and then you have only the permitted eight. (SL will now import objects with more than eight materials, but it does so by splitting them into multiple objects). More generally, we have known for a long time that Sketchup works in ways that are very problematic for mesh imported to SL. One of the major problems is that it splits things into many small objects as you see here. While it is just about useable for a simple mesh like this, the problems become very serious for more complicated objects. In particular, the splitting up leads to inefficiencies that are punsihed by high Land Impact. It will also lead to problematic LOD behaviour (changes in appearance as you zoom out). So I would very strongly second Aquila's suggestion that you would do well to invest some time learning Blender instead.
  12. Mesh house can't walk into door (again)

    "Is there an easy way to sort the vertice list in a dae file (or in Blender) in an exact specific order?" In Blender, there is a Mesh->Sort Elements menu that offers a few ways of sorting. It does sort the order the vertices come out in the collada file, as used in my recent offset origin kludge (using sort by distance from cursor). Whether that could produce the ordering you need, I don't know. The coordinate sorts are relative to the 3D view. Together with the cursor-relative one, you could achieve some complicated sorts by sequentially applying these, I suppose, but only a few simple ones. Beyond that, I think you have to resort to scripts. I have done some of that for experimental purposes by using R, which is particularly good for large arrays, and has a function library for reading and writing XML. I was just doing the rouding we have discussed, but it gets more complicated for sorting because changing the order of the vertices means you have to change all the indices referencing them in the triangle or polygon lists. If the desired effect is sufficiently general that you could reuse the same script for all dae files, then once the script is written it is simple to apply. Otherwise it's a bit of nightmare.
  13. Mesh house can't walk into door (again)

    In my RL house, all the doors have exactly the same woodgrain pattern under the paint. That's because they are fake embossed hardboard underneath. It makes them look cheap and nasty to me (which, of course, they are). I am trying to decide whether I can afford to replace them with real wooden doors, because they annoy me too much. Nobody else notices. I think the same applies to objects and surfaces in SL. Avoiding repetition, even beyond simple tiling artefacts, can yield great improvement to the critical eye. But most eyes are not critical and you really have to weigh up the cost/benefit carefully.
  14. Mesh house can't walk into door (again)

    You mean the image size you construct the UV map on in Blender etc., as opposed to the actual size of the texture applied? I don't think the size of the former makes any difference. If I remember correctly, the UV coordinates are normalised for upload anyway. There could be a very small effect because exactly matching values after rounding might be more frequent for smaller numbers, allowing more efficient compression, but I doubt that ever has even an observable effect.
  15. Mesh house can't walk into door (again)

    Oh, but all the moss and algae and cobwebs and snail tracks ... :matte-motes-smile: