Renderbump

[Springheel]

Has anyone here used renderbump as part of their workflow? I'm just starting to try and use it, and tutorials are difficult to find. As far as I can tell I'm doing everything right, but when I try it, the console pops up a few errors I don't have time to read (I caught something about can't find image) and then the screen goes grey with weird pixels. Doom does create the normalmap file, but the contents are solid grey.

[PinkDot]

I had been using renderbump before I learnt how to do it in Max (it gives some better control). I remember that it took me some time to figure out what was wrong. Are you working with LWO or ASE files?

Few questions:

- does your low poly model have UV applied?

- do LP and HP occupy the same space? (they should overlap each other in 3D app before exporting)

- are paths correct? where did you place your models? Separate folder is a good idea (f.e.models/renderbump or whatever).

- does low poly model points to existing material shader?

- what are your renderbump parameters? (those in material declaration)

[Springheel]

I remember that it took me some time to figure out what was wrong. Are you working with LWO or ASE files?

 

I'm working with .lwo files.

 

- does your low poly model have UV applied?

 

Yes.

 

- do LP and HP occupy the same space? (they should overlap each other in 3D app before exporting)

 

Ah, no, I don't think they do. So their origins have to be in the same place but they are separate files, or do you mean they have to be on separate layers in the same file?

[PinkDot]

Ah, no, I don't think they do. So their origins have to be in the same place but they are separate files, or do you mean they have to be on separate layers in the same file?

origins the same, one overlapping the other, but exported in separate files.

That might be the cause - grey (=blank) normal map means that rays did not reach hipoly model (it was too far from hipoly).

[greebo]

@Springheel: I wrote a renderbump tutorial on the wiki a while back, but I don't know if it contains any more information than you already know. I only used it once - then angua tried xNormals and found it to work much better. Sometimes the resulting normalmap has to be tweaked after xNormals is done with it, but overall it's very fast.

[Springheel]

@Pink: That was it, thanks. It seems to have worked now.

 

@greebo: I did read that one but I didn't understand some of the non-lightwave terms. I assume xNormal is for blender?

[Springheel]

I got it to work more or less, but there are some weird shapes overlapping the normals. Any idea what those greenish triangles are? Should I leave the points unwelded when running this? That's what it looks like to me, vaguely, like something is merged.

 

[Baddcog]

Those weird shapes are most likely polys that overlap somewhere. Best to have NO overlapping polys anywhere on model. Makes it hard to reuse tex and save space.

 

I've been using renderbumpflat and I like it alot better. Reasons:

1-you don't have to use material shader, just uv map the obj.

2-Easy to avoid weird shapes/overlapping polys

3-no need to have high and low poly models overlapped/exported, only need high poly.

 

I basically lay out the high poly object flat, or just small pieces of it. I did this with my metal chest. I can have several flat images, render them, then paste together in photoshop. Then uv map the low poly object and adjust uv's to fit.

[greebo]

@greebo: I did read that one but I didn't understand some of the non-lightwave terms. I assume xNormal is for blender?

No, xNormals is a stand-alone application, which can handle at least ASE (I haven't checked LWO, I have to admit). Yes, some terms are Blender-specific, but you can skip the parts "Apply Scale and Rotation" and "Export your Mesh" - just export your model to LWO. Anyway, if renderbump is working fine for you, there's no need to switch.

 

Also, I don't know if ASE and LWO are working equally well with renderbump, but I always got strange results with my ASEs and had to play around with the trace a bit. And it takes ages. xNormals takes just a few seconds and is supporting multi-core processors.

[Springheel]

I found out that the problem had to do with some points that had two sets of uv coordinates. I'll have to check out xNormals though, as renderbump takes forever.

[OrbWeaver]

I found out that the problem had to do with some points that had two sets of uv coordinates.

 

If you mean parts of the UV map were non-unique (i.e. mapped to more than one place on the model) then yes, that would cause problems.

[PinkDot]

I found out that the problem had to do with some points that had two sets of uv coordinates.

You can't have overlapping polygons only at the moment of baking normal maps. So when you want to have your model with overlapping polygons on texture, just save that UV coordinates set, then take all overlapping polygons out of the UV space (out of 0,0 to 1,1 range), so no polygons are overlapping. Export that model and use it for renderbump. When you're happy with the result you can load the previous UV set.

 

I use Max, so I can't tell you where are Save UV and Load UV commands but I'm pretty sure Lightwave can do that as well.

 

BTW: not everything looks fine after renderbump. For instance that strip at the bottom of your baked texture. It could be corrected in 3D application, which gives you control over the projecting rays direction (again, I don't know how to do that in Lightwave). Or you can do it also in Photoshop (Gimp) - just make a simple height map simulating those round edges and run nVIdia filter.

[Springheel]

Something still doesn't look right.

 

Here is the model in-game (it's the covered serving dish).

On the left is the model with both the renderbumped normalmap and the metal normalmap 'addnormaled' together. On the right is JUST the metal normalmap.

 

 

I almost think it looks better on the right, but specifically I'd like to know why part of the handle is black when the normalmap is applied?

 

 

Here's the current version of the renderbumped normalmap with the handle part circled in red. It looks fine to me. The same part of the model was black the last time, before I totally redid the uvmap.

 

Any ideas?

[Baddcog]

Can't get that pic to load no matter what. cable net too. How big is it? too much for server?

I even copied the path into browser, still won't load.

[PinkDot]

Spring - could you post an image of UV layout? and image of low and hipoly models overlapping each other (with mesh visible)? Maybe this could tell us more...

[Springheel]

Here's the lowpoly with the highpoly in another layer.

 

[angua]

My guess is that the handles of the highpoly and lowpoly model do not overlap well enough. You could try to move the handle up a bit or make it a bit smaller.

[PinkDot]

Yeah, that's what I though as well. Looks like distance from low to high poly model is bigger at that spot than at other places and maybe rays miss high poly model (they never go too far to speed up projecting process). And you can see there's a mess on the normal map for the corresponding polygons.

Just try to fit low poly mesh as much as you can to high poly mesh. And if you want to keep that shape of handle, you can revert it later, after baking the normals.

[Baddcog]

Yeah, you could just grabe the verts of the handle and drag em up to match. Bake, then drag em down again for export.

 

Looks good other wise though. I can finally see the pics