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.
Closing in on 3.10
- 1
- 2
15 posts
Page 1 of 2
@ 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.
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.
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.
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.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.
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.
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.
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.
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.
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 3 guests
