[Solved]Loading obj file with mtl problem.

You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers.
No questions about C++ programming or topics which are answered in the tutorials!
lvgeng
Posts: 38
Joined: Fri Aug 14, 2015 4:35 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by lvgeng »

CuteAlien wrote:Yeah, often all the default-materials are not doing exactly what you want and you have to write your own material shader.
:shock:
Actually... I run into something even more interesting.
Code is as following, almost no difference from the original one. I test different parameters and find out something interesting, the results of rendering is depended on the scale of the model.
If the lighting is disabled (but added like in the code), the model looks fine and have no relation with the scale with the model.
But if the light is enabled, the render result of some part of the model will be related to the scale of the model (The larger scale factor, the darker the window part is). It is something really wired and I think it should never happen. (I have test the result of putting the light quite far away from the model, seems no difference.)
Would you mind to check what happened?

Code: Select all

#include <irrlicht.h>
using namespace irr;
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#pragma comment(linker, "/subsystem:windows /ENTRY:mainCRTStartup")
#endif
 
int main()
{
    IrrlichtDevice *device =
        createDevice(video::EDT_OPENGL, dimension2d<u32>(800, 600), 16,
            false, true, true, 0);
    if (!device)
        return 1;
    device->setWindowCaption(L"Hello World! - Irrlicht Engine Demo");
    IVideoDriver* driver = device->getVideoDriver();
    ISceneManager* smgr = device->getSceneManager();
    IGUIEnvironment* guienv = device->getGUIEnvironment();
 
    IAnimatedMesh* mesh = smgr->getMesh("../media/f14/f14d.obj");
    if (!mesh)
    {
        device->drop();
        return 1;
    }
    IAnimatedMeshSceneNode* node = smgr->addAnimatedMeshSceneNode(mesh);
 
    if (node)
    {
        node->setMaterialFlag(EMF_LIGHTING, true);
        node->setScale(core::vector3df(1,1,1));
        node->setRotation(core::vector3df(0,135,0));
    }
 
    smgr->addLightSceneNode(0, core::vector3df(2000, 2000, 2000), video::SColorf(1.0f, 1.0f, 1.0f), 20000);
    smgr->addLightSceneNode(0, core::vector3df(2000, 2000, -2000), video::SColorf(1.0f, 1.0f, 1.0f), 20000);
    smgr->setAmbientLight(video::SColorf(0.3f, 0.3f, 0.3f));
 
    scene::ICameraSceneNode* currentCamera = smgr->addCameraSceneNodeFPS();
    currentCamera->setFarValue(20000.f);
    currentCamera->setPosition(core::vector3df(0, 0, -70));
    currentCamera->setTarget(core::vector3df(0, 30, 0));
 
 
    while (device->run())
    {
        driver->beginScene(true, true, SColor(255, 100, 101, 140));     
        smgr->drawAll();
        guienv->drawAll();
        driver->endScene();
    }
    device->drop();
    return 0;
}
node->setScale(core::vector3df(1,1,1));
node->setMaterialFlag(EMF_LIGHTING, false);
Image


node->setScale(core::vector3df(1,1,1));
node->setMaterialFlag(EMF_LIGHTING, true);
Image


node->setScale(core::vector3df(2,2,2));
node->setMaterialFlag(EMF_LIGHTING, true);
Image


node->setScale(core::vector3df(3,3,3));
node->setMaterialFlag(EMF_LIGHTING, true);
Image


node->setScale(core::vector3df(3,3,3));
node->setMaterialFlag(EMF_LIGHTING, true);
Image


node->setScale(core::vector3df(10,10,10));
node->setMaterialFlag(EMF_LIGHTING, true);
Image


node->setScale(core::vector3df(10,10,10));
node->setMaterialFlag(EMF_LIGHTING, false);
Image
CuteAlien
Admin
Posts: 9682
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by CuteAlien »

Try setting: node->setMaterialFlag(video::EMF_NORMALIZE_NORMALS, true);
Otherwise you can't scale models with correct light.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
lvgeng
Posts: 38
Joined: Fri Aug 14, 2015 4:35 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by lvgeng »

CuteAlien wrote:Try setting: node->setMaterialFlag(video::EMF_NORMALIZE_NORMALS, true);
Otherwise you can't scale models with correct light.
Here is the result I got. (with light enabled and setScale to 3) It seems that a large piece of shinning bright white should be the RIGHT result of the material with the model... And I think the only reason why my former trying seems to have the "right" result is that it's wrong so that the impact from the light became less effective... Then which part of the MTL file I should modify? Ka? Kd? Ks? illum? Ns? (Actually a little confused about what it means for each of them...)

PS: I disabled the dot light sources and I can see the bright is dark but with texture, I think the other part has only material for dot light and won't react to ambient light. On the other side, the bright part in the following image should have quite a strong diffusion I guess...

Code: Select all

# 
# Wavefront material file
# Converted by the DEEP Exploration  Deep Exploration 6.0 6.0.0.5908 Release
# Right Hemisphere, LTD
# http://www.righthemisphere.com/
# 
 
newmtl Material__44
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 25.9921
map_Kd f14landinggear.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__26
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 19.6983
map_Kd f14fuselage_lower.jpg
map_bump f14fuselage_lower_Normal.jpg
bump f14fuselage_lower_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14fuselage_lower_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__27
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 27.8576
map_Kd f14intakes_misc.jpg
map_bump f14intakes_misc_Normal.jpg
bump f14intakes_misc_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14intakes_misc_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__29
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 29.8571
map_Kd f14_wing_2.jpg
map_bump f14_wing_2_Normal.jpg
bump f14_wing_2_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14_wing_2_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__38
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 59.7141
map_Kd f14d_burner.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__28
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 29.8571
map_Kd f14_wing_1.jpg
map_bump f14_wing_1_Normal.jpg
bump f14_wing_1_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14_wing_1_spec.jpg
map_kA 
map_Ns 
 
newmtl _1___Default
Ka 0.588 0.588 0.588
Kd 0.588 0.588 0.588
Ks 0.9 0.9 0.9
illum 2
Ns 24.2515
map_Kd 
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__39
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 21.1121
map_Kd f14taileron_lt.jpg
map_bump f14taileron_lt_Normal.jpg
bump f14taileron_lt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14taileron_lt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__40
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 18.3792
map_Kd f14taileron_rt.jpg
map_bump f14taileron_rt_Normal.jpg
bump f14taileron_rt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14taileron_rt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__25
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 24.2515
map_Kd f14fuselage.jpg
map_bump f14fuselage_Normal.jpg
bump f14fuselage_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14fuselage_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__37
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 22.6274
map_Kd Pilota_militare.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__43
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 45.2548
map_Kd f14engine.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__31
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 18.3792
map_Kd f14_stores.jpg
map_bump f14d_stores_Normal.jpg
bump f14d_stores_Normal.jpg
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__30
Ka 0.482353 0.52549 0.54902
Kd 0.482353 0.52549 0.54902
Ks 0.9 0.9 0.9
illum 2
Ns 29.8571
map_Kd 
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__32
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 21.1121
map_Kd f14canopy.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS f14canopy_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__42
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 32
map_Kd f14tail_rt.jpg
map_bump f14taileron_rt_Normal.jpg
bump f14taileron_rt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14tail_rt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__41
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 1 1 1
illum 2
Ns 14.9285
map_Kd f14tail_lt.jpg
map_bump f14tail_lt_Normal.jpg
bump f14tail_lt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14tail_lt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__33
Ka 0.00784314 0.0705882 0.0980392
Kd 0.00784314 0.0705882 0.0980392
Ks 0.9 0.9 0.9
illum 2
Ns 19.6983
d 0.38
map_Kd 
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__34
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 25.9921
map_Kd f14interior_detail.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__36
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0.9 0.9 0.9
illum 2
Ns 34.2967
map_Kd sju17ejectionseat.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
Image
Last edited by lvgeng on Mon Jan 11, 2016 5:00 pm, edited 1 time in total.
CuteAlien
Admin
Posts: 9682
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by CuteAlien »

The bright parts are probably because those parts are not textures. So it is using vertex-colors. You can disable lighting per mesh-buffer - and maybe the best idea in your case is to do that for all meshbuffers which have no texture (loop over all materials and check which have a nullptr for the first texture - disable lighting for those).

It obj format the vertex-colors might be set by 'Kd', but I'm not sure about that.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
lvgeng
Posts: 38
Joined: Fri Aug 14, 2015 4:35 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by lvgeng »

CuteAlien wrote:The bright parts are probably because those parts are not textures. So it is using vertex-colors. You can disable lighting per mesh-buffer - and maybe the best idea in your case is to do that for all meshbuffers which have no texture (loop over all materials and check which have a nullptr for the first texture - disable lighting for those).

It obj format the vertex-colors might be set by 'Kd', but I'm not sure about that.
I set all Ks to "Ks 0 0 0" manually and it works fine now. Seems to be a problem of specular colour, not the diffuse colour. Although I am still confuse about why the others work fine from the beginning. (Their Ks value are quite close to each other)

Thanks for your help. Currently I don't have time to deal with it, but I guess it is better to figure out why. PS: the model looks quite good in other model editors, so ... I guess irrlicht might still have some problem to solve in this area.
CuteAlien
Admin
Posts: 9682
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by CuteAlien »

Ks is probably ignored when the material also has a texture. So for others it doesn't matter which value it has.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
lvgeng
Posts: 38
Joined: Fri Aug 14, 2015 4:35 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by lvgeng »

CuteAlien wrote:Ks is probably ignored when the material also has a texture. So for others it doesn't matter which value it has.
Well.... truth is it did make a difference... Be my guest to try. I will paste the new mtl file.

Code: Select all

# 
# Wavefront material file
# Converted by the DEEP Exploration  Deep Exploration 6.0 6.0.0.5908 Release
# Right Hemisphere, LTD
# http://www.righthemisphere.com/
# 
 
newmtl Material__44
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 25.9921
map_Kd f14landinggear.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns
 
newmtl Material__29
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 29.8571
map_Kd f14_wing_2.jpg
map_bump f14_wing_2_Normal.jpg
bump f14_wing_2_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14_wing_2_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__26
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 19.6983
map_Kd f14fuselage_lower.jpg
map_bump f14fuselage_lower_Normal.jpg
bump f14fuselage_lower_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14fuselage_lower_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__27
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 27.8576
map_Kd f14intakes_misc.jpg
map_bump f14intakes_misc_Normal.jpg
bump f14intakes_misc_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14intakes_misc_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__29
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 29.8571
map_Kd f14_wing_2.jpg
map_bump f14_wing_2_Normal.jpg
bump f14_wing_2_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14_wing_2_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__38
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 59.7141
map_Kd f14d_burner.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__28
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 29.8571
map_Kd f14_wing_1.jpg
map_bump f14_wing_1_Normal.jpg
bump f14_wing_1_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14_wing_1_spec.jpg
map_kA 
map_Ns 
 
newmtl _1___Default
Ka 0.588 0.588 0.588
Kd 0.588 0.588 0.588
Ks 0 0 0
illum 2
Ns 24.2515
map_Kd 
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__39
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 21.1121
map_Kd f14taileron_lt.jpg
map_bump f14taileron_lt_Normal.jpg
bump f14taileron_lt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14taileron_lt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__40
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 18.3792
map_Kd f14taileron_rt.jpg
map_bump f14taileron_rt_Normal.jpg
bump f14taileron_rt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14taileron_rt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__25
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 24.2515
map_Kd f14fuselage.jpg
map_bump f14fuselage_Normal.jpg
bump f14fuselage_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14fuselage_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__37
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 22.6274
map_Kd Pilota_militare.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__43
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 45.2548
map_Kd f14engine.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__31
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 18.3792
map_Kd f14_stores.jpg
map_bump f14d_stores_Normal.jpg
bump f14d_stores_Normal.jpg
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__30
Ka 0.482353 0.52549 0.54902
Kd 0.482353 0.52549 0.54902
Ks 0 0 0
illum 2
Ns 29.8571
map_Kd 
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__32
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 21.1121
map_Kd f14canopy.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS f14canopy_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__42
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 32
map_Kd f14tail_rt.jpg
map_bump f14taileron_rt_Normal.jpg
bump f14taileron_rt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14tail_rt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__41
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 14.9285
map_Kd f14tail_lt.jpg
map_bump f14tail_lt_Normal.jpg
bump f14tail_lt_Normal.jpg
map_opacity 
map_d 
refl 
map_kS f14tail_lt_spec.jpg
map_kA 
map_Ns 
 
newmtl Material__33
Ka 0.00784314 0.0705882 0.0980392
Kd 0.00784314 0.0705882 0.0980392
Ks 0 0 0
illum 2
Ns 19.6983
d 0.38
map_Kd 
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__34
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 25.9921
map_Kd f14interior_detail.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
newmtl Material__36
Ka 0.588 0.588 0.588
Kd 1 1 1
Ks 0 0 0
illum 2
Ns 34.2967
map_Kd sju17ejectionseat.jpg
map_bump 
bump 
map_opacity 
map_d 
refl 
map_kS 
map_kA 
map_Ns 
 
Vectrotek
Competition winner
Posts: 1087
Joined: Sat May 02, 2015 5:05 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by Vectrotek »

If you write your own shader that uses normal maps then make sure the "bump map" reference in the material file
is commented out using # at the beginning of the line containing the reference because your normal mapping gets screwed up by Irrlicht
when it sees the reference.
With objects using only one material you can delete the material file completely.
If your object uses more than one material then you must keep the material file and disable the bump references as above.
There should be a way to control the way Irrlicht handles materials.
You could also have Irrlicht render the normals in debug mode to see if they are in fact facing the right way.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by mongoose7 »

This is not quite accurate. The bump_map reference must be a reference to a "bump" map. You cannot use a normal map here. Some programs still export bump maps, Poser for example. You must keep the material file in all cases unless you programmatically apply materials after loading the model.
Vectrotek
Competition winner
Posts: 1087
Joined: Sat May 02, 2015 5:05 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by Vectrotek »

O.K. The "Bumpmap" reference in Alias's (now Autodesk's) "*.mat" file does not mean it "must" be a bump map as we understand it to be a simple
but effective "8 bit pixel" driven deviation of a normal which is in fact not really physically correct under lighting as a subject..
ID, with Doom III used it first as a simple addition of "micro bumps" to the then quite new "Normal Map".
It is usually used in shaders to effect a "deviation" of the normal on a surface so that bumps or cracks in surfaces
can be rendered along with the Normal Mapped Normals as an extra bit of detail.
The true deviation-direction of this normal cannot be controlled like with a true Normal Map in which RGB is interpreted as Range Compressed XYZ values.
Some software titles and even people (mistakenly) understand this "Bump" to also mean "Normal Map".
One example of such a software title that use this "Bump" image as a normal map is "Asimp Viewer" which, when it encounters
this "Bump" image file treats it as a "Normal Map" which deviates the normals in a physically correct manner.

Now.. Irrlicht, even when you "Programatically" assign textures to materials (under your own material shaders of-course), when loading an object that refers to an existing "*.mtl" file
somehow (wrongly) "overrides" your Normal generating code to make bumps on the surface when it encounters, this bump reference and the associated image file.

What I mean is that Irrlicht does not seem uphold a "clear line" between "Irrlicht Rendering" and user custom "Shader Rendering" in that once you have
assigned a shader to a material, it still allows Irrlicht internal things to affect the final render.
I understand, that once you have created a material which refers to a shader, then it should not be possible to render it in a style anything other
than what is coded in the "Fragment" part of your Shader (GLSL or HLSL). Another example of this is the fact that the image that you set as diffuse under HLSL is not
really under your control as it should be (try it out yourself). The Diffuse image I choose in my fragment program should be the diffuse image
rendered.. It is not.. (GLSL is fine however).

[correction]
See the "Joker" model as rendered by my shader and the same model rendered by "robmar's" (gone now) shader. (elsewhere on the forums)
You'd need to take a close look at these two renderings to see the difference between Irrlicht induced bump mapping
and Physically Correct Normal Deviation Lighting.

I may have missed something but I had a real close look at this and I keep getting the same results.

I'm busy with my software engineering studies, so it may be a while before I post a good example of this.

I will however post a shader soon that I wrote which does the "physically based lighting" thing in both its GLSL and HLSL form.
Last edited by Vectrotek on Mon Jan 18, 2016 6:28 pm, edited 1 time in total.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by mongoose7 »

You don't seem to understand the difference between a bump map and a normal map. It is normal maps that provide a deviation from the normal. Bump maps don't do this. They contain a displacement to add to the surface. So, normal maps give the appearance of bumps by affecting the lighting by changing the normals. Bump maps have got nothing to do with lighting and more with displacing the surface. They were probably intended for ray tracers. Irrlicht will convert a bump map into a normal map in the loader, so it is a loader feature, not a core Irrlicht feature.
Vectrotek
Competition winner
Posts: 1087
Joined: Sat May 02, 2015 5:05 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by Vectrotek »

It seems you may have confused Bump Mapping with Height Mapping and more advanced Parallax Mapping or even Cone Step Mapping..
You see, if you look at shader tutorials in which bump mapping is mentioned you'll notice that it usually
includes code that clearly has a process in which the final normals are perturbed by the values of pixels
in a "Bump Map". Bump Mapping is nothing more than a cheap imitation of Normal Mapping with the
constraint that Normal Deviation cannot be truly controlled resulting in true physically based lighting.
see https://en.wikipedia.org/wiki/Bump_mapp ... ing_basics..
One can only appreciate the difference between Bump Mapping and Normal Mapping when
you witness the render from a shader that truly takes light positions and normals into consideration..

As for the Irrlicht issue in which the "loader" is considered the culprit, I can only state that
once you have assigned a shader to a material, then Bumps should absolutely not be rendered
even if the image for them was found by this loader. So I stand by my statement on Irrlicht not
completely respecting the shader once it has been hooked to a material.
If you wish to see a shader that "correctly" renders lighting using Normal Maps
then see http://irrlicht.sourceforge.net/forum/v ... bb832c8c84
(I believe this was the first time that true normal mapping was shown on any of these forums.)
I'm actually surprised you had not looked at it as it was your help that made it possible.

The bottom line is that there is something going on deep within the Irrlicht engine that renders things that has nothing
to do with the shaders assigned to materials and I still consider that a Bug!
In all the Open GL and Direct 3D material I have read sofar, I have never seen the Shader code getting "overridden" the way it does in Irrlicht.

Finally, a Bump Map can never be converted to a normal map simply because there is not enough X Y and Z information in a bump map to use for this purpose.
Only if the neighbors of such a pixel is considered to generate a linear "angled line" and thus a Normal but this tech was tried in things like "Crazy Bump" without
much success.

I could be wrong but ill need to be convinced.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: Loading obj file with mtl problem. (Model fine in exampl

Post by mongoose7 »

tl;dr

The Irrlicht method of creating a normal map from a bump map works fine for smooth surfaces. I think that is all you can ask for.
Post Reply