The latest SVN bugs thread

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.

Postby Nalin » Sun Feb 20, 2011 6:09 pm

greenya wrote: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.
Nalin
 
Posts: 194
Joined: Thu Mar 30, 2006 12:34 am
Location: Lacey, WA, USA

Postby greenya » Sun Feb 20, 2011 7:03 pm

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".
greenya
 
Posts: 1007
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine

Postby zillion42 » Mon Feb 21, 2011 6:29 am

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;
}
zillion42
 
Posts: 321
Joined: Wed Aug 29, 2007 12:32 am
Location: Hamburg, Germany

Postby Donner » Mon Feb 28, 2011 4:54 pm

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.
Donner
 
Posts: 87
Joined: Fri May 18, 2007 11:27 am

Postby wing64 » Sat Apr 23, 2011 6:56 am

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

enable blend [wrong]
Image

disable blend [right]
Image

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
      }
   }
//*/
wing64
Competition winner
 
Posts: 241
Joined: Wed Jul 23, 2008 2:35 am
Location: Thailand

Postby hybrid » Sat Apr 23, 2011 11:01 am

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.
hybrid
Admin
 
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Postby greenya » Tue May 10, 2011 10:02 pm

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.
greenya
 
Posts: 1007
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine

Postby Yoran » Mon May 30, 2011 2:38 pm

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
Yoran
Site Admin
 
Posts: 96
Joined: Fri Oct 07, 2005 8:55 am
Location: The Netherlands

Postby hybrid » Mon May 30, 2011 3:17 pm

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.
hybrid
Admin
 
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Postby greenya » Tue May 31, 2011 7:24 am

Now 10.Shaders renders next result:
Image
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.
greenya
 
Posts: 1007
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine

Re:

Postby Nalin » Mon Jul 04, 2011 6:21 pm

Nalin wrote: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.
Last edited by Nalin on Tue Jul 05, 2011 1:25 pm, edited 1 time in total.
Nalin
 
Posts: 194
Joined: Thu Mar 30, 2006 12:34 am
Location: Lacey, WA, USA

Re: The latest SVN bugs thread

Postby hybrid » Mon Jul 04, 2011 9:12 pm

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.
hybrid
Admin
 
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Re: The latest SVN bugs thread

Postby Nalin » Tue Jul 05, 2011 1:36 pm

hybrid wrote: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.
Nalin
 
Posts: 194
Joined: Thu Mar 30, 2006 12:34 am
Location: Lacey, WA, USA

Re: The latest SVN bugs thread

Postby hybrid » Tue Jul 05, 2011 2:27 pm

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?
hybrid
Admin
 
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Re: The latest SVN bugs thread

Postby downer » Sun Jul 17, 2011 5:25 am

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.
downer
 
Posts: 4
Joined: Tue Sep 14, 2010 3:34 am

PreviousNext

Return to Bug reports

Who is online

Users browsing this forum: No registered users and 1 guest