Vulpinus

So far, my work flow is to create my different LOD models in different layers. That's been easy with simple designs, but now I want to import objects from one Blender file (for instance, a window) with its multiple LOD layers into another design (a house), duplicate it and reposition the duplicates, etc. All while keeping the different LOD models 'together' in their different layers of course. I plan on making a library of parts to pull into my designs. How is it best to achieve this, or is there a better way than how I am working? (please tell me before I waste too much time doing what I am ;-) I've looked at grouping and parenting, neither of which seem to accomplish what I'm trying to acheive. For instance, after parenting all the LOD layes of the window, I still seem unable to duplicate all of it in one go, and importing it (with Shift-F1) into another design just shows the individual parts, not the group as a single object. Perhaps I'm missing something there.

That's great, thank you. It does just what I needed.

I have a curved and beveled object in Blender, and I'm trying to get it to unwrap onto a UV in a straight line along an axis with no gaps. I know that will distort the texture a little (if not 'corrected' on the texture) but that's better for me in this instance than the alternatives. Is there a way to get Blender to do this (semi)autmoatically? What I'm getting so far is shown below. What I need (if it's not already clear) is for the leftmost edge of the UV-mapped area to be straight along the V axis of the UV, likewise all the other vertical-ish lines, so everything maps to a rectangular area of the UV. Also, I need the gaps in the UV where the seams are to be eliminated by 'joining the dots'. I can do that, I guess, quite easily manually, provided everything is aligned along the axis already.At the end, each individual facet in the UV should be a rectangle, joined along its edges to the others, like a simple grid. Removing the seams just gives an even more pronounced curve of course. Manually realligning every segment is obviously rather cumbersome. 

Hmm... Having just tried on mine (I risked installing it again), it too seems to have reverted back down. So it looks like that is fixed. So much for that theory. Sorry for the confusion (that's what happens when we trust what's found on the 'net

ChinRey wrote: As for bloated viewer, I don't know of any Second Life viewer that isn't. I don't know of much of any software that isn't. Streamlined, efficient code is a rarity these days. Too many easy-to-use development environments and do-it-all libraries.

Apparently that is caused by the LL viewer forcing the graphics card profile into permanent maximum settings, at least on nVidia cards so probably on Radeon too I expect. That's another thing I discovered recently. I didn't even install the official viewer because it does it instantly and irreversably unless you know how to manually reverse it. https://community.secondlife.com/t5/Second-Life-Viewer/Second-Life-and-nvidia-drivers/td-p/2958144 The Firestorm people removed that bit of code when it became apparent.

Yes, as far as I can tell and from what I've read so far. There is no difference in-world, it's just about uploading mesh where the differences can be an issue.

That's a question I wondered about myself earlier today, having read a comment here somewhere about Havok and 32 bit. I've always installed 64-bit Firestorm, and I wondered if I'm missing something important. This is what I've found out so far with some searching... First, as KarenMichelle said, 64-bit gives the advantage of being able to use more memory, and (theoretically at least) use any amount more efficiently. Assuming of course you are running 64-bit Windows (or Linux???). Usually it's a no-brainer to use 64-bit software on a 64-bit system. But... Since LL only uses the 32-bit Havok library, we don't get that in the 64-bit viewers. Apparently the 64-bit library costs extra. It seems it is only of significance if one designs pathfinding things, or uploads mesh. Now, I've been uploading a *lot* of mesh recently and I've not realised that I was missing anything at all. I think it matters if one lets the viewer auto-generate the physics shapes. Without the Havok engine, that apparently does not work well. I don't do that, I make specific triangle-based physics shapes so maybe that's why I've not noticed anything lacking. That's what I've found so far, and might not be right given the Internet's (lack of) factual reliability. Perhaps this is a question more fitting for the mesh forum, thinking about it.

Some great homes here! Here's my little corner of mainland. I tend to go in for the modest, understated look as you can see. The property is in a state of flux a little at the moment as I gradually learn to make my own mesh and convert it all. So far I've saved 250 LI and improved it at the same time. I would absolutely love to have a full sim to play with for landscaping, but I can barely afford what I have (and since it's nearly payment time for my four premium accounts that chip in for the land allowance, it might not be there much longer!) 

The mind boggles! When I read the thread title, I thought, "You can have a copy of my script" which does exactly what you want, and can also act as a doorbell and IM/email you if you put it in something that a visitor can touch (like a doorbell on your door!). Too late now.

That looks interesting, thank you. I'll certainly try those ideas out in my experiments. I have my main staircase replacement on the to-do list. I had figured out that small triangles were not good. The steps I did are quite wide (6m) and concave. Trying to keep 'true' physics gave silly-high numbers (no surprise) so I went to a concave ramp (inside of a hollow cone section, like I used as a hidden prim originally so I could set the steps no-physics in the convex hull linkset). I ended up with just three segments though to get the 6 LI. Just about liveable with on both counts. Anyway, so far the meshification of my DIY prim house has saved me about 150 LI, so it's going well.

Hmm... that's about what I guessed. If I thought it would do any good I would go and add my name to the Jira. At least it's free on Aditi, although I'm watching my free money quickly dwindling. Yeah, I've found the physics particularly unpredictable. Sometimes analysing +/- simplifying produces a better result all round, sometimes it messes up the physics compared to my model, and sometimes my model works out best for LI and physics. I've just simplified my physics model even more (as much as I can tolerate on the steps - it's not 'good') and got it down to 6 LI. I can live with that, although I might link it to prims like I did with the original linkset for the physics which will keep it at 4 LI I think. I don't so much mind the physics LI itself, it is what it is, just the uncertainty and time it takes to test the unpredicatable options.

I've noticed before that when I set my uploaded mesh to prim physics, the physics weight goes up to more than the uploader said it was, but it's not been a problem until now. My latest object went from 4 LI to 13 LI when set to Prim. The uploader calculated the physics for the carefully minimised physics model I made at 0.8. I knew not to believe that from previous experience, but how on Earth can I know what it really is without uploading the object? What's the point of that seemingly fictitious and useless number? For what it's worth: the 13 was with an un-analysed model; it's mostly because of a concave staircase. If I analysed the model in the uploader then it dropped to only 9 when set to prim, but the physics was too far off. Mine was perfect. And it's still too high when the prim linkset I'm replacing is only 8 LI.

That's it exactly - you've described the issue better than I could. Seems things are a little glitchy around that area in Blender. I had the issue in (I think) 2.73 a few days ago and upgraded in case it was fixed. Thanks for the F6 work-around I'll try to remember that, along with all the other shortcut keys that are fighting for space in my brain.

You're right, as long as I don't touch the number entry fields that pop up in the 3D View window, it works. That's what's been confusing me. I usually press S and Enter to use the number entry fields instead of just typing. Try that, and see where the entry boxes appear, and try typing into them and pressing Enter there. For me, even though I'm supposed to be editing the UV map, those entry boxes get linked to the object scale instead. It seems wrong that that's the case - I should get entry boxes for the UV Map, not the 3D View. Still, now I know I can just type the number (with X or Y as well) I can just do that. Thanks for the help. I'm still getting my head around Blender's interface, and probably will be for some time.

Yep - that's what I'm doing. It works in 3D View like that, but in UV Edit, it's as if it links back to the 3D View entry fields instead of UV entry fields and so changes the object instead of the map. Really, it feels like a bug right now, but I'm assuming I'm somehow doing something wrong. One thing I noticed, with Rotate, which of course only needs one number: I could press R in UV View, type the number and it would appear in the entry field in the 3D view. Provided I just pressed Enter after the number, it worked and rotated the texture. If I clicked in the entry field where the number had appeared and pressed Enter there, it rotated the object instead of the texture.

This has been driving me nuts... I'm in the UV/Image Editor and trying to scale and rotate my UV maps. Pressing S or R (or the options on the UV View tools) lets me wiggle the mouse and scale or rotate the map. Fine so far. I usually want to do the above by a specific, numeric value though. Just like I can when scaling an object in 3D View. In UV Edit though that does not work for me. As soon as I press Enter to go to the entry fields, it's the entry fields in 3D View that get used and as soon as I enter my number, the object gets scaled/rotated, not the UV map. I am making sure to stay in the UV Edit view when doing all of this; my mouse is not straying into the 3D View. In fact, if I close the 3D View and try the above, I just don't get any entry fields when I press Enter. I also noticed that if I wiggle the mouse before pressing enter, the changed parameters are in the entry fields already, but as soon as I enter anything there it gets applied to the object. What am I missing here? There must be a way to do what I'm trying... ETA: I'm on Blender 2.76b

Yeah, I've been thinking about the balance of the three factors when linking. I need to start thinking on a larger scale now I'm getting at least a little of the hang of this stuff. Also, if I was designing for other people, I quite agree that I would keep more detail to account for potentially lower graphics settings. Since it's just for me, and I don't get many visitors, I'm happy with it. I noticed that the LI in-world went up to 2 when I made the physics shape Prim, but a quick optimisation of that shape got the physics cost down to, and staying at, 0.6. That's without analysing the shape in the uploader, which made it better in the first case but worse in my better optimised version. So, the final version... The better medium LOD model I made looks just like the orthographic projection; I flattened it and removed the needless bits. Even when it switches at 30-ish metres, it's hard to tell the difference if I miss the slight texture change on the frames. I made the medium LOD model double-sided again; it's only 44 tris per side. Like that, the mesh comes in at 2.1 download cost. The single-sided version is 1.2. I also discovered a loose vertex and edge or two and the useful 'select loose geometry' tool Thanks to some very good help here, things are coming along nicely!

1.2 LI - Yes! I'll have to check later on the beta grid (this laptop I'm on is not so good) but I think this should do the job. Removing the inside of the medium LOD model and simplifying the outside (but actually better visually than my first attempt) has got me down to 1.2 download cost. With the size of the thing, by the time anyone gets far enough away to drop down the LOD it'll probably be beyond their draw distance anyway. Of course, that might go up now when I link my other bits to it, but... 1.2 !!! Thank you for making me think about it further. (I doubt I've thought of everything though...)

ChinRey wrote: Now, get it down to 1 LI! It is certainly possible even without sacrificing LOD. ... 1 LI??? OK, you've got me thinking (that's sometimes dangerous, lol) I thought it might be by reducing the number of materials. I reduced it to just two, from six, and it only dropped the download cost from 2.984 to 2.962. Not that then. It's just occurred to me that I might not need the inside planes of the medium LOD model - I'll never get so far away that it will be needed, even in my mansion. So that can go. In fact, if that's the case, the outside of the full LOD model has fewer vertices than the whole medium model I made. Right, I'm off to experiment. I'll be back...

Thanks for your input Gaia, it's much appreciated. So, is having a face connected to another like I have, with only a single vertex, potentially not a good thing? Looking at that another way, is there some significance to having faces connected by a common edge? What probably looks like superfluous faces in my design was because I was planning to use a different texture on those places. However, I've rethought that somewhat, removed two materials and redesigned it similar to your example. I've also added extra faces either side of the quad above the door so that it isn't just connected by the lone vertices at the top corners. Surprisingly (to me at least), the import to SL came in fractionally lower than the original in download cost despite the extra vertices. I guess the fewer materials makes a bigger difference. I've made a lower detail version for the medium LOD and a physics shape, and it comes in at 2.984 LI. Nice! Even better, I can link the mesh doorbell I made (it IM's me if anyone presses it and records any visitors to my parcel) and the double doors and it's still only 3 LI. I like mesh!

Yeah, I guessed I was getting float rounding. 32 bit floating point.... that's so 20th century, :smileylol: I'll give your suggestions a try, thanks.

I've made a mesh entrance to replace my prim build, and I have two issues I need advice on... First, if I look at just the right angle, aligned with where two faces meet, I get a thin, flickering line as if there is the tiniest gap between the faces, reminiscent of two prims being off by a micron or so and why we texture the hidden, insides of prims where they abut. I've tried to capture it in the second picture below. It moves rapidly with the slightest change in view and looks much worse that the static photo shows. The faces terminate on the same vertices (no 'doubles'), although when I checked each one, for some reason some were off by a tiny amount. 7.50002 instead of 7.5 for instance. I put them all to 7.5 and reuploaded but could still see the flickering line. How do I stop this happening? Second, and worse, is what appears like a flicking 'shadow' around where my window frames protrude from the wall. This is not a shadow that should be there from a light source, but it appears nevertheless and flickers like crazy with the slightest movement. I've tried to capture that with the animated gif below, but again it looks much worse in the viewer. I think I've seen similar in other peoples mesh builds in SL. Looking closely at the prim version, I can see similar effects there but nowhere near as noticeably bad. Is there anything I can do about this? These problems happen on the mesh with or without a texture being applied; the photos have none because it's easier to see the issues.  [Editied to remove now-redundant link to my files]

Thank you Aquila, that's really helpful. Since my last post, I've figured out using seams on the window frames before unwrapping. In the process I discovered correcting/equalising the scale with Ctrl-A/Scale. (must have been needed due to the build I imported from SL to start with). I found a nice script that adds a vertex at the intersection of two lines; that came in handy for making a few corrections to the original. I also spent about thirty minutes with a calculator working out the x,y coordinates of every corner of every face for the building's front wall for placement on the UV map, then typing them all in. In the end I had a UV map that looks just like yours in the pictures. I'm so glad there's a quicker method I can use next time :smileyvery-happy: (I guessed there must be, but a quick google didn't help and I thought by the time I've found the answer, I can have it done manually). For a final laugh, the last thing I did was make a physics model. Easy, surely? Nope. I spent fifteen minutes redoing it in different ways, trying to analyse the model in the upload, or not, and any other changes I could think of, and still not being able to walk through the door. Then I changed the physics type in the SL edit window from Convex Hull to Prim, and kicked myself several times. Anyway, the front of my hallway is now 3LI, a great improvement over the 9LI (convex hull) of the original prim build. I didn't expect it to be that much better; this was in part an experiment to see if converting to mesh was worth the effort. My whole build is around 1000LI, so I'm looking forward to regaining a lot of space! (I can finally afford to have furniture, lol). Thanks again for the help folks! (I'm sure I'll be back for more - I've a lot to learn!)

[ I've just editied a previous reply here that said the above didn't work. Something must have borked because I tried it twice and it didn't. However...] Thank you Mylie, this seems to have done the trick (on my third try - don't know what happend to the first two). I suddenly have textures... yay! Now to get them all fixed up again... Thank you :smileyvery-happy: