The latest SVN bugs thread
Re: The latest SVN bugs thread
@SLC: Thanks for reporting. It's fixed again. I suspect that function doesn't belong in Irrlicht anyway - looks like a test. But I don't dare working on burnings.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
-
- Competition winner
- Posts: 688
- Joined: Mon Sep 10, 2012 8:51 am
Re: The latest SVN bugs thread
Burnings isn't as complicated as it seems initially. I probably should write about it, but haven't gotten around to it yet. Sorry. :-/ It's on the to-do list.
Re: The latest SVN bugs thread
Hi,
I don't know if the bug is known, but I have a problem with a project that I have passed from Irrlicht 1.8.1 to trunk r5103.
I send the mouse event captured by Qt to Irrlicht with the postEventFromUser function of the device to control a maya camera.
Works well with 1.8.1, but do nothing with the svn version.
I don't know if the bug is known, but I have a problem with a project that I have passed from Irrlicht 1.8.1 to trunk r5103.
I send the mouse event captured by Qt to Irrlicht with the postEventFromUser function of the device to control a maya camera.
Works well with 1.8.1, but do nothing with the svn version.
Re: The latest SVN bugs thread
@JLousB: Sorry, not sure what could be causing it. I'm not aware of any changes which should have affected this.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: The latest SVN bugs thread
I have find the origin of my problem.
It's not a bug of Irrlicht, it's du to mouse state checks added to the maya camera in r4762, so I have initialised the ButtonStates attribute in the EMIE_MOUSE_MOVED event in my code, and now it works.
It's not a bug of Irrlicht, it's du to mouse state checks added to the maya camera in r4762, so I have initialised the ButtonStates attribute in the EMIE_MOUSE_MOVED event in my code, and now it works.
Re: The latest SVN bugs thread
Ah ok - I've missed that.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
-
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
Re: The latest SVN bugs thread
Hi, Found a compilation problem with MSVC Community edition. Would have "syntax errors" because the DX SDK was referenced first.
Changed the defaults includes paths like this:
$(DXSDK_DIR)include;$(IncludePath)
to this:
$(VC_IncludePath);$(WindowsSDK_IncludePath);$(DXSDK_DIR)include;$(IncludePath)
I've migrated recently from VS2008 to the VS2013 community edition. So perhaps something that I have not done, seem that the global path settings are stored in the project now.
Once I've changed this, Irrlicht compile fine again.
Changed the defaults includes paths like this:
$(DXSDK_DIR)include;$(IncludePath)
to this:
$(VC_IncludePath);$(WindowsSDK_IncludePath);$(DXSDK_DIR)include;$(IncludePath)
I've migrated recently from VS2008 to the VS2013 community edition. So perhaps something that I have not done, seem that the global path settings are stored in the project now.
Once I've changed this, Irrlicht compile fine again.
Re: The latest SVN bugs thread
Hi,
I have a new problem caused by my switch from 1.8.1 to trunk 5109.
I have a big rendering problem that you can see in this video :
https://dl.dropboxusercontent.com/u/24460773/bug2.mp4
I have re-switched to 1.8.1 to be sure that the problem come from irrlicht, and it works well with 1.8.1 :
https://dl.dropboxusercontent.com/u/24460773/18.PNG
I havn't this problem on all the 3d models, it's a custom mesh loader for this model, but work well with 1.8 and the bug is really strange, so I don't think that it come from this.
So if you gave an idea about the origin of the problem, it can be very helpful.
Thanks.
I have a new problem caused by my switch from 1.8.1 to trunk 5109.
I have a big rendering problem that you can see in this video :
https://dl.dropboxusercontent.com/u/24460773/bug2.mp4
I have re-switched to 1.8.1 to be sure that the problem come from irrlicht, and it works well with 1.8.1 :
https://dl.dropboxusercontent.com/u/24460773/18.PNG
I havn't this problem on all the 3d models, it's a custom mesh loader for this model, but work well with 1.8 and the bug is really strange, so I don't think that it come from this.
So if you gave an idea about the origin of the problem, it can be very helpful.
Thanks.
Re: The latest SVN bugs thread
Hi JLouisB,
Do you use RTT feature in this sample?
Cheers,
Do you use RTT feature in this sample?
Cheers,
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Re: The latest SVN bugs thread
No, I don't use RTT.
-
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
Re: The latest SVN bugs thread
For me it look like some sort of clipping issue, seem caused by imprecision in the zbuffer because the geometry is overlapping. Do you use the alpha in the textures? Can you check the ZBuffer depth setting, perhaps forcing it to 32bit buffers?
Re: The latest SVN bugs thread
Thanks for the advice christian, but set the ZBuffer to 32 bits change nothing, and I don't use alpha in the texture (it's a basic EMT_SOLID material).
Look like a completlely buggy texture mapping wich depend of the camera coords for me.
I have checked with a previous build of my soft made with irrlicht trunk 5103, no problem...
So I have re-downloaded Irrlicht trunk 5110, it works.
But when I rebuild the trunk 5109 (wich is supposed to be exactly the same than the 5110 that I have just downloaded), I have always the same the same problem.
So for the moment I havn't the problem, but it's really strange and I don't understand this at all...
Just an other question wich is probably not related to my problem.
I have try to set the the material type at EMT_TRANSPARENT_ALPHA_CHANNEL with some models with no alpha channel in the textures (like sidney or dwarf.x) and there are some problems :
https://dl.dropboxusercontent.com/u/244 ... arancy.PNG
I suppose that it's not a bug because I have a similar result in the example 1 of 1.8.1 when I just change the material type, but can you say me if it's because I have forgotten something ?
Look like a completlely buggy texture mapping wich depend of the camera coords for me.
I have checked with a previous build of my soft made with irrlicht trunk 5103, no problem...
So I have re-downloaded Irrlicht trunk 5110, it works.
But when I rebuild the trunk 5109 (wich is supposed to be exactly the same than the 5110 that I have just downloaded), I have always the same the same problem.
So for the moment I havn't the problem, but it's really strange and I don't understand this at all...
Just an other question wich is probably not related to my problem.
I have try to set the the material type at EMT_TRANSPARENT_ALPHA_CHANNEL with some models with no alpha channel in the textures (like sidney or dwarf.x) and there are some problems :
https://dl.dropboxusercontent.com/u/244 ... arancy.PNG
I suppose that it's not a bug because I have a similar result in the example 1 of 1.8.1 when I just change the material type, but can you say me if it's because I have forgotten something ?
Re: The latest SVN bugs thread
Take a look at the texture matrix used in the D3D9 driver on the EMT_SPHERE_MAP/EMT_REFLECTION_2_LAYER materials. It is neither correct nor seems to work properly.
This is DX
This is GL
This is the code:
The matrix is set correctly perhaps only once, and then it is lost for any other material set. There is only one sphere in this example that complies to what a sphere map would look like. The point is that the OpenGL projection is more accurate, and none is lost. DX should do the same.
The SVN version is the 5224 (practically current) And the texture used is standard.
This is DX
This is GL
This is the code:
Code: Select all
manager->addCameraSceneNodeMaya()->setTarget(irr::core::vector3df(0,0,0));
irr::scene::ISceneNode* root = manager->addEmptySceneNode();
irr::scene::ISceneNodeAnimator* anim = manager->createRotationAnimator(irr::core::vector3df(0,0.3,0));
root->addAnimator(anim);
anim->drop();
for(int i=0;i<12;i++)
{
irr::scene::ISceneNode* sphere = manager->addSphereSceneNode();
sphere->setPosition(irr::core::vector3df(sin(2*i*irr::core::PI/12.0f)*50,0.0f,cos(2*i*irr::core::PI/12.0f)*50.0f));
sphere->getMaterial(0).setTexture(0,skydomeTex);
sphere->getMaterial(0).setFlag(irr::video::EMF_LIGHTING,false);
sphere->getMaterial(0).MaterialType = irr::video::EMT_SPHERE_MAP;
sphere->setParent(root);
}
irr::scene::ISceneNode* root2 = manager->addEmptySceneNode();
irr::scene::ISceneNodeAnimator* anim2 = manager->createRotationAnimator(irr::core::vector3df(0.3,0,0));
root2->addAnimator(anim2);
anim2->drop();
for(int i=0;i<18;i++)
{
irr::scene::ISceneNode* sphere = manager->addSphereSceneNode(3.0f);
sphere->setPosition(irr::core::vector3df(sin(2*i*irr::core::PI/12.0f)*60,0.0f,cos(2*i*irr::core::PI/12.0f)*60.0f));
sphere->getMaterial(0).setTexture(0,skydomeTex);
sphere->getMaterial(0).setFlag(irr::video::EMF_LIGHTING,false);
sphere->getMaterial(0).MaterialType = irr::video::EMT_SPHERE_MAP;
sphere->setParent(root2);
}
irr::scene::ISceneNode* root3 = manager->addEmptySceneNode();
irr::scene::ISceneNodeAnimator* anim3 = manager->createRotationAnimator(irr::core::vector3df(0,0,0.3));
root3->addAnimator(anim3);
anim3->drop();
for(int i=0;i<24;i++)
{
irr::scene::ISceneNode* sphere = manager->addSphereSceneNode(1.0f);
sphere->setPosition(irr::core::vector3df(sin(2*i*irr::core::PI/12.0f)*80,0.0f,cos(2*i*irr::core::PI/12.0f)*80.0f));
sphere->getMaterial(0).setTexture(0,skydomeTex);
sphere->getMaterial(0).setFlag(irr::video::EMF_LIGHTING,false);
sphere->getMaterial(0).MaterialType = irr::video::EMT_SPHERE_MAP;
sphere->setParent(root3);
}
irr::scene::ISceneNode* node = manager->addSphereSceneNode(15.0f);
node->getMaterial(0).setTexture(0,skydomeTex);
node->getMaterial(0).setFlag(irr::video::EMF_LIGHTING,false);
node->getMaterial(0).MaterialType = irr::video::EMT_SPHERE_MAP;
root2->setParent(root);
root3->setParent(root2);
The SVN version is the 5224 (practically current) And the texture used is standard.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: The latest SVN bugs thread
Also, on the OpenGL version of Irrlicht, i think there is a small issue that isn't handled.
In Direct3D9 i can access the mips levels on my latest demo seamslessly, that is, i access the levels with a float number, and the sampled texture will be smooth across the levels, but in OpenGL that doesn't happen.
I find it odd, because I haven't used very diferent routines to access the diferent mip levels.
In DX i use this
whereas in OpenGL GLSL i use this
I enable the trilinear filtering on both cases, and in one the returned value is mixed accross the mipmaps, while the other doesn't. I am not sure if it is because i haven't used the appropriate GL function, or perhaps it is an irrlicht miss.
The SVN version is the 5226
In Direct3D9 i can access the mips levels on my latest demo seamslessly, that is, i access the levels with a float number, and the sampled texture will be smooth across the levels, but in OpenGL that doesn't happen.
I find it odd, because I haven't used very diferent routines to access the diferent mip levels.
In DX i use this
Code: Select all
float4 gloss = tex2D(baseMap,IN.texcoord);
float4 uv = float4(sphere2uv(reflection),0,(1-gloss.y)*mipsCount);
return tex2Dlod(reflectionMap,uv);
Code: Select all
float gloss = texture(baseMap,Texcoord).y;
vec3 col = textureLod(reflectionMap,uv,(1.0f-gloss)*mipsCount).xyz;
The SVN version is the 5226
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: The latest SVN bugs thread
Is mipsCount an int or a float? textureLod itself works fine with half mipmaps, at least in my old version.