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.

Culling optimizations

Postby Pr3t3nd3r » Mon Jan 08, 2007 9:31 am

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!
Galactic Dream Best RTS game
http://www.rageofwar.net
Engage in epic galactic warfare, guide your people through the galaxy! in the real time strategy game made with Irrlicht
http://www.evolutionvault.com
Pr3t3nd3r
 
Posts: 186
Joined: Tue Feb 08, 2005 6:02 pm
Location: Romania

Postby Pr3t3nd3r » Tue Feb 06, 2007 12:59 pm

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 ...)
Galactic Dream Best RTS game
http://www.rageofwar.net
Engage in epic galactic warfare, guide your people through the galaxy! in the real time strategy game made with Irrlicht
http://www.evolutionvault.com
Pr3t3nd3r
 
Posts: 186
Joined: Tue Feb 08, 2005 6:02 pm
Location: Romania

Postby elvman » Sat Sep 08, 2007 8:43 pm

IGUIListBox'es setAutoScrollEnabled does not work as intended, it does not scroll down to show newly added items.
elvman
 
Posts: 253
Joined: Sun Sep 17, 2006 9:37 am
Location: Riga, Latvia

Postby christianclavet » Tue Sep 18, 2007 1:04 am

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. :) )
Last edited by christianclavet on Tue Sep 18, 2007 6:17 pm, edited 1 time in total.
User avatar
christianclavet
 
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA

Postby tonic » Mon Mar 24, 2008 7:43 pm

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
 
Posts: 69
Joined: Mon Dec 10, 2007 6:18 pm

Postby tonic » Fri May 16, 2008 10:40 am

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.
tonic
 
Posts: 69
Joined: Mon Dec 10, 2007 6:18 pm

Postby Mel » Tue Dec 09, 2008 11:54 am

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! 8)
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Postby rogerborg » Tue Dec 09, 2008 1:05 pm

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

Mel wrote: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.


Mel wrote: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.


Mel wrote:directX .x files play their animations too fast by default.


Too fast relative to what? ;)


Mel wrote: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.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
User avatar
rogerborg
Admin
 
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh

Postby hybrid » Tue Dec 09, 2008 1:20 pm

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

Postby Mel » Tue Dec 09, 2008 5:24 pm

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!
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Postby VioletAlixe » Thu Dec 18, 2008 9:14 pm

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.
VioletAlixe
 
Posts: 28
Joined: Thu Oct 04, 2007 9:03 pm

Postby rogerborg » Thu Dec 18, 2008 10:21 pm

Thanks for the report. On what platform are you experiencing that joystick behaviour?
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
User avatar
rogerborg
Admin
 
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh

Postby VioletAlixe » Sat Dec 20, 2008 11:22 am

Vista, using Visual C++ Express.
VioletAlixe
 
Posts: 28
Joined: Thu Oct 04, 2007 9:03 pm

Postby Malgodur » Fri Apr 17, 2009 5:33 pm

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

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=33210
Malgodur
 
Posts: 195
Joined: Sun Mar 15, 2009 8:22 pm

Postby christianclavet » Mon Jul 13, 2009 7:28 pm

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:
Image
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:
Image

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/viewtopic.php?t=20111
Last edited by christianclavet on Sat Oct 18, 2014 12:01 am, edited 2 times in total.
User avatar
christianclavet
 
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA

Next

Return to Bug reports

Who is online

Users browsing this forum: No registered users and 1 guest