Adding more detail to prims through a texture.

Rounding the corners of a cube, putting a hitmark dent on a tank, wrinkles in cloth, scales on a dragon, all possible with normal mapping.

Ill just get to the example.

Basicly Normal Mapping is like bump mapping but instead it used 3 channels, Blue for height, and Red and Green for X,Y.

Basically..

This,
Will become this.

And that would be just one prim.

The Big difference in bump mapping and Normal mapping, is that with NM, the normals, the lighting, etc will change in realtime based on camera angle and the lighting. Making the "Bump" look like its actually a bump.

Here is a fairly good tutorial on normal mapping.

If this feature suggestion were to pass, also it would be usless if we were restricted to preset maps, like we currently are with bumpmaps.

Here is the Preposal on the voting system.

Edited to add voting system link.

Stop it! Stop it! You're going to make me cry, because I've wanted this for the past half year or so.

This won't happen until the SL renderer/stream technology supports more than one texture on a prim. Texture data is very voluminous, and adding just a second texture to primitives doubles the data you need to stream. QED.

It's getting there, though. If you're interested on my $0.02, see here.

Well im going to (probably nieve-ly) believe that if enough people VOTE for it, it will happen sooner than later,

And really downloading more textures would not be an issue.
I mean if it really is, then there could just be a "ignore NM textures" option.
Ide rather stand around a bit longer to look at something that looks pleasing, then "most" of what I look at now.
Not saying people are bad at building/texturing, just that if things could stick out instead of looking like a sticker"decal" on the side of prims, Like burners on a Playschool kitchen set, sl as a whole would look a LOT better.


For the mostpart, Normalmap textures would not need to be as high-res as "diffuse" textures.

Imagine what Normal Mapping could do to the PrimHair industry.

Wow I think thats gonna be my new sig.

I gave it a vote.

How much corner/edge rounding could you really get with normal mapping? And would collisions still be handled by the base prim?

Conversely, if you used the normal mapping to make really deep dents in the middle of a relatively thin surface, would it make holes one could see through? Pass through? (I suppose you could do the see-through part with a texture with alpha windows.... but would the interior edges look right?) Could this give us the ability to make extruded shapes, at least fairly thin ones like, say, fancy ornamental metalwork railings?

neko

As of the Town Hall, I stand corrected.

See my responses here.

normal mapping is known since ages, the fact is that since there is no texture restriction in sl it would be DAMN resource consuming, i burn normal mappings in my clothing but yeah

until we get a light speed engine i would give up any attempts of multitexturing

Normalmapping only changes how lighting works with the object.

The different channels tell the engine what way to face the normals for the lighting to "shine" on them.
You could make a normal map that had its blue channel set below 50%.
That would "flip" the normals , but remember its only changing how the lighting is projected, so doing this would not make the object transparent, but rather flat black.

Regardless of how many bumps, vents, or warts you put on a cube, the normalmap wont change the physics of it.

And I dont know how well you could round corners, I do know it could be done, but to what extent I dont know.


" fancy ornamental metalwork railings" yes exactly, this combined with a good texture could make 1 prim railings,etc. that look great.

Another example: http://www.blender3d.org/cms/Normal_Maps.491.0.html

And no, it cannot "round corners" all that well. At best, it'll smooth the look of an existing model.

For rounded prims, I've been asking for Doo Sabin Subdivision since half-past forever. Unfortunately, that would screw with the physics of the object.

I really thought more people would vote for this. Considering how high res some of the textures being used are and how low res a map should be, I didn't think it'd be that difficult. We've got gobs of lag from high res textures so if we're careful with the others, it shouldn't be too bad. Or am I missing something?

how could a map and a lower res texture be more difficult than a 1024 single? Even the in-game snapshots can lag a sim horribly when you try to display them without taking them oog and resizing/converting them.

Then again, I miss lots of stuff...

Thanks LordJason for opening this discussion.

I would love to see normal mapping in SL. I'm not sure how feasible it is, but it was be incredibly cool if we ever get it. I'll give it a vote when I get some back.

We also need to have a shader making system to accompany this. That would allow for some wonderful looking creations with complex behavior.

Just have a look at the beauty of normal mapping and shaders.

http://www.unrealtechnology.com/html/technology/ue30.shtml

All the models on their site don't even break the 10,000 polygon mark, but have the detail of 1,000,000 polygons because of normal mapping.

We should also include High-Dynamic-Range lighting and Dynamic Dual-Paraboloid Omnidirectional Soft Shadow Mapping (http://www.doomiii.jp/slang/flx_demo_pa_1_0.htm). Both of these would really bring the world to life. =)

Why not simply bake the textures together, much like tattoos are done for the avatar. The only problem with this method would be that it would increase the amount of data that a prim would take up when stored in the database (you'd need to store the baked texture key, the texture keys that compose that baked texture, and the properties of the composing textures (offset, rotation, scale, etc)). Streaming time, however, wont be affected since your just sending one texture (the baked texture) to the client. The composing textures (and their properties) dont need to be streamed to the client unless the client is editing the prim.

In fact, I wonder why we aren't able to specify an unlimited number of tattos for our avs via this model...

Baked textures might not work for normal mapping, since the shape of the prim is affected by whatever's on the texture, but why not make the Normal texture a property of the object (much like cut, sheer, hollow, etc is for cubes) rather then treat it like another texture. The object tab's options for a Normal primitive would have five fields: position, scale, rotation, material and Normal map. The texture tab for a Normal primitive would be the same as it is for primitives now.

Collisions are a big problem that I haven't addressed though. That might be a bit difficult to handle with Normal prims. I wouldn't really care if they weren't implemented though. I would just link regular prims to the phantom Normal prim to approximate the Normal prim's collision skeleton.
==Chris

when i generate normalmaps, i've got the high rez model (hundreds of thousands of tri's) and the low rez (couple thou). both are meshes in order to map the vector displacement from high to low. both are centered for this to work properly. so i'm wondering how this would really benefit SL. prims aren't meshes. and to my knowledge, we'd need a tool to emulate how LL tesselates prims in order to properly make that vector property transference; if you have a single quad (one side of a cube prim) and it tesselates to two tri's, which way are they flipped?

if LL implements normal mapping, i'd want more than the pseudo-nmaps i've seen using PS plugins or photo image tricks. i'd want the real deal.

am i missing something here?

Refer to the thread I liked to above:

/13/38/48182/1.html

Basically, they want to move to a materials system. In my experiences, that kind of system works with nearly every texture method on the market, if added.

Well I do not think people will be using "SL models" to nm "Sl models".
That would require a mesh exporter/importer of some kind.

One of the big reasons behind requesting normal mapping is, Because we are restricted to prims. It would just make things nicer.

One way to make a normal map besides the Gimp/Ps plugin trick,
Make a complex mesh, give it a flat white material.
Put a blue light in front of the model a red light to the right, a neg red light to the left, a green light above and a neg green light below.

Then render the image from the front view. Or whatever direction your blue light is coming from.
Yes that would give you only one side of the model, But you can rinse repeat, and its better than nothing.

The Flexion Engine (nOObody posted the URL) supports VDM (virtual displacement mapping). Also known as parallax mapping. It's a step beyond normal mapping. VDM surfaces can look REALLY good. Another new engine that uses VDM is C4:

http://www.c4engine.com/c4engine/index.html

If we switch to a material-based system, I hope we can use effects like that.

why? if the engine knows how it's going to tesselate the geometry, then whether a model is a mesh or a prim shouldn't matter. after all, i can use bump/normal/displacement maps on NURBs surfaces.

what might be cool would be a clientside prim modeler like what's been discussed/requested previously on the forum. build into it a normalmapping feature - it'd tesselate like SL, do it on the fly and then kick out the nmap. could then upload the low detail prim and the data. i'd rather see this capability (and a way to import other file formats for the high-rez object) then just a partial implementation. your example is familiar to me. i'd just want more and would be happier with a nice shader system instead.

got to thinking about my suggestion above: if the prim is going to get tesselated, may as well make it exportable too.

But then how do you Import a mesh back into prims?
Eather your going to have 1 prim per polygon,
or there is going to be some serous errors, especially in lining up the textures.

"could then upload the low detail prim and the data." why is importing the mesh necessary?