The latest SVN bugs thread

[Pr3t3nd3r]

I added this:
http://sourceforge.net/tracker/index.ph ... tid=540678

let me explain some of the problems in the old frustum culling:

Code: Select all

	//transform the frustum to the node's current absolute transformation
			core::matrix4 invTrans(node->getAbsoluteTransformation());
			invTrans.makeInverse();
			frust.transform(invTrans);

This code is doing something strange! i belive is moving the camera frustrum to 'pseudorandom' position conected by the node location.
Personaly i don't belive the camera frustrum should be oriented/moved/scalled! to the node position because we want to to the culling on the actual pozitions .. + unuseful operations ...
Any way what is this doing is not really important because there are more important problems.

Code: Select all

			for (i=0; i<scene::SViewFrustum::VF_PLANE_COUNT; ++i)
			{
				bool boxInFrustrum = false;

				for (int j=0; j<8; ++j)
				{
					if (frust.planes[i].isFrontFacing(edges[j]) )
					{
						boxInFrustrum = true;
						break;
					}
				}

				if (!boxInFrustrum)
				{
					visible = false;
					break;
				}

			}

An other error i think is that isFrontFacing say if the edges and the plan have the same 'view' orientation and no not give any real useful culling information. Obviously 2 boxes will have many plane orientation / edge orientation.

But the biggest problem is that

Code: Select all

				for (int j=0; j<8; ++j)
				{
					if (frust.planes[i].isFrontFacing(edges[j]) )
					{
						boxInFrustrum = true;
						break;
					}
				}

is not doing any think.
Even if isFrontFacing will be classifyPointRelation or whatever there will ALWAYS! be edges what will be in front/oriented with the plane.

So right now the EAC_FRUSTUM_BOX is an more CPU expensive version of EAC_OFF.

Also doing directly frustum_box culling with out checking box culling will result in bad performance and lot of not needed calculations.

Also very important the EAC_OFF from the iscenenode constructor should be EAC_FRUSTUM_BOX or at least EAC_BOX. We want some default culling!

[Pr3t3nd3r]

It seems that in svn the code for guiToolbar maneged to be

Code: Select all

//! Adds a button to the tool bar
IGUIButton* CGUIToolBar::addButton(s32 id, const wchar_t* text,const wchar_t* tooltiptext,
	video::ITexture* img, video::ITexture* pressed, bool isPushButton, 
	bool useAlphaChannel)
{
	ButtonX += 3;

	core::rect<s32> rectangle(ButtonX,2,0,0);
	if ( img )
	{
		const core::dimension2di &size = img->getOriginalSize();
		rectangle.LowerRightCorner.X = rectangle.UpperLeftCorner.X + size.Width + 8;
		rectangle.LowerRightCorner.Y = rectangle.UpperLeftCorner.Y + size.Height + 6;
	}

(diferent form irr1.2)

But the problem is that if no texture image is added the button rectangle will be 0,0,0,0 ....
i just added the part from the original code .... so the buttons to appear like before ...

Code: Select all

	if ( img )
	{
		const core::dimension2di &size = img->getOriginalSize();
		rectangle.LowerRightCorner.X = rectangle.UpperLeftCorner.X + size.Width + 8;
		rectangle.LowerRightCorner.Y = rectangle.UpperLeftCorner.Y + size.Height + 6;
	}
	else
	{
			rectangle.LowerRightCorner.X = rectangle.UpperLeftCorner.X + 23;
			rectangle.LowerRightCorner.Y = rectangle.UpperLeftCorner.Y + 22;
	}

Also (irr1.2)
Sizes[EGDS_MENU_HEIGHT] = 28;
became
Sizes[EGDS_MENU_HEIGHT] = 48;

A change witch is useful probably for the person who have his own (skinned) menu with images ... but for creating an menu is just creating an over sized menu ....
I think the 28 value should be restored ... try to make an menu with buttons in svn (i think Meshviewer example will do that ...)

[elvman]

IGUIListBox'es setAutoScrollEnabled does not work as intended, it does not scroll down to show newly added items.

[christianclavet]

SVN 970 report:
Rendering difference in OpenGL and DirectX.

I see some differences now in both DirectX and OpenGL. Both screen render differently than Release 1.3.1

Examples:
- DirectX: In my demo: the ground is darker than release 1.3.1 (Applied Lightmap+light type surface) and Lighting flag is on. Relections (mapped reflections) also look strange.

- OpenGL: In my demo: The ground look brighter than release 1.3.1 (Applied Lightmap+light type surface) and Lighting flag is on. Reflections (mapped reflections) are very bright (almost white)

I know that new surface types were introduced, but it seem that the old ones seem affected.

EDIT: Theses display difference seem only apparent when using the "Light" flag. Non-Lighted surface look about the same as in 1.3.1. Could theses be only the fact that there is a new lighting system? (Didnt know that there was a new Lighting system in there. )

[tonic]

Two bugs:

1. Inconsistent translation (between video drivers) when using custom transform - already described here: http://irrlicht.sourceforge.net/phpBB2/ ... 329#151329

2. Small bug in the API of SMaterial::setFlag when setting EMF_TEXTURE_WRAP. The boolean value of setFlag is cast as E_TEXTURE_CLAMP which is not a boolean value.
Fix suggestion: maybe add overloaded SMaterial::setFlag which takes in either integer or E_TEXTURE_CLAMP to be used with setting of EMF_TEXTURE_WRAP. (and maybe change getFlag to return integer?)

[tonic]

When reading/writing IAttributes data to xml files, I noticed these:

1. user pointer value doesn't get serialized (written) properly, apparently because it's missing getStringW method

2. both binary and user pointer attributes are missing handler code in CAttributes::readAttributeFromXML, so they are ignored when reading in attributes.

[Mel]

I've been toying a bit with the last SVN, this is what i got after being able to compile the beta 1.5 (It is in the 1933, i updated to 1934, but it seems nothing changed since then)

In example 19, Joystick support is working ("logitech dual action", 12 buttons 4 axes, both non vibrating and vibrating models correctly detected and working), although, it seems it doesn't calibrate well when to stop, or perhaps the sensibility of the axes is too high, because when i saw the test in action, after leaving alone the controller, the arrow kept moving. Although this is basic implementation, i guess it is good to have some feedback.

I've found a .LWO model that won't load in the mesh viewer. But it is an old LW 5.5 model. On the other hand, LW 9 modeller models load well, so, it is advisable that people don't use old LWO models.

string operator + doesn't work well with other objects like simple integers. this is the original code i had written

Code: Select all

{
  video::IImage* image = device->getVideoDriver()->createScreenShot();
  u32 i=0;						//an index to diferenciate the screenshots
  core::stringc screenshot= "./Screenshots/SCREENSHOT";	//directory for screenshots storage
  core::stringc ext= ".bmp";				//extension used for the screenshots
  if (image)
  {   
  while(device->getFileSystem()->existFile((screenshot+i+ext).c_str())){ 	//check if the file named "screenshot+i+ext" exists
    i++;						//if so, increment i
  }
						//"screenshot+i+.bmp" won't overwrite another existent.						
  device->getVideoDriver()->writeImageToFile(image, (screenshot+i+ext).c_str());	//there we go...!
			image->drop();
			cout<<(screenshot+i+ext).c_str()<<endl;
		}
	  return true;
    }

and this was the errors shown, disabling that, compilation was flawless.

Code: Select all

g++.exe -c src/game.cpp -o obj/game.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include"  -I"C:/Dev-Cpp/include/c++/3.4.2/backward"  -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32"  -I"C:/Dev-Cpp/include/c++/3.4.2"  -I"C:/Dev-Cpp/include"  -I"C:/Dev-Cpp/Irrlicht/irrKlang-1.0.4/include"  -I"C:/Dev-Cpp/Irrlicht/Irrlicht-1.5/include"  -s   -O3src/game.cpp: In member function `virtual bool game::OnEvent(const irr::SEvent&)':
src/game.cpp:136: error: no match for 'operator+' in 'screenshot + i'
C:/Dev-Cpp/Irrlicht/Irrlicht-1.5/include/irrString.h:265: note: candidates are: irr::core::string<T, irr::core::irrAllocator<T> > irr::core::string<T, TAlloc>::operator+(const irr::core::string<T, irr::core::irrAllocator<T> >&) const [with T = irr::c8, TAlloc = irr::core::irrAllocator<irr::c8>]
src/game.cpp:139: error: no match for 'operator+' in 'screenshot + i'
C:/Dev-Cpp/Irrlicht/Irrlicht-1.5/include/irrString.h:265: note: candidates are: irr::core::string<T, irr::core::irrAllocator<T> > irr::core::string<T, TAlloc>::operator+(const irr::core::string<T, irr::core::irrAllocator<T> >&) const [with T = irr::c8, TAlloc = irr::core::irrAllocator<irr::c8>]
src/game.cpp:141: error: no match for 'operator+' in 'screenshot + i'
C:/Dev-Cpp/Irrlicht/Irrlicht-1.5/include/irrString.h:265: note: candidates are: irr::core::string<T, irr::core::irrAllocator<T> > irr::core::string<T, TAlloc>::operator+(const irr::core::string<T, irr::core::irrAllocator<T> >&) const [with T = irr::c8, TAlloc = irr::core::irrAllocator<irr::c8>]

directX .x files play their animations too fast by default.

Transition animation checked and flickering in Irrlicht beta 1.5 (svn 1933) is still present Someone pointed that around frame 40 there was a trouble. And i've noticed the same, around frame 40 of a .X animation the mesh flickers. It won't happen in another frame intervals, seemingly. I haven't tested another bone animated formats though. Not obstant, i think i can point a possible source of the trouble. Testing the animations, i noticed that when zooming in the view, there were moments in which the model simply, dissapeared from the scene, and couldn't be seen anymore, from certain angles of view, which points, IMO, to a possible trouble with the bounding box updating when playing the animations in the Transition mode. In other modes, it will work fine, at any zoom level.

Keep it up!

[rogerborg]

Wow, thanks for the testing. This is exactly what we need.

In example 19, Joystick support is working ("logitech dual action", 12 buttons 4 axes, both non vibrating and vibrating models correctly detected and working), although, it seems it doesn't calibrate well when to stop, or perhaps the sensibility of the axes is too high, because when i saw the test in action, after leaving alone the controller, the arrow kept moving. Although this is basic implementation, i guess it is good to have some feedback.

Fair comment. We don't implement dead zones inside the Irrlicht implementations; we just pass the raw axis values on to the application. Example 19 assumes a 5% dead zone, which I thought was actually being quite generous. I'll improve the commenting in the event and example.

string operator + doesn't work well with other objects like simple integers.

OK, but that's missing functionality, not a bug per se. We've never had an operator+(unsigned int). We only have operator+(const string<T>& other) and operator+(const B* const c).

We'll be revisiting stringc in 1.6, so I'll bear that in mind then.

directX .x files play their animations too fast by default.

Too fast relative to what?

Transition animation checked and flickering in Irrlicht beta 1.5 (svn 1933) is still present

I didn't have any luck replicating this. Can you provide a model and a code snippet?

Thanks again for doing this testing, it's really valuable.

[hybrid]

string operator + doesn't work well with other objects like simple integers.

OK, but that's missing functionality, not a bug per se. We've never had an operator+(unsigned int). We only have operator+(const string<T>& other) and operator+(const B* const c).

We'll be revisiting stringc in 1.6, so I'll bear that in mind then.

Actually, this worked before because we had a constructor for strings from integers. However, this had been made explicit, which means that you hav to put core::stringc(...) around your integer. This makes things a little more type-safe and avoids strange effects where integers are suddenly interpreted as strings although it was not really intended. And it let's you rethink your implementation in order to avoid performance issues with string conversions, because you can easily see that something big is happening at this place

[Mel]

Same code and same model i used for the last time i tested the error. That part hasn't changed a bit since the last time, so i guess this resource is still valid.

http://rapidshare.com/files/163700734/a ... g.rar.html

Its too fast relative to the previous implementation of the animation system. I mean, in 1.4.2 i didn't need to set anything else for the animation to play 1:1 with the model edition program. Now, it simply plays too fast.

I guess it is logic to think that "an integer is not a string" but it was easier. Anyway, thanks! and keep it up!

[VioletAlixe]

The joystick and mouse example included in the download for Irrlicht 1.5 doesn't check to see whether or not a joystick hat exists when it determines the direction to move the cursor.

Code here:

const u16 povDegrees = joystickData.POV / 100;
if(povDegrees < 360)
{
if(povDegrees > 0 && povDegrees < 180)
moveHorizontal = 1.f;
else if(povDegrees > 180)
moveHorizontal = -1.f;

if(povDegrees > 90 && povDegrees < 270)
moveVertical = -1.f;
else if(povDegrees > 270 || povDegrees < 90)
moveVertical = +1.f;
}


//end code.

Since the hat doesn't exist on some joysticks, it will just read that POV is zero, and so it will only satisfy the last "else if" which sets the moveVertical to 1. This makes the cursor move up and off screen irreversably if your joystick/gamepad doesn't have a hat!

Simply checking the status of the hat or putting a boolean in at the beginning of the run when it does check the status, so as to check against the boolean in this case, would fix the problem.




--
Edit: On a side note, it's picking up that I have an extra axes as well, for some reason. I double checked the configuration of the gamepad in my Control Panel, and it lists only one as well. Screwy.

[rogerborg]

Thanks for the report. On what platform are you experiencing that joystick behaviour?

[VioletAlixe]

Vista, using Visual C++ Express.

[Malgodur]

Theres probably bug in bsp entity ist loader. I wrote about it here:

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=33210

[christianclavet]

Hi, I've just downloaded and compiled the trunk revision 2474:

The quake 3 explorer is really impressive, also the light manager demo.

Great thing that you added the gun asset, example of the screen settings, example of the archives loading, the new treeview(wow!)

I would just have to report minor rendering errors I've encountered so far. (Checked with 1.5, if it was not my hardware first)

- Banding issues on Sky:

I've seen that kind of banding in the gradient of the image in the sky. Not sure if the problem is in the image itself.

- Particle billboard transparency issue:


Seem there is incorrect way to render transparency in billboards (as used in particles). The transparent edge is clipping the other billboards.
Could this be related to this thread?:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=20111