Mesh house can't walk into door (again)

[Drongle McMahon]

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.

[Chic Aeon]

Yep that is what I meant. Thanks.    

[ChinRey]

---

Chic Aeon wrote:

Would there be a "server load" advanatage to stacking the UV map all onto one texture plane rather than making them nice and neat in the manter you would for baking?

---

Usually yes but not always. It's all about how the compression algorithm works and that can sometimes be hard to predict for a human mind.

There's a practical side to it too though. If you place the windows side by side on the UV map like Aquila suggests, you can always change your mind and Add Drongle's snail tracks later. If you stack them on top of each other, they will always have exactly the same texture.

Edit: Special question for Drongle: Is there an easy way to sort the vertice list in a dae file (or in Blender) in an exact specific order? There should be quite a lot of LI to save that way but it may take more work than it's worth.

[Chic Aeon]

I almost always map (this is for baking here not tiling textures) so that the pieces if woodgrained or pattern each have a different look. In the real world that is most likely the way things would look. In my last project though I was trying to get  a LOT of information on one texture plane and so I matched the drawers (all with the same woodgrain).

 

It doesn't look bad really; most folks probably wouldn't notice. I told myself it was OK as this wasn't actually supposed to be "wood"  but "laminate" and that the producer of said article may very well have only one drawer pattern  LOL.  Sadly that is probably true.   If I CAN though I like to vary things. And that was a good comment on the overlay or side by side mapping for tiling textures. I do that for glass sometimes and it WOULD be better to use project from view rather than project from view (bounds) and then stagger the pieces somewhat so that they wouldn't all match.

 

I'll have to remember that next time it comes up .

 

I am to BED.

[Drongle McMahon]

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.

[Drongle McMahon]

"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.

[ChinRey]

---

Chic Aeon wrote:

I almost always map (this is for baking here not tiling textures) so that the pieces if woodgrained or pattern each have a different look. In the real world that is most likely the way things would look. In my last project though I was trying to get  a LOT of information on one texture plane and so I matched the drawers (all with the same woodgrain).

---

It is always a question of cost-efficiency - cost both in terms of time spent and LI/LoD/lag - and I think that decision ahs to be made on a case-by-case basis.

One technique that can sometimes give the best of both worlds, is mirrored UV maps.

[ChinRey]

---

Drongle McMahon wrote:

In my RL house, all the doors have exactly the same woodgrain pattern under the paint.

---

I remember a BBC program where Laurence Llewelyn-Bowen demonstrated how wallpaper makers used patterns deliberately made to look random. That is the secret behind good tileable textures and the reason why there asre so few of them.

The principle works on objects too. My 1 and 2 LI big plant groups are all made from very strict patterns but the patterns are hidden so hopefully you only notice if you look very closely.

[ChinRey]

---

Drongle McMahon wrote:

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).

---

I remember you showed me that trick on the beta grid, did I remember to thank you?

It's not enough for what I had in mind this time though. To really optimize for max compressability you would need a way to sort the vertices one by one - and do the same with the triangles too.

[Rhiannon Arkin]

Related to efficiency, if i would use the same texture file in two different items, but rezzed on the same sim, would sl be clever enough to load this texture only once? 

 

[ChinRey]

---

Rhiannon Arkin wrote:

Related to efficiency, if i would use the same texture file in two different items, but rezzed on the same sim, would sl be clever enough to load this texture only once?

---

Yes. It won't show up in the calculated render cost unless it's within the same linkset but it helps reducing the actual render cost.