|
|
|
Yeah more textures to download but normal maps would be cool! Id like to see this at some point
not sure if this is 'relates' or 'duplicates' for: VWR-1155: User-defined bumpmaps, as I am not sure on the difference (if any) between a "bump map" and a 'normals map'
Bumpmaps from my understanding use only one of the 3 colour channels in an image so it appears gray scale.
A normal map uses all 3 channels in the image. For a better description you can read this. http://en.wikipedia.org/wiki/Normal_mapping  normal maps could be stored in the alpha layer, and have some method to tell SL to use as a normal map or an alpha map. That could cut down on texture download, making it the same size as any texture with alpha.
drawback would be that you cant have alpha + normal, unsure what other format (besides a raw file) would support multiple alpha layers. I think a problem with this may be the overhead involved, depending on the amount of usage. Whilst normal maps do LOD the number rendered by the viewer would likely need to be capped and there may need to be a strong effort to discourage people from using them on EVERY surface. The artistic requirements may help this as they are not trivial to create.
Normal maps requre three channels of data. Bumpmapping, also known as displacement mapping, only requires one.
However this is requesting normal maps. Which are a different format than (and superior to) bump maps. Since normal maps require three channels, using the alpha channel cannot work; they would need to be a separate texture, this is how they are done in any 3D environment which utilizes normalmapping; it is quite standard. As for load, it would only be for the prims that use them, I would suspect that not all or even many would. For those that do, many prims would share the same normalmap; it would be rare to use a different normal map just because you used a different texture. For example: a mall might have every buyable prim box showing a different texture, but they would all probably share the same normal map, so the total addition is only one extra texture. Therefore the added lag would not be noticable by the average resident. But all this is disregarding the most important point: How much this would graphically improve SecondLife. Normal mapping would allow for realistic lighting effects and illusion of polygon complexity currently not possible on the platform. Full-out custom normal mapping would go far to put the SecondLife viewer up there with all other 3D rendering engines. Do we really need to concern ourselves with Bandwidth on this issue? It's ONLY another texture. We're bombarded with thousands and thousands of those every day and I doubt that introducing Normal Maps into the world of SL is suddenly going to push us over the edge. Do people abuse Bump Maps? Not really. Would they if they could create their own? Probably not! You're only going to use them if you know how to use them effectively, and anyone that knows how to use them effectively will hopefully also use them efficiently. Otherwise, it's just bad content and we naturally stay away from it, more or less.
And, people can just turn it off if they don't want it. We gotta move forward SOME time, and this here wouldn't be a huge step being taken. It would be wonderful if the alpha channel of the normal map could contain heightmap information. This is the way it is usually stored in video games, and it allows parallax mapping.
http://en.wikipedia.org/wiki/Parallax_mapping As you can see, this can give the illusion that millions of polygons are in use, without overburdening the video card. This, and one-bit alpha, would probably be the two biggest visual improvements that could be added to Second Life. For those that would like to know more about one-bit alpha, see: It's worth noting that the client already uses normal maps for water, and one-bit alpha for trees. All we're asking for is the ability to use them for things we build. This should include the avatar skin and clothing. Those that object to the additional bandwidth consumed by downloading these textures, and the additional load on the video card to process them, could simply turn the feature off. Many already do this with the improved lighting Windlight provided, and the result would look very similar to what you see in-world right now. The surface texture would be there, as usual, and the surface would appear smooth and undetailed, like we're used to. However, I expect this to actually reduce the total load on the video card, since mesh data is more demanding than texture data. Fine details, like scales or screw heads, could be stored in a texture rather than prims. It's similar to what happened with sculpties. The average single sculpty prim can make the same shape as 10 to 20 (sometimes slightly, but not much, more) parametric prims. Sculpties have approximately 1024 vertices (the exact count depends on the stitching selected), and so do parametric prims (the exact count depends on the shape and parameters chosen), so the same shape made with sculpties is (significantly) more efficient. As for concern that this will be used to make Second Life unreasonably slow, there is no reason to believe this feature will effect that. Currently there is a popular avatar that consumes 200MB of video RAM, which can be readily verified by looking at the statistics display before and after muting someone. Thus, it is perfectly possible to make ridiculously inefficient builds with the features Second Life already provides. There is no reason to reject features that can have a positive aesthetic and performance benefit, like parallax maps (normal maps with a heightmap in the alpha channel), just because some people show no concern for their effect on the viewer. As a side note, the problematic avatar mentioned uses 1024x1024 textures for everything, even sculpties, which do not benefit from more than 4096 pixels, and this illustrates the problem of Avatar Rendering Cost (ARC) not considering texturespace. The only reasonable way to stop builds like this is to enforce a prim (count) and texture (total space, not number of textures) quota per avatar. Forcing Second Life to continue looking like something from around year 2000 is not reasonable. Added examples of a bump map and a normal map to show the difference between the two. I also added an example of one of the common uses of normal mapping.
aren't the hardcoded bumpmaps actually normal maps? (check their the texture called fromt heir UUIDs, I have a faint memory of discovering they were actually normal map can't go check it right now)
It would be lovely to support this both for prims and for avatars, although those would be different chunks of code and hence two separate features.
Hey I'm all for this I've hated how flat everything has to look on SL because we lack things like this :c
Three channel normalmaps + alpha layer for height map seems like the ideal request.
This is needed so bad. It should at LEAST be supported on avatar textures, if not prims also. It would allow us to create convincing avatars (even with the rather crappy meshes LL supplies us with) without needing to clutter the avatar with prims and sculpties.
All modern 3d applications use this. SL is so far behind, this is the least LL could do to bump visual quality forward a little. If the only concern is bandwidth, allowing us to use normal maps on avatars should not be a problem, should it? It would only be a maximum of three extra textures. With specular maps, add another three. That's a total of 9 textures per avatars. Normals and speculars could be capped at 512x, or even 256x, to further reduce bandwidth concerns. Really, it wouldn't be that hard to implement, and it would be a huge upgrade. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Feature Request - Normal Maps
I suspect that may be why we don't have this yet. Maybe. NEvertheless, if it's feasible, it would be nice.