fuag@Posted: Tue Aug 15, 2006 11:30 pm    Post subject: : I cant get it to renderbump right.. I have my mesh in md5mesh format and the high poly mesh in .ase because i tried it as .md5mesh and it hella didnt work. This time it says ti took .36 seconds to complete the renderbump but I don't see anything in the target filepath. heres my material def

Quote:

models/marine/boonemarine { renderbump -size 1024 1024 -aa 2 -colorMap textures/marine/marine_local.tga models/marine/marine_hp.ase "qer_editorimage" "textures/marine/marine_d.tga" "diffusemap" "textures/marine/marine_d.tga" "bumpmap" "textures/marine/marine_h.tga" noSelfShadow }

exported the ase using the exporter for blender posted in the forums with material, vert and uv unselected.

can't find a *BITMAP line to change to a material but I guess that shouldn't matter

---

Bittoman@Posted: Wed Aug 16, 2006 12:00 am    Post subject: : Well there's no trace value set (probably just defaults to something if one isn't set in the material file so this may not be a big deal) and I've no clue what the colorMap declaration is for, I've never seen it used and iddevnet doesn't explain what the function does.

As for the problems with rendering, did you apply a material to the low poly model? Did you UV map it? Both of these are required for the low poly model (presumably the md5mesh model in your case) but make sure that you don't add them to the high poly one.

---

fuag@Posted: Wed Aug 16, 2006 12:08 am    Post subject: : yeah, the low poly md5mesh has a material and is uvmapped and just ran a testModel on the high poly .ase and it loads ok, i unchecked exporting uv material and vertex color when i exported the .ase but there were uv coordinates in there because its based off the low poly that I had already uv'd and I'm not sure how to delete uv maps. I took out the -colorMap option but I still get that renderbump took .18 seconds rendrbump completed with no actual rendering hapening or files created.

Command I'm using in the console is

renderbump models/marine/marine.md5mesh

marine.md5mesh points to boonemarine

---

Bittoman@Posted: Wed Aug 16, 2006 2:24 am    Post subject: : Something just hit me that might be the problem. Did you freeze the mesh's size and rotation before you exported it for both the low and the hi poly?

---

fuag@Posted: Wed Aug 16, 2006 3:24 am    Post subject: : i froze it on the .ase but not the md5mesh, just tried freezing that and still wont actually renderbump anything... I'll at it to the .ase along with the rest of the files at

http://fuag.is-a-geek.com/filez/Marine/

---

Bittoman@Posted: Wed Aug 16, 2006 3:53 am    Post subject: : Ahh I see what's wrong. You didn't apply an image but rather a series of blends within Blender to try to, what I'd assume, is render a normalmap using Blender. Delete the Red, Green, Blue links in the Textures tab (F6) and then add one "Image". Then click the "Load Image" and just choose the skin you're applying (any image will work fine if you plan on going back and manually editing the link).

---

fuag@Posted: Wed Aug 16, 2006 6:08 am    Post subject: : sorry, the materials were left over from my first attempt at normal mapping before i realized doom3 had renderbump, I took them out though. The marine.blend is just bieng used to export marine.md5mesh and marine.md5anim so I only set up the uv coordinates in the uv image editor so that they would work when I linked a .mtr to the md5mesh. the marine_hp.blend is the one i'm tryingto use as a high poly model for the renderbump.

I've been told to not include uvmapping or texturing in the ase file. I wanted to just use a higher poly md5mesh file for the renderbump because I've already figured them out but it doesnt take md5mesh's for high poly models I'm guessing.

---

Bittoman@Posted: Wed Aug 16, 2006 12:57 pm    Post subject: :

Quote:

The marine.blend is just bieng used to export marine.md5mesh and marine.md5anim so I only set up the uv coordinates in the uv image editor so that they would work when I linked a .mtr to the md5mesh.

For the low poly model you still have to reference an image, otherwise when it's exported it'll export UV coordinates but it won't export properly. It'll export error free but if you try to force a material on it afterwards it may not actually render the material, UV coordinates or not (I made this mistake many times when I first started hehe). This very well may still be the problem you're having though.

I'll try and renderbump it using static models and see what happens.

---

Bittoman@Posted: Wed Aug 16, 2006 1:48 pm    Post subject: : Ok, here's some problems:

-the high poly model still has an image reference and UV coordinates attatched. To fix this just delete the material and TexFace
-the material file is saved in rich text format instead of simple text (just use Notepad and create a new txt file then change the extension)
-Also you had noselfshadow at the bottom of the shader rather than at the top. Declarations like these should be at the top
-There was also no trace value set. I added one and started at .02 (it may need to be set higher, there were some render errors with it at .02 so this is a heavily experimental setting)
-Quotes were used around the texture links and functions, it may actually ignore these but I've never done it so I don't know for sure. It's best to not add them though and save yourself some troubleshooting

After correcting all of these it rendered fine (it's still baking atm).

---

fuag@Posted: Wed Aug 16, 2006 11:03 pm    Post subject: : cool, thnx for looking at em! It worked over here 2. Now on to animating md5meshes

---

juve@Posted: Sun Jan 12, 2003 7:36 pm    Post subject: D3 - renderbump: Doom3 renderbump:

_______________________

if you don't know what renderbumbing is, search google for it ("renderbump")and read what the developers say about it. Alternatively search for "polybump"
_______________________

if you look through the material files you can find some materials defined for some models where the shader has an additional line with "renderbump..." in it. I tried to figure out what it can be used for and how to do it.

What i know so far:

if i had a model:
"model/juve/sphere1/sphere1.lwo"
(the ligthwave-material in the lwo-file would be named "surface2")

and had defined a shader named:
"surface2"

looking like this:

Code:

surface2 { renderbump  -size 256 256 -trace 0.03 -colorMap -aa 1  models/juve/sphere1/sphere1_local.tga models/juve/sphere1/sphere1_hp.lwo diffusemap models/juve/sphere1/sphere1_d.tga bumpmap models/juve/sphere1/sphere1_local.tga, specularmap models/juve/sphere1/sphere1_s.tga }

and if had a high-poly "mooncrater"-detailed model of my sphere named:
"models/juve/sphere1/sphere1_hp.lwo"

i can now use the command renderbump like this:

renderbump models/juve/sphere1/sphere1.lwo

Doom3 would load the sphere1.lwo and the sphere1_hp.lwo and create a tga named: models/juve/sphere1/sphere1_local_color.tga

___________________________________________________

the Problem is, the output image is no normalmap-tga, has only 2 colors and doesn't help me much.

did anybody have more luck with doom's renderbump-cmd ?

---

BNA!@Posted: Thu Jan 16, 2003 1:48 pm    Post subject: : Look in the folder you're keeping the model in - there will be two new tga's - one with the name you've specified in the headline of the shader along with the renderbump settings and a second one with the same name but a _color extension.

Rewrite your shader to use the correct tga's at the right places.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

juve@Posted: Fri Jan 17, 2003 12:25 am    Post subject: : yes i know, but the one tga is simply gray and the other has only 2 colors: white and gray. ... no normal-map-tga is produced

---

BNA!@Posted: Fri Jan 17, 2003 7:33 am    Post subject: : This is one of my last shaders i used to renderbump models:

Code:

bna/corridor/structure2 {    renderbump     -size 512 512 -aa 2 -colorMap bna/corridor/structure2.tga bna/corridor/structure2_hp.lwo    bumpmap      bna/corridor/structure2.tga    diffusemap    bna/corridor/structure2_color.tga    //specularmap     models/bna/grey512.tga    translucent    noshadows    //twoSided    //{    //   blend add    //   cubeMap      env/bland    //   texgen      reflect    //} }

The only difference I see is that my -aa settings switch is located differently in the shader.

You can ignore the uncommented sections of course.

If it still doesn't work send me the two lwo models and I'll take a look.

It's also useful to dump the conole output after renderbump has completed.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

juve@Posted: Fri Jan 17, 2003 1:33 pm    Post subject: : If you say doom3's renderbump works just fine,i think i'll give it another try.

btw. I'm looking forward to your renderbumptutorial.

---

rich_is_bored@Posted: Sun May 04, 2003 7:20 pm    Post subject: : Juve, check to make sure your surface names in both your hi-poly and low-poly versions are different. That was what my problem was. Thanks BNA!

Here is two new issues regarding renderbump...

First, I've been told time and time again that a UV map is not needed for the hi-poly model. It's only needed for the low-poly model.

Yet, when I open my hi-poly model and delete the UV map, then try to use the renderbump command I get this error...

Code:

******************** ERROR: Bad texcoord index in ase file rich/box_hi.lwo ********************

I'm not trying to say your wrong BNA. I just need some form of explaination for why doom is insisting that I have a "texcoord" index on the high poly model when the UV on the low-poly model is sufficient. Would deleting the UV from the low-poly model work instead? That would mean that a UV map for the hi-poly model is necessary while a UV for the low-poly model is optional.

I'm having trouble trying to imagine how a bumpmap is projected on to a low-poly model without some form of UV coordinates on both models to link portions of the hi and low poly models together. Basically, How does the game know where to project those non-existant curves onto the low-poly model without a similar UV map present in the hi-poly model?

Second, When I have a UV present in both models and renderbump completes succesfully, I have what appears to be a perfect normalmap and colormap. (Other than the fact that my UVs suck. )

But in game when the normalmap is applied to the object it doesn't look quite right. I can see the effect working properly however the normalmap does not look as smooth as it should. It almost looks bitmapped or pixely.

To illustrate my point I would post a screen but we all know the rules. Instead I am going to post my photoshop rendition of what the normalmap actually looks like and what it seems like in game.

The normalmap below is what renderbump outputs.


And this is what it seems to render when applied to a model.


Notice how the second image looks pixellated or grainy. Try to imagine what the Welding Gun from my third scripting tutorial looks like with this second image as a normalmap.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Sun May 04, 2003 8:13 pm    Post subject: :

rich_is_bored wrote:

First, I've been told time and time again that a UV map is not needed for the hi-poly model. It's only needed for the low-poly model.

Still true.

Quote:

Yet, when I open my hi-poly model and delete the UV map, then try to use the renderbump command I get this error... Code: ******************** ERROR: Bad texcoord index in ase file rich/box_hi.lwo ********************

I swear to god that something in your high poly model file is wrong.
Try the following:
- merge points
- delete points with zero polys
- make sure you have only 3 point polygons! (doom doesn't like 2 point polys)
- if everything fails: run the model through qemLOSS2, keep the defaults but set the goal as 0.99999999

By deleting the UV map from you high poly model you may end up with left over points or a few doubled polygons.

[quote]I'm not trying to say your wrong BNA. I just need some form of explaination for why doom is insisting that I have a "texcoord" index on the high poly model when the UV on the low-poly model is sufficient. Would deleting the UV from the low-poly model work instead? That would mean that a UV map for the hi-poly model is necessary while a UV for the low-poly model is optional.[quote]

You can't prove me wrong on this because I'm not

If you delete the UV map from your low poly model, the engine does not know how to project the image on the mesh. Imagine the vertex points as pins you use to apply/stretch a flat rubber poster to a soccer ball.

The UV map for the low poly model is mandatory, for the high poly model it's a crazy attempt to try to create a correct UV map for 500k polys.

Quote:

I'm having trouble trying to imagine how a bumpmap is projected on to a low-poly model without some form of UV coordinates on both models to link portions of the hi and low poly models together. Basically, How does the game know where to project those non-existant curves onto the low-poly model without a similar UV map present in the hi-poly model?

See above - no UV map, no projection.

Quote:

Second, When I have a UV present in both models and renderbump completes succesfully, I have what appears to be a perfect normalmap and colormap. (Other than the fact that my UVs suck. ) But in game when the normalmap is applied to the object it doesn't look quite right. I can see the effect working properly however the normalmap does not look as smooth as it should. It almost looks bitmapped or pixely.

Maybe you just have to up the resolution a little?

Quote:

To illustrate my point I would post a screen but we all know the rules. Instead I am going to post my photoshop rendition of what the normalmap actually looks like and what it seems like in game. And this is what it seems to render when applied to a model. Notice how the second image looks pixellated or grainy. Try to imagine what the Welding Gun from my third scripting tutorial looks like with this second image as a normalmap.

This looks like color banding to me and this could be considered as a diffuse map issue and not as a per pixel lighting issue.
Take your diffuse map and give it a pattern overly in photoshop - use something cloudy.

This should help you to avoid banding.

If it helps you - everything flat colored I use ends up with heavy color banding.

This may be an graphics card internal floating point color value calculation rounding error when composing the images with the light overlay.
You can reduce it even further by adding an additional slightly grainy heightmap to to the normal map in the material shader.

Another possibility could be that you use some lower quality setting in the DoomConfig.

To draw a conclusion:
- Low poly = you need a UV map
- High poly = you don't need a UV map
- Color banding = break flat surfaces up with varying colors and heightmaps
- BNA wrong on this issue = no


_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Sun May 04, 2003 9:55 pm    Post subject: : Like I said earlier, I wasn't trying to prove you wrong. Why? Because you know what your talking about. Anyway, again you have solved the main problem.

Here I am, following all the specifications.

Nothing but triangle polys. No 2 point polys. No points floating in space. And yet I run qemLoss2 and for some odd reason removing a poly or two seems to fix things.

Why? Just a retorical question as I know that nobody not even god could explain it. I guess its one of those mysteries of the universe.

I'm still working on phasing out the color banding. BTW thanks for adding that term to my vocabulary. I always had trouble explaining that one.

So far it looks like I will be needing a heightmap to composite over the normal map to smooth things out. Even without it, it still looks sweet f***ed up.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 6:18 am    Post subject: :

rich_is_bored wrote:

Like I said earlier, I wasn't trying to prove you wrong. Why? Because you know what your talking about. Anyway, again you have solved the main problem.

I've been just joking on that

Quote:

Here I am, following all the specifications. Nothing but triangle polys. No 2 point polys. No points floating in space. And yet I run qemLoss2 and for some odd reason removing a poly or two seems to fix things. Why? Just a retorical question as I know that nobody not even god could explain it. I guess its one of those mysteries of the universe.

Yes, strange.
I've encountered the problem many times but never found out which poly was the problem and why. I realized that while working in subdivision mode in Lightwave you can easily provoke a bad texcoord index when you shape your object by moving points around.
If you move polygon planes instead there's a good chance you'll have a valid mesh later.
I assume that dragging points in SDS mode can result in pretty strange placed points - looks good in Lightwave while SDS is turned on, but ...

Another good technique to model is spline cage modelling.
I draw my curves and then a patch them one time with relatively few subdivisions and another time with as many as I feel like it looks good.
This way you easily maintian the general outline shape without any difficulties.

Quote:

I'm still working on phasing out the color banding. BTW thanks for adding that term to my vocabulary. I always had trouble explaining that one.

My pleasure
Color banding was the reason why graphic card producers switched to 24bit (+alpha) rendering.
You can still see it very eye poking when playing SOF2 and the whole scene is covered with fog.
The pixels get blended many times for the final rendering output, but since the graphic cards calculate "only" with 32bit precision the final image may look worse than running an old game in 16 bit.

Carmack is begging for 64bit internal color precision in graphics cards for years to avoid that.
Doom3 basically is the prime example why we need it - the pixels get recalculated many times for lights and surface property effects that the outcome easily looks screwed.
I assume that's why you don't see any flat colored surface in the alpha.
Detailing the textures more does not only look more interesting, but it's also neccessary to avoid this sort of image corruption.

Quote:

So far it looks like I will be needing a heightmap to composite over the normal map to smooth things out. Even without it, it still looks sweet f***ed up.

Side note about heightmaps:
Just use any procedural texture of choice (I do it this way).
Something grainy looks fine - play with the strength setting.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 5:16 pm    Post subject: : Does anyone know what the maximum number of polys allowed on a single object are?

I've been getting good results with the following polycount:

High Poly Model: 40,000
Low Poly Model: 400

At first I thought I could just make a 6 poly box, triple it, and save it as my low poly and then subpatch, and save it to create the high poly model. Hey, I'm new at modeling, give me a break.

What happens then is you need to create a heightmap to compensate for color banding.

The best solution is just to increase the polycount. Then most times when you renderbump you won't even need a heightmap.

I also suggest you create a map in the editor with a light or two, a player start point, and a func_mover to load your model. Then you can create a script to rotate the object. This serves as a good way to view your object so you can make adjustments.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 6:41 pm    Post subject: :

rich_is_bored wrote:

Does anyone know what the maximum number of polys allowed on a single object are? I've been getting good results with the following polycount: High Poly Model: 40,000 Low Poly Model: 400

I've been getting good results with polycounts as high as 20,000 for low poly models and with over a million for high poly models

Seriously, the RAM's the limit.
I've also managed to load really high polygon models into the game engine, but that's not what it was meant for.

When halfway good renderbumped a character model with approx 15,000 polys looks 99% perfect to the high poly model.
But with 1,500 polys it still looks almost 90% perfect to the high poly one - as long as you don't get angular heads in view...

To have better controll over my objects during renderbump I split the low and high poly parts up.
Possible parts are head - eye(s) - ear(s) - teeth;
torso - armor - fancy deco;
arms - wristwatch - hands;
pelvis - legs - feet - shoe details;

But I UV map them first as one model.
When copying every part to a new object layer, the parts retain their UV map, so I just have to layer the individual tga's back together in photoshop.
The same applies to the individual mesh parts (so make sure not to move them a single inch!).

It's a lot of work though - maybe that's why I avoid renderbumping right now...

Quote:

At first I thought I could just make a 6 poly box, triple it, and save it as my low poly and then subpatch, and save it to create the high poly model. Hey, I'm new at modeling, give me a break.

Don't triple it before you subpatch it!
Tab the object into SDS mode and then subdivide it untill it looks good to you.
When making a box give the edges a radius to allow Doom3 to interpolate at angles smaller than 90 degrees. A round cornder normal map looks bad on a sharp angle. Breaking it into an additional plane rotated to 45 degrees will do suffice to create the supension of a perfect round corner (if the normal looks right) .

[/quote]The best solution is just to increase the polycount. Then most times when you renderbump you won't even need a heightmap.[/quote]

Creating high poly geometry

Quote:

I also suggest you create a map in the editor with a light or two, a player start point, and a func_mover to load your model. Then you can create a script to rotate the object. This serves as a good way to view your object so you can make adjustments.

I do it this way:

I've made a huge box map with 1 fixed and 4 bobbing lights (a circle in top down view) each with a different color.

When I'm done with a few models, I load the map up and type "testmodel basfolderrelative_path/modelname.extension" and then "r_testmodelrotate 1".
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 7:28 pm    Post subject: : The reason I mention 400 as a good polycount for the low poly model is that I use my objects in scripted events. There is a limit for scripted objects. I cannot remember what it is but I do remember having to cut back on the details so I could script movements for the object in game.

I suppose if your just rendering a texture for a flat panel or a static object then hey, bust your computer's balls by making it calculate an insane amount of polys.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 8:11 pm    Post subject: :

rich_is_bored wrote:

The reason I mention 400 as a good polycount for the low poly model is that I use my objects in scripted events. There is a limit for scripted objects. I cannot remember what it is but I do remember having to cut back on the details so I could script movements for the object in game.

Ah thanks - another piece that falls into place.

Quote:

I suppose if your just rendering a texture for a flat panel or a static object then hey, bust your computer's balls by making it calculate an insane amount of polys.

The same hold valid for 3D models, not only for renderbumpflat.

The high resolution models for Doom3's characters count in at over half a million polys.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 10:27 pm    Post subject: : I'm going to have to test that limit out a little because I just made a 1000+ poly and it scripted fine. I'm in no rush to test this out so... I'll post it when I post it.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 10:40 pm    Post subject: :

rich_is_bored wrote:

I'm going to have to test that limit out a little because I just made a 1000+ poly and it scripted fine. I'm in no rush to test this out so... I'll post it when I post it.

Hmm, just a thougt:
Shouldn't the engine give a damn about the polycount of the model attached to a func_mover?
Basically it's "only" handling the func_mover as null object and it only uses the pivot / origin point for calculations.

In my opinion the complexity of the model does not bother the scripting functions. All we do is push and rotate single points around while the renderer rewards us with the attached model as visual feedback.

When the engine has finished the repositioning of the null object according to the scripting variables it is using the newly constructed scene for collision detection and of course rendering (not to mention sound and such).
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 10:43 pm    Post subject: : Send me that landscape *.lwo you made a while back. I'll just stick it in a room and rotate it. HA!
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 10:44 pm    Post subject: :

rich_is_bored wrote:

Send me that landscape *.lwo you made a while back. I'll just stick it in a room and rotate it. HA!

That landscape had less then 1000 polys
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 10:47 pm    Post subject: : BAH! I'll subpatch and freeze it like 50 times.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

fuag@Posted: Tue Aug 15, 2006 7:12 pm    Post subject: : wait, if the high poly models not getting uv'd where does renderbump get the diffuse map it generates from? wouldn't you have to uv the high poly to put the color map on it?

---

Bittoman@Posted: Tue Aug 15, 2006 9:24 pm    Post subject: : The high poly model doesn't need a UV map, in fact it'll cause renderbump to flake out if you try to add one. All the high poly model is being used for is to be traced using the low poly model like a lathe would use a template and a piece of wood (I hope you understand that analogy hehe). No diffusemap is used during renderbumping and in many cases the diffusemap is created after renderbumping (I usually use the UV layout as a template after I've already creaed the normalmap).

---

juve@Posted: Sun Jan 12, 2003 7:36 pm    Post subject: D3 - renderbump: Doom3 renderbump:

_______________________

if you don't know what renderbumbing is, search google for it ("renderbump")and read what the developers say about it. Alternatively search for "polybump"
_______________________

if you look through the material files you can find some materials defined for some models where the shader has an additional line with "renderbump..." in it. I tried to figure out what it can be used for and how to do it.

What i know so far:

if i had a model:
"model/juve/sphere1/sphere1.lwo"
(the ligthwave-material in the lwo-file would be named "surface2")

and had defined a shader named:
"surface2"

looking like this:

Code:

surface2 { renderbump  -size 256 256 -trace 0.03 -colorMap -aa 1  models/juve/sphere1/sphere1_local.tga models/juve/sphere1/sphere1_hp.lwo diffusemap models/juve/sphere1/sphere1_d.tga bumpmap models/juve/sphere1/sphere1_local.tga, specularmap models/juve/sphere1/sphere1_s.tga }

and if had a high-poly "mooncrater"-detailed model of my sphere named:
"models/juve/sphere1/sphere1_hp.lwo"

i can now use the command renderbump like this:

renderbump models/juve/sphere1/sphere1.lwo

Doom3 would load the sphere1.lwo and the sphere1_hp.lwo and create a tga named: models/juve/sphere1/sphere1_local_color.tga

___________________________________________________

the Problem is, the output image is no normalmap-tga, has only 2 colors and doesn't help me much.

did anybody have more luck with doom's renderbump-cmd ?

---

BNA!@Posted: Thu Jan 16, 2003 1:48 pm    Post subject: : Look in the folder you're keeping the model in - there will be two new tga's - one with the name you've specified in the headline of the shader along with the renderbump settings and a second one with the same name but a _color extension.

Rewrite your shader to use the correct tga's at the right places.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

juve@Posted: Fri Jan 17, 2003 12:25 am    Post subject: : yes i know, but the one tga is simply gray and the other has only 2 colors: white and gray. ... no normal-map-tga is produced

---

BNA!@Posted: Fri Jan 17, 2003 7:33 am    Post subject: : This is one of my last shaders i used to renderbump models:

Code:

bna/corridor/structure2 {    renderbump     -size 512 512 -aa 2 -colorMap bna/corridor/structure2.tga bna/corridor/structure2_hp.lwo    bumpmap      bna/corridor/structure2.tga    diffusemap    bna/corridor/structure2_color.tga    //specularmap     models/bna/grey512.tga    translucent    noshadows    //twoSided    //{    //   blend add    //   cubeMap      env/bland    //   texgen      reflect    //} }

The only difference I see is that my -aa settings switch is located differently in the shader.

You can ignore the uncommented sections of course.

If it still doesn't work send me the two lwo models and I'll take a look.

It's also useful to dump the conole output after renderbump has completed.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

juve@Posted: Fri Jan 17, 2003 1:33 pm    Post subject: : If you say doom3's renderbump works just fine,i think i'll give it another try.

btw. I'm looking forward to your renderbumptutorial.

---

rich_is_bored@Posted: Sun May 04, 2003 7:20 pm    Post subject: : Juve, check to make sure your surface names in both your hi-poly and low-poly versions are different. That was what my problem was. Thanks BNA!

Here is two new issues regarding renderbump...

First, I've been told time and time again that a UV map is not needed for the hi-poly model. It's only needed for the low-poly model.

Yet, when I open my hi-poly model and delete the UV map, then try to use the renderbump command I get this error...

Code:

******************** ERROR: Bad texcoord index in ase file rich/box_hi.lwo ********************

I'm not trying to say your wrong BNA. I just need some form of explaination for why doom is insisting that I have a "texcoord" index on the high poly model when the UV on the low-poly model is sufficient. Would deleting the UV from the low-poly model work instead? That would mean that a UV map for the hi-poly model is necessary while a UV for the low-poly model is optional.

I'm having trouble trying to imagine how a bumpmap is projected on to a low-poly model without some form of UV coordinates on both models to link portions of the hi and low poly models together. Basically, How does the game know where to project those non-existant curves onto the low-poly model without a similar UV map present in the hi-poly model?

Second, When I have a UV present in both models and renderbump completes succesfully, I have what appears to be a perfect normalmap and colormap. (Other than the fact that my UVs suck. )

But in game when the normalmap is applied to the object it doesn't look quite right. I can see the effect working properly however the normalmap does not look as smooth as it should. It almost looks bitmapped or pixely.

To illustrate my point I would post a screen but we all know the rules. Instead I am going to post my photoshop rendition of what the normalmap actually looks like and what it seems like in game.

The normalmap below is what renderbump outputs.


And this is what it seems to render when applied to a model.


Notice how the second image looks pixellated or grainy. Try to imagine what the Welding Gun from my third scripting tutorial looks like with this second image as a normalmap.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Sun May 04, 2003 8:13 pm    Post subject: :

rich_is_bored wrote:

First, I've been told time and time again that a UV map is not needed for the hi-poly model. It's only needed for the low-poly model.

Still true.

Quote:

Yet, when I open my hi-poly model and delete the UV map, then try to use the renderbump command I get this error... Code: ******************** ERROR: Bad texcoord index in ase file rich/box_hi.lwo ********************

I swear to god that something in your high poly model file is wrong.
Try the following:
- merge points
- delete points with zero polys
- make sure you have only 3 point polygons! (doom doesn't like 2 point polys)
- if everything fails: run the model through qemLOSS2, keep the defaults but set the goal as 0.99999999

By deleting the UV map from you high poly model you may end up with left over points or a few doubled polygons.

[quote]I'm not trying to say your wrong BNA. I just need some form of explaination for why doom is insisting that I have a "texcoord" index on the high poly model when the UV on the low-poly model is sufficient. Would deleting the UV from the low-poly model work instead? That would mean that a UV map for the hi-poly model is necessary while a UV for the low-poly model is optional.[quote]

You can't prove me wrong on this because I'm not

If you delete the UV map from your low poly model, the engine does not know how to project the image on the mesh. Imagine the vertex points as pins you use to apply/stretch a flat rubber poster to a soccer ball.

The UV map for the low poly model is mandatory, for the high poly model it's a crazy attempt to try to create a correct UV map for 500k polys.

Quote:

I'm having trouble trying to imagine how a bumpmap is projected on to a low-poly model without some form of UV coordinates on both models to link portions of the hi and low poly models together. Basically, How does the game know where to project those non-existant curves onto the low-poly model without a similar UV map present in the hi-poly model?

See above - no UV map, no projection.

Quote:

Second, When I have a UV present in both models and renderbump completes succesfully, I have what appears to be a perfect normalmap and colormap. (Other than the fact that my UVs suck. ) But in game when the normalmap is applied to the object it doesn't look quite right. I can see the effect working properly however the normalmap does not look as smooth as it should. It almost looks bitmapped or pixely.

Maybe you just have to up the resolution a little?

Quote:

To illustrate my point I would post a screen but we all know the rules. Instead I am going to post my photoshop rendition of what the normalmap actually looks like and what it seems like in game. And this is what it seems to render when applied to a model. Notice how the second image looks pixellated or grainy. Try to imagine what the Welding Gun from my third scripting tutorial looks like with this second image as a normalmap.

This looks like color banding to me and this could be considered as a diffuse map issue and not as a per pixel lighting issue.
Take your diffuse map and give it a pattern overly in photoshop - use something cloudy.

This should help you to avoid banding.

If it helps you - everything flat colored I use ends up with heavy color banding.

This may be an graphics card internal floating point color value calculation rounding error when composing the images with the light overlay.
You can reduce it even further by adding an additional slightly grainy heightmap to to the normal map in the material shader.

Another possibility could be that you use some lower quality setting in the DoomConfig.

To draw a conclusion:
- Low poly = you need a UV map
- High poly = you don't need a UV map
- Color banding = break flat surfaces up with varying colors and heightmaps
- BNA wrong on this issue = no


_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Sun May 04, 2003 9:55 pm    Post subject: : Like I said earlier, I wasn't trying to prove you wrong. Why? Because you know what your talking about. Anyway, again you have solved the main problem.

Here I am, following all the specifications.

Nothing but triangle polys. No 2 point polys. No points floating in space. And yet I run qemLoss2 and for some odd reason removing a poly or two seems to fix things.

Why? Just a retorical question as I know that nobody not even god could explain it. I guess its one of those mysteries of the universe.

I'm still working on phasing out the color banding. BTW thanks for adding that term to my vocabulary. I always had trouble explaining that one.

So far it looks like I will be needing a heightmap to composite over the normal map to smooth things out. Even without it, it still looks sweet f***ed up.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 6:18 am    Post subject: :

rich_is_bored wrote:

Like I said earlier, I wasn't trying to prove you wrong. Why? Because you know what your talking about. Anyway, again you have solved the main problem.

I've been just joking on that

Quote:

Here I am, following all the specifications. Nothing but triangle polys. No 2 point polys. No points floating in space. And yet I run qemLoss2 and for some odd reason removing a poly or two seems to fix things. Why? Just a retorical question as I know that nobody not even god could explain it. I guess its one of those mysteries of the universe.

Yes, strange.
I've encountered the problem many times but never found out which poly was the problem and why. I realized that while working in subdivision mode in Lightwave you can easily provoke a bad texcoord index when you shape your object by moving points around.
If you move polygon planes instead there's a good chance you'll have a valid mesh later.
I assume that dragging points in SDS mode can result in pretty strange placed points - looks good in Lightwave while SDS is turned on, but ...

Another good technique to model is spline cage modelling.
I draw my curves and then a patch them one time with relatively few subdivisions and another time with as many as I feel like it looks good.
This way you easily maintian the general outline shape without any difficulties.

Quote:

I'm still working on phasing out the color banding. BTW thanks for adding that term to my vocabulary. I always had trouble explaining that one.

My pleasure
Color banding was the reason why graphic card producers switched to 24bit (+alpha) rendering.
You can still see it very eye poking when playing SOF2 and the whole scene is covered with fog.
The pixels get blended many times for the final rendering output, but since the graphic cards calculate "only" with 32bit precision the final image may look worse than running an old game in 16 bit.

Carmack is begging for 64bit internal color precision in graphics cards for years to avoid that.
Doom3 basically is the prime example why we need it - the pixels get recalculated many times for lights and surface property effects that the outcome easily looks screwed.
I assume that's why you don't see any flat colored surface in the alpha.
Detailing the textures more does not only look more interesting, but it's also neccessary to avoid this sort of image corruption.

Quote:

So far it looks like I will be needing a heightmap to composite over the normal map to smooth things out. Even without it, it still looks sweet f***ed up.

Side note about heightmaps:
Just use any procedural texture of choice (I do it this way).
Something grainy looks fine - play with the strength setting.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 5:16 pm    Post subject: : Does anyone know what the maximum number of polys allowed on a single object are?

I've been getting good results with the following polycount:

High Poly Model: 40,000
Low Poly Model: 400

At first I thought I could just make a 6 poly box, triple it, and save it as my low poly and then subpatch, and save it to create the high poly model. Hey, I'm new at modeling, give me a break.

What happens then is you need to create a heightmap to compensate for color banding.

The best solution is just to increase the polycount. Then most times when you renderbump you won't even need a heightmap.

I also suggest you create a map in the editor with a light or two, a player start point, and a func_mover to load your model. Then you can create a script to rotate the object. This serves as a good way to view your object so you can make adjustments.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 6:41 pm    Post subject: :

rich_is_bored wrote:

Does anyone know what the maximum number of polys allowed on a single object are? I've been getting good results with the following polycount: High Poly Model: 40,000 Low Poly Model: 400

I've been getting good results with polycounts as high as 20,000 for low poly models and with over a million for high poly models

Seriously, the RAM's the limit.
I've also managed to load really high polygon models into the game engine, but that's not what it was meant for.

When halfway good renderbumped a character model with approx 15,000 polys looks 99% perfect to the high poly model.
But with 1,500 polys it still looks almost 90% perfect to the high poly one - as long as you don't get angular heads in view...

To have better controll over my objects during renderbump I split the low and high poly parts up.
Possible parts are head - eye(s) - ear(s) - teeth;
torso - armor - fancy deco;
arms - wristwatch - hands;
pelvis - legs - feet - shoe details;

But I UV map them first as one model.
When copying every part to a new object layer, the parts retain their UV map, so I just have to layer the individual tga's back together in photoshop.
The same applies to the individual mesh parts (so make sure not to move them a single inch!).

It's a lot of work though - maybe that's why I avoid renderbumping right now...

Quote:

At first I thought I could just make a 6 poly box, triple it, and save it as my low poly and then subpatch, and save it to create the high poly model. Hey, I'm new at modeling, give me a break.

Don't triple it before you subpatch it!
Tab the object into SDS mode and then subdivide it untill it looks good to you.
When making a box give the edges a radius to allow Doom3 to interpolate at angles smaller than 90 degrees. A round cornder normal map looks bad on a sharp angle. Breaking it into an additional plane rotated to 45 degrees will do suffice to create the supension of a perfect round corner (if the normal looks right) .

[/quote]The best solution is just to increase the polycount. Then most times when you renderbump you won't even need a heightmap.[/quote]

Creating high poly geometry

Quote:

I also suggest you create a map in the editor with a light or two, a player start point, and a func_mover to load your model. Then you can create a script to rotate the object. This serves as a good way to view your object so you can make adjustments.

I do it this way:

I've made a huge box map with 1 fixed and 4 bobbing lights (a circle in top down view) each with a different color.

When I'm done with a few models, I load the map up and type "testmodel basfolderrelative_path/modelname.extension" and then "r_testmodelrotate 1".
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 7:28 pm    Post subject: : The reason I mention 400 as a good polycount for the low poly model is that I use my objects in scripted events. There is a limit for scripted objects. I cannot remember what it is but I do remember having to cut back on the details so I could script movements for the object in game.

I suppose if your just rendering a texture for a flat panel or a static object then hey, bust your computer's balls by making it calculate an insane amount of polys.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 8:11 pm    Post subject: :

rich_is_bored wrote:

The reason I mention 400 as a good polycount for the low poly model is that I use my objects in scripted events. There is a limit for scripted objects. I cannot remember what it is but I do remember having to cut back on the details so I could script movements for the object in game.

Ah thanks - another piece that falls into place.

Quote:

I suppose if your just rendering a texture for a flat panel or a static object then hey, bust your computer's balls by making it calculate an insane amount of polys.

The same hold valid for 3D models, not only for renderbumpflat.

The high resolution models for Doom3's characters count in at over half a million polys.
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 10:27 pm    Post subject: : I'm going to have to test that limit out a little because I just made a 1000+ poly and it scripted fine. I'm in no rush to test this out so... I'll post it when I post it.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 10:40 pm    Post subject: :

rich_is_bored wrote:

I'm going to have to test that limit out a little because I just made a 1000+ poly and it scripted fine. I'm in no rush to test this out so... I'll post it when I post it.

Hmm, just a thougt:
Shouldn't the engine give a damn about the polycount of the model attached to a func_mover?
Basically it's "only" handling the func_mover as null object and it only uses the pivot / origin point for calculations.

In my opinion the complexity of the model does not bother the scripting functions. All we do is push and rotate single points around while the renderer rewards us with the attached model as visual feedback.

When the engine has finished the repositioning of the null object according to the scripting variables it is using the newly constructed scene for collision detection and of course rendering (not to mention sound and such).
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 10:43 pm    Post subject: : Send me that landscape *.lwo you made a while back. I'll just stick it in a room and rotate it. HA!
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

BNA!@Posted: Mon May 05, 2003 10:44 pm    Post subject: :

rich_is_bored wrote:

Send me that landscape *.lwo you made a while back. I'll just stick it in a room and rotate it. HA!

That landscape had less then 1000 polys
_________________
Staff - The world is yours, soon in 6 degrees of freedom!
Visit ModWiki

---

rich_is_bored@Posted: Mon May 05, 2003 10:47 pm    Post subject: : BAH! I'll subpatch and freeze it like 50 times.
_________________
Staff
Learn something today? Why not write an article about it on modwiki.net?

---

fuag@Posted: Tue Aug 15, 2006 7:12 pm    Post subject: : wait, if the high poly models not getting uv'd where does renderbump get the diffuse map it generates from? wouldn't you have to uv the high poly to put the color map on it?

---

Bittoman@Posted: Tue Aug 15, 2006 9:24 pm    Post subject: : The high poly model doesn't need a UV map, in fact it'll cause renderbump to flake out if you try to add one. All the high poly model is being used for is to be traced using the low poly model like a lathe would use a template and a piece of wood (I hope you understand that analogy hehe). No diffusemap is used during renderbumping and in many cases the diffusemap is created after renderbumping (I usually use the UV layout as a template after I've already creaed the normalmap).

---

fuag@Posted: Tue Aug 15, 2006 11:30 pm    Post subject: : I cant get it to renderbump right.. I have my mesh in md5mesh format and the high poly mesh in .ase because i tried it as .md5mesh and it hella didnt work. This time it says ti took .36 seconds to complete the renderbump but I don't see anything in the target filepath. heres my material def

Quote:

models/marine/boonemarine { renderbump -size 1024 1024 -aa 2 -colorMap textures/marine/marine_local.tga models/marine/marine_hp.ase "qer_editorimage" "textures/marine/marine_d.tga" "diffusemap" "textures/marine/marine_d.tga" "bumpmap" "textures/marine/marine_h.tga" noSelfShadow }

exported the ase using the exporter for blender posted in the forums with material, vert and uv unselected.

can't find a *BITMAP line to change to a material but I guess that shouldn't matter

---

Bittoman@Posted: Wed Aug 16, 2006 12:00 am    Post subject: : Well there's no trace value set (probably just defaults to something if one isn't set in the material file so this may not be a big deal) and I've no clue what the colorMap declaration is for, I've never seen it used and iddevnet doesn't explain what the function does.

As for the problems with rendering, did you apply a material to the low poly model? Did you UV map it? Both of these are required for the low poly model (presumably the md5mesh model in your case) but make sure that you don't add them to the high poly one.

---

fuag@Posted: Wed Aug 16, 2006 12:08 am    Post subject: : yeah, the low poly md5mesh has a material and is uvmapped and just ran a testModel on the high poly .ase and it loads ok, i unchecked exporting uv material and vertex color when i exported the .ase but there were uv coordinates in there because its based off the low poly that I had already uv'd and I'm not sure how to delete uv maps. I took out the -colorMap option but I still get that renderbump took .18 seconds rendrbump completed with no actual rendering hapening or files created.

Command I'm using in the console is

renderbump models/marine/marine.md5mesh

marine.md5mesh points to boonemarine

---

Bittoman@Posted: Wed Aug 16, 2006 2:24 am    Post subject: : Something just hit me that might be the problem. Did you freeze the mesh's size and rotation before you exported it for both the low and the hi poly?

---

fuag@Posted: Wed Aug 16, 2006 3:24 am    Post subject: : i froze it on the .ase but not the md5mesh, just tried freezing that and still wont actually renderbump anything... I'll at it to the .ase along with the rest of the files at

http://fuag.is-a-geek.com/filez/Marine/

---

Bittoman@Posted: Wed Aug 16, 2006 3:53 am    Post subject: : Ahh I see what's wrong. You didn't apply an image but rather a series of blends within Blender to try to, what I'd assume, is render a normalmap using Blender. Delete the Red, Green, Blue links in the Textures tab (F6) and then add one "Image". Then click the "Load Image" and just choose the skin you're applying (any image will work fine if you plan on going back and manually editing the link).

---

fuag@Posted: Wed Aug 16, 2006 6:08 am    Post subject: : sorry, the materials were left over from my first attempt at normal mapping before i realized doom3 had renderbump, I took them out though. The marine.blend is just bieng used to export marine.md5mesh and marine.md5anim so I only set up the uv coordinates in the uv image editor so that they would work when I linked a .mtr to the md5mesh. the marine_hp.blend is the one i'm tryingto use as a high poly model for the renderbump.

I've been told to not include uvmapping or texturing in the ase file. I wanted to just use a higher poly md5mesh file for the renderbump because I've already figured them out but it doesnt take md5mesh's for high poly models I'm guessing.

---

Bittoman@Posted: Wed Aug 16, 2006 12:57 pm    Post subject: :

Quote:

The marine.blend is just bieng used to export marine.md5mesh and marine.md5anim so I only set up the uv coordinates in the uv image editor so that they would work when I linked a .mtr to the md5mesh.

For the low poly model you still have to reference an image, otherwise when it's exported it'll export UV coordinates but it won't export properly. It'll export error free but if you try to force a material on it afterwards it may not actually render the material, UV coordinates or not (I made this mistake many times when I first started hehe). This very well may still be the problem you're having though.

I'll try and renderbump it using static models and see what happens.

---

Bittoman@Posted: Wed Aug 16, 2006 1:48 pm    Post subject: : Ok, here's some problems:

-the high poly model still has an image reference and UV coordinates attatched. To fix this just delete the material and TexFace
-the material file is saved in rich text format instead of simple text (just use Notepad and create a new txt file then change the extension)
-Also you had noselfshadow at the bottom of the shader rather than at the top. Declarations like these should be at the top
-There was also no trace value set. I added one and started at .02 (it may need to be set higher, there were some render errors with it at .02 so this is a heavily experimental setting)
-Quotes were used around the texture links and functions, it may actually ignore these but I've never done it so I don't know for sure. It's best to not add them though and save yourself some troubleshooting

After correcting all of these it rendered fine (it's still baking atm).

---

fuag@Posted: Wed Aug 16, 2006 11:03 pm    Post subject: : cool, thnx for looking at em! It worked over here 2. Now on to animating md5meshes

---