The latest SVN bugs thread

[Nalin]

Also if Filename in io::SAttributeReadWriteOptions will stay char*, then next small patch also necessary (but I don't like it) in \source\Irrlicht\CSceneManager.cpp at line 2237:

Code: Select all

options.Filename=core::stringc(currentPath).c_str();

You really want to avoid doing things like that. It would break the purpose of the WCHAR_FILESYSTEM as you be destroying path names that contain UTF-16 surrogate pairs. Any time you convert wchar_t to char by casting is a point where unicode support could be broken.

[greenya]

Nalin,

between, non-compilable code and compilable (but not working in some class method with UTF-16), i choose second. As i stated, i do not like it. But i need compilable code to rebuild my project, even if it does not uses that method.

I agree that char* must not be used in places where we use it in the meaning of "file path".

[zillion42]

Hi,

I've had some issues with Terrains when trying to rotate them. I'll post some code below, so if anyone feels like checking it out, take a look at it, or just put it on a list, or at least know and acknowledge something seems wrong and confirm it, wouldn't be bad.

As a general description, seems like the pivot is not centered for rotations above 90°

Code: Select all

#include <irrlicht.h>

using namespace irr;

#ifdef _MSC_VER
#pragma comment(lib, "Irrlicht.lib")
#endif

IrrlichtDevice* device;
SIrrlichtCreationParameters param;
video::IVideoDriver* driver;
scene::ISceneManager* smgr;
scene::ICameraSceneNode* cam;
scene::ILightSceneNode* light;

int main()
{
   
   param.DriverType = video::EDT_OPENGL;
   param.Vsync = false;
   param.AntiAlias = true;
   param.Bits = 32;
   param.WindowSize = core::dimension2d<u32>(800,600);
   param.Fullscreen = false;

   //create pointers to device, scene manager
   device = createDeviceEx(param);
   driver = device->getVideoDriver();
   smgr = device->getSceneManager();
   light = smgr->addLightSceneNode();
   cam = smgr->addCameraSceneNodeFPS();

   //create Test Terrain, need some Heightfile here
   
   io::IReadFile* testFile = smgr->getFileSystem()->createAndOpenFile("../anyFile.jpg");
   scene::ITerrainSceneNode* testter = smgr->addTerrainSceneNode(testFile,0,-1);
   testFile->drop();

   f64 rot = 0.0;

   while(device->run())
   {
      rot += 0.1;
      testter->setRotation(core::vector3df(0,(f32)rot,0));
      driver->beginScene(true, true, video::SColor(0,100,100,100));
      smgr->drawAll();
      driver->endScene();
   }
   
   device->drop();
   return 0;
}

[Donner]

In CColorAttribute, getString() is not implemented. Hence a CColorAttribute object takes the getString() function of CNumbersAttribute, which returns the color with its four components (like 255, 255, 0, 255) instead of a hexadecimal value.
I believe it should behave the same way as getStringW.

[wing64]

MRT and deferred shader render wrong when blend function enabled (see image)

enable blend [wrong]


disable blend [right]


At COpenGLExtensionHandler.cpp Line 2916 (Irrllicht trunk SVN 3657 revision) commented all blending code.

Fixed Code

Code: Select all

/*
   if (queryFeature(EVDF_BLEND_OPERATIONS) &&
      (resetAllRenderStates|| lastmaterial.BlendOperation != material.BlendOperation))
   {
      if (EBO_NONE)
         glDisable(GL_BLEND);
      else
      {
         glEnable(GL_BLEND);
#if defined(GL_EXT_blend_subtract) || defined(GL_EXT_blend_minmax) || defined(GL_EXT_blend_logic_op) || defined(GL_VERSION_1_2)
         switch (material.BlendOperation)
         {
         case EBO_MAX:
#if defined(GL_EXT_blend_minmax)
            extGlBlendEquation(GL_MAX_EXT);
#elif defined(GL_VERSION_1_2)
            extGlBlendEquation(GL_MAX);
#endif
            break;
         case EBO_MIN:
#if defined(GL_EXT_blend_minmax)
            extGlBlendEquation(GL_MIN_EXT);
#elif defined(GL_VERSION_1_2)
            extGlBlendEquation(GL_MIN);
#endif
            break;
         case EBO_SUBTRACT:
#if defined(GL_EXT_blend_subtract)
            extGlBlendEquation(GL_FUNC_SUBTRACT_EXT);
#elif defined(GL_VERSION_1_2)
            extGlBlendEquation(GL_FUNC_SUBTRACT);
#endif
            break;
         case EBO_REVSUBTRACT:
#if defined(GL_EXT_blend_subtract)
            extGlBlendEquation(GL_FUNC_REVERSE_SUBTRACT_EXT);
#elif defined(GL_VERSION_1_2)
            extGlBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
#endif
            break;
         default:
#if defined(GL_EXT_blend_subtract) || defined(GL_EXT_blend_minmax) || defined(GL_EXT_blend_logic_op)
            extGlBlendEquation(GL_FUNC_ADD_EXT);
#elif defined(GL_VERSION_1_2)
            extGlBlendEquation(GL_FUNC_ADD);
#endif
            break;
         }
#endif
      }
   }
//*/

[hybrid]

The blend code is not yet fully tested. Best thing is to disable completely (EBO_NONE). The materials using blend will anyway change the blend settings on their own. I'll add blend tests in the next days and check which things are working and which not.

[greenya]

Hi!

#1
Unable to build BuildAllExamples_vc10.sln after Clean Solution, because Irrlicht.lib gets cleaned and 25.XmlHandling complainig about error LNK1104: cannot open file 'Irrlicht.lib'.
Fix: Right click on 25.XmlHandling -> Project Dependencies -> check Irrlicht.

#2
warning C4996: 'irr::io::IFileSystem::addFolderFileArchive': was declared deprecated in \examples\09.meshviewer\main.cpp at line 706

P.S.: svn trunk 3714.

[Yoran]

A few things:

(Revision 3728)
LukePh last commit making EBO_NONE into if (material.BlendOperation==EBO_NONE)
breaks support for multiple textures on a meshbuffer, where one is a transparent TGA alpha support in directx! (eg my windows were suddenly nontransparent)


SRGB and paramters changes:
- AlphaToCoverage support queries the wrong adapter -> should not be params.displayAdapter, but real UINT adapter, defined a few lines higher

[hybrid]

Well, what happens with the alpha texture. Moreover, what would you expect to happen if you set nothing there. Blending is enabled or disabled per material, you could safely set the blend mode to seomthing different if you really need blending enabled. Otherwise, alpha will probably do nothing.

[greenya]

Now 10.Shaders renders next result:

Notice that there is no transparency in the front shaded cube.

I get the same result for OpenGL and Direct3D drivers.
I use svn trunk 3767.

[Nalin]

Also, do you know why that red color appears on the character sprite? It only happens in the DX9 driver, not the OpenGL driver.

Hybrid, CuteAlien helped me fix the transparency issue. Turns out I needed to add MaterialTypeParam:

cpp Code: Select all

mat.MaterialType = video::EMT_TRANSPARENT_ALPHA_CHANNEL;
mat.MaterialTypeParam = 1.0f;  // <--

It defaults to 0 in Irrlicht. When combined with EMT_TRANSPARENT_ALPHA_CHANNEL, OpenGL seems to use FLT_MIN instead of 0, while DX9 just uses 0. This is why it worked with OpenGL and not DX9. Since I was not using bilinear filtering, any non-zero value would enable transparency to work. Setting it to 1.0f fixed all the issues.

I tried to PM you this, but it seems the Private Message feature just doesn't work. So you either got a dozen duplicate PMs or you got none. Posting here just in case and so other people can see.

[hybrid]

This is not correct, though. The value 0 should give the best alpha shading, giving every alpha value except for 0 will lead to a blended pixel. For larger values (ranging from 0 to 1) the low alpha values are simply discarded. This results in faster rendering, but also stronger border artifacts. Don't know what is actually wrong here.

[Nalin]

This is not correct, though. The value 0 should give the best alpha shading, giving every alpha value except for 0 will lead to a blended pixel. For larger values (ranging from 0 to 1) the low alpha values are simply discarded. This results in faster rendering, but also stronger border artifacts. Don't know what is actually wrong here.

Also, I found out that using 1.0f resulted in OpenGL not drawing anything at all. I had to switch it to use 0.99f. The higher the value, the less it blended the transparent pixels into the image.

Basically, I used an 8-bit PNG. The color gray was set to be the transparent color. I turned on bilinear filtering. As I used values closer to 0, the sprite had a more pronounced gray outline as it blended more of the gray into the image. As I used values closer to 1, the halo disappeared as it used more of the non-transparent pixel.

If I use 0 exactly, DirectX 9 ignored all transparency while OpenGL seemed to use a value like FLT_MIN.
If I use 1 exactly, DirectX 9 had no gray in the image at all while OpenGL didn't draw the whole entire image.
Since I didn't want any of the gray in the image, I was able to use 0.99f and both DX and OpenGL gave similar results.

[hybrid]

If you use a transparent color, the transparency should be sharp anyway. Strange that it is not. I might have your image data and code somewhere, but could you maybe pack the textures and simple example again for further testing?

[downer]

I tried compiling the latest SVN for sharedlib on Fedora 15 updates-testing with gcc 4.6.0-10 on AMD 64, and I got

cpp Code: Select all

g++: error: unrecognized option ‘--no-export-all-symbols’
g++: error: unrecognized option ‘--add-stdcall-alias’
make: *** [sharedlib] Error 1

I can get the latest SVN to compile without sharedlib and run the test and build the examples.