Masami Kuramoto

iamtheainar wrote: So basically all what was needed is to extract the dowloaded file (SecondLife-i686-3.3.1.254524.tar.bz2 (I extracted it in Downloads folder and run the game from there too)), open extracted file folder, find the file in it named "secondlife", double click it and press "Run in Terminal". That's it, no instaletion was needed. ^^ Congratulations! Now take a look in the GNOME applications menu. There should be a Second Life program shortcut in the "Internet" submenu, so you don't need to launch the script from the folder any more. Have fun!

Storm Clarence wrote: Masami, let me put it this way: people like you seem to display your ignorance so willingly it is no wonder SL has a bad reputation. (I did not know Linux had a bad reputation; since when-- today?) I don't need a lesson on how to create a writable directory structure within the Linux FS hierarchy--the OP needs this lesson. Perhaps so do you! The OP did not get a lesson in computer science today as you have offered absolutely nothing. I offered advice to the OP to learn basic Linux skills or he will suffer nightmares in the future. Ostensibly the same nightmares you are wrestling with regard to creating writable directories. Go figure. Oops. I take back what I said earlier. You are not a pedant. No one pedantic about Linux would ever suggest breaking FHS rules to accommodate to misbehaving applications -- and then propose this as "the right way" to newbies. You are dangerously incompetent, Storm. Go away. You are not helping anyone.

Storm Clarence wrote: The rest of what you wrote is garbage; typical n00b talk; if no one is going to teach me then how am I to learn type talk. I enjoy nothing more than to help, offer guidance, and work within an environment in which I am brutally comfortable, and have embraced since its inception. Yes, I am a pedant when it comes to installing, configuring, tweaking, and using/developing operating systems and writing software. There is a right way and a wrong way. It is called computer sciences for a reason. YMMV. Storm, let me put it this way: People like you are the reason why Linux has a bad reputation. Don't get me wrong, pedantry is great. If Linden Lab's developers were as pedantic about Linux as you are, then we wouldn't have this discussion. Then the viewer would be two-click installable from the distribution app store, just like everything else. Unfortunately that is not the case here. The SL viewer for Linux comes in the form of an unpack-and-run archive and requires a writable install location for automatic updates, which practically rules out everything but the home folder. If that bothers you, tell Linden Lab how to fix it. Do not tell the OP how to fix it, because that is not his job. The OP is a user, not a developer. He didn't ask for a lesson in computer science or an introduction to the ten commandments of Linux system administration.

Min Barzane wrote: 2.You counter DMCA,LL gives your info to real copyright holder They don't need anyone's payment info to do that. The counter-notice includes the defendant's RL info, otherwise it would be invalid. Idk if you noticed how manny screwballs like that apeared on marketplace and disapeared in mater of weeks,an i meen disapeared ,not only from MP but totaly from SL,banned forewer! So....Nonsense you say? LL doesnt take legal actions..true...real IP rights holders do!!! Wishful thinking. What I did notice is that content creators keep screaming at LL because they follow the letter of the law. And the law is telling LL to process takedowns and counter-takedowns, nothing more. There are tons of ripped content on the marketplace because the copyright owners simply don't care about it and ignore all the "mesh police" reports. Payment info has done nothing to stop that.

Storm Clarence wrote: 2) There is a *right* way to do things in Unix/Linux and there is the quick and easy way. I have seen too many times (actually every time) the quick and easy way leading to nightmares within the environment e.g., someone above mentioned to place the package in your home directory -- this is something I would never do; the Linux FS is designed and implemented the way it is for a reason; and the reasons are way outside the scope of this conversation. Placing the package in the home directory was my suggestion, and I explained why. In fact your "right way" is what causes trouble for most people. You have to understand that the SL viewer is not your typical Linux application. It was developed with Windows in mind. If it were a proper Linux application, it would ship as multiarch .deb archives in a regular APT repository, use APT as an updater instead of implementing its own one that requires install folder write access at runtime (!), not modify LD_LIBRARY_PATH in its startup script, not overwrite its own desktop shortcut upon every launch, etc. Shoehorning such an application into a system that is maintained by a package manager is much worse than using the home folder as an install location. If you ever installed real Windows applications under WINE, you would know that they all end up in a hidden folder in the user's home directory as well. WINE is totally breaking the rules there, and for good reason.

Min Barzane wrote: its gives LL ability to take legal actions against ppl who upload ilegal models! Nonsense. LL cannot take legal action against uploaders. They cannot even decide which models are "illegal" and which ones are not. That is up to the courts. LL also cannot legally pass uploader identities to complainants in case of alleged copyright infringement. Only the uploaders themselves can do so by filing a DMCA counter-notice. LL cannot take shortcuts here and bypass the DMCA process. If they do, they'll risk losing their safe-harbor status. Maybe now you understand why the payment info policy didn't stop people from uploading ripped game meshes. The only reason why LL implemented this policy at all is because content creators requested it. It's a placebo, nothing more. If any of this were legally relevant or even required, then other uploads (images, audio clips, animations) would require payment info, too.

Mint should have all the necessary libraries for audio and video playback pre-installed, since that is exactly why Mint was created in the first place. The only package that may be missing in a default install is "ia32-libs" for running 32-bit apps, and installing that is anything but rocket science. In fact Mint and its parent Ubuntu have become so noob-friendly, it's almost embarrassing. I'm at risk of losing my geek card.

Instead of working around a bug that has been fixed already, you could as well just update Blender and forget about it. This way you'd also get the latest fixes and improvements to the COLLADA exporter. http://builder.blender.org/download/

Pamela Galli wrote: Oh I did not know I was supposed to avoid doing things at object level! That's pretty important to know. That's not what Drongle was saying. You can work at the object level just fine; you just have to remember to apply object-level modifications to the mesh before exporting. But you already knew that. You don't have to change your way of working at all.

Qie Niangao wrote: That's the simplest, least intrusive way to start. Eventually, you may want to actually "install" it (the "install.sh" file might be all you need, but you may also want to add it to whatever desktop you're running--but that's a more advanced and specialized operation. The viewer's auto-update feature requires the install location to be user-writable. In general, I would recommend against "installing" anything that doesn't ship as a .deb archive. I've had SL in my home folder for more than five years; it really is the ideal install location for now, IMO. By the way, the viewer will also automatically add a launcher to the GNOME applications menu and the Unity dashboard. Not sure if that will show up in KDE as well, but GNOME is the default in Mint if I remember correctly. Some special preparations are needed if the computer is a laptop with Nvidia Optimus hybrid graphics. I'll write more about that if anyone is interested.

Drongle McMahon wrote: The following was done wityh 2.63 (sorry, haven't downloaded 2.63a yet). I guess that explains it. I'm running 2.63.7 here and can't reproduce the problem at all. Note to self: Make sure Pamela is up to date before investigating any of her reports...

Applying scale changes the shape of the mesh if the scaling is not uniform (i.e. the same factor along each axis). This will also change the orientation of the vertex normals, because they are supposed to be perpendicular to the unscaled mesh surface. The vertex normals determine how a face gets shaded in response to light sources. This is why applying non-uniform scale has a visible effect on smoothly shaded meshes. I guess you applied scale to the joined pillows but not to the unjoined ones you imported earlier. Applying scale did not make the pillows darker; it just made them reflect light correctly. The reflection angle on the scaled ones is physically wrong because the vertex normals are stretched non-uniformly and no longer perpendicular to the surface. Here's an example to illustrate the effect: Start with an empty scene in Blender. Add two mesh cubes and change their shading from flat to smooth. Now switch one cube into edit mode and scale it by factor 100 along the Z-axis. Then switch back to object mode and scale it by factor 0.01 along the Z-axis. This will bring the cube back to the original size, but you'll notice that its shading is now very different from the other cube that was not touched. The scaled one will look flat and either be much brighter or much darker than the other one, depending on the viewing angle. Only after you apply scale, the second cube will return to normal.

Baloo Uriza wrote: I'm not saying it can't render more than 45 FPS. I'm saying it's overkill. Even if that was a hard limit to SL, it's still at least 10 frames faster than the human eye can even distinguish as individual frames, short of taking a lot of meth. It's not about distinguishing individual frames but about perception of flicker. There are two types of photoreceptor cells in the human eye, rods and cones, and their flicker fusion threshold is different: 15 Hz for rod cells, and 60 Hz for cone cells. These are average values; some individuals will see flicker up to 75 Hz and higher. The slow response time of photoreceptor cells is the reason why we see fast moving objects blurred. If a fan rotates faster than the eye's flicker fusion threshold, its blades blur into a transparent disc because the eye can no longer distinguish between the blades and the background; it will see both at the same time. Motion pictures run at 24 FPS; much slower than the flicker fusion rate. They get away with it because movie cameras expose frames long enough to include a considerable amount of motion blur. The faster an object moves, the softer its edges will be rendered on screen. This reduces the strobe effect and makes the experience bearable. In Second Life each frame is rendered with zero seconds of motion blur; it looks like it was shot at infinite FPS. That's OK as long as nothing is moving faster than one pixel per frame. Once you have objects moving faster than that, the strobe effect becomes fully visible along their edges. This strobe effect is what triggers epileptic seizures in some individuals. And it is stronger in peripheral vision. If you focus on your avatar while turning it around at 45 FPS, you can easily see it, no meth required. So there are two ways to eliminate the strobe effect: add motion blur to each frame, or render frames faster than the eye's flicker fusion rate. In the latter case, motion blur will appear naturally.

Deej Kasshiki wrote: Nope because the same thing happens in the craptastic LL viewer as well. And lest you forget all TPVs are 95% or so based on LL's code... No, it doesn't happen in LL's viewer. Those 5% of the code make all the difference. Mesh was not developed for Viewer 1 but shoehorned into it. Being a luddite is no fun these days, you have to live with buggy mesh or no mesh at all.

Suki Hirano wrote: Does it run smoothly, like more than 5fps? Absolutely. I ran my tests on a dual-Atom nettop with Ion 2 chipset two years ago. The device came with 2 GB RAM and 500 GB HD and cost EUR 300. Today you can get it for half that price. The framerates I saw in graphics mode Low were on par with what many people get in Ultra mode on dedicated hardware. 28 FPS in a shopping mall sim with few people around. 12 FPS at an infohub crowded with avatars, most of them dressed properly. The system was running 32bit Linux and Viewer 2. Voice chat was off. Graphics mode Low is not pretty, but it exists for a reason. Windlight effects would have brought that machine to a halt, no doubt. There are no miracles here, the laws of physics still apply. However, I'd be the last person to recommend an Intel GPU. I wouldn't even recommend ATI. Second Life is an OpenGL application, and Nvidia has the best OpenGL drivers hands down. The fact that I wasn't running Windows may have helped, too. Call it a rigged setup if you will. But the point is that anyone can afford it.

Baloo Uriza wrote: Higher FPS is better, but you're running into what your eyeballs can tell the difference easily after 25 FPS, and what SL can deliver at 45 FPS. Go with what you can afford, but anything rated past 45 FPS on that benchmark will be overkill. I do appreciate the level of detail on the graph, though I'm curious which operating system they did this on, since you'll have lower framerates on platforms with no direct support for OpenGL (Windows) and lower again if you're not using a Windows Classic-based theme on versions that have Aero enabled by default (Vista, 7). Myth #1: Second Life cannot render more than 45 FPS. Fact: Sim/physics FPS and client FPS are unrelated. The viewer will interpolate between simulator updates, predicting updates before they happen and rendering intermediate frames to keep things smooth. This is precisely why avatars start walking through walls or beyond simulator boundaries whenever there is sim lag or network congestion. "Overkill" is any framerate above the monitor's refresh rate (e.g. 60 FPS on LCD/TFT screens). Myth #2: Windows has no direct support for OpenGL. Fact: Plans to provide OpenGL only as an emulation layer on top of Direct3D 10 were discarded before Windows Vista started shipping.

danicah wrote: Does that mean those designers had to ask permission too before putting them on their clothes? Yes. However, there are exceptions. For example, if someone transformed Hello Kitty into a parody of herself, poking fun at the entire franchise or consumerism in general, the result may qualify as a derivative work of significant originality, and the use of Sanrio's character in that context would constitute fair use. Kalashnikitty may be such a case, but that doesn't mean the image isn't copyrighted. Unless you created the image yourself, you'd still have to ask for permission to use it on your shirts. Whether you ask Sanrio or the creator of the derivative work is up to you. You'd risk a takedown by either party. So you might as well not bother at all and use the picture without permission, hoping that whoever owns the copyright won't care. That's what a lot of people do in SL, and apparently they get away with it most of the time.

There is no inherent reason for meshes not to render properly on computers with integrated GPUs. Every "tangible" object in SL is a mesh, and every avatar is a rigged mesh. If rigged mesh attachments don't show up on your screen, it is due to a bug in the viewer, not due to a bug in your hardware. This sort of thing is not supposed to happen, even at low graphics settings. However, before you blame LL, you have to confirm the bug in their own viewer. LL is not responsible for rendering bugs in third-party viewers, especially those based on viewer 1 where support for mesh assets had to be retrofitted. You were looking for suggestions, so here's what you can do: Confirm that your hardware meets the minimum system requirements as laid out by LL here. Intel integrated GPUs are officially supported if you are using Windows, but not if you are on Linux or a Mac. Nvidia Ion integrated GPUs (used in some netbook-type PCs) are supported too; they are identical to GeForce 9400M. Confirm that the problem persists in the latest release of Linden Lab's official viewer. If it does, look for existing bug reports or file a new one. The issue with invisible rigged mesh attachments has been fixed according to SH-2779. Reopen that ticket if you have evidence to the contrary. If the problem occurs only in a third-party viewer, file a bug report with its developer. At this point it is no longer LL's concern. The idea that SL requires high-end hardware to run properly is a myth. I've seen Linden Lab's viewer perform just fine on Ion-based "nettop" PCs running Linux two years ago. This sort of hardware is now available for about $150. If that is out of reach for you, then SL should be the least of your problems.

Deej Kasshiki wrote: My computer is a custom-built, high spec gaming rig using up to date hardware and the most current version of my TPV of choice. Go ahead and give me a smartass reply about how I should stop using a toaster because sometimes mesh refuses to render properly for me as well. Perhaps the fault lies in the Lab's half-assed implementation and rushed deployment of mesh? Oh heavens no, that couldn't possibly be the issue! Blame the end users, that's the ticket! Maybe some of you LL apologists should climb down from those high horses you're perched on before you get a terminal nosebleed. Emphasis added. How is it LL's fault if mesh doesn't render properly in your TPV? Doesn't that make you a TPV apologist?

Cully Andel wrote: If your clothes are mesh PLEASE!!!!! put it on the poste of the item! I know a lot of people, myself included, who have a mesh viewer but we cannot see rigged mesh (And please no one tell me what settings I need to alter. I already know this. My hardware can't cope) This bug has been fixed. Please update your viewer. If you sell mesh clothing it would be nice if your customers knew before wasting their lindens on your outfits. Their lindens won't be wasted because others can see the outfits correctly. If you use outdated viewers or hardware that doesn't meet the minimum system requirements, it's no one's problem but your own.

By the way, shape files in .blend format have been added to STORM-1716 (uploaded by Darien Caldwell and Siddean Munro) which can be used as an alternative to the COLLADA files.

Xavorin Whitesong wrote: Report this to LL directly. They have a legal team who's job it is, is to validate whether it's a rip or not, and if it is, to get in touch with the IP owners and find a solution. No, that's not their job at all. In fact they would be stupid to get involved in these things. Read the law.

You can also download daily "official" SVN builds from http://builder.blender.org/download/.

By the way, Blender's built-in select functions have been improved with BMesh as well. For example, you can find all triangles and n-gons at once using Select --> By Number of Verts, and then setting Number of Vertices = 4 and Type = "Not Equal To". A function to search for loose vertices and edges is available, too.

Arnaldo23 wrote: No, is only a graphic of intel, on board. In that case it's a miracle you had SL running on Ubuntu 11.10. Check out the system requirements. One of my computers is a laptop with both Intel and Nvidia graphics (Optimus). If I don't assign the SL viewer to the Nvidia card, it won't run at all. And that was in no way different under Ubuntu 11.10.