Stunt Rally 3.0 beta RC3 - testing

[CryHam]

Well you probably can guess what happened but if not, then I've actually built SR3 on Windows 10 and it starts.
Now the big question is, is it broken due to my laptops crappy integrated GPU, or is it working okay?
Hope you can test and report the outcome. Details are on github, don't want to duplicate it.
It's just a small binary build, it needs redists, and pulling (or download Zip) of stuntrally3 and tracks3 repos, I tagged it 3.0-rc1.
https://github.com/stuntrally/stuntrall ... ag/3.0-rc1

[rubberduck]

oh, finally, I am gonna try it soon.

[rubberduck]

the first second it looked like this, but it only took a bit longer to load

a few seconds later I made this screenshot

but then I got issues like this

or this.

[rubberduck]

I was then interested how glitchy .. well glitchy looks, but not that kind of glitchy I expected
I discovered that it is caused by highest slopes, and because glitchy should look anomaly-glitchy it doesn't use highest slopes somewhere

but when I enable it on one terrain, then I get this

edit: I also forgot so say, that the resolution is messed up, everytime I start the editor, is there a setting somewhere? haven't found one yet

[CryHam]

Argh.
Okay let's go through this.
1st screen is normal when loading in ed. Game only hides it.
2nd looks fine, like all was working ok.
3rd and 4th have black terrain. This is bad, I didn't have it. Weirdly I saw no road or water but terrain was always ok for me.
3th has this stupid issue with pipes going bad texture with no wrap, I have it too. In 2nd track load if road/pipe materials match. I don't yet understand why. And help on Ogre-Next rather doesn't exist right now.

Can you try a few times, but quiting ed after track load?
So e.g. load 1 track, set some other in list and quit, it should load in next run (if not then put its name in editor.cfg for track = ) and check if this black terrain only happens on 2nd track load, is it random etc? If loading was okay for 1st track after start then I'd know what to suspect wrong. Even if I don't have that on Debian.
Game doesn't start track right?

[CryHam]

You are using Renderer GL3+ right?
You can change screen resolution in that dialog at start, that will be if you start exe with 'cfg' argument (I made that bat for it). If this doesn't save it (odd) then you can edit in ogre.cfg (same where *.log).
And well let's not check Glitchy, it's looking different for sure, I didn't finish all and either way stuff looks different and there it will show most probably.
Can you find out when terrain goes black? Because I never had that. Is it with option for triplanar 1, 2 or such?
And above all.. please include Ogre_ed.log for issues, best for separate runs, e.g. one .log for when terrain got black (and you quit), one for other issues.

[CryHam]

Right I see that screen gets cut off a bit bottom. Are you on fullscreen? Maybe try also with windowed.
This is in ogre.cfg or in that dialog at start (with 'cfg' argument for exe)
Here is what I have in ogre.cfg:

{l Code}: {l Select All Code}

Render System=OpenGL 3+ Rendering Subsystem

[OpenGL 3+ Rendering Subsystem]
Colour Depth=
Display Frequency=N/A
FSAA=8
Full Screen=yes
RTT Preferred Mode=FBO
VSync=Yes
Video Mode=1920 x 1200
sRGB Gamma Conversion=Yes

[rubberduck]

haven't checked resolution yet, but yes, I am on full screen. I will check the rest tomorrow. Edit: I checked it now, resolution works now

Instead I played so long with the new brushes, even created a few

But I checked it with the black terrain again, it always happens, if at least one terrain has triplanar (highest slopes) on, when I deactivate all in a track where it happens, then the black goes away

I have also now the editor log

Ogre_ed.log

(49.15 KiB) Downloaded 53 times

[CryHam]

Right so the most important issue is that black terrain for triplanar.
Just for info, triplanar is either on or off, that thing from old SR with only marked layers having it isn't implemented. And I doubt with our GPUs we would notice, so not a priority.

I suspect this can be some issue in shader that only goes bad on nvidia cards. IDK but I don't have it on amd and neither on that poor integrated intel.
Yes, as you noticed triplanar goes off when no layer has that checkbox set. And it is also in Graphics options, tab Textures, under Triplanar for Terrain and Horizon set both to 0.
Can you also check if normal maps are there, after pressing F9?

So: can you load TestC13-Rivers, enable blendmap test F9 (to have R,G,B colors), disable vegetation V, enable fog G.
On Settings (Alt-E) press Right to set this camera view.
Now go to Layers Alt-T, on 3rd layer with enabled Highest slopes, take a screenshot, then disable Highest slopes, press Update, and take a screenshot (this should all be done with Triplanar option 1 or 2, should look same).
3rd case is with Triplanar set to 3 (3 = Normal) in options.
I'm attaching how it looks for me in all 3 cases

Let's then do another quick test on Mrs4-Platforms, with camera: View Left,
just go into Graphics options, tab Textures, set Triplanar for Terrain to 2 press F5 and do a screeshot, set it to 3 and do the same.

I probably need to check shaders output, but I need to enable them in code first and make another -RC2.

[rubberduck]

ok, for me it looks like this, 2 and 4 are with highest slopes disabled, and 3 is with settings of 4 where it is enabled after reload

[CryHam]

Holy sh!t, so it's not just full black, what the hell is that weird black pattern..

[CryHam]

Does that ever change? or is it static, black always the same way, in same places? Does it change when you deform? Does it go nuts, or is it because of IDK low terrain angles?
Could you upload a view from (Alt-Z) top for both tracks with those black spots?
Maybe its some division by zero somewhere I'm just guessing now.
I don't suspect my blendmap shader, why would it depend on triplanar.
And could you upload ogre_ed.log after you just started ed, and saw black terrain and quit?
I didn't see any shader errors (apart from that 1 that's spamming always).

[rubberduck]

ok, I try it soon

I experimented a bit more with the terrain brushes, I noticed that not just K and L change the power value, also Ö and Ä, and while Ö and Ä only change power, K and L are looking like they change offset too, though the value in the ui doesn't change.

When saving some of these as own brushes, giving them names to identify, I noticed that in the ini file there are now 2 offset values and not one, like in the ui, where the second one changes, though I found both soon there

brush_values.jpg

I also figured out, that changing values with the keys don*t update it in the big ui with the sliders, it only updates it when I change to a different brush by clicking on it, and that I can't set the power higher than 10 there (others have a field where you can put in numbers, but power doesn't have that) The only way to get it higher is with using keys.
I actually noticed that you can get some quite interesting things, and some stars have really huge numbers that go above 100,

but this is still very wip, for me enter in terrain mode didn't work either

[rubberduck]

I tested it now, it is definitly slope-angle dependent, in what direction the terrain is going to, but also independent from sky rotation / lighting, including both yaw values
edit: and here is the log too

[CryHam]

Keys, yeah, I think the idea was that most things that have K,L have " ' too which is Ö Ä I guess on German keyboard. But honestly all keys should be rebindable, this is a rather consuming thing to code so it wasn't even on any todo list.

Right well this dynamic Brushes list is a new thing (BTW it's way too slow). It's not that polished, yet. Same goes for vehicle Paints list.
Sliders yes, I guess I didn't need that. I usually put edit boxes to type in values. But if some could break or crash then I don't.

Ah I need to change that in help. Insert is meant for Lock terrain editing cursor. Enter now cycles through terrains.

[CryHam]

Wow that's bizzare.
But if it is depending on light direction, maybe its something from shadows freaking out.
Could you try with Shadows None (disabled) and restart editor?

[rubberduck]

that didn't help, setting shadows to none and restarting

though it is always in the same angles, independent from lighting

[rubberduck]

I also just figured out, that I can crash the editor when cranking the power or force value too high

[CryHam]

It seems to me like this was triplanar going bad for negative values IDK angles.
I got a few ideas. Fortunately we can edit shaders and test changes.
Let's test on Hole track from Top view. Nothing else matters. (We could try Platforms later when we fix it).

So, could you load track Hole, (that has black stuff) and quit.
Now, edit this file (first make a copy of it to restore later):
/Media/Hlms/Terra/Any/800.PixelShader_piece_ps.any
in SR3 dir, and we can try few things:

1. First try, find this:
return midf3_c( pow( v.x, e ), pow( v.y, e ), pow( v.z, e ) );
and replace it by:
return midf3_c( v.x, v.y, v.z );
// return midf3_c( pow( v.x, e ), pow( v.y, e ), pow( v.z, e ) );
Start editor, check if the completely black part is changed at, or anything changed at all. You could attach screens if it's not too much trouble.
Quit editor.

2. Second idea. Find this:
triplanarBlend /= dot( triplanarBlend, midf3_c( 1.0, 1.0, 1.0 ) );
and replace with:
// triplanarBlend /= dot( triplanarBlend, midf3_c( 1.0, 1.0, 1.0 ) );
triplanarBlend = midf3_c( 0.33, 0.33, 0.33 );
Start editor, check how "black" it looks, or best upload screen.

3. Replace that line with
triplanarBlend = midf3_c( 0.73, 0.73, 0.73 );

4. Find line with:
pixelData.diffuse.xyz *= (detailCol0.xyz * detailWeights.x + detailCol1.xyz * detailWeights.y) +
add this above, so replace to:
detailWeights = midf4_c( 0.25f, 0.25f, 0.25f, 0.25f );
pixelData.diffuse.xyz *= (detailCol0.xyz * detailWeights.x + detailCol1.xyz * detailWeights.y) +

[CryHam]

Hah, with keys or sliders? Ok which values did this and in which deform mode. I should restrict them to a range, just like for sliders I think. To avoid that.

[rubberduck]

with keys, though it was a really high value like 45000 or so

though I checked these codes of lines, it is much better, but not perfect, the black is gone, one other weird thing, that fits perfectly the anomaly scenery (I am sure I can make something like this as texture )

[rubberduck]

but I made new brushes again, only the order is messed up, all with a * in the name are new that I made

[CryHam]

Nice, I'll try to add them, later. I fear we will soon run out of place on that image with previews
And I even wanted to add new noise library in some future version.

Yeah, true, I thought of adding some stuff in code just for Anomaly. I will try someday, or maybe even some toggable mods, for other tracks in game too.

[CryHam]

Allright so I think I see what's wrong.
Could you restore /Media/Hlms/Terra/Any/800.PixelShader_piece_ps.any to original.
Then edit it and delete these 2 lines:

{l Code}: {l Select All Code}

      midf3 triplanarBlend = pow3( pixelData.worldSpaceNormal, _h( 4.0 ) );
      triplanarBlend /= dot( triplanarBlend, midf3_c( 1.0, 1.0, 1.0 ) );


and put this instead:

{l Code}: {l Select All Code}

        float3 absNormal = abs( pixelData.worldSpaceNormal );
        float3 triplanarBlend = absNormal;

        triplanarBlend = (triplanarBlend - 0.5);
        triplanarBlend = max(triplanarBlend, 0.0001);

        triplanarBlend /= triplanarBlend.x + triplanarBlend.y + triplanarBlend.z;


That's in our old SR code and it worked. Any issues left now, or is it working?

[rubberduck]

finally, everything works now
here is how now platforms look

the only thing left to mention is, that the screenshot function from editor doesn't work, did you change the key here too, or is that just not yet implemented.
For the game I haven't even tried to start it yet, but that comes next to see if it crashes or not

edit / update: yes it crashes right when the loading should be finished, like you mentioned before