Jump to content

Masami Kuramoto

Resident
  • Posts

    720
  • Joined

  • Last visited

Everything posted by Masami Kuramoto

  1. Zak Kozlov wrote: Hmm i'm not sure if i'm missing something but I have put those exact settings and gave it a try baking AO bring the same result, baking shadow bring a plain black texture You must bake in "full render" mode, and your target image must be of type RGBA, not RGB. To see the baked transparency in the UV/image editor, you must enable a view mode that includes the alpha channel, otherwise you'll see a plain black texture.
  2. Zak Kozlov wrote: edit; I forgot to mention i'm using Blender hehe
  3. Since Blender 2.58 it's also possible to attach reference images to Empty objects. This makes it easier to rotate the images, change their aspect ratio etc.
  4. Teddy Wishbringer wrote: It seems the SL population has dwindled substantially since I was last frequenting it, and I wonder if it's nearing the end of it's lifecycle. Sadly, nothing has really come along to offer a suitable replacement. I wouldn't worry about that. If Second Life gets shut down, those who are still interested in virtual worlds will likely move on to the hypergrid. Currently the biggest hurdle to OpenSim adoption is the fact that people have spent lots of time and money to grow their SL inventories. Once these inventories are gone, the prospect of starting from scratch in a truly open-ended world won't be so daunting any more.
  5. chuctanunda wrote: For using Blender in SL, you will need the Primstar 2 Addon. No.
  6. Kwakkelde Kwak wrote: I wonder if there even is a single resident with a computer that can't run a mesh compatible viewer. If there are any, I wonder how old those things are, 15 years, 20 years? How could you run SL on a machine like that? Example: Hamlet Au, ex-Linden and self-acclaimed tech blogger, is unable to run mesh viewers on his Alienware laptop from 2010. The reason? He's still using the original Nvidia driver that came preloaded with the machine. He's afraid to upgrade. In fact he keeps complaining about Linden Lab not bundling their viewer with the latest Nvidia driver. This is the kind of technological illiteracy we're dealing with. But it's only half the problem. The other half is content creators uploading unoptimized, lag-inducing, framerate-killing high-poly meshes straight out of Zbrush or Marvelous Designer.
  7. Susi Soothsayer wrote: Here are the mesh boots that show skin - there is nothing I can do to edit the boots or the alpha, there is nothing I can do to change my avatar shape. The designer very kindly tried to explain things like "RenderVolumeLOD" blah blah blah...tried it. It failed. So would any mesh geniuses out there know how to fix this product? Please? You can't fix those boots. Obviously they are poorly rigged, and the designer's suggestion to change settings in the viewer is nonsense, because even if that did fix the problem on your screen, everyone else around you would still see the glitches. The problem is that rigging is even harder than modeling, and many SL mesh designers already fail at the modeling stage. Poor topologies, excessive polygon counts and crappy vertex weighting are all over the place. You have to consider that most SL mesh designers don't have a professional background. If they did, they wouldn't create content for Second Life, because that would be the equivalent of a PhD flipping burgers at McD. Professional CG artists find much better paid jobs elsewhere, e.g. in the game industry, in advertising, movie VFX etc. However, that doesn't mean it was a bad idea to introduce mesh to Second Life. The feature has encouraged many prim builders to take the next step and become familiar with industry-level 3D modeling, and that is not a bad thing at all.
  8. Indigo Mertel wrote: Really? I thought that spilling from one UV island to another was to be avoided at all cost. Do you do this when you bake all maps (AO, color, normal)? Yes, I do that all the time. You will never see a bake margin spill into another UV island, because the process is adaptive, and the specified value is merely an upper limit. LOL! You are good at challenging my scarce knowledge on 3d modeling... Do you mean like this? No, I mean the vertex at the bottom between the front and back corners. The bottom is flat; there's no need for that vertex in the middle.
  9. All those artifacts are results of texture alignment issues. There may also be some intersecting faces involved, but I can't say for sure without taking a look at the geometry. Triangular UV islands are bad, especially if they are long and thin. Rectangles are good, especially on pixel boundaries. You can never completely eliminate visible seams when there are color gradients involved, but you can do a lot to minimize them. The UV editor has options and functions to align UV edges with an underlying bitmap image. You can select vertices and snap them to pixels. You can align rows and columns of vertices. You also need to consider the effects of "mipmapping": The graphics card maintains downsampled versions of all textures in memory (at 1/2, 1/4, 1/8 resolution etc.) and switches between them when appropriate. Downsampling also shrinks the bake margin, which is why seams can become visible when an object is further away from the camera. There is no reason to keep the bake margin at its default 2 pixels unless you bake in more than one pass. I always max it out at 64 pixels; it has no adverse effects on the result. By the way, the triangle in the second picture can be eliminated by removing the edge at the bottom. You will get two quads on each side and save at least two vertices.
  10. Indigo Mertel wrote: I thought perhaps the baking process had problems baking thin faces but the following image shows that some of them get partially baked: Thin UV faces are indeed a problem if they are less than a pixel wide and not properly aligned horizontally/vertically. Here's an extreme example: Usually the bake margin hides the pixel stairs at the edges, but if the faces are too thin so that the corresponding triangles cover less than half a pixel, no pixels get baked at all, and then the aliasing artifacts become fully visible in the form of gaps. Smart UV Project is not ideal for models like these because it doesn't pay attention to alignment. You'll probably get better results with Lightmap Pack. This will produce more islands but align them perfectly. If the lightmap layout extends beyond the texture area, use Pack Islands to rearrange it.
  11. http://www.xbdev.net/directx3dx/specialX/Fur/index.php
  12. Pix Jigsaw wrote: Does she mean she lights a model that has a normal and specular map and then bakes the visual impact those maps provide onto a diffuse texture?! Yes.
  13. Nalates Urriah wrote: On Ambient Occlusion... I doubt we will ever see that added into SL. AO is independent of lighting (it is from ambient light), so it can be pre-baked into the diffuse texture without detracting from the appearance. The specular effects can over shadow it to give it a more realistic appearance or at least in most rendering systems it does. We already have AO in SL, but it's part of the deferred rendering pipeline which is computationally expensive and therefore impractical on computers with less powerful graphics cards. This is why many creators still bake AO into their diffuse maps. However, as explained earlier, baking AO to diffuse maps limits their reusability and increases their size. We do it out of necessity, but it's bad practice and a terrible waste of resources. Light maps would be a much better option. Baked shadows are very useful at places where dynamic shadows are not available. SL's sun and moon require dynamic shadows because they change their position. Indoor lighting on the other hand is often static but consists of multiple light sources that cast soft-edged shadows. Light maps are ideal to simulate that, and it's amazing how small they can be when separated from the diffuse map.
  14. Gaia Clary wrote: As far as i know we will get these 3 mapping types: diffuse normal specular I do not know if we will get texture layers. What we get depends on how much noise we make. Mesh currently causes lag because of two issues: overdetailed geometry and oversized textures. Normal maps address the former, light maps address the latter. The problem is, once people get the means to control specular reflection, they will start baking AO and shadows not only into their diffuse maps but also into the specular maps, because shadow areas look convincing only if shiny highlights get attenuated as well. So in the future there will be two oversized textures instead of one. Shader-based light mapping on the other hand can attenuate both diffuse and specular reflection using the same AO/shadow texture, at zero cost. These textures can be very small because there is not much sharp detail in them. The potential savings in terms of graphics card memory and download times are huge as this would also increase reusability of diffuse/specular maps. However, I am confident that the developers will realize this and add light maps to the list. After all, they want to make SL better, not worse.
  15. Gaia Clary wrote: When you do point 4.) then consider to use "Multiply" for Influence -> Blend (in the texture properties). That is the intended (most useful) way to apply AO textures. Hopefully the upcoming materials upgrade for SL will include the option to apply these AO maps at render time, so that we can keep them separate from the main (diffuse) textures.
  16. Blaze Nielsen wrote: The statistics (and you can google this to verify) show that 9 out of 10 computers purchased over the $1,000 dollar mark are Macs. That is a very telling clue as to the usage of macs in the creative community. No, actually it's a telling clue that Mac OS users pay too much for their Foxconn PCs.
  17. Couldbe Yue wrote: Cris rarely bans people and it's only when they're completely out of control and refuse to modify their behaviour. As a forum moderator, Cristiano is as biased as it gets. There are a few SLU members who get away with literally everything, from trolling to stalking to defamation. I was banned after I had rejected a "privileged" member's Blender support request. After Cristiano had locked my account, that member went on to post defamatory accusations against me to "justify" the ban. One of the claims was that I had mocked the victims of the Touhoku earthquake/tsunami in the related SLU forum thread. Purely fictional and 100% contrary to the facts which are in plain view for anyone who bothers to look. I don't know how SLU gained its reputation, but I guess it's mostly due to SLU members like you boasting about it. However, it's entirely unjustified. The forum has a tradition of silencing dissent against the "party line" laid out by the members at the top of the social hierarchy, and even as an informational resource it is overrated. On topics such as SL content creation, people will find more in-depth and up-to-date information here in the official forum.
  18. Kwakkelde Kwak wrote: I'm just trying to grasp why LL doesn't want the lightmap because it would need its own UV map. Personally I'd say include it, in a lot of cases it would work just fine. I wonder whether LL cares at all. As usual, the whole process is as opaque as it gets. There is no communication beyond the weekly CCIIUG meetings. I cannot attend these. All I can do is post examples to demonstrate the potential texture space savings.
  19. The 2x2 layout is not ideal because a quarter of the UV space is wasted: Fortunately 2x2 is not the only available option. You can use 1x3 instead: Now your UV map looks much better: Of course I agree that a secondary UV map would make things easier. But diffuse + lightmap with a shared UV layout is still much better than no lightmap at all.
  20. Kwakkelde Kwak wrote: No, baking shadows is not rocket science, but you can stack a texture once baked. Only if the lighting supports the stacking. If it does, you can as well stack the lightmaps. It makes no difference.
  21. Drongle McMahon wrote: All that aside, it is Geenz who is doing the work, for which we must all be very grateful, and thus it is up to him to make the decisions. I fully support his efforts, whatever he decides. Maybe he just wants to keep the goodies for himself. :matte-motes-wink-tongue: http://forum.unity3d.com/threads/59077-Geenz-s-Shader-Stuff-Now-with-more-lightmap-shaders!?p=390518&viewfull=1#post390518 It seems that he does realize the value of lightmapping and knows how to implement the shader. Now all we need to do is convince him that SL is worthy of this feature. (And we're not even asking for advanced stuff such as RNMs.)
  22. Baking shadows is not rocket science. Many SL creators already do it, and they know that it usually takes a non-overlapping UV layout. This feature, if added, will not raise the bar at all.
  23. Drongle McMahon wrote: That prevents the huge economies possible with UV stacking and limits the pixel resolution of the sdn maps, EXCEPT in cases where the UV map can be laid out so that the sdn textures can be tiled. Whenever you can stack, you can tile as well. It just takes a separate material/face. However, once the shadows have been baked into the diffuse map, you can neither stack nor tile because the redundancy is gone. So you're still better off with a lightmap than without.
  24. http://modemworld.wordpress.com/2012/09/19/upcoming-sl-projects-update/2/ Lightmaps, however, will not be a part of materials processing. There are a number of reasons for this, which Geenz outlined at the CCIIUG meeting on Tuesday 18th September: “First off, never store the UVs for your lightmap in the same texture channel that everything else is based off of; they need to be in a separate texture channel where there’s zero overlapping faces. Second, in order to economize on texture memory, a batch of objects’ UVs would need to be “packed” to the point that you’re using as few lightmaps as possible. Then of course there’s the handling of lighting on dynamic objects; light maps only account for lighting being received on a static surface. So there’s a lot of issues that would need to be worked on if we were to do it.; but given the amount of work that would have to go into light mapping in order to do it “right”, it probably won’t be happening for a while.” Geenz is wrong there. Support for multiple UVs is indeed useful for a few things but not required for lightmapping. As explained earlier, lightmapping is so efficient because it separates the low-detail shadows from the high-detail surface definition. The result is a small "global" lightmap and one or more small (but tileable) "local" surface textures, instead of a huge global surface texture with all the shadows baked into it. Since a lightmap can be shared by multiple materials, it would be possible to use up to 8 different surface textures per mesh or prim without loading a new lightmap every time. Imagine a mesh house where the owner can use arbitrary texture tiles for the floors and walls without ever worrying about losing the nice prebaked shadows and ambient occlusion effects provided by the creator. All these things would work just fine with a single non-overlapping UV layout. And frankly, this must be the first time I hear someone dismissing lightmaps because they are static. Even the latest 3D computer games still use static lightmaps because shadows are essential to communicate depth and because there is still no way to achieve the same visual quality with dynamic lighting alone. And unlike dynamic lighting, static lightmaps actually work on low-end hardware without slowing it down to a crawl.
  25. Kwakkelde Kwak wrote: So what should be possible with three textures is this I guess: 1 High: RGB Diffuse, A transparency (like we have now) 2 High: RGB Normal, A Specular 3 Low: R Light, A Emission/Glow Let's make the third one RGB light + A emission/glow. RGB lightmaps are actually quite useful for radiosity effects or coloured shadows. Quick example following... No lightmap: Intensity lightmap: RGB lightmap: The textures:
×
×
  • Create New...