### Torque 3D 3.8 Release Candidate

#### Re: Torque 3D 3.8 Release Candidate

JeffR
Steering Committee
Posts: 757
Joined: Tue Feb 03, 2015 9:49 pm

Chelaru wrote:
JeffR wrote:
Chelaru wrote: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.

#### Re: Torque 3D 3.8 Release Candidate

koros
Posts: 46
Joined: Thu Apr 09, 2015 2:54 am
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

#### Re: Torque 3D 3.8 Release Candidate

Chelaru
Posts: 188
Joined: Wed Jul 01, 2015 10:33 am
JeffR wrote:
Chelaru wrote:
JeffR wrote: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.

#### Re: Torque 3D 3.8 Release Candidate

koros
Posts: 46
Joined: Thu Apr 09, 2015 2:54 am
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

#### Re: Torque 3D 3.8 Release Candidate

Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm

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.

#### Re: Torque 3D 3.8 Release Candidate

Timmy
Posts: 308
Joined: Thu Feb 05, 2015 3:20 am
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.

#### Re: Torque 3D 3.8 Release Candidate

Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm

@
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.

#### Re: Torque 3D 3.8 Release Candidate

Timmy
Posts: 308
Joined: Thu Feb 05, 2015 3:20 am
@
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

#### Re: Torque 3D 3.8 Release Candidate

Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm

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...

#### Re: Torque 3D 3.8 Release Candidate

Timmy
Posts: 308
Joined: Thu Feb 05, 2015 3:20 am
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.

#### Who is online

Users browsing this forum: No registered users and 1 guest