Closing in on 3.10

  • 1
  • 2
15 posts Page 1 of 2
JeffR
Steering Committee
Steering Committee
Posts: 741
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Sep 29, 2016 3:59 pm
Hey guys!

As we work on all the new doodads and baubles for 4.0, which includes an overhauled shadergen, more progress on PBR, new asset pipeline and other neat things you can read about in my work blog, due to some issues that cropped up with 3.9 we've also been doing some improvements and bugfixes for a 3.10 release in the short term.

While most of the stuff that went into 3.9 was solid, some issues, particularly related to the linearized lighting changes, slipped past testing and were causing some grief. So those have been hammered on and we have some PRs in testing to try and remedy the major issues that cropped up.

I'll be adding some new threads in the development section so we can try and hammer out the last issues and a handful of new features/improvements, but 3.10 should be ready pretty soon, as a good incremental update to the work being done on 4.0.
Chelaru
Posts: 186
Joined: Wed Jul 01, 2015 10:33 am
by Chelaru » Thu Sep 29, 2016 4:24 pm
This made my thursday.
JeffR
Steering Committee
Steering Committee
Posts: 741
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Sep 29, 2016 6:56 pm
@
User avatar
Chelaru
Glad to hear it :)

To help deal with subtle rendering issues from slipping past us in the future, I've been mulling on a visual unit test system, of sorts.

One thing I've been trying to hash out is a new test level that better covers the features bases so we can fire it up and test stuff and know if it works. However, in the case of the linear lighting issues and similar, the issies are often subtle enough that they're hard to catch.

With the work on the reflection probes, they can be utilized to capture cubemaps in the scene, which got me thinking of a Visual Unit Test, as said. My thinking is that we have our test level which acts as a sandbox for just about everything in the engine. We then establish a script that iterates over points in the scene - likely via camera bookmarks - that then go and capture the view from that marker, potentially even in a full cubemap format.

With a main release, we can establish a new baseline set of captures from these points, and then when we run our VUT, we use an image comparison tool such as Image Magick to compare the captures at the time of the VUT run to our baseline. This will highlight changes, even incredibly subtle ones, and so if something like lighting changes, or we get color banding, this will become immediately apparent in the comparison results and we can figure out if it was intentional or not.
Duion
Posts: 806
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Thu Sep 29, 2016 8:36 pm
Sounds interesting, I did not expect that update so soon.

The issues slipped past the testing likely because the testlevel did not utilize much advanced features, the test level has almost no normal or specular maps applied and not a reasonable lighting setup. I would also turn off the timeofday by default, since it confuses the lighting setup, you need a constant scene to have something as a benchmark, not something that changes all the time, this can give wrong impressions.
JeffR
Steering Committee
Steering Committee
Posts: 741
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Sep 29, 2016 8:55 pm
Duion wrote:Sounds interesting, I did not expect that update so soon.

The issues slipped past the testing likely because the testlevel did not utilize much advanced features, the test level has almost no normal or specular maps applied and not a reasonable lighting setup. I would also turn off the timeofday by default, since it confuses the lighting setup, you need a constant scene to have something as a benchmark, not something that changes all the time, this can give wrong impressions.


Indeed, the new test level will need to properly capitalize on the asset usage.
As for lighting, I'd say you partially right. The time of day is useful for a quick comparison on the lighting conditions, and to make sure that the feature works, but you're right in that it's hard to properly nail down points of comparison because it goes by quickly.

I'm thinking the new tester level would have the time of day on by defualt, but when we execute the VUT, it pauses it and sets it to certain times, like noon, midnight, dusk and dawn, to make sure the values are expected at different lighting conditions.
Chelaru
Posts: 186
Joined: Wed Jul 01, 2015 10:33 am
by Chelaru » Thu Nov 17, 2016 2:10 pm
How is the progress going on this version?
Azaezel
Posts: 383
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Thu Nov 17, 2016 10:49 pm
Chelaru wrote:How is the progress going on this version?

Still going over cleanups and pure additions, like the Mac support you'll find in the development fork.
saindd
Posts: 220
Joined: Wed Apr 15, 2015 3:20 am
by saindd » Fri Nov 18, 2016 10:31 pm
Are the lighting issues fixed? :D
JeffR
Steering Committee
Steering Committee
Posts: 741
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Nov 21, 2016 6:18 pm
Should be for the most part outside a few nitpick changes we're tossing around(like the removal of the dynamic refresh rate control for shadow caching)

The math for the linearized lighting should be pretty much correct now and as far as we can tell the banding has either been drastically reduced or removed.

So yeah, I spent this weekend moving into a house, so now that that junk is out of the way, we can put a wrapper on this this week.

One a few outstanding 'major' things, the big one being a double-check on an intel-specific issue with the GLAD OpenGL API PR, and some math that got tweaked at some point for the terrain shaders.

Beyond that, it's just a final go of testing on some of the outstanding PRs for fixes/improvements, and we'll have it ready for a release candidate to get put through the ringer.
Duion
Posts: 806
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Nov 21, 2016 7:44 pm
And what will the dynamic refresh rate then be set to? Did you look into my suggestion of using 15ms instead of 8ms?
8ms is 125 updates/frames per second but actually 60 fps is enough, since that is what V-sync limits to, 60 fps would be 16.6666ms, but when you set it to that the shadows occasionally jump since a frame is skipped, but 15ms offers enough buffer that this almost never happens.
I don't know how much performance increase this brings, from my tests I could see roughly 5-10% performance increase.
  • 1
  • 2
15 posts Page 1 of 2

Who is online

Users browsing this forum: No registered users and 1 guest