How To Use Renderbump?

[SneaksieDave]

Anyone know anything troubleshoot-specific for renderbump? I can seem to get renderbumpflat to work just fine, it generates what seems to be a mask in one file, and a nice flat normalmap in the other. However, renderbump consistently gives me results like this:

 

renderbump \models\darkmod\props\containers\crate03.lwo

----- Renderbump \models\darkmod\props\containers\crate03.lwo -----
surface 0, shader tdm_crate02
renderBump =  (no action)
0.39 seconds for renderBump
---------- RenderBump Completed ----------

 

It looks like it aborts before anything even starts. There are no images dumped anywhere. I've tried it with a bunch of different LWOs, the one above being a simple crate. These are the untouched TDM-ready versions, so I assume they're all set up with whatever texture coord info it needs.

 

http://www.iddevnet.com/doom3/bumpmaps.php

[OrbWeaver]

I recommend using ORB (http://engineering.soclab.bth.se/tools/177.aspx) rather than Doom 3's renderbump. It is more interactive and does not require setting up MTR files to define the parameters.

 

Otherwise, you have to have a renderbump global keyword in your low-poly model's material definition, giving the renderbump parameters and the path to the high-poly version.

[oDDity]

You do realise you need a low and high res version of the object to use renderbump? It's not for making a normal map from the crate texture, it's for making a normal map from the geomerty of the high res crate.

[SneaksieDave]

Right, I was trying/assuming to use the existing model to spit out a normalmap and have a look at it. It worked for renderbumpflat, so I assumed renderbump worked the same, just for objects instead of flat surfaces.

 

Okay, so the high is needed, hrm. Well perhaps I can do it with some test model I make.

[OrbWeaver]

Are you trying to achieve something in particular, or just learn about the techniques? For simple models like crates, you probably don't need renderbump at all.

[PinkDot]

I don't want to make new thread, so I'm writing here.

 

Does the trace parameter work for anybody? Sometimes I get holes and increasing it should theoretically help but the normal map I get after increasing the trace factor is completely messed...

[SneaksieDave]

I'd like to learn how, especially so I can make more than crates.

[SneaksieDave]

I tried ORB, but for whatever reason, it crashes when even trying to open one of my Blender-exported ASEs. It can open the ASE from 3DS which comes with the package (of course), but not mine.

 

So I'm giving Doom3 another try. Could any of you give me a sample material (or heck, even a low and high model and material) that I can look at and emulate? So far it's not working, and I don't really have any idea what I'm doing wrong - no example on modwiki, no example on iddevnet.

 

 

Edit: I'm just not getting this.

From id's mapobjects.mtr, the only type of hints I can find:

	renderbump  -size 512 512 -trace 0.1 -aa 2 
models/mapobjects/hell/torches/torso_local.tga 
models/mapobjects/hell/torches/torso_hi.lwo

I emulate that with my assets, even though it makes no sense to me, and it of course doesn't work. Why is there a *_local line in there at all? I'm trying to generate the normalmap; why would I include a normalmap in the material definition? What the hell? Time wasted++.

[OrbWeaver]

The local map is the file that is generated when you run the renderbump command in Doom 3.

 

The basic workflow is to export your low-poly model as normal, create a material from it in the usual way but add a renderbump line similar to the above which details the size, the path to the hi-poly model and the destination normalmap. Then when you call renderbump on your low-poly model in the console, it will pick up this information, load the high poly model and generate the normalmap.

[SneaksieDave]

But that's just it - it doesn't do that. Or rather, it hasn't:

 

- I used the working dice from in game (so that I know it's set up correctly)

- I used the original .blend file, subdivided a couple of times and smoothed, to make a higher poly version, and then exported it the same way, alongside the original dice.ase

- within the material I added:

 

renderbump  -size 512 512 -trace 0.1 -aa 0
models/darkmod/props/textures/dice_local.tga 
models/darkmod/props/misc/dice_high.ase

 

To which Doom3 answers:

 

renderbump /models/darkmod/props/misc/dice.ase
----- Renderbump /models/darkmod/props/misc/dice.ase -----
WARNING: unknown general material parameter 'models/darkmod/props/textures/dice_local.tga' in 'dice'
surface 0, shader dice
renderBump =  (no action)
0.04 seconds for renderBump
---------- RenderBump Completed ----------

 

And there's nothing, no output (as evidenced by the time as well). Even substituting my existing low detail normalmap doesn't do anything, so it's not clear if that instruction is for input, output, or something else altogether. Since we've had this done before (for characters at least), how was it set up?

[OrbWeaver]

That renderbump expression needs to be on a single line. It looks like you have split it over three lines which is causing the material parser to complain.

[PinkDot]

For some reason renderbump never works for me with .ase files. But after conversion to .lwo everything is OK.

[OrbWeaver]

Strange, I've renderbump'd plenty of ASE files. As long as you don't mix and match (low-poly ASE, hi-poly LWO) it should be OK.

[SneaksieDave]

That renderbump expression needs to be on a single line. It looks like you have split it over three lines which is causing the material parser to complain.

W00T! That was it! Now to the next step.

]renderbump models/darkmod/props/misc/dice.ase
----- Renderbump models/darkmod/props/misc/dice.ase -----
surface 0, shader dice
renderBump = - size 512 512 - trace 0.1 - aa 0 models/darkmod/props/textures/dice_local.tga models/darkmod/props/misc/dice_high.ase (rendering)
loading models/darkmod/props/misc/dice_high.ase...
12 triangles made 120000 links
trace fraction 0.10 =   0.15 model units
writing models/darkmod/props/textures/dice_local.tga (512,512)
8.08 seconds for renderBump
---------- RenderBump Completed ----------

However, the normalmap is blank grey. Hmmmm... I might have an idea or two as to why.

 

Edit: I assumed I must include a material in the high poly model (no effect).

 

Edit: I'm assuming the UV mapping has to match, for D3 to make something from the high which the low can use. But how can it? The seams won't be the same between a low poly and high poly model.

 

Edit: Using a simple cube made this task easy, however it didn't help.

[SneaksieDave]

Okay, I got it working with ORB. For whatever reason (probably depends on paths and materials more than I expected) it crashes loading local copies of the files, but seems to work with the darkmod-foldered items. Anyway, I generated a 2k poly normalmap in a few mins - which definitely tells me D3 isn't working, since it's done in 8 seconds, giving me a grey TGA.

 

This leaves me with two lingering questions.

 

1. Why doesn't it work in D3 with renderbump? Is it just much more sensitive to everything being set up in one exact way, and ORB is that much more forgiving? What little facet am I missing?

 

2. I'm assuming UV maps must agree between low and high poly versions (how else could it work?) How on earth is this achieved? I did it with a simple cube as proof of concept, but most game models aren't cubes. High poly versions will be much harder (and I'd imagine sometimes impossible) to reproduce the low poly UV map exactly. Is there a way to export or transfer the low poly UV map into the high poly model for export and use? Or is that the wrong approach completely? Could it be that (dare I dream) these things take the high UV map, and map it onto the low UV map shape for the output image?

 

Learning a lot in the past week. Head hurts.

[PinkDot]

You don't need UVW map for high poly model. It has to be just mesh - nothing more. Low poly model should be UVW mapped.

 

8 sec. for 512x512 map for simple cube with D3 is possible. It's fast normal map maker cause it's hardware supported. F.e. my recent models - cutlery - have around 150 faces for low poly and about 20-30k for hi-poly and it takes only 18-19 sec. to complete normal map.

 

Are you sure that your low and hi poly models are at exactly same positions (overlapping each other)? If not - then maybe that's why you get blank normal map...? Just guessing...

[SneaksieDave]

You don't need UVW map for high poly model.

Whew, that is great news. I was dreading even thinking about having to UV map everything twice, AND making them match. I guess it must use the low poly UV map for the coords?

 

Are you sure that your low and hi poly models are at exactly same positions (overlapping each other)?

Yep, in fact here's how I made my little test case, for simplicity. I took my simple cube for the dice and exported it, ready for in game use. Then, I took the same file and added a bevel, subdivided a few times, and then smoothed a bunch. Didn't change anything else, and exported as dice_high.ase. So they must coincide.

 

I'll try a new test with no high_poly UV map, but I still can't figure why D3 is giving me a blank. If it's useful info, the dice_d.tga file (presumably diffuse) that ORB is spitting out is the same as the D3 normalmap - a grey field. Could it be that Doom3 is being instructed to export the wrong map?

 

I could give the high poly file, if anyone wants to try that with the material and low poly which are already on CVS (except for the extra instructions pasted above).

 

 

Edit: Yay, it just worked in D3, too. I don't know why, the only thing I changed was generate a brand new high poly model and not provide a UV map at all. Maybe that was causing a problem somehow? Either way, success!! Thanks for the help guys.

[OrbWeaver]

Whew, that is great news. I was dreading even thinking about having to UV map everything twice, AND making them match. I guess it must use the low poly UV map for the coords?

 

Yes, it uses the low-poly UV map to identify a coordinate on the normalmap image, and then uses the high-poly mesh to calculate what the normal should be at that point.