The latest SVN bugs thread

[CuteAlien]

Ah ok. And I just got my Irrlicht compiling again. Will have to split up my collada patch for this - I had fixed something else as well (exporting nodes which share the same mesh but have different materials), but that still didn't load correct in any other tool. So will have to throw out that part first from my patch again and just fix the compile troubles (and do the other bugfix later or I'll never get this done).

[CuteAlien]

ColladaWriter should work now. I have no system yet to reproduce (I have to install mingw64 some day...) so I would appreciate if someone can test compiling newest svn trunk on a system where it failed before.

[hendu]

Ah right, my mistake. Win64 not Mac64, Mac64 is sane

[Randajad]

File: source\Irrlicht\COpenGLExtensionHandler.h, Line: 2459

#elif defined(GL_NV_occlusion_query)
glIsOcclusionQueryNV(id);
#else

I think it should to be "return glIsOcclusionQueryNV(id);".

[CuteAlien]

Yes, that looks correct. Thanks - it's fixed in svn trunk now.

[Randajad]

In same place look at:

#ifdef _IRR_OPENGL_USE_EXTPOINTER_
if (pGlIsQueryARB)
return pGlIsQueryARB(id);
else if (pGlIsOcclusionQueryNV)
return pGlIsOcclusionQueryNV(id);
#elif defined(GL_ARB_occlusion_query)

There is no return value if pGlIsQueryARB and pGlIsOcclusionQueryNV gets false.

[CuteAlien]

Thanks, it's fixed again in svn trunk.

[Mel]

The stencil shadows in DX are still disabled for some reason. And the demo will still show some odd artifacts with the particles, like that the furthest particle system won't have blending at all. And when the stencil buffer is disabled, the particles from the smoke of the impacts won't show either. In the software renderers it works, but this won't in GL or DX.

[kaos]

I have 200 mB in Ram, when arrive to render( next code ), ram grow up many.

Code: Select all

 
driver->setMaterial( cr->getMaterial(0) );
                for( int cont = 0; cont < cr->getMesh()->getMeshBufferCount(); cont++ )
                        driver->drawMeshBuffer( cr->getMesh()->getMeshBuffer(cont) );
 

And them I can't release the memory.

edit- if I don't write this lines, the memory don't change.

[kaos]

I have 200 mB in Ram, when arrive to render( next code ), ram grow up many.

Code: Select all

 
driver->setMaterial( cr->getMaterial(0) );
                for( int cont = 0; cont < cr->getMesh()->getMeshBufferCount(); cont++ )
                        driver->drawMeshBuffer( cr->getMesh()->getMeshBuffer(cont) );
 

And them I can't release the memory.

edit- if I don't write this lines, the memory don't change.

Ok if I dont't activate hardwarebuffer the problem disappears

[hybrid]

Actually there is no significant RAM usage inside Irrlicht for the VBOs, but it is probably the memory allocated by the gfx driver. You can delete hardware buffers after you're done with rendering these components with the proper driver call.

[kaos]

Actually there is no significant RAM usage inside Irrlicht for the VBOs, but it is probably the memory allocated by the gfx driver. You can delete hardware buffers after you're done with rendering these components with the proper driver call.

I have a list of models( big models, 32 bit vertex index, around the max of primitives count), when I select one, free the last object. The memory( ram ) grow and grow, only if I have hardware buffer.

I don't understand, I think that this is a bug, because I free the memory with irrlicht. If I don't activate vbo, work perfect.

My card it's nvidia geforce 560 ti,

So, I need free the hardwarebuffer with directx in this case... ( and I don't know how )

[Mel]

I remember having some troubles like that. And i solved them by waiting. Simply waiting a bit so the hardware buffers were also released. I noticed that when i loaded and unloaded a model constantly (with Hardware Buffers), the memory would increase and increase. But if i wait a bit, the memory will be released properly. I think it is an issue of the graphics driver that won't release inmediately a buffer.

[greenya]

Hello.
Trying to compile rev. 4206 in vs2010 with dx8 renderer:

Code: Select all

error C2065: 'Params' : undeclared identifier
\source\Irrlicht\CD3D8Driver.cpp
line 329

======================================================== ADDED =============================================================

While compiling usage of matrix4<f32>, we get bunch of warnings under vs2010:

Code: Select all

warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 959
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 960
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 961
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 965
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 966
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 967
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 971
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 972
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 973
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 993
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 994
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 995
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h      line 999
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h     line 1000
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h     line 1001
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h     line 1005
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h     line 1006
warning C4244: '=' : conversion from 'const irr::f64' to 'irr::f32', possible loss of data      \include\matrix4.h     line 1007

I suggest to all these assignments apply casting to (T), for example:

Code: Select all

M[0] = tx * axis.X + c;

should be

Code: Select all

M[0] = (T)(tx * axis.X + c);

P.S.: just like setInverseRotationRadians(), setRotationRadians() and others already has.

[CuteAlien]

@greenya: Sorry my fault, I needed a flag in dx9 and just added code to dx8 to keep it similar, didn't see the code there already was differnt. I removed support for that flag again in d3d8 driver and installed a dx8 sdk now on my new system so I can also test for that again once in a while (and I kind of wonder if there's still anyone using it anway - Thomas was probably the last one, but haven't heard from him in a while).