[JeffR]

Hey i think there is a small issue with the spot light and point light animation type. If i set for example brightness 0.2 and select one of the animation types the light goes from 1 brightness on the max value not the 0.2 value that i set up. Should it be like this or i am using it in a bad way?

Definitely sounds incorrect.

I'll check on that. Did it matter what animation type?

With all of them.

As a solution: a check box could be added to say if the user wants the animation to be from 1 brightness or the one that was set.

Well, I mean, if they wanted a brightness of 1 on the light, they'd probably just set the brightness to 1

Alright, could you make T3D/lightAnimData.cpp's animate function at line 193

bool LightAnimData::AnimValue<COUNT>::animate( F32 time, F32 *output )
{
   F32 scaledTime, lerpFactor, valueRange, keyFrameLerp;
   U32 posFrom, posTo;
   S32 keyFrameFrom, keyFrameTo;
   F32 initialValue = *output; //Add this
   
   bool wasAnimated = false;

   for ( U32 i=0; i < COUNT; i++ )
   {
      if ( mIsZero( timeScale[i] ) )
         continue;

      wasAnimated = true;

      scaledTime = mFmod( time, period[i] ) * timeScale[i];

	   posFrom = mFloor( scaledTime );
	   posTo = mCeil( scaledTime );

      keyFrameFrom = dToupper( keys[i][posFrom] ) - 65;
      keyFrameTo = dToupper( keys[i][posTo] ) - 65;
	   valueRange = ( value2[i] - value1[i] ) / 25.0f;

      if ( !smooth[i] )
         output[i] = value1[i] + (keyFrameFrom * valueRange) * initialValue; //and add the * initialValue to the end
      else
      {
         lerpFactor = scaledTime - posFrom;
   	   keyFrameLerp = ( keyFrameTo - keyFrameFrom ) * lerpFactor;

         output[i] = value1[i] + ( ( keyFrameFrom + keyFrameLerp ) * valueRange ) * initialValue; //and add the * initialValue to the end
      }
   }

   return wasAnimated;
}

And see if that makes it behave as you expect.

The way it's set up, the min/max brightness is being set in the animation data, which makes it override the particular light. So we just scale it by our input brightness level, and it seemed to work for me. If that behaves as you expect, I'll get that rolled in.

[koros]

Wasn't able to replicate it on the AMD card just with my dicking around.

Any chance you could upload the mission file with the terrain and textures it uses somewhere so I could try and test your exact case?

The empty terrain level with the stock textures, I'll gladly upload them if you want but they're just whats in the download.

I must have some edge case combo of card/driver/opengl or settings that is really, really unique.

Appreciate you going to all this trouble. It's not much of a problem if there is only one case

I'll try to futz around with it tomorrow, force a driver clean/update etc.

Hopefully you saw the fog issue, if not then maybe I need to put down the pipe

[Chelaru]

Definitely sounds incorrect.

I'll check on that. Did it matter what animation type?

With all of them.

As a solution: a check box could be added to say if the user wants the animation to be from 1 brightness or the one that was set.

Well, I mean, if they wanted a brightness of 1 on the light, they'd probably just set the brightness to 1

Alright, could you make T3D/lightAnimData.cpp's animate function at line 193

bool LightAnimData::AnimValue<COUNT>::animate( F32 time, F32 *output )
{
   F32 scaledTime, lerpFactor, valueRange, keyFrameLerp;
   U32 posFrom, posTo;
   S32 keyFrameFrom, keyFrameTo;
   F32 initialValue = *output; //Add this
   
   bool wasAnimated = false;

   for ( U32 i=0; i < COUNT; i++ )
   {
      if ( mIsZero( timeScale[i] ) )
         continue;

      wasAnimated = true;

      scaledTime = mFmod( time, period[i] ) * timeScale[i];

	   posFrom = mFloor( scaledTime );
	   posTo = mCeil( scaledTime );

      keyFrameFrom = dToupper( keys[i][posFrom] ) - 65;
      keyFrameTo = dToupper( keys[i][posTo] ) - 65;
	   valueRange = ( value2[i] - value1[i] ) / 25.0f;

      if ( !smooth[i] )
         output[i] = value1[i] + (keyFrameFrom * valueRange) * initialValue; //and add the * initialValue to the end
      else
      {
         lerpFactor = scaledTime - posFrom;
   	   keyFrameLerp = ( keyFrameTo - keyFrameFrom ) * lerpFactor;

         output[i] = value1[i] + ( ( keyFrameFrom + keyFrameLerp ) * valueRange ) * initialValue; //and add the * initialValue to the end
      }
   }

   return wasAnimated;
}

And see if that makes it behave as you expect.

The way it's set up, the min/max brightness is being set in the animation data, which makes it override the particular light. So we just scale it by our input brightness level, and it seemed to work for me. If that behaves as you expect, I'll get that rolled in.

Thank you for the response. I don't use it. It was just an observation when i was doing some test.

[koros]

Here's a link to /levels /terrains and the console log
https://www.dropbox.com/s/i4fxxvw1gi5zi ... E.zip?dl=0

Tried it on the other box in the house, same AMD GPU though, same issues.

Like I said if I am the only one seeing it then it's really not an issue.
This isn't a production project.

Cheers

[Azaezel]

Program shadergen:/9310a62897cf71f6_V.glsl / shadergen:/9310a62897cf71f6_P.glsl: WARNING: Too many temp register is used in Vertex shader, it may cause slow execution.

Mind posting that shader? It'll be under \game\shaders\procedural.

[Timmy]

Here you go @

Azaezel http://pastebin.com/jjen0DJJ noticed that warning on my laptop the other week (amd gpu). Didn't look into it though.

[Azaezel]

@

Timmy: and the _P? looks like that ones a vertex shader, and most of the time temp variables crop up in pixel shader loops.

On the sdl2 keybinding front... still looking into it https://github.com/Azaezel/Torque3D/commits/SDL_Synergy (Code-dump courtesy of mango: https://onedrive.live.com/redir?resid=5 ... file%2czip , though a straight drop-in and replace still showed some interference. Might rule a few things out though.), don't think that's gonna make cutoff however, unfortunately.

[Timmy]

@

Azaezel
_V : http://pastebin.com/upqpeKDW
_P: http://pastebin.com/eYuB35hv

Sorry i couldn't remember which one that was i posted originally haha. Same error happens on multiple shaders, i think the imposter is the common connection, i think

[Azaezel]

If it is, about the only thing that sticks out that'd likely be applying too much pressure might be https://github.com/Azaezel/Torque3D/com ... 45b4a504fe if yall want to try and throw that at it, see if that helps or not...

[Timmy]

I'll give it a shot tomorrow, my first guess was that imposter uv size too. There is just nothing else obvious apart from that.