how to work with low-poly models?

echolab's picture

hi all, a lot of low-poly 3d models from the internet come with texture maps. what is the best way to reproduce the bump effect, seen in the picture, in kineme3d?

and does anybody know what these ".mtl" files are about?

i attached a sample model of a shipping container.obj with normal, diffuse and bump maps.

grischa@echolab

PreviewAttachmentSize
container_textured.jpg
container_textured.jpg34.96 KB
ShipContainer.zip223.09 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
mtl + fanciness

mtl files are Material files for objs. They describe the ambient coloring/transparency of a model, and possibly some other data. Why this isn't bundled into the obj file itself is probably because the obj file format is already 100% nonsense anarchy, and adding mtl definitions would lower the entropy some. [/sarcasm] Kineme3D Doesn't handle lighting or per-vertex coloring, so they're not useful.

Bumpmapping (and normal mapping, and parallax mapping, and all the other fancy texturing techniques that have been invented over the history of 3d computer graphics) can probably only be performed in a GLSL shader designed to apply those mappings. There's a way to get Stock OpenGL to do bump mapping, but it's not generic enough to be employed in Kineme3D. [i.e. it requires multitexturing, which is hideously archaic, and severely deprecated in favor of glsl]

[Edit: before you spend too many calories trying to pull it off: Bumpmapping and normal mapping both require tangent vectors to be fed in as vertex attributes -- nothing in QC currently does this, and isn't likely to in the near future.]

franz's picture
ROTFL

really.... a realtime GL app that can't do bump mapping , in 2009 ....

statement: serious 3D stuff will lead to switching to Ogre. Or not.

EDIT: maybe finally not: have a look at the DIMPLE GLSL example in your dev. folder.... isn't that bump mapping ??? quote: " vec3 n = normalize(gl_NormalMatrix * gl_Normal); "

cwright's picture
FTW

It's bumpmapping, but it cheats and isn't generally useful.

Detailed list of aggravations:

  • manual light position input? give me a break (i hate 3dlabs for doing this in all their shaders)
  • diffuse color? is a diffuse image input so difficult? (no: i did it in a few seconds -- why don't they ever do this?)
  • while it's bumpmapping, note the lack of control on the bumps: no parameters, no images. Let's explore this.

The bump magic takes place in the vertex shader with the following snippet:

vec3 n = normalize(gl_NormalMatrix * gl_Normal);
vec3 t = normalize(cross(vec3(1.141, 2.78, 3.14), n));
vec3 b = cross(n, t);

n = normal. t = tangent vector (darn). b = binormal vector(cross product of tangent and normal vectors).

So there you have it: This method still requires tangent vectors, which no built in objects provide. It also generates them mathematically, instead of pulling it from a texture. Kineme3D could provide tangent/binormal vertex attributes, but then what do we do when it breaks GLSL shaders that do weird things with attributes? (and how in the hell will the 8-way mesh blender work? all those attributes are already tied up with other mesh vertices...)

Taking it a step further, let's explore the GLSL showpiece: Exhibit Bumpmap. (follow along at /Developer/Examples/OpenGL/Cocoa/GLSLShowpiece/Exhibits/Bumpmap/)

from Bumpmap.vert, we get the following:

...
attribute vec3 Tangent;
attribute vec3 Binormal;
...

Damnit, there they are again.

It's a simple concept, I agree. It's amazingly powerful too (check out any decent normal mapped mesh, and tell me it isn't shockingly better than per-vertex normal'd). But pulling it off in QC requires a much better shader foundation than it currently has -- hacking it in to appease a few people doesn't feel as right as architecturing a proper solution that solve this, and other vertex attribute problems elegantly.

Non-glsl bump map example: http://www.paulsprojects.net/tutorials/simplebump/simplebump.html

Note the glTexEnvi calls -- that's where the magic happens. This could be possible, but it requires writing a patch designed specifically around this feature (to handle textures properly, and massage them into the right place with OpenGL's fixed-function texture units). meh.

echolab's picture
glsl bump

thanks for the advice....i was able to apply the bump mapping thanks to some sample code by alex. but now i lost my diffuse texture info (the picture). since i don't know much about glsl coding, can someone help me integrating this into the shadercode?

PreviewAttachmentSize
Container 2.zip243.08 KB
container_bump.jpg
container_bump.jpg56.07 KB

cwright's picture
hero!

wow, I'm impressed -- all the implementations of bump/normal mapping I've seen require lots more.

Here's a modified shader that takes the diffuse input. Looks convincing.

[edit: Or, better yet, just uncomment the last part of the last line of the fragment shader -- this looks much better than my hacked attempt...]

PreviewAttachmentSize
Container 3.zip244.94 KB

gtoledo3's picture
iffy?

Hero you are!

But, I'm not 100% convinced on this... if it was actually doing a bump, wouldn't it respond to lighting correctly? If I rotate it 180, the "light" parts of the indentation are not correct. Hmmm... I wonder if it isn't bumping at all, but is just an eye trick because of the picture?

echolab's picture
credits

all credits go to alex: http://machinesdontcare.wordpress.com/2008/03/31/bump-mapping .

thanks for the help, i think i will start to learn glsl now ;-)

grischa

edit: here's the link to the original 3d model: http://nfollmer.com/art.html

cwright's picture
*nods*

that's part of the reason why this is all faked... real bump/normal mapping doesn't suffer from these problems (but requires extra data).

gtoledo3's picture
Oh. Then what is the point

Oh. Then what is the point of this, if the normals aren't really getting manipulated? I know I am missing something on this :o) Is it just a way of at least being able to utilize the "normal" file out of the box for some effect, but at the end of the day, it is basically a glorified image map since there is no real displacement?

EDIT: just saw you "edit"... I'll shut my big mouth for now, and look at the file...

psonice's picture
bump methods

There's a few ways to fake (or not even) bumpy surfaces.

The most fake (but easiest to implement in QC) is to bake your textures in a 3d app that supports it.. you make your model either in high res or with bump maps, light it, and the app spits out a new texture which has the lighting and bumps already there. You just texture with that in QC, and you'll have a very high quality lit, bumpy object. The catch is that the light is totally fixed of course, but it's good for static scenery etc.

Then you have a fair few different bump map techniques, going from the old dot3 methods (i think that had a fixed light angle in some way.. it was popular before shaders) up to the more recent stuff. The more recent stuff is more interesting, but you will generally need those normals.

Normal mapping: for this, you have an extra texture that stores the normals for the surface (bump maps tend to just store the surface height, for normal maps you have RGB representing the XYZ rotation of the normal for the pixel). You read this in the shader, and rotate the normal for each pixel by the values in the normal map. That makes the lighting show the small details in the texture correctly. The downside is that it's still technically flat, it's just lit as if it's bumpy.

Displacement mapping: for this you generally subdivide the actual geometry, and displace it using a texture. You get actually bumpy geometry instead of low-poly that looks bumpy, so it's very high quality, and looks good at any angle. Of course it's expensive, and probably impossible in QC.

The most popular one of late is parallax occlusion mapping. This is something of a hybrid.. you render in the pixel shader on a low-poly object, as if it's a bump map, but it renders the bumpy surface in 3d via a bit of raytracing in the pixel shader. It's complex, but the results are really good. Decent explaination of a good looking technique (well, a bit in-depth and lacking in handy copy + paste code :) is here: http://ati.amd.com/developer/techreports/2006/I3D2006/Tatarchuk-POM-SI3D...

You can mix them at will of course for better results.. I used a mix of displacement and normal mapping in my demo tool, the results seem to be decent enough. Quick pic available here (the mountainy bits are from the kineme texture plugin :) http://psonice.untergrund.net/images/tool2.jpg

gtoledo3's picture
Thanks for the post, that

Thanks for the post, that cleared up the fuzzies for me. I was confusing/overlapping aspects of normal and displacement mapping.

echolab's picture
Steep Parallax Mapping

gtoledo3's picture
That was a nice read,

That was a nice read, thanks. It's interesting how ray tracing is intertwined in that technique... I actually wikipedia'd ray tracing after looking at this and am finding all of the related articles pretty enlightening as well.

gtoledo3's picture
I think you are right in

I think you are right in that it is better to have stability and everything "work as it should" rather than just shoehorn stuff in.

It is really irritating when you spend a lot of time on something and then go to do something standard like, put it in a render in image or something, and it doesn't work.

However, there's something to be said for the "prescription bottle label" style as well... doesn't bother me on the mesh blender :o) I think prior disclosure is key.

This has been one of my favorite threads!

cwright's picture
zen

We've done a few "prescription bottle label" things, but historically the number of users that read them is very low, and the time spent servicing "OMG, it's teh br0ken! kineme sux!" e-mails is significantly higher. That was fun when there weren't many users, and explanations were easy, but now that there are tons of users, and extremely contrived cases where things fail (3D opens a big can of worms: We've got GLSL state, GL Tools state modifiers, track balls, lighting, texturing, depth buffers, alpha blending, blah blah blah), making it less obvious for new users, and more time-consuming for us to elaborate on (Note how long these "This technique is impossible" threads get for 3D junk, whether it's technically impossible, or just wildly inconvenient due to QC's environment, or I'm just an idiot who doesn't know anything).

So I guess I'm torn on how to proceed in that direction -- make whole sets of private patches/plugins? Fire up more annoying pop-up boxes ("Attention: You shouldn't use this patch. If you continue and things explode, we'll have to disable your mail program so you can't whine at us, or post complaints on the forums!"). I'm open to ideas for this though - back when I was just starting out, most of my stuff was recklessly careless of "good form" in QC (because I had no idea what I was doing, mostly :), and getting a bit of that back might trigger some really cool innovations.

yanomano's picture
Clear and net !

Thanks mister Wood. Very instructive...:)

toneburst's picture
Bumping Along

I'm a little embarrassed you're using some of my code here. I did this ages ago, without really having much idea what I was doing, and it never really worked properly.

a|x