Maeve Balfour

Nacy: Sorry for my delay in responding (I have been without my internetz for the past week or so, bah!) :matte-motes-sour: Drongle's answer is a good description of my reasonings - and his explanation on the technical issues is far better than I could have worded! Thanks for that Drongle :matte-motes-smile: In essence, regarding the shadow plane I mentioned - by using a separate material zone for it, it keeps the alpha-texture totally separated from the rest of the mesh. By doing so, the alpha glitching is isolated to the shadow material area... Any other material sections on the mesh, IF they use totally different textures, won't be held hostage to the glitching (assuming they don't contain alpha channels). If you take a texture with any kind of alpha channel included, and apply it to an entire mesh, you will clearly see how the alpha glitching can make a terrible mess of things. So in a case where shadow planes (or any kind of transparency effect) are used in a single mesh, materials can be your best friend! Plus in this manner, you can have shadow effects WITHOUT needing individual prims dedicated for the effect (ala the old shadow prim concept from the "olden days" of building). So a big plus in PE savings as well. :matte-motes-smile:

Carrara is quite suitable for SL mesh, and as a bonus it has a built-in Collada exporter as well. (Being primarily a stubborn Hexagon user, I only know the basics of Carrara (to my shame LOL!) even though I have owned it for a long while). However, when I was figuring out my SL mesh workflows, I managed to get my Hexagon .obj files converted to Collada .dae files via Carrara, which is very handy (Hexagon has no such option). Be aware though, that being a quad-based modeler, you will need to convert your quads to triangles prior to final mesh conversion to .dae (collada) for exporting. From my limited knowledge of Carrara, its automated triangulate function is a bit inefficient (it divides each quad into FOUR triangles); I ended up using Blender for this function, as its triangle conversion merely divides each quad into TWO triangles, which results in HALF the poly count as the Collada equivalent. So keep this in mind - for mesh efficiency, it might be worth jumping between Carrara and Blender (model the mesh in Carrara, and then use Blender to convert to triangles; after which you can re-import the resultant .obj file back into Carrara for the remainder of your workflow (UV-mapping, materials etc)). It's definitely NOT as scary as this might sound, though! So yah, if you use a common-sense low poly approach to your mesh creation, Carrara Pro 8 should be perfect for most of your SL workflow. (Not sure about sculpties - although you could possibly create a sculptie primitive inside of Hexagon, and then import that mesh into Carrara for shaping - as long as you don't remove any of the vertices or faces, it should in theory be fine - how you go about converting it to an RGB sculpt map I am unsure of though, short of taking it back into Hexagon for that step). Regarding tutorials specifically for SL, I don't think I have seen any for Hexagon/Carrara, other than a basic sculptie tutorial over on DAZ for Hexagon. But you could use pretty much any modeling tutorials for Carrara/Hexagon, and they would be applicable to mesh building for SL in general - the main thing to keep in mind is that you would be wanting to keep your meshes relatively LOW POLY (I assume most tutorials would not be overly concerned with poly counts, due to them being aimed for meshes to be used in high-polycount 3D rendering). However, the general mesh building theory would still be applicable, providing you stick with a low-polygon approach as you create. Have a lot of fun! :matte-motes-smile:

Long shot here - would it be anything to do with material mapping? If you have more than one single material map applied, mayhaps one of the material maps is being excluded in one of the automatically generated LOD meshes. I have encountered this before when I had problems with a smallish material area on my mesh being dropped out in LOD4 (due to triangle reductions, and the problem material only being a smallish area of the mesh). If the number of materials aren't exactly the same for each LOD, the uploader won't accept it. A sidenote: For your shadow plane (if you aren't doing it already), consider applying a material dedicated to it entirely. For instances where textures use alphas, materials are very handy for separating alpha-textures from the rest of the mesh, and can prevent transparency glitches taking hold. :matte-motes-smile:

Valid points, and ones I will definitely keep in mind when I get around to creating a store (one day, LOL). I love the idea of a small rezzing area for customers, however, I would be concerned about griefers causing problems when I am offline. I know I could set auto-return to a couple of minutes, and mayhaps have a customer group requirement for rezzing rights, but I still worry that determined griefers would manage to take advantage of that. (Having lived next door to a sandbox at one stage, I have seen all the idiocy they carry on with). A possible workaround would be to restrict visitors via age (minimum of a week old or something) via land settings / security system etc... but that would be discriminating against legitimate newbies and give a bad impression. It's sad that workarounds like this are required to prevent the griefer minority from spoiling things for everyone else. But yah, I would definitely consider a rezzing area if I could eliminate the griefer potential for sure.

A bit off-topic here, but I'd just like to mention a slightly worrying trend I've begun noticing with a few mesh creators on the marketplace, without pointing any fingers etc. Mesh in theory is supposed to be less demanding on system resources, due to efficient modeling techniques etc, which I fully support and applaud - plus it is miles easier to texture etc. HOWEVER, I've noticed a trend for some merchants at least to use the sculptie mentality in their mesh techniques - as in, absolutely INSANE amounts of triangles in their AV attachments (clothing etc). They would probably argue that since it doesn't count towards land impact, the PE is irrelevant, but I would think it would cause considerable lag just for it render. I'm talking about clothing meshes (rigged or unrigged) with PE counts in the 80 to 230 range etc - utterly insane triangle counts which all need to be rendered in real time, whether visible or not. When looking at some of these items in wireframe mode, I am utterly floored at the wastage of triangles - the creators clearly have no concept of efficiency in meshwork for realtime framerates. No removal of invisible backfaces, huge amounts of incredibly tiny geometry detail which nobody will ever really see, but will cause lag due to them needing to be processed, often with no LODs (just the full mesh for each LOD) etc. The meshes I am referring to have triangle counts comparable to (and even in some cases, surpassing) the levels of mesh geometry detail I have seen and used for general 3D RENDERING work (NOT realtime rendering). To have this amount of mesh geometry inside of SL is only going to add to the misconception that mesh is bad, causes lag etc. (Not being egocentric or elitist in the slightest here... but I could make equivalent mesh attachments with about 10% of the triangle counts of the worst cases, and at normal viewing distances would look quite comparable in quality (even zoomed in they would look reasonable, with a sacrifice in "curvyness" - but that is the nature of realtime meshes - tradeoffs for performance). There will always be inefficient mesh makers, and no doubt some terrible ones. My main worry is that many creators don't have a clue about mesh making for efficiency, especially for real-time rendering, and just go along their way happily making meshes with insane levels of triangle counts without ever knowing how much of a lag-monster they are producing. I'm not referring to meshes with a little more detail than is really necessary - but rather, the ones with massively excessive triangle counts... the ones that really cause and add to the lag problem. Please note my rant isn't aimed at anyone in particular, but this is a trend which is beginning to worry me.

Yah, the test grid is still there (at least, the last time I looked). Just choose ADITI as your starting grid. Same thing applies - free upload money for testing with. And now that mesh is on the main grid, the test grid seems to be far more stable and reliable as well, in regards to mesh uploading etc. You will probably have to use your world map to find a sandbox (the default location drops you in a strange spot). But easy enough to find one. When you have a location you like, just LM it. Have fun! :matte-motes-smile:

There is a workaround you could probably do to animate a mesh, but keep in mind this is very limited.... Meshes can have up to 8 materials, and each material can have its own texture. This can be exploited I assume to fake a basic animation of up to 8 different frames. In essence... make eight frames of movement using your mesh (by tweaking of arms, limbs etc). ALL these frames of mesh would be included in the one mesh upload, BUT each of these mesh "frames" would have a separate MATERIAL applied. If you used a script to alternate between the texture and a full alpha for each material, you could simulate an animation playing via the texture flipping between visible and invisible. How effective this would be is dependent on how creatively you can set up your mesh frames... but for simplistic, repetitive movements, it would certainly be feasible I think. (All of your mesh frames would share the same UV map, so only the one main texture would be required in addition to the full alpha). Also keep in mind that this method would push up the PE due to the additional complexity of your mesh (in theory by the multiple of how many frames of animation you create, up to a total of 8). So your 4PE Zombie Worm would I guess become 32PE.... so a tradeoff there.... although, I guess you could break up your Worm into components... one main mesh for the static body, and a smaller, lower PE animated mesh for the waving arms. Food for thought (and fun) at least. :matte-motes-smile:

UV-map creation is as much an artform as creating mesh shapes. Usually it is a matter of balancing compromises. Essentially, it's about how and where you choose to make the cuts/seams to flatten your meshes. The goal is to reduce texture distortion as much as possible - however, the compromises often involve awkward seams that can result in visible (or difficult to hide) joins in the textures. So it is often a balancing act in choosing WHERE to make the cuts, and WHEN the texture distortion is acceptable to avoid painful texture seams. In the case you refer to here, with the series of planks, it is relatively easy to define the cuts (on the corners of the thin edges) and lay them out flat, since the cuts are on logical corners of the planks, and the mesh consists of flat surfaces. As such, it's a simple matter to lay them out in the example you mention. If I remember correctly, Chosen's mesh had the bottom face removed, hence his easy-to-visualise UV map... if the bottom face had been included in his mesh, the layout would probably look quite different. In the matter of getting the flattened UV-map to be proportional to the faces, well, that depends on the software you are using. Some software will flatten your UV-maps via an automated process after you have defined the cuts/seams, which makes the task a lot easier... however others require you to do this manually via pinning it flat, and this can often result in a bit of a guessing game. So it all depends on what program you are using. Every mesh is different, and as such the resultant UV-maps will require different approaches. There is no easy, straight-forward answer - it's a matter of deciding where you want to cut your mesh in order to flatten it. I would suggest, at least for relatively simple geometric meshes, to make your cuts in logical places (edges, corners) where texture joins won't matter much (ie: eliminating the need for textures to perfectly align). If you can visualise in your mind where the joins are, when the mesh is flattened, you will be able to know logically what each area of your UV-map represents. And then there is tiling/overlaying repeated faces to better use texture resolution, but that is another subject. :matte-motes-smile:

I think in some cases, the no-mod aspect is used to generate further revenue from existing product lines. I have found a prime example of this with clothing, especially shoes and boots. Being no-mod means the textures and tinting abilities are locked (although mayhaps I wasn't trying hard enough to tweak them!). As such, if you want other colours, you generally need to re-buy the same item again - hence the fatpacks etc. Obviously, the annoying side effect of no-mod is the painful resizing scripts, which can severely limit proper fitting. It is something that has always annoyed me, although I can understand the reasoning behind it from the merchant viewpoint. If the prices are fair, I generally accept it - although at times excessive pricing makes me think it's milking a product for all its worth.

Actually Medhue, if I can briefly correct you in regards to single alphas.... at least with V3 (and previously with V2), and possibly other viewers.... instead of choosing to wear an alpha layer, try ADDING. For me at least, I often stack my alpha layers to let me wear, say, a mesh skirt as well as my boots. Works nicely. I would assume there is a limit with how many alphas you can stack (four I think I remember hearing, though I haven't tested it yet). This also works with tattoo layers as well. But yah, it isn't widely known, which is a pity. Multiple alphas are definitely possible. :matte-motes-smile: I fully agree with your comments about the monumental task it has been for LL to implement mesh to the main grid though. It's a massive step forward in improvement in general, we just have to wait for the rest of the population to accept it (and be using viewers to see it as well). Having worked outside of SL making the occasional items of clothing for Poser usage (3D rendering etc), I can fully understand the complexities (and all the possible combinations) needed to be taken into consideration for morphing meshes to fit various body shapes and sizes. It's not as simple as many assume it will be to implement - and I fully appreciate the efforts behind the scenes to get it working, be it LL or the parametric deformation project. Still, I am looking forward to embracing it when it finally arrives! :matte-motes-smile:

Yah, mixed mesh clothing items are something I've considered for sure, and probably a thing I'll try out eventually... although with separated mesh pieces, I can envisage LOD issues kicking in (with LOD switches at different times between the meshes, due to varying sizes - making it harder to control). For the time being though, I'm mostly focused on just improving my mesh skillsets overall. I guess I'd rather have my skills refined as much as possible before I attempt releasing products for sale... fussiness and perfectionism can be a curse if you want to earn income! :smileyvery-happy: But back on topic... Partial mixes of rigged mesh and mesh attachments is a concept I am exploring. Whether or not it results in a saleable product is uncertain - I guess I am more interested in the creative process than the sales I could potentially make. Must be my artistic side to blame LOL. I am surprised, though, that other merchants haven't already explored this niche potential in mesh. Mayhaps your prodding will result in a change. :matte-motes-smile:

I can understand your frustration with worn meshes (rigged) not being able to be adjusted for body shapes. However, keep in mind that mesh is an ongoing process for LL - eventually, it WILL be possible for mesh to be adjusted for body shapes. It's just a matter of when LL gets an opportunity to implement it with their limited dev resources. I know many creators (myself included) will jump on mesh clothing wholeheartedly once this is possible - the ability for residents to adjust the worn meshes to fit their shapes. For the moment, it's a waiting game, but trust me, we are impatiently waiting for it to be implemented. (Even to the point of some initiating a third-party to work on a solution as an open source project, but that is an entirely different subject). Yah, portional mesh clothing would be feasible as you suggest, but it would be a stop-gap measure. I imagine that, although better, you would still get that "cardboard" clothing look where parts of it will rigidly intersect other sections of it (the upper body section of a jacket worn as an adjustable attachment cutting into the lower section worn as a rigged mesh). Still, it's definitely feasible for sure, especially for worn arm sections in conjunction with an attached mesh upper torso - the combination of the best of both worlds that way. Oh, and for the record - mesh CAN be worn as non-rigged ATTACHMENTS, just like traditional attached sculpted clothing too - fully resizable, BUT it will be exactly the same result - that "cardboard" rigid look. It's only when meshes are worn as RIGGED meshes that you cannot change their shape / size. So don't give up on mesh clothing by any means - we creators are impatiently awaiting the implementation of properly adjustable worn meshes. At that point, mesh will REALLY show its potential. :matte-motes-smile:

Thank you for posting this - I would probably never have seen it otherwise in my part of the world. It made me smile, and it also made me shed a few tears. It makes me realise just how lucky I am in RL, but also, to appreciate SL for how wonderful it can be to those less fortunate. The very end - the meeting in Berlin... and the brief SL dance shot which mirrored the shot in the square, left me with a few happy tears. Very emotional. A positive documentary, definitely worth watching. :matte-motes-smile:

Although I don't have the issues you describe here, I have a method which might be useful as a workaround. Basically, I get annoyed when my customised physics meshes don't properly match my mesh floors (which sometimes results in my AV "walking on air" due to the floor plane sitting higher than the mesh floor). In my modeler AND in the uploader window, my pre-made physics mesh perfectly aligns the main mesh, but for some reason when rezzed the floors are out of alignment - despite my efforts of perfectly matching bounding boxes etc. (Generally this happens if I have a mesh room interior, with most of the physics happening INSIDE the mesh - meshes with exterior based physics are generally fine). Aargh! LOL. :matte-motes-big-grin-squint: Anyways, my workaround is to upload my simplified physics mesh as a mesh in its own right, and the original main mesh I rez as a phantom. I align the two, then apply a full alpha texture to the fake physics mesh. Not ideal, but it works well enough as a functional build. Because the fake physics mesh should already be optimised (low triangle count), there won't be any need to touch the other buttons in the Physics section of the uploader. If you intend on using this method, I would suggest for the main mesh that you create a basic three-vertex triangle mesh, which you nominate as the physics hull in your main mesh (the one which will be phantom) - it will save on PE, and most likely negate the extra PE cost of the fake physics mesh when the two are combined. For the fake physics mesh, in the uploader, use it as is for the physics hull (since it should be optimised for physics already). For the LODs section, use the three-vertex triangle for LODs 2, 3 and 4 - it's LODs won't matter, since it will be invisible in usage. Using the triangle for the lower LODs will usually result in a major reduction in its PE cost overall. So yah, my method is a (not ideal) workaround that I use sometimes, and might be useful to get around the problem you describe. :matte-motes-smile:

Hmm... I guess I should prepare myself for a possible smack across my knuckles then, since I reported about a dozen spam threads here in the mesh forum yesterday... It's a pity we potentially risk being punished for being vigilant about the spammers. :matte-motes-sour:

Yah, I had the pleasure of seeing your build in Aditi earlier today, Arton - a lovely example of tight mesh work and texturing (and the LOD held up very nicely, even from over on my side of the sim). Gorgeous shots, by the way! (PS - Did the sandbox guy come back and annoy you after I logged off?) :smileyvery-happy:

Have you gone into the edit menu when you rez the mesh, and adjusted the physics properties? (This is the standard build menu in SL, NOT the uploader). Change it from its default to either Convex or Prim physics (I can never remember which one it is LOL). That should fix your issue I think (you are probably being blocked by the bounding box of the mesh itself, with its default physics when rezzed. :matte-motes-smile:

Thanks for the thought-provoking posts in this thread, Chosen... although I am already fairly experienced with UV-mapping etc, your methods have given me even more ideas in this regard to experiment with, especially for optimising texture efficiencies. :matte-motes-smile: My own frustration has tended to be the limits of mixing baked AO with detailed surface textures... as in, they can't be used over large areas without the texture becoming blurry/pixellated - and obviously, tiling it won't work due to the baked-in AO. Currently, I am exploring things similar to what you mentioned - using separate mesh planes for the faked AO, and utilising material mapping to allow their shadows with alpha to be applied separately to the main textures (tiled/non-tiled etc). Obviously, the shadow planes need to sit out slightly from the main mesh surfaces to render correctly, but works sufficiently well - the main benefit for me is that it allows me to use relatively few, high quality textures in a large build (mixing them up via tiling, rotation, diffuse tinting etc), in conjunction with a relatively low resolution fake shadow on separate planes (which can also be repeated, if UV-mapped with a bit of imagination). Not technically correct lighting, but sufficient for some nice results - and using mesh planes for the shadows definitely saves in regards to doing the same with the old prim-shadow method. Probably not the most perfect way of doing things... but for my usage, it seems to work quite nicely. Thanks again for your valuable insights - much appreciated! :matte-motes-smile:

From what I can ascertain in the Prim Oven listing on the marketplace, it operates in a similar method to Sculptcrafter (which I have used in the past).. in that it gets you to create a build via its product prims, and it converts the result to a sculptie. That same kind of building technique can be replicated directly inside of Blender (or any other 3D modeler), via primitive shapes. You could just create basic primitive cubes, for example, and shape/size them accordingly, and build up your project like that (the basic modifier tools (size/rotate/move) tend to be the same from program to program - and pretty much the same as those in SL - so if you can shape and build with prims in SL, you should feel right at home playing with primitives inside a 3D modeling program). This can be handy for creating complex builds from scratch, however, it would be strongly recommended that once completing this step via primitive building, that you then optimise the resultant mesh (removing hidden faces, welding/merging vertices etc). This really isn't as scary as it sounds - just a matter of getting familiar with some of the basic building tools in your 3D modeling program of choice. The end result is that you have as efficient a mesh as possible, which will give a lower PE (land cost). Cube primitives are probably the best shapes to use (fewer faces etc) - primitive spheres and cylinders would be far more costly in face count, which would penalise your mesh PE. Jump in and have a go - I am sure you will get addicted to it quickly :matte-motes-smile:

Yah, it's silly how Aditi dumps you in that spot when you land nowadays. All you need to do, is open up the world map view, and zoom out... you will be able to see sandboxes in nearby sims (the Aditi grid is pretty small, so it's not hard to find them). I think the issue of the strange landing point is due to the Aditi grid being rearranged... when I first started visiting Aditi many months back, I was dropped in the same silly location. When you find a sandbox, be sure to LM it for next time! :matte-motes-smile: EDIT - LOL, too slow! :smileyvery-happy:

I don't work with 3ds, but my general workflow should translate anyway... I generally create my full detail mesh intended for LOD1, and UV-map it etc as per normal. For the lower LODs, I simple reduce the triangle counts in the original mesh, trying as much as possible to keep a recognisable shape - the further out you are, where each LOD kicks in, you will see less detail, so you can trim and merge triangles a fair bit. This is still tedious, but not as bad as redoing the mesh from total scratch each time (at least for me, anyway). Regarding the UVs... What I do is use the existing UV layout of the main LOD1 mesh as a guide (it's easier if it already has a texture made for it for visibility), and just create the UVmap for each LOD mesh by overlaying it. If the lower LODs are reduced in triangle count, it isn't too much a hassle to UVmap them. You won't get a perfect fit over your texture UV, but near enough is often good enough for long distance viewing. You'd be surprised at how much a good texture will "fill in" the missing geometry details for lower LODs at distance. Personally, I find it definitely worth the hassle of manually creating the LOD meshes and their UVs to retain complete control of how they deform over distance (instead of the totally random auto LODs generated by the uploader). :matte-motes-smile:

Long shot.... Have you tried just using the current Viewer-3? I'm thinking that mayhaps the mesh project viewers are no longer current, since V3 is able to work with mesh now as standard. Also... by chance, does your physics mesh have materials mapped to it? This could possibly be a problem if it does. In the past, if I used any LOD meshes with materials assigned, and they don't match the main mesh in regards to NUMBER of materials assigned, the uploader won't accept them... Although unlikely, this might also apply to physics meshes as well, IF they have materials assigned to them (physics hulls normally don't have materials assigned at all, and the uploader accepts them - not sure if it makes any difference if they DO have materials, but worth mentioning anyway). :matte-motes-smile:

Thanks for the info, Drongle, it helps me get my head a bit more around the complex ways physics works with PE. Generally, I deliberately keep my physics hulls as simplified as possible to reduce their triangle counts, so I am on the right track there... and I avoid curved surfaces for the same reason. Your mention of smaller triangles in physics being more costly is a good reminder for me (I have read that before, but I forgot that important factor, so thank you). Lots of handy things for me to digest :matte-motes-smile: For personal usage, I will still probably use my separated physics hulls (with alphas) to get better aligned physics in my builds... or at least until I figure out how to get consistent results which avoid the "floating on air" issue I have mentioned previously. Regardless... I am happy with my own PE results, so in the end that's what matters for me. :matte-motes-smile:

Indigo: Hmm... thank you for your suggestion. I had never considered adding to the Wiki before, since I am still much a learner with mesh. However, if you think my tips are valid, sure, I'd be happy to submit them sometime (although my separated physics hull idea is "under review" currently! LOL). Do you have a link for the relevant Wiki page? (I am so sloppy with my browsing habits - I keep forgetting to bookmark stuff!) :matte-motes-smile:

Arton... Hmm, regarding your question about decomposing... it's quite possible I did what you suggested, unintentionally (it was in the early hours of the morning when I was experimenting, so I was probably half awake at the time, and could have done something like that without realising it)... If so, that would skew the results, so in hindsight may not be a valid 'scientific' analysis. Also, I must say that I am still figuring out parts of the uploader, so I might be overlooking important steps in the procedures. I might be making things heavier in PE than they should be due to this, and that my "discovery" might actually be due to me accidentally doing something that I should already be doing in the uploader window LOL. Ah, gotta love it! :smileyvery-happy: ..... Getting a bit off the track of the original OP, but I'll ask anyway since this subject has taken off: I have found that by using a separate mesh for fake physics, I have effectively eliminated my problem of my optimised physics hulls not accurately matching my main mesh (the "walking on air" effect). Now, for a large mesh structure, where you really only need to model physics for anticipated floor traffic (assuming people won't be flying around etc), I would think you would only need a physics hull for floors, walls to about AV height, gaps for doorways, ramps etc.... in other words, you could probably skip modeling physics planes for high areas where AV traffic is not likely. So... if a separate fake mesh for physics was in this way smaller (similar ground area, but nowhere near as high as the much taller "real" phantom mesh), and it having a smaller bounding box area due to this... would this help result in a lower PE? (Compared to a combined physics hull which I assume would need to have the same bounding box dimensions as the target mesh). Smaller meshes as far as I know generally have a reduced PE compared to larger ones (ie: identical in triangle count etc)... so my theory is that a smaller "fake" physics mesh might be a PE saver in this regard when compared to a physics hull of larger dimensions, especially if you can eliminate a lot of triangles from the higher areas. Please feel free to shoot me down if I am incorrect with my concept LOL :smileyvery-happy: ..... And back to the OP topic... yah, as I mentioned originally, meshes have a lot of potential for houses, especially if you build in ways to make effective use of PE. :matte-motes-smile: