Torque 3D 3.8 Release Candidate

44 posts Page 3 of 5
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Sep 13, 2015 1:47 am
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 :P

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
Posts: 46
Joined: Thu Apr 09, 2015 2:54 am
by koros » Sun Sep 13, 2015 5:10 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 :lol:
Chelaru
Posts: 174
Joined: Wed Jul 01, 2015 10:33 am
by Chelaru » Sun Sep 13, 2015 3:58 pm
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 :P

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
Posts: 46
Joined: Thu Apr 09, 2015 2:54 am
by koros » Sun Sep 13, 2015 5:14 pm
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
Posts: 353
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Sun Sep 13, 2015 7:32 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.
Timmy
Posts: 237
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Fri Sep 18, 2015 7:26 am
Here you go @
User avatar
Azaezel
http://pastebin.com/jjen0DJJ noticed that warning on my laptop the other week (amd gpu). Didn't look into it though.
Azaezel
Posts: 353
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Fri Sep 18, 2015 8:01 am
@
User avatar
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
Posts: 237
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Fri Sep 18, 2015 8:45 am
@
User avatar
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
Posts: 353
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Fri Sep 18, 2015 9:51 am
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
Posts: 237
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Fri Sep 18, 2015 11:30 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.
44 posts Page 3 of 5

Who is online

Users browsing this forum: Bing [Bot] and 1 guest