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

Post by Nalin »

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

Post by 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
Posts: 324
Joined: Wed Aug 29, 2007 12:32 am
Location: Hamburg, Germany

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

Post by 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
Competition winner
Posts: 242
Joined: Wed Jul 23, 2008 2:35 am
Location: Thailand
Contact:

Post by wing64 »

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

Post by 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
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

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

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

Post by 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
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

Post by greenya »

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

Re:

Post by Nalin »

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:

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

Re: The latest SVN bugs thread

Post by 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
Posts: 194
Joined: Thu Mar 30, 2006 12:34 am
Location: Lacey, WA, USA
Contact:

Re: The latest SVN bugs thread

Post by Nalin »

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

Re: The latest SVN bugs thread

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

Re: The latest SVN bugs thread

Post by 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

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.
Post Reply