Irrlicht Engine

Light Direction problem


////
when I set Light direction, doLightRecalc() will force light direction to core::vector3df(.0f,.0f,1.0f);

////
ILightSceneNode* scnode = smgr->addLightSceneNode(0, core::vector3df(0,5,20), video::SColorf(1.0f, 1.0f, 1.0f, 1.0f), 100.0f, -1);
SLight spotLightData;
spotLightData = scnode->getLightData();

spotLightData.Type = video::ELT_SPOT;
spotLightData.Direction = core::vector3df(0,1,0);
spotLightData.Falloff = 60.0f;
spotLightData.OuterCone = 20;
spotLightData.InnerCone = 10;

////

//LightData.Direction = core::vector3df(.0f,.0f,1.0f); //need remover???
void CLightSceneNode::doLightRecalc()
{
if ((LightData.Type == video::ELT_SPOT) || (LightData.Type == video::ELT_DIRECTIONAL))
{
LightData.Direction = core::vector3df(.0f,.0f,1.0f);
getAbsoluteTransformation().rotateVect(LightData.Direction);
LightData.Direction.normalize();
}
.
.
.
}

//

Get final light direction in
void COpenGLDriver::assignHardwareLight(u32 lightIndex)
void COGLES1Driver::assignHardwareLight(u32 lightIndex)
void COGLES2MaterialBaseCB::OnSetConstants(IMaterialRendererServices* services, s32 userData)

final light Direction is different from my setting

Check documentation - SLight.Direction is meant to be read-only. I'm not sure why it's public at all (probably to avoid having to work with friend-classes as the node needs access to it and friend classes are bad as it prevents custom user-node classes).
http://irrlicht.sourceforge.net/docu/st ... 895ab42d41
So like documentation says - you have to use the node-direction and then this is calculated.
Maybe we should rename it to SLight.InternalDirection or something like that to make it more clear this variable is not meant to be touched by users. I run into it myself just not too long ago...

thanks a lot man

the spotlight seems to move relative to my camera~~ the fixed way~~~

I have the same problem so post the solution here

https://www.opengl.org/discussion_board ... -spotlight

I successful when use follows

////

void dirLight(in int index, in vec3 position, in vec3 normal, inout vec4 ambient, inout vec4 diffuse, inout vec4 specular)
{
//same as opengl and oges1 setting
//vec3 L = normalize(-uLightDirection[index]);
vec3 L = normalize(uLightPosition[index]);
.
.
}

/////

void spotLight(in int index, in vec3 position, in vec3 normal, inout vec4 ambient, inout vec4 diffuse, inout vec4 specular)
{
vec3 L = uLightPosition[index] - position;
float D = length(L);
L = normalize(L);

//vec3 NSpotDir = (uViewMatrix * vec4(uLightDirection[index],0)).xyz; //must do outside or become flashlight follow
vec3 NSpotDir = normalize(uLightDirection[index]);
.
.
.
}

////
////c++
switch (CurrentLight.Type)
{
case ELT_DIRECTIONAL:
LightType = 2;
//same as opengl and oges1 use
//CurrentLight.Direction = ViweDirTrasform(Matrix_V, CurrentLight.Direction)
CurrentLight.Position = -ViweDirTrasform(Matrix_V, CurrentLight.Direction);
break;
case ELT_SPOT:
LightType = 1;
CurrentLight.Direction = ViweDirTrasform(Matrix_V, CurrentLight.Direction);
break;
default: // ELT_POINT
LightType = 0;
break;
}


core::vector3df COGLES2MaterialBaseCB::ViweDirTrasform(core::matrix4 matrix, core::vector3df vec3_dir)
{
struct _Vec4_T
{
f32 x,y,z,w;
};
struct _Vec4_T vec4_dir;

vec4_dir.x = vec3_dir.X;
vec4_dir.y = vec3_dir.Y;
vec4_dir.z = vec3_dir.Z;
vec4_dir.w = 0.0;

vec4_dir.x = matrix[0*4+0]*vec4_dir.x + matrix[1*4+0]*vec4_dir.y + matrix[2*4+0]*vec4_dir.z;// + matrix[3*4+0]*vec4_dir.w;

vec4_dir.y = matrix[0*4+1]*vec4_dir.x + matrix[1*4+1]*vec4_dir.y + matrix[2*4+1]*vec4_dir.z;// + matrix[3*4+1]*vec4_dir.w;

vec4_dir.z = matrix[0*4+2]*vec4_dir.x + matrix[1*4+2]*vec4_dir.y + matrix[2*4+2]*vec4_dir.z;// + matrix[3*4+2]*vec4_dir.w;

//vec4_dir.w = matrix[0*4+3]*dir.x + matrix[1*4+3]*dir.y + matrix[2*4+3]*dir.z + matrix[3*4+3]*dir.w; //no need return

return core::vector3df(vec4_dir.x, vec4_dir.y, vec4_dir.z);
}

//
void CLightSceneNode::doLightRecalc()
//LightData.Direction = core::vector3df(.0f,.0f,1.0f); //remove this line

Hello!
I just wanted to point some things out again, which haven't been fixed yet.
And one new thing

1. Irrlicht doesn't compile
trunk rev 5042 does not compile: the compiler tells me it can't wchar_t[] into LPCWSTR
what the compiler says exactly: Essentially the compiler tells you to use a c-style cast or a reinterpret cast.

2. Irrlicht doesn't compile with my configuration
I still compile Irrlicht with D3D8 and CG, but both don't compile correctly.
I just wanted to know whether that's gonna be fixed or whether both will be removed soon, so I can remove it from IrrlichtLime as well.

3. The material type EMT_SOLID_2_LAYER works incorrectly
I already wrote a topic (http://irrlicht.sourceforge.net/forum/v ... =7&t=50202) about it but I'm gonna sum this up here quickly:
The solid 2 layer material has 2 'bugs'.
1. In the D3D drivers it only uses the first texture coordinates for both layers but OpenGL uses the first texture coords for the first layer and the second ones for the second layer (the right behavior in my opinion).
2. Both D3D and OpenGL ignore lighting on the second layer. Only the first layer is lit correctly.

I fixed all of this in that topic already, but I was told that there's nobody who can check it, so it isn't in trunk yet.
I was told that it could break other peoples stuff, but I don't think many people could have used that material type, because of the very odd behavior it had.
So I hope this will be corrected because it doesn't make sense to not replace it, because even if the new one wouldn't work (it does work, I tested it), it wouldn't make it worse, I think.


That's it, thanks for reading.

@Foaly: Can't reproduce the first problem. You either have another change in IrrCompileConfig.h (maybe widechar something) - or it's some other setting. I tried with VS 2012. If you look closely the cast that fail are by the way between char* -> LPCWSTR and wchar_t* LPCSTR. I think there was some other unicode setting in VS itself. I'll try to find it when I have a little more time again (still in the middle of a release here - had 3 release candidates fail yesterday.

The second should be fixed. But that interface is rewritten right now. So either we get it working after that's changed or we kick DX8. The original plan was to kick out DX8 anyway for Irrlicht 1.9, but for stupid reasons we didn't do so immediately - and by now I have a bad feeling about removing so shortly before release. So... it might stay in - if we fix this - otherwise it will be removed I suppose.
Can't help much with CG - I see it fails, but I know absolutely nothing about that code so far. Given that we don't seem to have a maintainer for it anymore I would like to remove it from Irrlicht. Unless some maintainer steps up?

3. I just don't know what to do. Someone obviously has to invest time into this. But that someone can't be me - my open list of tasks is already far too large. If I put this on my todo it'll never get done. So for now I suppose it will simply stay on the bugtracker (if it's there) until we get someone into the team who works on it.

Yeah, it's true, I've defined _IRR_WCHAR_FILESYSTEM and I've enabled unicode in the project settings.
But that's necessary for compiling for IrrlichtLime because .NET has chars with 2 byte length.

I thought CG was from Nadro and he is still around.
Anyway - CG is not supported by NVidia any more.

Foaly wrote:Yeah, it's true, I've defined _IRR_WCHAR_FILESYSTEM and I've enabled unicode in the project settings.
But that's necessary for compiling for IrrlichtLime because .NET has chars with 2 byte length.

Thanks, enabling that should be fine I think - so has to be fixed. I just needed to know which settings you used to reproduce it :-)

I think that we should remove D3D8 asap, maintain of this driver is really problematic I don't have even a DX SDK with support for this stuff).

In my opinion Cg is in similar situation - NV no longer support this project, so we should remove support for this shading language from the engine. Of course I can fix compilation issues related to Cg, but I think that it's better to just remove it.

OK, lets remove them. Less problems for everyone I guess (I still have dx8 on my system, but hadn't compiled with it for ages).

I think I know how to solve the unicode related compiler errors.

In CIrrDeviceWin32.cpp (line 419 and line 429): Replace "RegQueryValueExA" by "RegQueryValueEx", there's a macro in WinReg.h, which chooses the right one.
And in CSoftwareDriver2.cpp (line 2432): Replace "CreateEvent" by "CreateEventA".

But I'm not sure whether this compiles correctly for non unicode.

@Foaly, thanks, I'll try that.

Seems it worked - compiles now in all settings and the corresponding function still seems to work (at least the joystick names). Thanks.

I was trying to compile the SVN version of Irrlicht without the Burning's video driver and I got an undefined reference in "[irrlicht-dir]\source\Irrlicht\CSoftwareDriver2.cpp". Somewhere at the bottom of the file there should be a check if the video driver is actually enabled. Instead it checks only if it's on the Windows platform.
Should be: