Build 254 / Biodome Technical Issues (Updated for Build 255)
-WildCat-
Cape Town, South Africa Join Date: 2008-07-19 Member: 64664Members, Reinforced - Shadow
Cape Town, South Africa Join Date: 2008-07-19 Member: 64664Members, Reinforced - Shadow
The Reinforced Update looks great although I have to admit that I haven't actually "played" it yet because I've been too busy testing the new render modes and looking for bugs in Biodome. There are a number of separate issues I'd like to raise so here's a table of contents:
1. Disappearing props
Sometimes, certain props will disappear when you look at them from a certain angle. Typically, it happens when you look at them straight on and it seems to be associated with props placed in "alcoves" (or indented parts of the map geometry). This is not an issue that's new in the Reinforced Update but there are a couple of instances of it in Biodome so it's probably about time I reported it.
Instance 1 (Fixed in build 255):
Instance 2 (Fixed in build 255):
Instance 3 (Remains in build 255):
In Docking, in "Stability Monitoring", some of the wall props disappear if you face that wall perfectly straight on. In the left screenshot, one wall prop has disappeared. In the right, two props have disappeared. (Side note: the pipes don't connect with the wall properly.)
There was another instance in Biodome with one of the vent/air-con units in "Bio Reactors" near "Main Hall" but that seems to have been fixed in build 254.
2. Mapping mistakes in Biodome
Both of the issues I want to report here were actually partially fixed in build 254.
Issue 1 (Remains in build 255):
The power node in "Access Tunnels" is not connected properly with the wall. In build 253, it was embedded in the wall. It probably needs a piece of geometry built behind it in order to look right.
Issue 2 (Remains in build 255):
The water sprinkler effects around "Bridge" come through the glass in places. In build 253, it came through really obviously, right next to the power node. In build 254, it's only coming through below the walkway.
3. Shadow rendering differences
In the D3D11 and OpenGL render modes, the shadows look grainy. In D3D9, the shadows look quite smooth.
The appearance of the shadows in D3D11 and OpenGL reminds me of how shadows used to look a long time ago. I don't think this grainy look represents an improvement in visual quality.
Comparison screenshots:
Scene 1: D3D9 / D3D11
Scene 2: D3D9 / D3D11
4. Performance observations with new renderers
Before I begin, here are my system specs:
The GTX 690 is a dual-GPU graphics card so I've tested each render device with multi-GPU enabled and disabled.
Have a look at the following 6 screenshots:
The purple text is provided by MSI Afterburner's "On Screen Display". The percentages indicate the GPU usage. Below the purple text is the output from NS2's r_stats command. All of the screenshots were taken of this scene in Biodome.
The first thing to note is that multi-GPU is not working in D3D11. However, the performance appears to be a tiny bit better than D3D9 in single-GPU mode. I suspect that it's NVIDIA's responsibility to update the SLI profile in their drivers so that multi-GPU works in D3D11 mode.
Multi-GPU appears to be working in OpenGL but the performance is worse than in single-GPU mode. There is something very wrong with OpenGL in both single and multi-GPU modes. You'll see that, in both cases, the GPU is not being fully utilized. Notice how long the "waiting for render thread" time is.
While testing this stuff, I noticed that mouse input lag became much more perceptible at lower frame rates. When using D3D11 (as well as D3D9 in single-GPU mode), I could feel a bit of mouse lag at times. With OpenGL in single-GPU mode, the mouse lag was really bad and, in multi-GPU mode, it was absolutely diabolical.
(Side note: This update seems to have messed up the r_stats command because it shows zeros for many of the stats. I can see values occasionally flicking to something other than zero.)
5. Frame rate anomalies (Fixed in build 255)
6. PhysX GPU acceleration doesn't work
The NVIDIA Contol Panel provides a way to see if PhysX is being run on the GPU or the CPU. In the menu bar at the top of the Control Panel, open the "3D Settings" menu and click the "Show PhysX Visual Indicator" to check it.
In NS2, the indicator shows that PhysX is running on the CPU, despite having the "PhysX GPU acceleration" set to "On" in the General Options menu. I even tried forcing one of my GPUs to be dedicated to PhysX but it didn't help.
I verified that this visual indicator actually works using Borderlands 2. In that game, you can set the "PhysX Effects" to "Low", "Medium" or "High". In "Medium" and "High" modes, the visual indicator shows that it's running PhysX on the GPU.
My PhysX version is 09.12.1031
Well, making this post has taken far longer than I had anticipated. I hope y'all appreciate it. :P
- Disappearing props (Some instances fixed in build 255)
- Mapping mistakes in Biodome
- Shadow rendering differences
- Performance observations with new renderers
- Frame rate anomalies (Fixed in build 255)
- PhysX GPU acceleration doesn't work
1. Disappearing props
Sometimes, certain props will disappear when you look at them from a certain angle. Typically, it happens when you look at them straight on and it seems to be associated with props placed in "alcoves" (or indented parts of the map geometry). This is not an issue that's new in the Reinforced Update but there are a couple of instances of it in Biodome so it's probably about time I reported it.
Instance 1 (Fixed in build 255):
In Biodome, in "Condensators" - The grass plantation under the thick blue pipe. In the left screenshot, the grass is visible. In the right, it disappears.
Instance 2 (Fixed in build 255):
In Biodome, in "CO2 Scrubbers", right next to the entrance to "Exchange" - The pipes on the wall disappear when faced straight on.
Instance 3 (Remains in build 255):
In Docking, in "Stability Monitoring", some of the wall props disappear if you face that wall perfectly straight on. In the left screenshot, one wall prop has disappeared. In the right, two props have disappeared. (Side note: the pipes don't connect with the wall properly.)
There was another instance in Biodome with one of the vent/air-con units in "Bio Reactors" near "Main Hall" but that seems to have been fixed in build 254.
2. Mapping mistakes in Biodome
Both of the issues I want to report here were actually partially fixed in build 254.
Issue 1 (Remains in build 255):
The power node in "Access Tunnels" is not connected properly with the wall. In build 253, it was embedded in the wall. It probably needs a piece of geometry built behind it in order to look right.
Issue 2 (Remains in build 255):
The water sprinkler effects around "Bridge" come through the glass in places. In build 253, it came through really obviously, right next to the power node. In build 254, it's only coming through below the walkway.
3. Shadow rendering differences
In the D3D11 and OpenGL render modes, the shadows look grainy. In D3D9, the shadows look quite smooth.
The appearance of the shadows in D3D11 and OpenGL reminds me of how shadows used to look a long time ago. I don't think this grainy look represents an improvement in visual quality.
Comparison screenshots:
Scene 1: D3D9 / D3D11
Scene 2: D3D9 / D3D11
4. Performance observations with new renderers
Before I begin, here are my system specs:
- MSI Big Bang MPower Z77 Motherboard
- Intel Core i7-3770K @ 4.5GHz
- Corsair Dominator Platinum 8GB DDR3 1866Mhz RAM
- NVIDIA Geforce GTX 690
- NVIDIA driver version 320.49
- Windows 7 Professional 64-bit
- In NS2: 1920 x 1080 @ 120 Hz fullscreen, v-sync off, texture streaming off, all graphics settings maxed, PhysX GPU acceleration on
The GTX 690 is a dual-GPU graphics card so I've tested each render device with multi-GPU enabled and disabled.
Have a look at the following 6 screenshots:
The purple text is provided by MSI Afterburner's "On Screen Display". The percentages indicate the GPU usage. Below the purple text is the output from NS2's r_stats command. All of the screenshots were taken of this scene in Biodome.
The first thing to note is that multi-GPU is not working in D3D11. However, the performance appears to be a tiny bit better than D3D9 in single-GPU mode. I suspect that it's NVIDIA's responsibility to update the SLI profile in their drivers so that multi-GPU works in D3D11 mode.
Multi-GPU appears to be working in OpenGL but the performance is worse than in single-GPU mode. There is something very wrong with OpenGL in both single and multi-GPU modes. You'll see that, in both cases, the GPU is not being fully utilized. Notice how long the "waiting for render thread" time is.
While testing this stuff, I noticed that mouse input lag became much more perceptible at lower frame rates. When using D3D11 (as well as D3D9 in single-GPU mode), I could feel a bit of mouse lag at times. With OpenGL in single-GPU mode, the mouse lag was really bad and, in multi-GPU mode, it was absolutely diabolical.
(Side note: This update seems to have messed up the r_stats command because it shows zeros for many of the stats. I can see values occasionally flicking to something other than zero.)
5. Frame rate anomalies (Fixed in build 255)
While exploring Biodome, I came across a spot in the map that reliably triggers really bizarre frame rate fluctuations.
Behind the tech point in "Exchange", there are some pipes. When I go close to these pipes and look at them, my frame rate soon becomes very low and jittery. The strange thing is that NS2 still reports that I'm getting 100+ FPS despite the fact that I feel like I'm getting about 20 FPS. FRAPS also indicates that I'm getting 100+ FPS in that spot.
If I turn around and leave the area, it takes a while for the jitteriness to go away. I can often walk all the way out of "Exchange" before smoothness returns.
The fact that both NS2 and FRAPS continue to report normal frame rates while this is going on suggests to me that the frames are being lost after they get passed over to the rendering API. I don't know if the frames are being completely dropped or if they're being displayed as "runt" frames. If you don't know what I mean by "runt" frames, please watch the following video where Tom Petersen from NVIDIA talks with Ryan Shrout from PC Perspective about Frame Rating and FCAT. There's also discussion about SLI metering, v-sync and input latency. It's an hour-and-a-half long but it's fascinating and very useful information.
I opened up the profiler in NS2 and I noticed that this anomaly correlates with some unusual frame times. Check out this screenshot:
As you can see, every odd frame takes longer than every even frame. I wonder if this is messing up the SLI metering system or something like that.
I'd really love to run this scenario through the Frame Rating methodology but you need a video capture card. The one mentioned in the video ("Datapath VisionDVI-DL") is unfortunately quite expensive.
Behind the tech point in "Exchange", there are some pipes. When I go close to these pipes and look at them, my frame rate soon becomes very low and jittery. The strange thing is that NS2 still reports that I'm getting 100+ FPS despite the fact that I feel like I'm getting about 20 FPS. FRAPS also indicates that I'm getting 100+ FPS in that spot.
If I turn around and leave the area, it takes a while for the jitteriness to go away. I can often walk all the way out of "Exchange" before smoothness returns.
The fact that both NS2 and FRAPS continue to report normal frame rates while this is going on suggests to me that the frames are being lost after they get passed over to the rendering API. I don't know if the frames are being completely dropped or if they're being displayed as "runt" frames. If you don't know what I mean by "runt" frames, please watch the following video where Tom Petersen from NVIDIA talks with Ryan Shrout from PC Perspective about Frame Rating and FCAT. There's also discussion about SLI metering, v-sync and input latency. It's an hour-and-a-half long but it's fascinating and very useful information.
I opened up the profiler in NS2 and I noticed that this anomaly correlates with some unusual frame times. Check out this screenshot:
As you can see, every odd frame takes longer than every even frame. I wonder if this is messing up the SLI metering system or something like that.
I'd really love to run this scenario through the Frame Rating methodology but you need a video capture card. The one mentioned in the video ("Datapath VisionDVI-DL") is unfortunately quite expensive.
UPDATE: Obraxis posted a potential fix for FPS issues and input latency in his thread (Microstuttering/Input Delay Fixes to try). It involves disabling "visual themes" and "desktop composition" in the compatibility settings for the NS2 executable.
Whilst there was no discernible change to input latency, it did seem to fix this frame rate anomaly. I tested it reasonably thoroughly (twice with compatibility settings applied and twice without - alternating between the two cases) and in both cases where compatibility settings were applied, I couldn't reproduce the frame rate anomaly whereas, in both cases where the compatibility settings were not applied, I could.
Whilst there was no discernible change to input latency, it did seem to fix this frame rate anomaly. I tested it reasonably thoroughly (twice with compatibility settings applied and twice without - alternating between the two cases) and in both cases where compatibility settings were applied, I couldn't reproduce the frame rate anomaly whereas, in both cases where the compatibility settings were not applied, I could.
6. PhysX GPU acceleration doesn't work
The NVIDIA Contol Panel provides a way to see if PhysX is being run on the GPU or the CPU. In the menu bar at the top of the Control Panel, open the "3D Settings" menu and click the "Show PhysX Visual Indicator" to check it.
In NS2, the indicator shows that PhysX is running on the CPU, despite having the "PhysX GPU acceleration" set to "On" in the General Options menu. I even tried forcing one of my GPUs to be dedicated to PhysX but it didn't help.
I verified that this visual indicator actually works using Borderlands 2. In that game, you can set the "PhysX Effects" to "Low", "Medium" or "High". In "Medium" and "High" modes, the visual indicator shows that it's running PhysX on the GPU.
My PhysX version is 09.12.1031
UPDATE: Tested with newer PhysX version 09.13.0604 and it still doesn't run on the GPU.
Well, making this post has taken far longer than I had anticipated. I hope y'all appreciate it. :P
Comments
I only used the FRAPS and Afterburner overlays for testing and diagnostics after previously observing the issue without any overlays activated (other than the Steam overlay, of course).
Rest assured UWE and the playtest team are working hard to iron out these bugs and issues!
* In Hydroponics, infestation goes through the glass tubes on the west and east walls as if they weren't there.
* In the north-east corner of Seeding, some of the "NO STEP" textures are flipped so the text is backwards
imgur.com/a/kZDw7/embed
Nothing really gamebreaking or any exploits just tiny alignments and modelscales that are off when working on such a big and amazing map like biodome. The overlapping ventilation model and portalling of the pipes are more of the obvious ones but i focused more on the smaller exposed skybox from the inside of the map. Glad to se the map in its full flawless glory in the next build
imgur.com/a/kZDw7/embed