Mesh UV Mapping?

[Alisha Matova]

There are a lot of ways to go about this. I have another suggestion. More a global idea, than specifically aimed at this frame. Since SL is full of textures, why not uv map in a way that alowes us to use them.

A simple example would be materialing and uv mapping a mesh cube to take textures like a prim cube would. Extrapolate that into a house UVed to accept normal textures, and it behaved like the prim houses everyone is used to(texture wise).

Of course in a complicated build this method is trickier than clicking the auto uv map button, but, will make for a much more useful in world object.

The only downside of this method, baking shadows or rendering textures in your modeler gets confusing.

My two cents, though I don't mean everyone needs to redo their uv mapping. Just an idea I have been playing with.

[Drongle McMahon]

You are absolutely right. This is important for two reasons; it means you can use small tiled textures, so saving texture dowload lag, and it means you can reuse the same textures on many different meshes, with even greater saving. It is sometimes hard to resist using baked textures which can look a lot better, but they generally have to be bigger and different for each mesh. I generally try to make UV maps that will work either way; hard work, and a compromise, but worth it in the end. Then the type of texture used can be chosen according to circumstances. I suppose I could make two models with maps optimised for either method (doubling upload cost :matte-motes-sour:).

[Sae Luan]

I am no where near advanced enough in this stuff to do something like that, but if I was, I would do it in a heartbeat.  I prefer to make things my customers can get a lot of use from.  

[Nacy Nightfire]

That's a useful idea, but the op began the thread expressing she's a newcomer to UVing. In short order, when she's more comfortable with the process, the idea of UVing and isolating material groups expressly for the purpose of swapping out textures inworld will follow naturally.

I don't run a business here, but if in gifting my meshes for friends to use, I'd provide them with a greyscale ao image or bump/ao combination from the bake.   Most folks are pretty comfortable with basic graphic editing programs and can export their desired textures if permissions allow and use the greyscale "overlay" or another blend mix to add in the ao detail  to their texture and upload it back to SL for their use on the mesh.

[Chosen Few]

---

Alisha Matova wrote:

Since SL is full of textures, why not uv map in a way that alowes us to use them.

---

That was precisely why I kept the UV layout from the torus, in my example.  Any existing generic texture could be applied to it, without having to change a thing. This made for a good "beginner level" example. 

Were it a more advanced lesson, or were I making the same model for any of my own work, I'd never leave it like that.  I'll explain.

This subject may seem like a logical no-brainer, at first glance.  As you said, Alisha, there are thousands upon thousands of existing textures out there, so sure, make models that can use them.  That's only fitting.  But upon closer examination, the concept is riddled with problems.

As with so many "which path should we take" questions, it really boils down to what our goals are for the given task.  If the goal is just to allow people to mix and match everything with everything else, at their leisure, just as has always been the case in SL, then sure, be as generic-friendly as possible with all your UV's.  But if you're gonna do that, you might as well just continue using prims and sculpties, because here's going to be little if any benefit for you in using mesh.

On the other hand, if the goal is to do the things that mesh is actually good at, like dramatically lowering rendering costs of your models, or creating things you could never make with prims or sculpties, then there's no sense at all in being so inefficient with your UV's. I'll take these principles one at a time.

First, let's talk about render costs.  I'm going to largely ignore the subject of polygon efficiency for the moment, and just focus on efficiency in UV'ing the polygonal models we're already making.  We all (hopefully) know by now that prim builds are relatively poly-heavy because they nearly always have hidden faces, and sculpty builds are quite poly-heavy just by virtrue of the fact that they are sculpties.  I'd like to think eveyrone involved with mesh is striving to do better than that.  Since the subject at hand is UV'ing, let's focus in on texture efficiency.

The single biggest reason SL runs as slowly as it does is because of texture inefficiency.  It's not uncommon for a scene in SL to contain tens of gigabytes worth of texture data, while most video cards can only handle a few hundred megabytes at a time, at most.  Hence, video cards choke, and SL's frame rate for all users remains at a tiny fraction of what it otherwise would be. 

With that in mind, it's really not in the community's best interest to encourage people to keep using the thousands of existing inefficient textures that are out there.  The whole point of mesh is to do away with exactly these kinds of limitations, to improve performance as well as aesthetics.

People selling those textures will likely choose to disagree, of course, as well may many of their customers.  But the self-interest of the status-quo-invested doesn't change the mathematical principles or the cold hard computer science involved.  Lag is lag, and the factors that contribute to it are the factors that contribute to it, period.

Second, and far more fundamentally, it's possible to make things with mesh that you could never make with prims or sculpties.   Because of this, there's no escaping the very real fact that with a great many models, it's simply not possible to UV them in such a way as to allow the use of generic textures.  For something like that picture frame, or an exceedingly simple prim-style house, or a the equivalent of a low-prim vehicle, etc., sure, it could work.  But it's important for everyone to understand that those kinds of models are just the first water molecule on the first snowflake on the smallest tip of an icerbeg the size of ten galaxies.

A lot of people are just kind of in "do-over mode" right now, looking at ways to remake the same stuff they've already made in SL, only with mesh this time instead of prims or sculpties.  That's fine, as a starting point.  But once people get past that, and start to explore the other things it's possible to do with mesh, they'll quickly see that 99.99999999% of mesh models cannot (and should not) be compatible with the kinds of textures we've all been using in SL these past years.

An example we're all already familiar with is the base avatar mesh.  We've all seen its UV maps a thousand times (the skin/clothing templates).  There's no way we'd ever be able to make that model compatibile with textrues that were meant for prims.  It's just not built that way.  Neither are most mesh models you'll ever encounter, even ones that are far simpler than the avatar.

Mesh opens up a new and better world of possibilities, both aesthetically and technically, for everyone.  In the words of High Aldwin the wizard, "Forget all you know, or think you know."  Clinging to the old ways of thinking as an SL user doesn't really jive with what mesh is all about.  It's time for SL content creators to expand their thinking, to join the larger collective of 3D artists.  

 

It's also worth noting that there's a new business opportunity here.  If you're selling a model that doesn't have a prim-like UV layout, the sky's the limit for the amount of profit you can make on that one model.  After all, why stop at selling it with just one paint job, when you can offer dozens of texture packs for it as well?  You could do different color schemes, different lighting schemes, bakes of different kinds of materials, etc., etc., etc.  This does several key things for your business:

 

• It keeps your customers interested, and in the habit of coming back to you.  People already routinely come back to their favorite clothing designers, to see if that blue dress with yellow flowers is available yet as a yellow dress with blue flowers.  Now they'll come back to you to see if that brick-front colonial home is available with cedar siding yet.
• It curbs texture theft.  No longer will you need to worry about your full perm textures getting out, and being used for lord knows what, by people who didn't buy them.  If a texture only works on your model, it's of no use to anyone who hasn't already bought the model.  Let it run grid-wide, who cares?  They still need to come to you to be able to use it.  Even if you lose money on the stolen texture, at least you made something on the model itself.
• It gives you a chance to explore your creativity as a texture artist, in away you otherwise might not have.  Let's face it, texturing prim and sculpty models well is a tremendous PITA.  We've all gotten so used to it over the years, we tend to forget how horribly time consuming it really is.  Texturing a model you've made "your way", in a 3D modeling program is damned sight easier and is inherently MUCH faster.  You could turn out 55 different varieties of that shiny new sports car you just made, in less time than it would take you to texture it once if it were made the "SL way".
• It allows you to "sign your work".  Leave a small portion of the texture canvas unused, and you can put your name or logo on it, so people know it came from you.  This isn't erase-proof, of course, if it's downloadable, and it won't necessarily be practical on smaller textures, but at least the option is there.

OK, so what about the people who want to buy a model, and then retexture it themselves?  No problem, just include the UV map with the purchase (or charge a little extra for it, if you prefer).  If you want to go the extra mile, you can even include a shading map, just as sculpty artists often do.

 

 

 

 

 

 

As for that picture frame, here's what I'd do with it, if I were making it for one of my own builds: 

1.  I'd resize the faces across the canvas, to ensure even texel density on all.  The side faces have far less surface area than the top and bottom faces, so they should occupy proportionally less canvas space.  This will not only keep the texturning on the sides from looking squished, it will also allow for far more detail on the larger faces.

2. I'd delete the bottom faces.  When the frame is mounted on a wall, those faces will be the back of the frame.  No one will ever see them, so they're just a waste of resources.  Their removal would not only lighten the polygon load, it would also allow for even more texture canvas space to be devoted to the front of the frame.

 

[Sae Luan]

After all the comments on this thread and advice, I'm going to redo the frame completely.  I never thought my thread about UV mapping would teach me a better way to model the frame itself lol.  It's great that SL has so many people so willing to help others.  Thanks again.

[Drongle McMahon]

Hmm. I' don't think I understand what you mean by "texture efficiency". It seems to me to point in the opposite direction, although that might be my misunderstanding and/or ignorance. Your bullet points enumerate most of what makes baked or other non-generic textures attractive. However, this is exactly what I try to resist, to avoid texture lag. 

I made two buildings during the beta, an underground chamber witha pool and a much larger gallery. For the underground pool, which only had inside textures because it was buried under a grass mound, I used specific baked textures. That was six 1024x1024 textures. I used as much stacking of UV maps as I could given the limited symetry of the chamber, but still the textures had barely acceptable close-up resolution.

For the gallery walls, much bigger, I used four materials all textured with tiled 256x256 or 512x512 textures. The same set of textures was used on all the five different (but repeated) meshes that made up the gallery walls. Of course the lighting effects were not much good, but the surface detail was fine despite maybe ten times the total surface area of the chamber and less than a sixth of the total texture data.

To texture these with baked textures, each of the wall components would have required its own different set of 1024x1024 textures. I think the total would be about 16, exploiting symmetry where possible. That's more than 16 times the total amount of texture data. To get the same closeup detail would need 2-4 times that much. That appears to mean the generic texture approach gives a huge saving in texture download time, cache use and gpu memory (I think? Don't know the internals well enough*)

Now each technique certainly has it's place, but  I would expect that filling sims with a few hundred meshes each with its own set of several unique 1024x1024 textures would surely be disatrous for texture lag. I will admit that without quantitative data the argument is insecure, but my worry is that this would give mesh a bad reputation for, not from the geometry, but from the associated expansion of texure data in a mesh scene. That is why I have striven to make UV maps that can be used with generic textures.

The doors and windows illustrate the dliemma. The doors look so much better with a baked textures that I used them. The underlying woodgrain is a 256x256 texture, which is also used for the window frames, but the doors use three 1024x1024 baked textures based on it. For the 30 windows, the solid frames are replaced by small alpha textures at the lowest LOD, the only way to get acceptable PE.  Apart from those, there is just the 256x256 for the woodgrain and another for the glass, re-used on all the windows. To give these baked/unique textues would mean at least two 512x512 and one 1024x1024 textures (three window shapes/sizes). That would be twelve times the data used as they are. It is a huge sacrifice in appearance, as they look much better with baked textures. Nevertheless, I suspect this sort compromise might have to be made often to prevent mesh becoming an unacceptable source of lag.

*If you use the same texture on multiple meshes, does it only need to be in gpu memory once, or is it replicated for each? And if it's tiled, is the tiling implicit, or does the gpu actually replicate it to fill the needed area? I hope the first alternative applies for both questions.

[Chosen Few]

There's going to be some variance, from model to model, of course.  For larger models, it won't always be possible to avoid tiling a generic texture.  But we have that same issue with prim-builds, too, so things certainly won't get worse, in that regard.

In other platforms, we solve that issue with light maps, small secondary textures which dictate how much light is reflected off each point on an object's surface.  Each model has two UV sets, one for the diffuse texture, and one for the light map.  In most cases, the light map just needs a few pixels per face, since the shading gradients can be interoplated, so the light map texture itself can be really tiny.  The diffuse texture can be tiled as much as you want across the primary UV set, and it won't affect how the light map gets applied.  Shadows stay where then need to be, regardless of whether the diffuse texture tiles once or a hundred or a thousand times.  You can even animate the diffuse texture without moving the shadows (or vice versa).  Multiple UV support rocks.

Hopefully, we'll get that technology in SL one day.  Until then, we do have a few options of trickery we can employ.

One option is to use shadow planes, in the same way we currently use shadow prims.  For a simple example, say you've got a wall with a window sill sticking out of it.  Obviously, there should be a shadow underneath the sill.  If you want to repeat a small texture across the wall surface, you can't bake that shadow into the texture.  But what you can do is add a small polygonal plane, under the sill, just in front of the wall surface, and you can put a translucent shadow image on that plane.  Because we can apply multiple materials to a single mesh, that plane could be part of the same mesh as the rest of of the wall, and there won't be any alpha sorting issues.  The 32-bit shadow texture won't interfere with the 24-bit wall texture.  Or, if you prefer, it could just as easily be a stand-alone secondary mesh, so you can adjust it in-world to your liking.

We do this all the time with prim builds.  How many times have you put an extra prim underneath a chair or a table, to sit just above the floor, for the shadow?  Probably more times than you can count.  The only difference now is you can use a 2-polygon plane (or even a 1-polyon triangle) instead of a whole cube, so you eliminate five unnecessary sides, the unnecessary render passes that go with them for their transparency, the unnecessary transparency texture itself that you would have put on them.

If you examine just about any prim build I've made in SL, you'll find lots and lots of such shadow prims all over the place.  I'll likely be using lots of shadow planes in exactly the same way.

Another way to go, which will work in many circumstances (but not all), is just to be clever about how you distribute your UV's themselves. Let's revisit that wall example. Say I want to use this small plaster texture to cover the whole thing:

It's only 128x128, nice and tiny.  Needless to say, from the sizing of the details that are in it, I'm going to have to repeat it quite a few times to cover the whole wall.  That's easy, but what about that pesky window sill shadow?  If I add that to the texture, I get this:

Clearly, I can't tile that across the wall?  So what do I do?  The solution is I mount both images, on a single canvas, and I let the UV's do the work that UV's are good at, to distribute them.  Check this out.

Here's my wall:

 

Now here's its polygon configuration:

 

 

Note that extra quad underneath the window.  (The window sill is a separate object, by the way, but it doesn't have to be.)  That quad is gonna be really important in a minute.  Before we get to that, let's look at how I'm arranging the two images on the texture canvas:

 

This is a 128x512 canvas, with a total of five tiles on it.  The top tile, quite obviously, is the version of the texture that has the window sill shadow on it.  The bottom four tiles are all repeats of the sans-shadow version.  I set it up this way, knowing that the wall was 4M tall, and that I wanted 1 repeat per meter.

With that in mind, here's how I'll UV it.  Rememer that extra quad underneath the window sill.  That quad will occupy the top 20% of the canvas.  It'll get the full width of the canvas, but only enough height to cover the one instance of the texture that has the shadow on it.  The rest of the wall will cover the bottom 80% of the canvas.  But it can't just be the width of the UV canvas.  The whole wall is 8 times as wide as that one quad.  So, to keep everything proportional, the texture should repeat 8 times horizontally, everywhere except on that one quad.  So, here's my map:

 

Each of the heavy gray lines is a full UV tile.  You can see the extra quad for the shadow sitting at the top of tile primary tile, just as described above.  The rest of the wall spans the width of 8 tiles, and the 80% of the height of one.

Alternatively, I could have left it at one UV tile width, and just used the in-world repeat settings to make it repeat 8 times.  Either way does the same thing.  Unless specifically directed otherwise (which happens on some projects) my personal preference is always to do it directly in the modeling program, rather than after the fact in the destination platform.  It's just faster.

And here's the wall, with the texture applied:

 

The shadow is right where it's supposed to be, the borders between the two texture sections are totally seamless, and the level of detail across the entire wall is superb.  And that's just with a 512x128, which consumes only 256K of texture memory (equivalent of 256x256).  If the wall were twice the height, I could simply make the texture 1024px tall, and I'd still be using a relatively small image, to get the exact same level of detail.  The width of the texture wouldn't need to change.

Further, I could put in as many additional windows as I want, and as long as no two of them are less than one UV tile apart, the texture tiling would remain perfectly seamless.

Now, obviously, this was a very overly simplistic example.  But it also had a very overly simplistic solution.  There are plenty of other clever UV tricks we could throw at a more complex problem.

Will you ever be able to apply a single texture to an entire building?  Probably not.  But you can't really do that in any game engine either, even with light maps and such at your disposal.  There are always going to be SOME limitations.  But those limitations are a hell of a lot fewer and futher between, and way less stringent, with mesh than they are with prims or sculpties.  We can now achieve the aesthetics we want, with far less overhead than prims and sculpties ever afforded us.

That's for large items like walls.  How about smaller ones?  Well, when a single texture canvas inherently has more than enough space for all the parts, in a model, the efficiency will be extreme.  A single 512x512 can be more than adequate for the entire body of a car, for example, if the model is well UV'ed.  Sculpty cars and prim cars, tend to have lots of unique texrtures, that they just wouldn't need if we were able to control their UV's.

For even smaller stuff, like avatar attachments, the savings simply can't be overstated.

 

Ideas starting to buzz around in your head now?  I sure hope so.

[Drongle McMahon]

Ah. I guess I was essentially talking about about the alternatives of with/without lighting detail etc., thinking that most prims things don't use them because of the texture proliferation. In fact these cause texture proliferation whther they are on mesh or ordinary prims, and if you are going to use them on both, then the mesh win because the flexibility of UV control gives greater effiiency. UV mapping allows greater efficiency of textures with mesh than with prims, for the same amount of unique lighting effect etc. So the threat of lag comes from including these details, whether on mesh or prims, and the threat is greater with the prims than with the mesh. OK.

Using the UV map extending outside the unit box to achieve tiling, as in the wall horizontally, is very nice. Explicitly stacking UVs  achieves the same effect, even more flexibly as far as texture use is concerned, but costs a lot of PE as you have to have more triangles and seams. More work too.

However, you still use four times the texture area compared to the wall without the shadow. Also, if I made the wall with four box prims, could I not get exactly the same effect by using exactly the same texture with appropriate offset and repeat settings*? (Sorry, that's probably an unfair question, as it would likely be untrue for more complex, realistic cases).

There is a materials project wishlist thread where I added a laymans version of what you call a light map. Meanwhile, yes, the alpha overlay panel is a great way around that, although it does mean extra geometry. I will certainly use that (if I ever get the time again). I am sure you could add to the wishlist, although it may never be read where it matters. (The trouble with materials is that they will mean more and more single-use data to dowload).

* 2x0.8 offset 0,0.1 for the left side; 5x0.8 offset 0,0.1 for the right; 1x0.2 offset 0,-0.4 for under the window; 1x0.6 offset -0.1 for above the window. (That took me longer to work out than doing it your way though. More important, fixing it in the uv map prevents a client messing it up, as does having the wall in one piece?).

[Chosen Few]

---

Drongle McMahon wrote:

 

However, you still use four times the texture area compared to the wall without the shadow. Also, if I made the wall with four box prims, could I not get exactly the same effect by using exactly the same texture with appropriate offset and repeat settings*? (Sorry, that's probably an unfair question, as it would likely be untrue for more complex, realistic cases).

---

 

Sure, you could use four cubes to get the same effect, and you'd be able to cut the texture size in half.   But you'd also be expending 432 polygons instead of just 10, not to mention 4 full prims instead of whatever fraction of a prim a 10-polygon plane comes out to for PE.

I'm not sure exactly where the tradeoff is between texture memory considerations and polygon processing considerations.  But I have a hard time assuming merely doubling the memory usage from 128K to 256K is going to be a bigger performance hit than multiplying the poly count by a factor of 40 or more.  Obviously for this simple example, the difference for each is so small it's impossible to measure the real impact on performance.  But as you scale up to more complicated examples, I do think the low poly count is likely to trump the relatively slight increase in texture memory consumption.

Also, in a great many models, especially ones that aren't so neatly rectilinear, the texture usage could potentially be far less on a well UV'ed mesh model than on a prim model of similar design.  In those cases, you get potentially get a triple win: less polygons, less texture usage, and often less PE to boot.

Plus, if nothing else, it's just a heck of a lot faster to drag UV's around a canvas than it is to plug numbers into SL's editor.

 

---

Drongle McMahon wrote:

Using the UV map extending outside the unit box to achieve tiling, as in the wall horizontally, is very nice. Explicitly stacking UVs  achieves the same effect, even more flexibly as far as texture use is concerned, but costs a lot of PE as you have to have more triangles and seams. More work too.

---

 

For a case like the example, I wouldn't want to stack the UV's.  You'd have to have at least 8 times as many polygons to make that work.   There's no way to justify that.

Where stacking does come in really handy is on models that already have to have higher poly counts, and/or less uniform distribution across the texture canvas.  Cars are easy examples for this.  Usually, the paint job on a car is going to be symmetrical.  So, right away, you can cut the texture size in half. Just flip one side's UV's over, and stack them right on top of the other side.  Each tire is going to look the same, so you only need one instance of the tire on the canvas.  Ditto for both front seats. The savings can be enormous, when you hunt down every part that can share canvas space with another part.

You can sometimes use this same strategy, to a degree, with a prim car or a sculpty car, but not always.  And, as we discussed the prims and/or sculpties are going to have a higher poly count than the mesh.

 

There's also another benefit to clever UV'ing that we haven't discussed.  You can use a single texture on multiple models (or multiple parts of a single model), and each one can look like it was uniquely textured.  As an example, here are some super low poly asteroids I made for a video game a couple years ago:

 

Each one looks like it's got a custom tailored texture on it, but really, they're all using the exact same texture.  They're just using it in different ways.  By rearranging the UV's differently on each asteroid, the pattern of craters, ridges, etc, becomes entirely different on each model.  So, even though they've all got the same basic mesh topology, give or take a few polys here and there, and exact same texture, each one looks entirely unique. 

There are only three in the picture, but I could do 300 different ones, all using that same texture, and you'd never know they're not unique.  Imagine an entire rock garden in SL, with hundreds of unique rocks, utilizing just a single 256x256 texture.  That's something you could never ever achieve with prims or sculpties, but you can do it very, very easily with mesh.

Why stop at rocks, though?  You could do the same thing for a forest full of trees, or the stone blocks of a castle wall, or a range of distant mountains, or an assortment of giant snowflakes, or the wings of a flock of butterflies, or whatever else you could think of. 

There's no end to what can be acheived, simply, effectively, and FAST, when the old constraints of SL are left behind.

 

(Did I mention it's fast?  Yeah, I think I said it's fast.  How fast?  It took me less than five minutes to mak the whole batch of aseroids.  About three minutes worth of modeling, a minute or two of UV'ing, and another minute or two to whip up the texture in Filter Forge.  Done before breakfast, and paid for the day.  Can't complain about that!)

 

 

---

Drongle McMahon wrote:

 

There is a

materials project wishlist thread

where I added a laymans version of what you call a light map. Meanwhile, yes, the alpha overlay panel is a great way around that, although it does mean extra geometry. I will certainly use that (if I ever get the time again). I am sure you could add to the wishlist, although it may never be read where it matters. (The trouble with materials is that they will mean more and more single-use data to dowload).

---

Thanks.  I went ahead and added my small assortment of must-have items to the list.

As for the increased downloads, I'm not terribly concerned about that.  The amount of data in question can be really tiny, even for everything on my list.  Shader materials themselves are parametric, so all you need is a small list of values.  Things like bump maps, spec maps, and light maps can be capped at 64x64, just like sculpt maps, and they'll work just fine in nearly all cases.  Normal maps will sometimes need to be bigger, but considering the kind of savings discussed above, I'm still confident that in the hands of any intelligent user (which admittedly may be asking a lot in SL), we can still come out far ahead of how things have been up until now.

 

---

Drongle McMahon wrote:

 

* 2x0.8 offset 0,0.1 for the left side; 5x0.8 offset 0,0.1 for the right; 1x0.2 offset 0,-0.4 for under the window; 1x0.6 offset -0.1 for above the window. (That took me longer to work out than doing it your way though.

---

Yup, that's exactly the kind of math I REALLY hate doing.  Had to do it every day for years when SL content was my full time gig, so it did get to be second nature, but good lord, does it disturb my calm.

 

---

Drongle McMahon wrote:

More important, fixing it in the uv map prevents a client messing it up, as does having the wall in one piece?).

---

Yeah, that's always in the back of my mind, which is one reason I do prefer to UV it, rather than parameterize it in the destination platform later.

There are two definitions of "client", and both can potentially mess it up.  There's the technological kind, which is the viewer software, and there's the human kind, which is the customer.  Both tend to really love to destroy anything that is left breakable.

Of course, client software could probably bork a UV map as easily as it could bork the parametric data, through a botched download or whatever.  But at least if the original model has all the needed information, it can easily be put back.  If you're relying on the destination platform to remember things like repeats and offsets, it can be awfully time consuming to fix stuff when it breaks.

As for those pesky human customers, I'd rather not give them enough rope to hang themselves, when and if I can help it.

[Drongle McMahon]

"You can use a single texture on multiple models (or multiple parts of a single model), and each one can look like it was uniquely textured. "

Eureka! The uploader can do this for you! And I thought it was a bug! Silly me. :matte-motes-grin:

[Maeve Balfour]

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: