Masami Kuramoto

Gadget Portal wrote: The point I was trying to make is that we have been, and keep saying, that tablets are no good for SL, not enough power, etc., and there's Microsoft, stuffing the most powerful processor they can fit, inside a tablet. And the thing is capable of running a lot of software traditionally thought was only available on PCs, barring GPU intensive software. Which is significant. Which means- How much time before we see someone figure out cooling and stuff a good nVidia GPU into a tablet with that kind of RAM and CPU power? Ten years? Five? Even less? You are not paying attention. The tablet you are looking for is the Asus Transformer Book, unveiled at this year's Computex show in Taiwan. It has an Ivy Bridge Core and a discrete Nvidia GPU.

Gadget Portal wrote: People have been asking for mobile SL. Looks like Microsoft is bringing us one step closer to it. They've announced their own tablet capable of running traditional Windows software. All that's left now is for powerful graphics processing to become smaller to fit in their tablet. Sure, it's still no gaming rig, but it makes the iPad look like an Etch-A-Sketch. http://lm.pcworld.com/t/3536132/5573006/325062/0/ The Microsoft offer sucks, as usual. The SL-capable tablet you are looking for is the Asus Transformer Book, because it has the Nvidia GPU that the MS Surface Pro is sadly missing. But then again, is SL even ready for the touch screen? I doubt it.

In my opinion the most impressive thing about Cloud Party is that it just starts up. No OS-specific viewer to be installed and updated, no proprietary browser plug-ins such as Flash or Unity 3D, no Java... A plain web browser with WebGL capability is all it takes. Of course CP is taking some shortcuts to make that happen. For example, there are no region crossing issues because there are no adjacent regions in the first place. Neighboring islands floating in the sky convey a sense of proximity although they are little more than fancy landmark icons (and replaceable with user-defined objects). Very clever. Avatars cannot collide with each other, and they also seem unable to push objects. This considerably reduces the amount of data sent by clients or neighboring regions and shared with other clients through the server, a major contributor to lag in SL. Avatar geometry is very low-poly, but normal maps actually make the cloth wrinkles look better. The renderer even supports shadows. Remember how long we had to wait for those to arrive in SL? CP is an impressive WebGL proof-of-concept and a wake-up call to Linden Lab.

That's right, Edit mode can only see the vertices of the base mesh. However, you can import vertex positions from another mesh using the Reshape function.

The problem with Subsurface is that you can't edit the high LOD until you apply the modifier. And once you apply it, you lose the low LOD. With Multires all the lower LODs remain accessible, and while you sculpt one of them, all the others change accordingly. Since Multires has been implemented as a modifier in Blender 2.50 and later, you can even change the topology of the base mesh without losing all the work done at high LODs. And of course the higher LODs will automatically share the UV layout of the base mesh, so you need to unwrap only once, bake only once etc.

Fizz Savira wrote: On the plus side for sculpties is that you don't have to produce multiple versions at different LOD's, you just have to take LOD into consideration during your design. Sculptie LODs are the same thing as multiresolution meshes in Blender. You can enjoy all the benefits of mesh (free-form topology and UV layout, 16-bit coordinates, accurate collision detection, improved DRM etc.) without substantial workflow changes. Sculpties just don't make sense any more.

Nacy Nightfire wrote: However each overlapped "group" of uvs will then need to be seperated by material group Yes, but not necessarily at the time of baking. The input materials may be totally different and even use different UV layouts. Baking multiple images with a single click is a huge timesaver, especially when you do full render bakes for SL including shadows and highlights, because it's hard to get the lighting right the first time. Imagine you had to redo up to eight separate bakes every time you move a lamp...

One of Blender's less prominent features is that bake target images can be assigned on a per-face basis. So even if there are multiple overlapping islands in a UV map layout, it is still possible to bake them properly because a single bake operation can render to multiple target images at once.

Why people still bother making sculpties is beyond me. And frankly, considering the lag they cause, LL should disable new sculpt map assignments altogether.

Btw, unassigned faces appear white in textured draw mode, not black. In 2.49 and earlier they were drawn pink, if I remember correctly.

A normal map turns this... into this... without adding geometry.

Nacy Nightfire wrote: Yes unassigned faces wouldn't bake and the faces would appear black. That seems to be what Pamela was experiencing. They were no longer black after she flipped the normals and baked again.

Amras Sparta wrote: The problem is... the model is not inside out, but the light seems like the faces are on the other side. The vertex normals are inside out.

If the light is of type "sun" or "hemi" (= sky), then its distance to an object has no effect on the object's brightness. Sun and sky are always considered to be at "infinite" distance. A single sun in the scene will result in very hard contrasts between lit and unlit sides. Hemi lights, on the other hand, cause soft transitions. If you want to bake global illumination (i.e. fairly realistic light coming from all sides), you have to use a combination of multiple lights, soft shadows, ambient occlusion and possibly indirect lighting. This is tricky to set up indeed and takes some practice to get right. It would be easier with Blender's new renderer "Cycles", but unfortunately Cycles cannot (yet?) be used for baking.

Unassigned faces wouldn't bake at all, even after flipping the normals. Blender 2.63 is known to have some issues with normals. This could be one of them. There was a follow-up bugfix release 2.63a. Has Pamela installed it?

Hi Gaia! This is what happened, in a nutshell: Thread #1: Pamela: Blender keeps screwing up my AO bakes! Audience: It could be X, Y, or "Bake selected to active". Pamela: The problem just disappeared after I restarted Blender. It must be a bug! Thread #2: Pamela: Blender keeps screwing up my AO bakes! Audience: It could be X, Y, or Z. Pamela: The problem just disappeared after I restarted Blender. It must be a bug! Masami: It took you three days to try the trick that worked last time? Pamela: No, last time it was "Bake selected to active". Masami: wtf...?

.blend files, or it didn't happen. Does the problem persist after you restart Blender?

Ashasekayi Ra wrote: "We" don't know anything isn't true since we are not sitting at her desk when she opens Blender. I know for a fact that I have found errors clear up after a restart or after exporting/re-importing a model. It isn't that uncommon. "We" know because she told us so, right here, message #17. It was the checkbox that fixed it, not the magic restart. It was a wrong setting, not a bug. Her response in the other thread was deliberately misleading. Why does it matter? It matters because fake bug reports waste other people's time. Blender's development is community-driven; the quality of the software largely depends on the accuracy of bug reports. If there is actually a bug in Blender's bake function, I want to see it fixed, because I use that function all the time. It's essential for game models. But please, don't BS me with these magic restart stories just because you can't admit that your settings were wrong. Be accurate. That's all I am asking for. I reproduced the "bug" that Pamela described here. I can email you the .blend file if you like. It behaves exactly as Pamela described it, except that it isn't a bug. It's a perfectly logical result of two object duplicates sharing a single image. Pamela ran into a similar problem before. Many people do, because the depth of copy operations in Blender is not immediately obvious. I have no problem with that, but I do have a problem with people inventing BS stories to distract from the real issue. Blender does not "remember" previous positions of objects during a bake. But it does remember previous bakes, until you overwrite them. And that is exactly what happened here. Feel free to prove me wrong. Show me the evidence, and I will gladly forward it to Blender's bug tracker.

Jacki Silverfall wrote: Can't anyone with the same problem read the same thread and get the same answers as Pamela? I don't see why she needs to come back and say "hey it worked" when the information is right there in the thread. Hardly anyone comes back to give gold stars. And we shouldn't expect it. It's not about giving gold stars. It's about documenting the solution for other users. It's not about saying "hey, it worked". It's about saying "hey, THIS worked", so that others can take a shortcut instead of trying all the different suggestions again. Pamela did come back to the other thread, falsely claiming that the correct solution did NOT work. Here's the quote: Pamela Galli wrote: I selected that after it started bakingc something besides the selected wall mesh. My understanding is that you can bake one object mesh to another,c something like that. The fact that the problem disacppeared on restart tells me it was another Blender bug. Which is why I am not asking about Blender baking problemJs any more but looking for something else to use. Keep in mind, she said this AFTER someone correctly identified the checkbox that caused the problem. A simple "Oops, that was it" could have concluded the thread and would have kept others from investigating any further. But no, she insisted on blaming the tool. No one was asking for a gold star. Basic courtesy, an alien concept? Now she's pulling the "magic restart" story again. Excuse me, but I see a pattern emerging there.

Ashasekayi Ra wrote: Wow Masami. What exactly are you trying to accuse Pamela of? Making up bugs to make Blender look bad or having actual bugs that she doesn't share the fix to? It really can't be both. As for her sharing .blend files, why would she since she is obviously working on merchandise for her business. When someone posts a problem on this forum, none of us are obligated to respond or "waste their time" as you put it. I'd also point out that there are a number of threads on this forum where people new to Blender post a question and come back later and say "nevermind, I figured it out". She is hardly the only one. It's a matter of courtesy, Asha. If your call for help in a community forum results in multiple responses suggesting possible solutions or workarounds, you don't just walk away after you got what you were looking for. You contribute back by sharing the solution that worked for you -- especially if it is one that you figured out by yourself --, so that the thread is useful to other people running into the same problem later. Pamela doesn't do that. The last time she had a problem with ambient occlusion bakes, she didn't even give a nod to the person who pointed her in the right direction. Instead she claimed that the problem magically went away after a program restart. Today we know that this wasn't true. And here we have it again. The miraculous program restart that fixed everything -- after three days! I didn't expect her to share the entire .blend file she was working on. I asked her to isolate the problem in a smaller model which contained nothing but those few elements that were causing the trouble, so that someone else could take a look at it and eventually attach it to a bug report at blender.org. Apparently I was already asking too much. You are right, sometimes people post a question and immediately follow it up with "Never mind, I figured it out" if the answer is obvious. But very few people do so after several days of guessing and a dozen suggestions. Because that is just impolite. And it is also short-sighted because people may feel less inclined to help in the future once they realize that favours don't get returned.

They only abandoned the sidebar. The rest of V2 is still there.

Pamela Galli wrote: That is not the same issue -- that is issue was caused because I had some box checked that I should not have, which someone in the thread identified. After the checkbox was identified as a possible cause, you insisted that it was not checked when you started the bake, and you claimed that only a program restart magically fixed the problem. Now you are doing the same thing again. You are asking us to believe that after three days of searching and trying, a simple restart suddenly fixed everything. You gladly accepted all the helpful clues but now refuse to share the actual solution, just like last time. Probably because that information could be valuable to other people struggling with Blender, who may end up becoming competitors. Eat the free lunch and keep blaming the cook, that is your motto.

Pamela Galli wrote: Anyway I restarted Blender and it baked fine on both Wait a minute... Are you saying that this was your first Blender restart since the beginning of the thread? You moved the railing around, fixed the textures in Gimp etc., but you didn't restart Blender until now? You've got to be kidding. Don't get me wrong; if this is in fact a bug in Blender, I'm all for reporting it and getting it fixed, which is why I'm here, wasting my time trying to figure out what's going on. However, there are some things odd about this one: You keep reporting the same issue again and again, see here. You never provide a .blend file, only screenshots. No one ever manages to confirm the bug. After about three days, you say: Never mind, it's fine now.

Pamela Galli wrote: I sort of reproduced it. The railing is between two columns, so after I moved the railing up and baked the other column, Blender remembered where the column had been before I moved it up. So I can have the railing match one column or the other but not both. I think you created the second column by duplicating the first but forgot to make single-user copies of the assigned image. Both columns now share one image, and every time you bake either of the columns, the bake result of the other gets overwritten. It is not a big deal, I can fix it in Gimp, just wondered if anyone here knew what the deal was. Only noobs fix broken bakes in Gimp or Photoshop. Come on, Pamela, you can do better than that.

Can you isolate the problem or reproduce it with a smaller model, e.g. two cubes? Or at least have Nacy take a look at it. These things are not supposed to happen, and changing the model to match the bake is hardly an acceptable solution.