RipleyVonD

Hey Cathy. Yeah he's from IMVU, I needed a quick avatar to represent my online self. I've been meaning to recreate him, or something very similar so it can be my avatar in SL but my real life job keeps me pretty busy. I work five days a week, after work I'm tired, and on my days off there's always something to do or go to, its an endless cycle. lol I managed to learn SL's marketplace system which was a great investment of time, and also took the time to learn Linden Scripting and HUD building. Currently I'm waiting for materials scripting functions to be finalized so that I can start creating more stuff for my store that includes an HUD with Materials functionality. From what I can see the code for a similar system on the SL Marketplace is already partially implemented. I noticed you can set royalties for products, products that are created by yourself and another creator. It seems with some tweaking and testing a partially working royalties system could be up and running in no time, but again I'm only guessing since I have no actual experience with how the Marketplace works internally.

Yes it seems like a bum deal buying a full perm item that requires royalties, but a system like this in place would allow selling full perm items for free and earn income with royalties. A scenario i had in mind was encouraging some one that is interested in modding full perm items and starting without investing money upfront, money they probably don't have to get started. I thought this would also encourage people to get familiar with modding textures for models and might find that they actually enjoy doing so. Then later with some gained confidence and experience in texturing and some earned lindens they could buy more advanced full perm content that's a bit more pricey and does not require royalties. I wasn't hoping to have more control over the content I would make because I am greedy or anything, sorry if I gave that impression.

Something I've wondered for a while now is whether the permissions system in SL would get an update at some point in the future. Something I would like to see implemented is having control of starting price and royalties earned if someone were to purchase a full perm item from my store. It seems like a simple fix, but maybe not Im just guessing. Has anyone heard of updates relating to the permissions system in SL? P.S. I just thought this probably dosent go here, if a mod can help thanks.

A better question would be: "Is swearing against the TOS against the TOS? :smileyvery-happy:

"Material face" sounds right to me, and what I would of suggested if I had been present in that meeting.

I stumbled onto this post in a Google search trying to find away to switch alpha modes with LSL but no luck. The only work around I can think of is always have your target Alpha Mode set and control your transparency or emissivity with your Alpha channel by switching textures. I haven't tried it yet but it should work, the down side is your making an extra texture to pull it off. But it probably dosen't apply to your needs.

That's a fresh idea. That's Good, I haven't stumbled on anyone else mention that. I wonder how much effort would be involved in implementing something like that. Even if this would get implemented it would only attract my attention if Normal Maps were also supported along with that. Mesh bodies have my attention because of Normal Map support, I am so ready to start working on a Fitted Mesh body but I'm currently distracted by Linden Scripting, its a must, a necessary evil. LOL Just like UV mapping.

I thought of working on a mesh character and matching the UVs to the default avatar's, but those UV's are not something I want to work with. lts been ten years since that model was first mapped, UV maping tools have advanced significantly, and there are better ways of UV mapping a mesh character. The huge inventory of skins and clothing compatible with the old UV mapping is very appealing, but I would rather UV map a mesh character with UV's I think are ideal for easy texturing.

HD Pomeray wrote: This is not a new SL avatar. They use the same old avi. These are just fitted mesh bodies that are worn over an alpha. No different than the ones offered in the Market Place. Crap, I thought so. @ Sassy Romano Are those UV maps the new mesh avatar on the left and Mixamo avatar on the right? I did a quick search for Mixamo character UV maps and didn't see anything right away.

I was pretty excited to check them out, and I headed straight to the Zombie characters. lol Just the snapshots of the heads look so much more modern, but for some reason when I click their thumnails nothing happens. I see a short loading animation for a second and then nothing. I stumbled on a post on the SL Universe forums who is having the same trouble, and we are on the latest LL viewer. That's alot of great Ideas Cathy, and since these are mesh avatars I would hope theirs a sort of clean slate for LL to consider improving them with out hesitation, but I get the feeling they are still relying on old Avatar tech somehow so I imagine its gonna be the usual pace LL moves at in improving things... Yeah... I know. :smileysad: The new Avatar headshots remind me alot of Mixamo characters. Seriously, which wouldn't be bad... I think. https://www.mixamo.com/fuse

I'm looking foward to checking out the new mesh Avatar's UV Mapping and weighting. Any word if we'll get some source files to develop for soon?

I was real hesitant to say it's a bug given all the hard work the Linden Lab programmers put into implementing Materials code, but after considering everything I've seen sofar it kinda seems like it is. This kind of bug is madness inducing. LOL Foreal. :smileyvery-happy:

Manually painting Normal Maps to fix seam issues, seems like extreme measures. I remember manual editing back in 2005 when I would edit FarCry Normal Maps (I was so green then lol) back then I would use Nvidias DDS Plugins for Photoshop. This plugin had an option to Re-normalize your Normal Map after editing it. http://www.bencloward.com/tutorials_normal_maps12.shtml I do some manual editing to my normal maps and they turn out just fine without re-normalizing, its probably because of the type of editing I choose to do, I don't dare touch the colors on a Normal Map in any way, flipping channels or anything. The only manual editing I do is clean erase in pencil mode to combine details from two different bakes of the same UV Layout, or paint in a Normal Map's base color to shave off some height (with the brush tool) or to completely remove height on a Normal Map. I usually bake out two different bakes to try and get correctly baked details in different areas and then use the erase tool in pencil mode to combine correctly baked details into one map. Thats all the type of editing I dare try in Photoshop, but I rarely try and paint in a Normal Maps base color to adjust height, I would rather fix surface details on my high resolution model. I haven't had the need to fix Normal Map seam issues by manually painting a Normal Map. I usually add enough edge padding, keep my seams away from flat surfaces, and try to keep my islands right side up. In some cases you will need to add a seam on a flat surface, but like you saw from your example don't rotate your Islands unnecessarily, try to keep them in close relation to how they actually look on your model. Getting a perfect bake on complicated models in one shot can be difficult sometimes, so i adjust my settings and bakeout at least two maps, then in Photoshop I combine correctly baked portions into one map. Another thing, never resize your Normal Maps with a filter that adds a sharpening effect, it can be done by accident. Normal Maps don't need a sharpening effect applied to them they are not treated like regular diffuse textures. I hope that helps, goodluck.

RipleyVonD wrote: With this Normal Map you are getting close detail definition and no uv seam, yes because of the angle of the UV Layout matching square pixels, but also because they are using very close pixel utilization. Along the seam is one of the most important area to match your pixel utilization and ensure the UV Island are closely sized. If these two issues don't fix your UV seam then the last thing I can think of is Triangulating your mesh before you bake your Normal Map, and make sure you upload that exact mesh you Triangulated and use only Normal Maps baked from that same Triangulated mesh. Triangulating before baking your Normal Map is something that is supposed to be done also. One more thing I use significantly smaller checkerboard squares to to test my distortion amount on my meshes, about 1/4 the size of the squares you are using on your checkerboard. I've nearly exhausted myself from sitting infront of my screen. lol I'm gonna call it quits for awhile good luck. In this post I wasn't supporting this type of UV mapping for an organic shape like the body, I was just pointing out the few things it was doing right that can be applied to the proper mapping.

Yesterday I spent some more time thinking about what was happening with this UV seam, until I decided to import the mesh and Normal Map Jake sent me into Marmoset Toolbag, to see if the Normal Map would be interpreted correctly. Marmoset Toolbag is a great program for testing your 3D Models and Textures in a realtime renderer and its really affordable. Part of Its business model is accurately presenting Artists work (IMO) so I expected to see accurate results. The Normal Map is working correctly like I would expect it to work with its edge padding. It seems Second Life's tangent space interpretation of Normal Maps is different. Yesterday I didn't spend too much time wondering why the UV seam on this mesh was so resistant to getting fixed because I then realized I myself would never create such complicated UV islands on such a simple surface. All this mesh needs is a flat projection and one UV island and that's all. The UV seam here was created from improper UV mapping, and as Jake stated rotating the Island to match the other Island fixes the UV seam. This example isn't a realistic example of a Normal Map seam. The UV seam on your male character is a real world example of a UV seam that can be fixed. When I said UV islands weren't dependent on angle that's assuming you choose your UV seams in places where you find hard edges, places where your UV islands split your vertices's, and also keeping your UV islands right side up as possible to closely match what you see on your model. When I look back at my castle's UV mapping (my first SL project) I mostly have my UV seams running along hard edges away from large flat surfaces. If I do have a seam splitting a flat area its usually away from view and its part of the same UV island usually keeping both ends of the split right side up because its from the same island, thus not showing a seam. Normal Maps work good enough at the moment from what I can see with my castle, but good practice with UV mapping is essential for a good result to avoid UV seams. So that brings me to Jakes male UV seam I still wonder whats going on there.

This is about the most resilient Normal Map seam problem I have ever encountered. lol I'm gonna need to take sometime and really think about what the cause is. That last simple example clearly has nothing wrong with it. This is almost like a seam that actualy exists with unmerged geometry. Just weird.

I forgot to also ask a key question. Which viewer are using? I'm using the latest Linden Lab viewer. Last thing I can offer is baking the Normal Map myself for that cylinder example and take a inworld screen shot.

I forgot to mention this last thing. Select all your faces and align your normals before you bake. That's all I can think of at the moment.

With this Normal Map you are getting close detail definition and no uv seam, yes because of the angle of the UV Layout matching square pixels, but also because they are using very close pixel utilization. Along the seam is one of the most important area to match your pixel utilization and ensure the UV Island are closely sized. If these two issues don't fix your UV seam then the last thing I can think of is Triangulating your mesh before you bake your Normal Map, and make sure you upload that exact mesh you Triangulated and use only Normal Maps baked from that same Triangulated mesh. Triangulating before baking your Normal Map is something that is supposed to be done also. One more thing I use significantly smaller checkerboard squares to to test my distortion amount on my meshes, about 1/4 the size of the squares you are using on your checkerboard. I've nearly exhausted myself from sitting infront of my screen. lol I'm gonna call it quits for awhile good luck.

The only thing I can think of at the moment is there is not enough edge padding. Can you show your current Normal Map? Or Is it the same one I saw above? If its the same one I saw above, it still needs more edge padding. Dont worry about pixel amount in edge padding focus on how much is actualy extending away from the UV Islands. Strech the UV padding atleast as much as i did, or a little more if you need to. It seems to me the Back UV island around the waist isnt using the same amount of texture pixels producing less detail definition. Below is the edited Normal Map showing how I would ensure the waist ant the pectoral area are reasonably closely sized along the UV seam. Of course the UV Island would need to be edited and then rebake the Normal Map.

Can you double the amount of your blocks? Those blocks might be too big to notice small differences. Actualy, no they are reasonably closely sized.

Jake Koronikov wrote: After a second look, it seems like the UV Island that represents the back isn't sharing the same pixel texture space as the UV seams around the waist and the pectoral. The only way to remedy this is to use a larger size texture or stretch that part of the UV island to match the size of the other UV Island. Testing your UV Island with a checkerboard texture is good to unsure some parts of a UV Island is not overly reduced or enlarged. Before baking out your Normal Map its good practice to check and ensure your UV Islands are uniform as possible. This should be the reason why it works with your other UV Layout, because the other UV Layout looks reasonable sized to the other UV Island. This can also be achieved with irregular sized UV Islands you just need to ensure some parts aren't overly reduced or zoomed out. You can use a checkerboard texture and adjusting the square sizing to spot the reduced and zoomed parts.

It seems like all you need is to add some more edge padding. Here is one of my normal maps, I didn't worry about UV Island shape or angle. I added a good amount of edge padding, add a good clearly definable amount of padding. There are no UV seam issues with this Normal Map at all it works perfect. From my experience edge padding seems to stop when it meets itself so it dosen't seem to bleed onto the UV Islands themselves.

Jake Koronikov wrote: That is true, there is some misinformation, because UV islands *should not be restricted to 90 angles*. However, in SL engine one cannot make Normal Maps work properly if the island borders are in some other angle than left-right or up-down.... As an example: If you have a human body uv map where upper body is unwrapped naturally up-down direction (neck up, waistline down) and lower body is for some reason unwrapped left-right direction (toes right side of uvmap and waistline on the left side of map)-> result is a bad seam between upper body and lower body when rendered in SL. And this is the whole point. Why in other shaders the UV seams can be in any angle but not in SL shader engine. This baking one uv into another uv is of course a bad hack. But it was the only way I could get rid of most of the ugly seams. And you are right, normal maps are uv layout specific. The map has to be baked and used with same uv layout. Otherwise the tangent space is broken. I have been studying a lot about this UV island issue on other forums, and they admit that in some shaders there is issues (or bugs) that cause false rendering. But can this be interpreted as bug or as a feature in SL? I read alot of those same threads and posts giving me the sense that the Normal Maps I would bake would not work correctly. I have baked flawlessly working Normal Maps just recently. As long as the viewer code dosen't change, they should continue to keep working ok. As I stated before Normal Maps are not dependent on UV Island shape or angle, UV seams are fixed by adding "Edge Padding" around the bake of your UV Islands. The tangent basis of Second Life and baking software is not significantly different because I have them working just right. When you bake a diffuse texture to another UV Layout in Blender you also have the option of adding "Edge Padding". If you fixed you seam issue's this way its likely edge padding was added in the diffuse texture baking process doing the exact same thing baking out your Normal Map with edge padding would of done. Baking a Normal Map to another UV Layout using diffuse texture baking is like making a copy of a VHS tape losing fine detail.

Jake Koronikov wrote: I am actually answering the previous post myself. I found out interesting issues regarding uv-seams, normal maps and shader engine. Quote: Conclution after several tests: To get baked normal map (at least baked by x-normal,blender or zbrush) work correctly across UV seams -> UV seams has to be aligned left-to-right and up-down, eg along the uv-axeses. This means about like tiling the uv-seams, as mentioned above in the last paragraph. This kind of aligning ruins the whole UV map of more organic model. The only workaround I found was to make a temporary UV map with all seams aligned to the axeses and baking normal map to those uv islands. Then I took the resulting normal map as a "diffuse texture" and baked it to the final uv-map. (In Blender you could think this as 'bake with bake mode textures', original normal map as texture, and coordinates UV mapped according to temporary UV) ETA: Afterwards I noticed the final uv-islands require some additional flipping. Seems to be they have to be 90 degree angle compared to original ones, and mirrored... so ..umh...looks like not a suitable for everyday thingies... Their is some misinformation in this conclusion. UV Islands are not restricted to 90 degree angles in order to bake out a properly working Normal Map, if this where true Normal Maps would not have been widely accepted as they are now. Some models are gonna have irregular UV Islands with no real sense of what is 90 degrees or any other angle for that matter. Baking a Normal Map as a "diffuse texture" to a different UV Layout is a messy hack that will never produce properly baked out Normal Maps. A Normal Map is unique to the UV Layout it was baked to, if you change your UV Layout you need to rebake you Normal Map. Normal Maps are suitable for any kind of model, especially low-poly models. Linden Lab went through a great deal of trouble to implement Normal Maps into Second Lifes rendering engine because they new the benefits of their use would give people the option of not having to resort to using extreme triangle numbers in daily uploaded geometry.The solution of Normal Maps was created over a decade ago and professional Artists and Game development houses haven't looked back since. And finally their will not be a situation where the use of more triangles over the use of Normal Maps will be favored. CPU and Memory resources will always have better things to do than being used on an unnecessary amount of triangles. Real time: Ambient Occlusion, Global Illumination, Subsurface Scattering, Liquids, Cloth, Physics, Particle Effects, Spatial 3d Audio, Post Prossecing Effects, Dynamic Lights and Shadows, AI, Ragdoll, Procedural Terrain Texture Generation (the list goes on and on) are all better suited for CPU and Memory resources than rendering more triangles. I still haven't researched the performance hit that comes from using the Oculs Rift but I imagine their is some, which is another example for better suited CPU and Memory. Of course alot of these effects arent availible in Second Life but the Oculs Rift is, and dedicating CPU and Memory for the Oculs Rift and real time tracking, and tracking devices is alot better suited.