Object space bump mapping

Wow, those last two images are pretty cool. They really show the detail a bumpmap can show .

If I had 3dstudio I’d dl them in a flash…but I only have LightWave3D[7]. I’m gonna write myself an object-space normal map when I finish my mesh to tri-strips algorithm. Gah, I don’t want to use my brain just yet though…I’m gonna go play with some register combiners and add simple stuff to Spider3D .

btw, castano, I know how people like to be complimented on their work, so I will contribute right now. Your Titan engine was pretty cool. I never really used it, BUT it taught me a few things about OpenGL that I needed to know back then.

Whatever, thanks for the compliments, writting the engine was also a great learning exercise. :slight_smile:

The plugin was originally an external command line tool, I integrated it in max for ease of use, but will write a standalone application again if there is enough interest.

By now, you can at least test the BumpViewer to see the results for yourself. I’d appreciate any kind of feedback and bug reports.

Talking about the topic again. One of the things you have to take care of when using tangent space bumpmaps is that the tangent space you use for rendering, must be identical to the tangent space used to generate the normalmap. For this reason you cannot use any kind of LOD in conjunction with tangent space bumpmapping if you want to avoid artifacts. On BumpCharm I used nvidia’s meshmender, so anybody can obtain the same tangent space basis with ease. You can also extract object space normals thought.

We had a very long thread about this, where we even sketched out what the various shaders would look like, a few months back.

I started out in the object space camp, because I like the shorter shaders, but I came to appreciate the memory savings of tangent space through the course of the investigation. Regular lighting calculation is so much cheaper in object space, though; saves a lot of fragment program ops.

Note that reflection mapping on bump maps is also much cheaper in object space, as you have eye and normal right there; no need to generate a reflection in tangent space and then un-skin that reflection to world texture space.

dorbie: You can add bumpmaps and objspc-nmaps by computing the tangent space normal for the bumpmap and translating it to object space. I did a similar approach in my plugin.

Object space normal maps are usefull for objects and characters, but not for level geometry (unless you go for unique texturing), so you will have to code two diferent paths for each target. That’s why I keep it simple and just use tangent space bm.

Two different paths mean two different shaders, more state changes, etc. But maybe the benefits are worth the effort.

Castano, yes, but I think it’s equivalent to what I said. I’d hate to think you’d need to reintroduce the coordinate frame per vertex to combine the images. Ideally this would be an image operation only without reference to the geometry, but whatever works. I think an image only operation is possible where tangent space is defined by the normal in the vector map and the the ordered rotation of the implied texture axes around into the frame of that normal.

And it IS useful for some types of geometry. You’re talking about a transform per vertex, compared to a transform per object for rigid body stuff. Look at all the stuff in doom3 for example. A lot of it is baked and non repeating (doors and other items), I can do that in object space and still reuse by doing the vector transforms to object space and having an object coordinate frame. I think there are a lot of general assumptions getting made where people aren’t trying to solve the object space problems so it doesn’t get a fair shake. This transform once per object to reuse object space vectors is a good example. You still save on per vertex transform work.

[This message has been edited by dorbie (edited 11-13-2002).]

Yeah, it’s definitely not an image based operation. I combine bumpmaps during extraction for that reason.

There’re still some issues when combining bumpmaps the way you want. That was discussed in the Algorithm ML some time ago: Someone said that he had lighting discontinuities on the texture discontinuities, even when the bumpmaps matched correctly on the edges. That happens because the tangent space basis on both sides of the edge are different. Both basis have the same normal, but the tangents are not the same.

If the normalmap on the edge is (0,0,1) there won’t be any error, because the transformed vector will be the same on both sides of the edge, but if it points in another direction, you will have lighting discontinuities.

When combining a normalmap with a bumpmap just by adding and renormalizing you will suffer from the same artifacts. If those artifacts are noticeable enough or not, depends on your case, but in my case it was.

And yes, object space is cheaper, I’m not discussing that, I just said that in some cases you need tangent space, and if you do, you will need two different code paths.

Looks like there’s a bug in the list, the thread has been forked.

Yep two code paths seems right.

As for combining the bump maps you need to do a coordinate frame interpolation per texel to get it right if you’re working in tangent space, but I still think it can be an imaging operation done post extraction. The normal defines your coordinate frame in a DOT3 map, and I think you can compute ‘local’ tangent space tangent and binormal vectors using just that normal given that you are in texture space.

[This message has been edited by dorbie (edited 11-13-2002).]

Ok let me see if I can get this straight. So what you’re saying is that the correct way to combine an object space bumpmap generated from some polybump tool and a tangent space detail normal map is for each texel in the object space map, compute a tangent basis for each texel and transform each texel in the detail tangent space map by that inorder to have both maps in object space? Or am I just way the hell off?

-SirKnight

You’re exactly right.

P.S. in the doom3 thread someone suggested that this is also better for tangent space normal maps, and I think that strictly speaking they’re right. The accurate combination is to rotate the bump map to the perturbed tangent space per texel.

Thinking about this you then SUBSTITUTE the vectors instead of adding. Ahh… it suddenly seems like absolutely the right thing to do.

So:

Compute bump vector using derivitives, transform to local tangent space per normal, substitute the new transformed vector.

[This message has been edited by dorbie (edited 11-13-2002).]

You’re exactly right.

w00t!

-SirKnight

That way of combining bumpmaps is something like what I explained here:
http://sourceforge.net/mailarchive/message.php?msg_id=1974094

And here is a more detailed explanation of the artifacts I was talking about:
http://sourceforge.net/mailarchive/message.php?msg_id=2287208

perhaps im not understanding the ‘edge artifacts’
if its what i think u mean i have seen it before but this was easily solved by ‘expanding’ the edges of the normalmaps like so

for ( x=0; x<width; x++ )
for ( y=0; y<height; y++ )
{
if ( data[xwidth+y].x == 0 && data[xwidth+y].y == 0 && data[xwidth+y].z == 0 )
{
int num=0;
VECTOR tot(0,0,0);
if ( is_vector_NULL( data[((x+1+W)%W)width +y] ) )
{
tot += data[((x+1+W)%W)width +y]; num++;
}


if ( num )
tot /= num;
edge_data[x
width+y] = tot;
}
else
edge_data[x
width+y] = data[x
width+y];
}

this expands them by one pixel which removes the worse of the artifacts (u will still get them with mipmaps) but the ‘edges’ can be enlarged further to prevent this.
those are the only artifacts ive seen, then again perhaps ive got these ‘artifacts’ and havent seen them yet (cause im using nice models or something)
do u have any screenshots of the problem

zed: no that’s not the artifact I’m talking about. What you are doing can be done much better with an EDT (Euclidean distance transform) The 4-pass lienar aproximation isn’t very difficult to code, and gives really good results.

Have you never seen a bumpmap that perfectly fits on the edges, but that under some lighting conditions produces small discontinuities?
It’s something pretty common, because most people do it wrong, but I will look for an example, to show you the difference.

>>Have you never seen a bumpmap that perfectly fits on the edges, but that under some lighting conditions produces small discontinuities?<<

no admitly though all the models ive done have been ones ive made + thus have been very simple (does this matter?)
i wouldnt mind have a go at a more complicated model they do exist on the net eg www.3dcafe.com but unfortunaeltly are never uniqly texturemapped (+ bugger me if im going unwrap them myself)

then again perhaps i are seeing the problem but didnt realise it is a problem (im more of a person that if it looks ok, then finished onto the next problem)

kind of rotating + accumulating + renormalizing of several normal maps from different tangent spaces on single model:

http://mz_000.tripod.com/images/11.JPG
http://mz_000.tripod.com/images/22.JPG
http://mz_000.tripod.com/images/33.JPG