Masami Kuramoto

Pamela Galli wrote: Thanks to everyone who took the time to share insights! Yes I rebaked many times, deleted the column and copied another one and baked it, same thing. Blender thinks the railing is higher than it is and that's that. I finally decided to do the easiest thing and just move the railing up to where Blender thought it was. It is not level with the other perpendicular railing but that is probably not noticeable. I agree with Drongle. Unless this is a bug in Blender 2.63 (Why don't you install the latest version?), there must be something wrong with your UV layout. Due to aliasing it is normal for bakes to be up to one pixel off, but in your picture it's clearly more than that. As usual, since all we have is screenshots, there is no way for anyone of us to tell exactly what's going on. However, I can prove that Blender's bake function is as accurate as it gets. The worst you should ever see is something like this: The best way to avoid these effects is to design the model as constructive solid geometry, i.e. instead of making separate meshes intersect one another, use boolean modifiers to merge them into a single mesh. Then your ambient occlusion bake will look like this:

Shelby Silverspar wrote: Not funny, or even slightly accurate. I'm an artist in RL, employed, and have to be very copyright-aware so my clients and I don't get sued. Yes, those generic patterns you put on your textures are so artistic, so original, so uniquely yours, no one would ever claim to have seen that kind of stuff a thousand times before.

Shelby Silverspar wrote: Copyright is about using other people's stuff. That's it. I create art. LOL Show me your "art", and I'll show you the stuff you stole from others and used without permission.

First, select all (press A), then choose "clear seam" from the mesh menu. Now all the seams are gone. Next, switch to edge select mode, hold Alt and Shift, then right-click any vertical edge of the cylinder. This will select an entire edge loop running from the top edge to the bottom edge. Now choose "mark seam" from the menu. The selected edge loop will turn into a seam.

TransPleasure wrote: I was joining the top vertices in order to create a mark seam. But like you see in the image, there are some of them which are not joined. I call "gaps" these edges between 2 unjoined vertices. You don't need seams along the edges at the top and bottom since there is nothing to cut off anyway. All you need is one seam from the top edge straight to the bottom edge. For a sculptie-compliant rectangular UV layout, switch to face select mode, activate one of the four faces that touch the top or bottom end of the seam, press A twice to select all faces, and then use "Follow Active Quads" to unwrap the object. In the UV editor, resize the layout so that it fits perfectly into the image area, and rotate it so that the seam is at the side, not at the top or bottom.

Unfortunately the image shows neither the unwrapped UV layout nor the gaps you mentioned. If by "gaps" you mean that there are holes in the object after you upload it to SL: This may be caused by the mesh not being closed. You have to remember that SL does not render the backsides of polygons. If you want both the inside and the outside of such an object to be visible, you have to solidify it.

Bentley Squeegee wrote: I want to be able to include it in the UVW map for the base of my object, this is working fine with the shadow maps and textures for the base of the chair itself but the ground plane is still pure white with the shadows ontop. I am guessing there is a simple click of a button or a slight adjustment to a material property but I am non the wiser after playing with it for hours. I don't know where it is in 3ds Max, but in Blender it is indeed a material property that allows shadows to modify the material's transparency. Of course in order to bake the effect to a texture, the target bitmap must include an alpha channel. Maybe that helps you figure it out.

Boudicca Littlebird wrote: Like in RL dissenters are suppressed and even destroyed, that shows by the amount of people that just "disappear" from these forums I found that the risk of getting banned for expressing controversial opinions is smaller here than it is on other SL-related forums.

Did you check out the user manual?

lol

Drongle McMahon wrote: The edges will disappear leaving 8-edged ngons with an vertex in the middle of side of the squares. Now go to vertex select mode and select all these extra vertices. Do Mesh->Dissolve->Dissolve again. The extra vertices disappear. By the way, if you enable "Dissolve Verts" in the operator panel after the first Dissolve, that extra clean-up step will not be necessary.

Is this the mesh exactly as MD2 exported it? It seems that the inside and the outside are welded together in a single seam on the left and right side. So it's not Remove Doubles that caused it. I guess the best way to fix that is to delete most or all of the inside faces. They won't be visible anyway when the mesh is worn, except near the shoulders maybe. Press TAB to enter Edit mode. Press A once or twice to make sure that no part of the mesh is selected. Switch to Face Select mode and enable "Limit selection to visible". Press C to activate the circle selection tool. Now you can select faces simply by holding the left mouse button and sliding the circle across the mesh surface. Holding the middle mouse button will unselect faces. Pressing the right button will deactivate circle selection. Select all the outside faces and some of the inside faces near the shoulder that may be visible when the mesh is worn. When done, press Ctrl-I to invert the selection and then X to delete the selected faces. Recalculate the normals and see if there are still shading errors. Press TAB again to leave Edit mode. Attach a Decimate modifier and see if it still complains about the mesh being non-manifold. If the shading looks good and the modifier does not complain, you're done. Don't forget to delete the modifier.

JeanneAnne wrote: The thing I think you need to realize tho is that it's LL executives & shareholders who are the real parasites, much moreso than SL "freeloaders." Execs & shareholders rake in profit while contributing nothing. The freeloaders freeload with LL's blessing because that's the way they've decided to run their business. There's no use resenting freeloaders when LL allows & encourages the freeloading. Well, to be fair, LL's shareholders took a risk by investing capital and creating the platform. So of course they want to see some return on their investment. I would not call them parasites because SL would not exist without them. But yes, resenting freeloaders is shortsighted. The SL boom period of 2007 would not have happened if LL had not opened the gates for "freeloaders". If all the freeloaders of today became productive tomorrow, doing business in SL would be harder, not easier. And if all the freeloaders said goodbye to SL and hello to OSGrid, a lot of paying customers would follow them. Because the main thing that keeps people coming back to SL is other people. Don't underestimate the social value of freeloaders. After all, these people spend most of their in-world time on nothing but socializing.

cinda Hoodoo wrote: The trend has always been, those that can pay and are willing to, for services or products, and the free loaders. From an economic perspective, the term "freeloader" is ambiguous because it doesn't say anything about a resident's level of participation in economic activities. A content creator selling tons of prims and spending all his earnings on other people's prims is as much a freeloader as someone who does not buy and sell stuff at all. From Linden Lab's point of view, both are equally "parasitic" because they spend no money on the platform. Successful merchants who cash out more than they spend are actually worse than freeloaders. Their trade surplus must be offset by someone else's trade deficit, otherwise the in-world economy would implode. For the owners of Linden Lab, Second Life is a profitable product as long as the sum of resident spending exceeds the sum of resident earning plus the cost of running the platform. The result of this model is that SL business owners find themselves in competition with Linden Lab, because every dollar that is cashed out decreases Linden Lab's own bottom line. Maybe this explains why Linden Lab has very little incentive to help you become a successful SL merchant. Those who blame their own business failure on freeloaders have not really understood how this platform works. Think of it this way: Every freeloader is one competitor less to worry about.

Shelby Silverspar wrote: Yeah, why let pesky things like ethics and legality spoil your day... If you thought copyright was about ethics, this will spoil your day: Is Copyright Ethical? An Examination of the Theories, Laws and Practices Regarding the Private Ownership of Intellectual Work in the United States

OK, here's what usually works for me: The basic challenge is to separate the edges that you want to merge from those that you want to keep separate. Remove Doubles will ignore unselected vertices, but how do you select the right vertices if the mesh is a mess like the one above, with lots of overlapping? One method to do it is by temporarily attaching a Smooth modifier and applying it to the editing cage during Edit mode. Smoothing will shrink the unconnected parts of a mesh so that doubled edge loops get pulled apart and become visible gaps. Now it is very easy to select the opposite sides of such a gap using Alt-Shift + Right-Click and then applying the Remove Doubles function only to those vertices. The Merge Distance should be set as small as possible first and then gradually increased if necessary until the gap closes completely and the number of selected vertices (displayed at the top of the screen) is exactly half the previous value. After all the gaps have been merged this way, the normals can be recalculated and the Smooth modifier be removed. Unfortunately I can't upload screenshots from my current location. Maybe I'll add them later.

Attach a Decimate modifier to the mesh and see if you get an error message telling you that the mesh is non-manifold. Non-manifold meshes don't have a clear separation between inside and outside, for example if an edge is connecting more than two faces. Recalculating normals on such a mesh will fail and leave shading errors behind like the ones in your second screenshot. Sometimes meshes become non-manifold by accident if you remove double vertices. I see a lot of overlapping faces in that mesh, so this is likely what happened. If the mesh imports as several parts that you have to connect manually, don't use the Remove Doubles function on the entire mesh. There is a better way to do it which will avoid the non-manifold trap. I'll describe that in another post if you are interested.

Storm Clarence wrote: Lol, just simply lol. ETA: Now I see your humor! And I see you trying hard to dodge my question.

Storm Clarence wrote: Reread the thread Mas and you will find that It is you that offered nothing to the OP. Wrong. I offered help in case the OP ran into trouble with hybrid graphics on a laptop. How about you start offering an answer to my question instead of filling your posts with hot air? What is wrong with the way the OP installed Second Life? How exactly should he do it instead? Why "MUST" he learn "the tools"? Why is he going to find himself in a "nightmarish hell" if he doesn't? Those were your terms if I remember correctly. Oh, and where is that manual you claim to have written? This is your chance to share your infinite wisdom, Storm. Don't let us down now!

Storm Clarence wrote: I wrote about RTFM and to learn the tools (my exact words.) So, when did the kernel become a tool? Or are you trying to impress me again? OK, you didn't get the kernel joke, so let me paraphrase: Why should someone learn the tools if all he wants to do is run an application? By the way, you did not only suggest to RTFM. You suggested to make protected system folders writable so that the SL updater would work. Since you insist on accurate quotes, these were your words: 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! After I told you why creating writable directory structures within the FS hierarchy is a bad idea, you replied: PS Thanks for the lecture on Linux file systems. The OP sure needs it. But, do you think he understood? I do respect arrogant people if they have the skills and knowledge to justify that arrogance. But you have neither the skills nor the knowledge. Your desire to appear "1337" and make an impression on newbies makes Linux look much more complicated than it actually is. This is why I said people like you give Linux a bad reputation. Oh, and you didn't get the geek card joke either.

Storm Clarence wrote: Classic! Don't follow my advice to RTFM to acquire basic Linux skills and learn the tools. Just wonderful! You are really full of yourself aren't you? You sure showed me up. Why should the OP learn to compile a kernel if all he wants to do is run Second Life? Didn't you get the memo? Linux is mainstream now. People have it on their smartphones and tablets. Hell, I even have it in my bedside clock. What do you think I do in the morning? Launch a shell and enter a command line to turn off the alarm? If the OP had followed your advice, he would have screwed up his freshly installed system. Maybe that was your goal, I don't know. At any rate, you seem profoundly disappointed about the fact that SL is running on the OP's computer without a hitch.

Storm Clarence wrote: PS Thanks for the lecture on Linux file systems. The OP sure needs it. But, do you think he understood? I wouldn't worry about the OP. He solved the problem all by himself and was smart enough not to follow your advice.

Storm Clarence wrote: What? Placing third party software in your home directory is convention I do not follow. Who ever suggested 'breaking rules" but you and Mas? I certainly didn't. What I suggested is that misbehaving applications do not belong anywhere except in a user's home folder. I pointed at WINE as an established software implementing that rule. You were suggesting to break the rules by making parts of /usr or /opt user-writable so that SL can replace its own binaries at runtime. There is a reason why UNIX and Linux strictly separate executable files from variable content instead of mixing it all together. Executable files are supposed to be modifiable by no one but the system administrator, except if they reside in a user's home directory. Under no circumstance is a writable folder supposed to end up in the system $PATH. If we teach newbies that bypassing these rules is acceptable, then developers like LL have no incentive to improve their code, and Linux will quickly become the next Windows 95 in terms of security. I repeat: As long as the SL viewer is not behaving like a UNIX/Linux application, it is not supposed to be installed like one. Period. What people do under their user accounts inside their home folders is unlikely to jeopardize system integrity. So yes, running SL from a download folder somewhere below /home is perfectly fine. Changing system folder permissions is not.

That's right. I find it ridiculous how some people keep claiming that mesh payment info was Linden Lab's idea or, even more ridiculous, that it was somehow required by law. Has anyone ever been asked to provide RL info to upload a YouTube video? No. Does that keep Google from complying with the DMCA and keeping their video platform legal? Of course not. When LL announced mesh, there was a huge outcry by content creators who feared that mesh would destroy their old-school prim-based business. There were numerous proposals to cripple mesh in various ways to make it cost-prohibitive, less competitive and less disrupting to the in-world economy. The idea behind payment info for mesh uploads was to raise the barrier to entry for mesh creators. In fact some people suggested to make mesh upload a premium-only feature or introduce a special mesh developer program with paid membership. This was always about protectionism and never about copyright. When I and a few others actually suggested to make payment info a requirement for ALL uploads, you could suddenly watch all those staunch IP defenders bend over backwards to protect their right to steal images, textures, music, sound effects and animations with impunity. A double standard, if there ever was one.

Object properties are like a lens that is used to look at the mesh. When you change object properties, you are not changing the mesh itself. You only change the lens to make the mesh appear bigger or smaller, squeezed, stretched or otherwise manipulated. Ctrl-A applies one or more of these effects to the mesh itself and then resets the corresponding lens property to default. Alt-G, Alt-R and Alt-S on the other hand reset lens properties without applying their effects to the mesh. Modifiers (such as Mirror, Subdivision, Decimate, Shrinkwrap, Armature etc.) are extensions to that concept. They also do not modify the mesh itself but make it appear different, until you either apply or delete them. Modifiers are extended object properties, which explains why you have to be in object mode to apply them to the mesh. What's cool about this concept is that you can make several linked copies of a mesh, attach different modifiers to them, and then watch all the copies change in realtime while you sculpt the first one.