Dice and collsion

[CuteAlien]

It's a sad fact of life that we're sometimes stuck with the nicks we chose when younger and more drunk ;-)

[mongoose7]

But it still is not bad. What an English speaker would appreciate is the clash between "cute" and "alien", and this would negate the standalone effect of cute.

[CuteAlien]

Following is the closest I got. There is still a problem - which seems to depend on the camera angle. Maybe you get lucky and can get better results by playing some more with the parameters.

Code: Select all

 
#include <irrlicht.h>
 
using namespace irr;
using namespace core;
 
#ifdef _MSC_VER
#pragma comment(lib, "Irrlicht.lib")
#endif
 
int main()
{
    IrrlichtDevice *  Device = createDevice(video::EDT_OPENGL, core::dimension2d<u32>(800,600));
    if (!Device)
        return false;
   
    scene::ISceneManager* smgr = Device->getSceneManager();
    scene::IMeshManipulator * manipulator = smgr->getMeshManipulator ();
    video::IVideoDriver * videoDriver = Device->getVideoDriver ();
    
    // fps-camera
    scene::ICameraSceneNode * camera = smgr->addCameraSceneNodeFPS(0, 20.f, 0.1f );
    camera->setTarget(core::vector3df(0, 0, 0));
    camera->updateAbsolutePosition();
    camera->setPosition(core::vector3df(0, 50, -100));
    
    // you can use up to 2 lights with default normal-map shader
    smgr->addLightSceneNode(0, core::vector3df(-200, 200, -200),
                            video::SColorf(1.0f, 1.0f, 1.0f),
                            1000.0f);   
    
    smgr->addLightSceneNode(0, core::vector3df(200, -200, 200), video::SColorf(1.0f, 1.0f, 1.0f), 1000.0f);
    /* // test with rotating light
    scene::ILightSceneNode* light1 = smgr->addLightSceneNode(0, core::vector3df(0, 0, 0), video::SColorf(1.0f, 1.0f, 1.0f), 1000.0f);
    scene::ISceneNodeAnimator * flyCircleAnimator = smgr->createFlyCircleAnimator(core::vector3df(0.f, 0.f, 0.f), 200.f, 0.001f);
    light1->addAnimator(flyCircleAnimator);
    flyCircleAnimator->drop();
    */
    
    scene::IAnimatedMesh* mesh = smgr->getMesh( "grenade/grenade_obj_format/grenade.obj" ); 
    /* //  problem: X is not having correct normals
    //scene::IAnimatedMesh* mesh = smgr->getMesh( "grenade/grenade_x_format/grenade.X" );   
    bool recalculateNormals=true;   
    bool smooth=true;
    bool angleWeighted=false;
    bool recalculateTangents=true;
    manipulator->createMeshWithTangents(mesh, recalculateNormals, smooth, angleWeighted, recalculateTangents); */
 
    // using .x texture as the one in the .mtl got modified on loading and we want the non-modified.
    mesh->getMeshBuffer(0)->getMaterial().setTexture(1, videoDriver->getTexture("grenade/grenade_x_format/nrm.tga"));
 
    /* // texture clamping and filtering seems to have no effect
    mesh->getMeshBuffer(0)->getMaterial().TextureLayer[1].BilinearFilter = false;
    mesh->getMeshBuffer(0)->getMaterial().TextureLayer[1].TextureWrapU = video::ETC_REPEAT;
    mesh->getMeshBuffer(0)->getMaterial().TextureLayer[1].TextureWrapV = video::ETC_REPEAT;
    */
    //mesh->getMeshBuffer(0)->getMaterial().MaterialType = video::EMT_NORMAL_MAP_SOLID;
    mesh->getMeshBuffer(0)->getMaterial().NormalizeNormals = true; // only needed when scaling the node
    mesh->getMeshBuffer(0)->getMaterial().MaterialType = video::EMT_PARALLAX_MAP_SOLID;
    mesh->getMeshBuffer(0)->getMaterial().MaterialTypeParam = 0.02f; // bumpiness, has some effect
    
    scene::ISceneNode * node = smgr->addMeshSceneNode (mesh, NULL, -1, core::vector3df(0, 0, 0) );
    node->setScale(core::vector3df(10.f, 10.f, 10.f));  // easier to adapt on testing than camera-code
 
    while ( Device->run() )
    {
        if ( Device->isWindowActive() )
        {
            videoDriver->beginScene(true, true);
 
            smgr->drawAll();
 
            videoDriver->endScene();
        }
    }
 
    Device->closeDevice();
    Device->drop();
    Device = NULL;
 
    return 0;
}
 

Unfortunately I can't invest more time into this. The corresponding shader (hardcoded in CD3D9ParallaxMapRenderer.cpp) is written in a low-level shader language which I haven't learned yet (and likely never will). And I don't have the spare-time to learn to write a new normal-map shader (if I had that time I would already have a long list of other urgent tasks...). Also I still don't know if the shader is to blame or if this is a problem in the export/import/model. Lastly I can't do other tests as I don't own 3ds max (I work with Blender, but also never learned to use normal-maps there). It's pretty much impossible to fix such a toolchain without having the corresponding tool available for testing.

Sorry if this means you can't use Irrlicht, but the original authors of that code are all gone, so unless someone else in the forum can help you out you are on your own for this.

edit: Btw, I only tested this on Linux/OpenGL - maybe you are lucky and it works better with DirectX. Having the exact same error might be a hint that it's not a bug in the shader (as it uses a different shader) unless it's a problem in the math used.

[Asimov]

Hi CuteAlien,

Whether I stay with the engine or not I would like to thank you for all your help.

This is the best my model has looked in the engine(by the way I am not using this model in the game, but my idea was that once this one is right I can make others right.)
This is close to how it looks in max, apart from the strange shadow effect, and obviously the unsightly seam. There is obviously a seam there, but it is much more obvious in irrlicht.

I will say I really do want to stay with this engine, and I believe the only way to get my models better is to use a shader.
It is a real shame, when I know that I have the ability to make nice models, and I can't get them to look good in the engine.

I will now try and incorporate your additions into my loader class and see if I can get them working in there.

I think the true answer to this problem is the shader route though.
However I am having a hard time with that area at the moment.

The Glitch said he would give me a basic set-up and hopefully I can learn from there.

[CuteAlien]

Well, shadows can change a lot when you change the light-values (larger distance, brighter light, maybe ambient can be increased if the current shader supports that). But I meant the seam - I don't know what's causing that.

[mongoose7]

@CuteAlien: I don't know what problem you got with the camera angles, but you should avoid a low angle of incidence with a parallax mapping shader. Do you get a better result just from normal mapping (as in the commented out code)? I just don't think there is a problem with the shader.

[CuteAlien]

The line which looks bad wanders around depending on the camera-angle. I also suspect it's not the shader (same trouble with normal mapping) but rather something on import.

[mongoose7]

I believe that the one shader does both normal mapping and parallax mapping.

[thanhle]

Hi CuteAlien,
Your code works on DirectX and OpenGL.

Possible Bug: There is an issue with the light switching at certain angle when you rotate the camera on DirectX.

OpenGL works fine with light. Also, lights seems to be brighter and nicer in OpenGL (See below).



The seams are also clearly visible on 3DXMax 2015. Asimov might need to use the texture painting tool in 3DSMax to fix up that seam.


regards
thanh

[Asimov]

Hi thanhle,

The seams are also clearly visible on 3DXMax 2015. Asimov might need to use the texture painting tool in 3DSMax to fix up that seam.

Yes there is a slight seam in max, but hardly what you call noticable. I could clean it up, but not necessary. You wouldn't even notice it unless you looked really, and in real life all things have seams, but in irrlicht the seam is very pronounced, like the normalmap is being blown up if you know what I mean.

I am not too worried about this model, as it won't be in the game. Only using it to test normalmaps at the moment.

I also noticed the light switching bug also. When you rotate around, suddenly it goes dark at the bottom.

[The_Glitch]

Most likely because all the support here is mostly geared towards OpenGL and DirectX get's shafted in this engine. I have noticed strange things while working with direct3d in Irrlicht but didn't really bother as most likely will be 5 years for a fix.

[CuteAlien]

@The_Glitch: OpenSource is a lot about scratching your own itch. So yeah, I mostly fix the bugs I run into myself unless it's either something easy or someone provides me with a patch+testcase. It's simply not possible otherwise as I haven't enough time to hunt such problems down on my own when they turn out not to be trivial. Thought I do switch between OGL and D3D projects regularly. The trouble here is likely not DX or OGL, but probably the export/import toolchain. The involved shader was btw coded first in D3D and then just ported to OGL (still has some comment about that in it's code).

[Asimov]

Hi CuteAlien,

but probably the export/import toolchain

It is strange however that the export toolchain works fine in Unity, mudbox, and Marmoset, but not in irrlicht.

Heh heh I tried getting your code to work in my class and for some reason it works when I run your code on my own, and the normalmap won't show up when it is in a class.
Will struggle to work out why.

[CuteAlien]

@Asimov: Once people have the tools available and the programming time to work on it such import/export problems are usually easy to fix or work around. The reason I don't think it's the shader is that there are several shaders which all show the exact same problem. So it's more likely in the data - unless the shaders copied the same bug all over (which could also be). Unity with over 100 developers working on it as a job obviously can get more toolchains running than 2-3 Irrlicht programmers in their spare-time. We only shine because our source is open so people can work around specific problems they have on their own (which is worth a lot for experienced programmers who can run into hard walls with Unity, but unfortunately hard for beginners who have no idea where to start).

[The_Glitch]

Can I get a copy of the model and textures so I can test with my shaders to see if I get this problem also?