Luc Starsider

They're not screwing with you and wearing an alpha layer covering their entire body, are they? What Val asks will probably give us a better chance of providing an answer. - Luc -

If it's a relatively new mac, it should not really have any issues. Most Macs, apart from the now retired MacBook and the lower range MacBook Pros, have dedicated AMD or nVidia cards, but the MacPro tower model is the only one with a desktop version of the graphics cards (AMD). The rest of them have mobile versions of the card. I have Macs with cards from both of these vendors, and I rarely have issues seing mesh (or any other issues for that matter). Which Mac do you have? And what graphics card(s) does in have? The portables from later years have dual graphics on board - an integrated Intel chip as well as a dedicated card. Have a look in 'About Second Life' in the viewers help menu to see which one is in use. If it's the Intel chip - which I doubt - you could make sure the right one is used by checking a box in the energy savings control panel in system settings (on the Mac). On Macs from before the last two years, it may be an idea to check whether 'hardware skinning' is turned on. If it's on, try turning it off and see if it helps. You won't get shadows working if you turn it off, but chances are you don't use shadows on the mac anyway. Lastly - and this is not a Mac specific thing - try increasing the debug setting 'MeshMaxConcurrentRequests' from its default 32 to around 100. I'm not sure this is the problem or the solution for you, but who knows, it might help . I'm also not sure what the ideas number is for this setting, but have it set to 100 myself. - Luc -

I don't really know what the cause of the problem is, or what the error message you get means. I did, however, google the error message, and this: http://8help.osu.edu/4303.html article seems to explain the problem pretty well. I do not quite know how to resolve it, though, so perhaps someone else can help with that. This is the search I ran: http://www.google.com/search?client=safari&rls=en&q=%22side-by-side+configuration%22&ie=UTF-8&oe=UTF-8 - Luc -

I'm figuring it also had something to do with not knowing what the heck to do with all those who registered since last names were cancelled, who now have the last name of Resident. - Luc -

As Claireschen says, we need more information. Not only on any error messages, but also on you pc. Graphics card in particular. (Select Edit from the top right corner of your post to add information, and also press permalink and add a comment so that we are notified when you do add anything.) - Luc -

Some information came out some months ago on the subject in a blogpost from Rodvik Linden: http://community.secondlife.com/t5/Your-Avatar/Update-Last-Names-Roundtable/m-p/1409403 Basically, last names are gone (or will continue to be Resident) for new registrations. I don't know of any newer information regarding last names... - Luc -

I always understood it the way Drongle explains it. However, like you, I have also noticed that the LODs do not seem to change that way. I figure, though, that it is probably a good idea to create the LODs regardless in case something changes in the future, and because I'm likely to save on upload costs if the LODs are good. (I also create a physics mesh even if I don't know if it's used for rigged attachments). A few times I have also had the wrong LOD after tping. After camming in and out on the mesh a couple of times, it has sorted itself out. - Luc -

A couple of guesses... To me it seems that the AO bake is not just taking the dress itself into account. It seems there are other objects present affecting the bake. Do you have other objects on the layer where your dress is that is perhaps hidden from view, but not from rendering? If so, press the little camera icon next to the object(s) in the outliner to hide it/them from the renderer. To a degree it could also seem that some part(s) of the mesh is duplicated with normals facing the wrong way which can mess up the AO bake, but you say the normals are ok. ETA: What Gaia said - Luc -

Well. When you bake AOs, lights are not taken into account. Proximity to other objects and faces is, so perhaps you have other objects in the scene which are close to the mesh for which you are baking the AO? - Luc -

I agree - a screenshot and a few more details will make it easier to provide a solution. But if an AO bake is the problem, I can only think of adding the possibility that the blend mode for the AO could have been changed from 'Add' to 'Multiply' in the drop down next to the factor slider. - Luc -

Hi Gman. You can find where the viewer stores the cache by looking in the viewer prefs, in the Advanced, or maybe in the Setup, section. You should find a place where you can set the cache size and the location. You can clear the cache directly from this preference pane if you wish. But I don't think this is your problem. If you are able to log in with an alt, I don't think clearing the cache will help. It's more likely some setting file or other file specific to the one avatar that is the problem. I suggest you navigate to ~/Library/Application Support/Second Life/ and move the folder named after the avatar in question to your desktop and then log in again. This will recreate the avatar folder with new files, and hopefully you should have no issue. If everything is OK, delete the folder on your desktop, but first you may want to move chat and IM logs from this folder back in to the new one created. Also, the bandwidth numbers you state seem a bit high. If you are on a wireless network, 5-10K is way to high. The wireless can not transfer that much data quick enough, and you will most likely get packet loss as a result. On wireless networks you will probably get better results with a max bandwidth setting around 1.5K. On a wired network you can keep it higher. I don't know the ideal size, though. - Luc -

Dardissounet wrote: Also when I attach 2 individual objects to one armature, when I move a single bone like the thigh, the two limbs move with eachother i.e symetrically, to make the other limb I just duplicated the first one, separated it from the other and inverted it, I'd say it's to do with the parenting, but does anyone know how to fix that on blender 2.61? Thanks for the help guys! It sounds as if the duplicated limb is still weighted to the same bone as the original was. That is, it is influenced by the same bone(s) as the other one, thus moves in tandem with the first one. I might be wrong but I seem to remember that this works - If you use the mirror modifier to duplicate the limb, in stead of duplicating it (ctrl+D), and then apply the mirror modifier, you will have a duplicated limb weighted to the correct bones. This may depend on the armature - names and position of bones and so on - but have a go and see if it works. - Luc -

This time 'Apply modifiers' worked. (Blender 2.63.13 r48273 on MacOS X 10.7.4) But I came across a different issue. Perhaps it is by design? I had to check 'Include armature' in the Export data options section of the exporter for any rigging info to be included in the dae file (joints, vertex weights and so on). With the option unchecked, and no rigging data in tile, I could not check (naturally) 'Include skin weight' in the SL uploader. Let me know if you need any more information - dae files, system info, or anything else. - Luc -

Hi Gaia. Admittedly, it is a while since I tried to apply modifiers on export for rigged mesh. I only tried a couple of times using one of the early versions of the feature. I couldn't make it work - the modifiers was not applied - so I went back to 'the old way'. I will build a fresh version of Blender from svn, test this thouroughly and, if you don't mind since I haven't set up a bug-tracker profile, send you the details if I have issues making it work. I think you've probably done quite a bit of work on this since I tried it last, so hopefully, I can make it work now. - Luc -

In 2.64 - or right now, if you build Blender from svn yourself or use a later version downloaded from graphicall.org - you will indeed be able to have modifiers applied at export time. But the last time I checked this in a build from svn, it did not work on rigged meshes. This will hopefully be fixed and working before 2.64 is released. - Luc -

Regarding your first question. The others have given good advice. However, I didn't see anybody mentioning the solidify modifier to you. This modifier lets you add 'thickness' to a model. For instance to add the inside of a cup when you have created the outside of it. From your explanation, it sounds as this is what you want, but you may want to chech that the normals of this added surface is pointing in the direction you want. ETA: Reading your last reply makes me wonder if shrinkwrap is what you want... - Luc -

I think your options are limited. You can AR the object. And you can block/mute it. That's about it, I think. If you block it, you won't receive the spam, so you might want to try that. - Luc -

That's great, Irene! I always were under the impression that private region restarts had to go through the sim owner. It makes sense that it can be reported to LL and get a restart done directly. I'm learning... Thank you! - Luc -

I've had this problem once myself on my mainland parcel. A simple relog fixed it for me. Let's hope LL manages to fix it so it doesn't happen for everybody who can not make it go away that easily. ETA: I meant to reply to the OP, but the forum software screwed it up... - Luc -

Well, you have to create a new prim to get your own name as creator. If you used to make sculpties, you added the sculptmap to that same prim and the name would still be yours. With mesh, to get your own name as creator you either have to get the *.dae file from the maker and upload yourself, OR you make a single, regular prim which you link as root with the mesh. The root prims creator is the one which is shown when you edit or inspec the object. - Luc -

Another person recently had huge lag issues with SL. From what I understood, the issues only related to SL as in your case. The solution in that case was to disable a setting in their router - IP Flood Detection - which seems to fix the issues. Theirs was a Cisco router. Perhaps this is something for you to check/try? - Luc -

It could indicate that the region where your home is located is offline for some reason. Try specifying a different location on the login screen and log in. If you are successful, try opening the map and search for your home region and see if it says unavailable. Or try to tp to it after you logged in. If it is offline, contact the region owner to see if they can get it online. If it is mainland, try to file a ticket to get it sorted out. - Luc -

You have to remember that the alpha layer is applied to the avatar, not your mesh clothing. Thus it will not use the uv map you made for your clothing, but the one for the avatar. This may be why it seems different than you expect. - Luc -

Adding a bit of my own personal experience re. MeshMaxConcurrentRequest. At times I have had to increase the value to WAY more than 64. Often, this makes mesh show up. At which point, I've reduced it again. I rarely go lower than 100, though. Also, try to reduce the draw distance to 0 (or as low as you can), then increase again to the normal level. - Luc -

What Val says is absolutely true. Also, if at all possible, aside from ar'ing and possibly notifying your local authorities, I would advice to ignore the person as best you can. Do not give them the satisfaction of knowing they get to you. - Luc -