Land Impact for detailed bike parts.

[leliel Mirihi]

---

Drongle McMahon wrote:

"That means your normal map is too big."

 

I don't think I can entirely agree with that assertion, so far. The density of geometry can be highly variable. In my example, it's mostly in rounded bolt heads that occupy less that 2% of the surface area. The remainder doesn't use much geometry, but the normal map has to be uniform and of sufficient resolution to give the required detail for the bolt heads. In other words, the normal map resolution is determined by the finest detail to be represented. If the distribution of detail is non-uniform, that means it has to carry a great deal of redundant information. In contrast, the geometry only contains detail where it is required.

---

You're right about that, I suppose I should clarify. Normal maps have a high base cost but a low cost per feature. So they work best with larger objects with lots of detail that allows you to amortize the base cost accross the whole object. Also while the detail may be non-uniform on the mesh it doesn't have to be on the UV map.

[leliel Mirihi]

---

Kwakkelde Kwak wrote:

Anyway, I am talking about the maximum of 512 MB reserved for textures. No matter how muh memory a vertex uses, it doesn't qualify or is used as texture memory. If it is, the term is chosen poorly at best.

---

 Texture memory is an artificial construct of the viewer that is completely disconnected with reality. On the hardware side dedicated texture memory fell out of favor almost 15 years ago. The reason why the viewer can't use all the vram modern cards have is because it still clings to this out dated concept. LL knows this system is broken and needs to be removed but they're lazy so we should light a fire under them by abusing it as much as possible.:matte-motes-evil-invert:

---

Anyway, the entire point is: sometimes it's better to use geometry, sometimes it's better to use normal maps. It's

always

good to use as little as possible.

---

Agreed.

 

 

[Drongle McMahon]

I'm sure we all agree that we want to replace geometry with normal maps. The questions here are what are the limits of effectiveness in that effort, if any, and what are the quantitative bases that allow that to be estimated in any particular case. In particular, that requires deciding what resolution of normal map is needed to provide acceptable appearance. Generalisations without quantitative basis don't really help answering those questions (although they may well be all that is available).

As far as the composition of maps from separately baked parts is concerned, I don't know that that will help. The undesirable effects of the lower resolution maps, the blockiness and the glazed look at edges, appear to be the result of interpolation between pixels in the UV map. That will only depend on the pixel resolution of the map. Surely antialiasing or blurring will only exacerbate that, or can they let the gpu interpolation work better?  I will certainly grant that compositing is easier than making the geometry, but it sacrifices the possibility of direct comparison of geometry and normal map baked from it, which was my objective here.

Yes, the effect of lacking parallax when viewing the normal map at anything other than perpendicular is fairly obvious when you think about it. I made myself a picture to see just how bad it was, looking at 45 degrees at geometry and normal map. The squishing of the steep bit is quite nasty. Then the white line shows a bit that shouldn't even be visible. Oh well, you never get something for nothing.

 

[Drongle McMahon]

"Also while the detail may be non-uniform on the mesh it doesn't have to be on the UV map."

Yes. In fact that's the thing that really renders (sorry!) my questions a bit moot. In reality, I suppose, you simply don't do only the same the same thing with a normal map that you would otherwise do with geometry. In the actual crate, the normal map had woodgrain and pitted rust as well as the bolt heads. Those would have been beyond impractical with geometry. It would be nice to have numbers to back up the argument for normal maps, and to make some decisions, but I guess I'll have to do without. Right or wrong, I have a fairly developed sense of "that's too much geometry", but no such clear "That's too much normal map", and texture download delay is the major annoyance of SL, at least on my slow connection.

[IvanBenjammin]

The concept of "replacing geometry with normal maps" is the 'only in second life' part of my comment When normal mapping came along for video games, it wasn't about replacing geometry because you didn't have the polygons to replace in the first place, it was about giving detail where you previously couldn't.

So in a way, SL - as a platform, but also in terms of popular opinion and culture - is approaching it from the wrong side, and there's nothing to be done about that. So if I sound a little ranty and incoherent in what I say on the subject, its because I'm relatively new to SL so coming at it from a different angle. Questions like "should we use high poly geometry or normal maps?" sound kind of rhetorical to me

Composition of normal maps from separately baked parts (technical term: floating geometry) gives you a lot more control, and assuming you have the ability to create normal maps from grayscale images (ndo or whatever), then you have the ability to punch out detail and blur/sharpen pixels as much as you like.

Yes, it all comes down to pixel interpolation in the viewer, and there's definitely times when it makes more sense to bake in one layer, but those artifacts that you point out in your rivet are just the tip of the iceberg, and can get pretty messy in more extreme situations.  And little artifacts in normal maps can look pretty glaring if the light catches them.

[Drongle McMahon]

I guess it's a matter of perspective. Others coming from high poly modelling for static rendering, used to using high poly tools and methods, will see it the other way round. There are clearly tools and tutorials out there that use polygons with complete abandon, because it doesn't matter for their purposes. Unfortunately, some continue to do that in SL. Mostly this happens with clothing and other attachments, because those escape the LI penalty which is LL's way of encouraging polygonal thrift. Now, if we could add a texture component to LI, that would give a basis for balancing the two. No real hope of that though, because they are too reluctant to break old content.

Even those who aren't extravagant with geometry sometimes have older content made before the materials stuff came out, where they had to use geometry. So they can literally replace their geometry with normal maps to improve the efficiency of their stuff. I have a few things that I really should do that with, including a machine with 300 hexagonal bolt heads on it made of geometry :smileysurprised: (OK - it was an experiment to see what it would cost! ).

[IvanBenjammin]

I think they're going to have to start breaking old content sooner or later...

SL desperately needs accounting for textures. I was looking at the display weight value, because reading up on it it suggests it measures texture use. However, normal and spec maps have no effect on it at all, so that's pretty useless.

 

[Kwakkelde Kwak]

---

leliel Mirihi wrote:

Also while the detail may be non-uniform on the mesh it doesn't have to be on the UV map.

---

While this is very true, it's not as straight forward as it sounds. In most cases you don't set your UV map up for your normal map, but for your diffuse map, which in most cases will be more or less uniform to the mesh and in cases like the bolts or tapered box completely non-uniform to the geometrical detail.

You could split your UV map so you end up with multiple materials/SL faces, which would overcome this particular issue but raise some new ones instead, especially since (to my best knowledge) Blender (still) doesn't support vertex normal editing. On flat surfaces like Drongle's or mine, it could/would work. Isolate a small square around the bolt and give that a normal map. With the right offset/repeat it could share the diffuse map with the rest of the object. That doesn't cost you a whole lot of vertices. On curved surfaces this won't work without vertex normal matching.

---

Texture memory is an artificial construct of the viewer that is completely disconnected with reality. On the hardware side dedicated texture memory fell out of favor almost 15 years ago. The reason why the viewer can't use all the vram modern cards have is because it still clings to this out dated concept. LL knows this system is broken and needs to be removed but they're lazy so we should light a fire under them by abusing it as much as possible.**Only uploaded images may be used in postings**://secondlife.i.lithium.com/html/assets/emoticons/mattemotes/evil_invert.png" border="0" alt=":matte-motes-evil-invert:" title="" />

---

It being an outmoded (is that the right word?) concept doesn't change the fact it is reality. It's something we will have to live with and take in account when we build things.

 

---

Agreed

---

Agreed

 

 

[Drongle McMahon]

"On curved surfaces this won't work without vertex normal matching."

Thr crate map was meant for a prim cube, where you can't change the UV map, but for a mesh cube, I think your material split idea might be a good compromise - just a little more geometry to get the different normal map repeat on different material. It might depend on the regular feature spacing though.

I don't follow the quoted bit though. Aren't vertex normals preserved across material boundaries? I'll have to try it.

[Kwakkelde Kwak]

 

To clarify the idea:

In the above picture you have a single plane with two materials. The corners are 1/8 of the total for easy texture repeats and offsets. You can map the dark gray area as a plane, using the full canvas. It has no normal map at all. The corners you can map as a plane too, again using the full canvas. With the diffuse texture repeat at 0.125 and the right offsets for each corner they can use the exact same diffuse texture as the big plane, leaving no seams. You can assign a normal map with a 1x1 repeat to them.

Alternatively you could map the entire thing as a plane and play with the repeats (8x8) changed for the normal maps of the corners. Come to think of it, that's probably easier.

 

---

Drongle McMahon wrote:

"On curved surfaces this won't work without vertex normal matching."

I don't follow the quoted bit though. Aren't vertex normals preserved across material boundaries? I'll have to try it.

---

You are 100% right about the vertex normals, no idea where my mind wandered off to when I wrote what I wrote. The lacking ability to edit the vertex normals is only an issue when you push two curved elements (as they are called in max) or objects together.

[Drongle McMahon]

I did some experiments. Very instructive, and the runaway winner is Ivan's floating geometry combined with Kwak's material trick.

The high poly model is a cylinder with sixteen segments around and 15 top-to-bottom. All the quads are square. Every fourth square has a rivet. In the first version, the rivets are connected to the cylinder, and their bottom edge is sharp following a tight 5-segment bevel. The edge points are connected to the nearest corners of the square (trying other arrangemenst didn't make anyb useful difference). In the second, the floating geometry version, the squares with rivets are the same as the others, and the rivet is separate, with no bevel and its bottom edhes coplanar with the square. The low poly model is just the cylinder without rivets. Its UV map is a simple tiling of the unit UV space, and the square that will carry rivets are a different material.

For each version, normal maps for the were baked onto the low poly cylinder at three resolutions. Then one of the rectangles to receive a rivet was remapped to the whole UV space and the normal map was baked onto that at 64x64 resolution. Everything except the attached rivet edges were smooth shaded throughout.

Th picture shows the attached river version on the left and the floating rivet version on the right. At the topm of eaxh column is the high poly mesh, with blank normal map and spec map. Note that there are severe artefacts in the normals of the squares with the rivets sitting on them. These artefacts are absent from the floating geometry version. The next three, top to bottom, are the low poly mesh with the whole-model normal maps baked at 256x256, 512x612 and 1024x1024. The normal map pixelation effects are much as the were in the flat case. The nasty normals in the squares with attahed rivets do not improve (hardly surprising as they are there in the model itself).

At the bottom, the materials are used. The rivet-bearing squares us the 64x64 single rivet normal map baked from the floating rivet model, repeated 16x15, with a 0.5 offset for the former. The rest of the cylinder is wither using the blank normal map (left) or the 256x256 floating rivet map (right). These are very nearly as good as the 1024x1024 full-model normal map, while using only a small fraction of the texture data.

It was easy to set the repeat and offset here, because the model was designed with that in mind. It could be very difficult to achieve this in more realistic and useful cases. However, I guess it might be possible to obtain the desired effects by moving the targeted UV islands around instead when they start out in random positions.

ETA: Of course a real object like this might well have flattened patches to get the rivet to bind better -m in which case the "bad" version might be more realistec!

[RipleyVonD]

---

Drongle McMahon wrote:

"Also while the detail may be non-uniform on the mesh it doesn't have to be on the UV map."

Yes. In fact that's the thing that really renders (sorry!) my questions a bit moot. In reality, I suppose, you simply don't do only the same the same thing with a normal map that you would otherwise do with geometry. In the actual crate, the normal map had woodgrain and pitted rust as well as the bolt heads. Those would have been beyond impractical with geometry. It would be nice to have numbers to back up the argument for normal maps, and to make some decisions, but I guess I'll have to do without. Right or wrong,

I have a fairly developed sense of

"that's too much geometry"

, but no such clear "

That's too much normal map

",

and texture download delay is the major annoyance of SL, at least on my slow connection.

---

You can use your sense on whats too much texture and carry that over to Normal Maps and thats all you really need. Normal maps are just textures. Except you cant use lossy compression on them, or you get bad artifacts.

Im not an expert on LL's optimization alghoritm during upload of textures, but Normal Maps don't use every color of the rainbow so I imagine they get optimzed smaller than a diffuse texture for download size. The same goes for Specular maps, they are only grey scale so should be optimized even more so.

Normal Maps were created to relive stress on computer hardware not incur anymore.

PC hardware manufacturers have adapted there drivers and hardware over the course of ten years for the use of Normal Maps.

Even the lowest end hardware SL residents might have should be able to use "Materials" without a problem.

[Drongle McMahon]

"you cant use lossy compression on them"

If they are bigger than 128x128, you have no choice, they are always lossy (irrespective of what the checkbox says).

[RipleyVonD]

---

Drongle McMahon wrote:

"you cant use lossy compression on them"

If they are bigger than 128x128, you have no choice, they are always lossy (irrespective of what the checkbox says).

---

I actualy meant in your image editing program, saving Normal Maps to jpegs with too much compression is not good. PNG compresion is safe for storage on your harddrive but its best to upload your images as TGA so that your image is uploaded at its best quality before its uploaded and optimized (yes compressed). 

Yes Normal Maps do get compressed in rendering engines, they use their own special alghorithms, but when working with Normal Maps if you save them to lossy compression thats how it gets uploaded to Second Life so when you upload and SL applies its own compression it won't give you a good result.

 

[IvanBenjammin]

Nice work taking the time to analyze that, Drongle - you have way more patience for the theory than I do.