|Anonymous | Login | Signup for a new account||2021-01-22 20:00 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007955||opensim||[REGION] OpenSim Core||public||2016-07-03 20:34||2016-07-05 05:19|
|Platform||Operating System||Operating System Version|
|Target Version||Fixed in Version|
|Summary||0007955: Severe Texture Issues|
|Description||OpenSim version: 0.8 and 0.9|
My OS: Windows 8.1
Viewer: Firestorm (and really, all other viewers I've tested)
I've been examining and researching texture issues on OSgrid. I've tested these issues on multiple regions, using a test device I created. Also watched in detail the texture progress screen (ctrl shift 3). In order to reduce distance issues I set my draw distance to a minimum of 32m.
Here are my findings:
* When logging in to a region, the system appears to load ALL region textures to the viewer cache. On one region I tested, some 16,000+ textures were loaded to cache before the system stopped loading textures.
* Evidently the method of loading textures is antiquated UDP (?). Many textures seemed to glitch during load, and attempt reload up to 4 times (4 was the highest I saw). This is an extreme waste of system time and resources.
* Logically, with a draw distance of 32m only textures within a 32m radius should be loading, with additional textures loading as my movement requires it.
Note: I think it's a great idea to load all region textures to cache-- but only if it loads local textures first and then sets all other texture loading to a background task. This does not seem to be the case. It appears to load textures in a specific order (FIFO? LIFO? Random?) and texture loading seems to be taking top priority, causing significant lag.
THE TEST MACHINE
I built a texture load test machine. It contains a main panel with 10 sub-panels. The main panel contains a slideshow script and 50 textures. The subpanels are flattened so that 5 sides are showing toward the user at all times. Each of those sides contains one of the textures in the slide show.
The idea is that all of the textures in the slideshow are ALREADY LOADED and showing on the smaller subpanels. The logic: since they are already showing, flipping through the slideshow should present those textures INSTANTLY, with no delay.
This is not what happens. What manifests when flipping through the slideshow is four items:
1. The system displays some textures instantly (maybe 10% to 25% of the time)
2. Some textures it displays only partially (ie, "out of focus"). Estimate at least 50% of the time.
3. In some instances textures do not display at all, resulting in a gray screen although the SAME TEXTURE is visible on the smaller subpanels.
4. Many of the textures appear to reload from the asset server-- should not be necessary since the texture is already cached on the client system.
In short, the entire texture system is broken. As I mentioned to LL many years ago... a 3D system cannot function properly when the 2D isn't working correctly.
Whether this is an asset server issue (probably), a region server issue (possibly), or Viewer issue (likely)... or a combination of two or three, it's difficult to tell from the client end.
Hate to be the bearer of bad news, but the texture system is majorly borked. It could be a simple fix, or it could be a major re-write is necessary.
What is certain is that the texture system needs to be examined with a microscope, and from what I've seen very likely entirely re-written. It's my belief it is one of the chief causes of poor system performance. Textures that are reloading unnecessarily puts an extreme strain on the asset and region servers. It is a strongly negative user experience, discouraging people from taking VR seriously. It explains why people can't read signs, items don't "rez" (their textures aren't loading), and why the more avatars on a region the greater the lag becomes proportionally (imagine all those textures loading and reloading, again and again, for every avatar on the region).
Once a texture is loaded on a client system it should stay loaded until cleared from the client cache. The fact that these textures are very evidently re-loading again and again is a major flaw in the system, almost "block" status.
|Steps To Reproduce||Turn on the texture monitor (ctrl shift 3) and teleport to another region. Watch the figures. Do this three or four times. |
Now return to your original region, and watch the textures that should already be in your cache totally reload all over again.
Then return to the first region you ported to, and watch it happen all over again.
|Additional Information||Observation: It's very obvious the texture loading and tracking system needs a major overhaul, and quite possibly replaced. Can't get a 3D world to work if the 2D textures aren't loading properly.|
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim)|
|Viewer||Firestorm + others|
- udp download: check if your viewer has http enabled for textures
- textures download is controlled by viewers, not regions, this only send back what is requested.
- a texture asset can have several copies of the texture with different compression quality for different LODs. Viewers usually start getting only the low quality part, and may later ask for better, so it may appear as several downloads of same texture.
the last part of previous comment explains your test machine problem.
viewer decides to download the textures on the small subpanels with only low resolution, since they are small... (low resolution makes them look as out of focus)
When you change to display fully, the viewer needs to get a higher resolution and its possible not in cache.
Snoots Dwagon (viewer)
This makes sense Ubit, and thank you for your answer.
To be noted however, is that I and two friends were on our region last night using a slideshow display device. *As is common*, it would take a single texture up to 30 seconds to load and display. So whatever the cause, asset server or viewer... there's definitely a bottleneck somewhere. No texture should ever take more than a few seconds to display.
If the viewer is displaying textures at only partial rez because the subpanel is .5x.5... I would consider that a logic issue. The builder intends the item to display, regardless of panel size. The viewer overrides that preference. It's the case of the automobile trying to tell the driver where to go. ; )
Snoots Dwagon (viewer)
edited on: 2016-07-05 05:24
Follow-up: bottom line, this texture issue is bad enough it makes parts of VR unusable. When a slideshow presenter takes 30+ seconds for a texture to load, it becomes useless as a slideshow viewer. Even pre-loading textures does not improve this function.
As a note of prior experience: Inworldz checked the texture loading system and found it to be extremely flawed. They re-wrote the entire system. If OpenSim hasn't made the same finding and taken the same step, then OpenSim is suffering from the same 2D texture issues that plagued SL back in 2005 when I and Balpien Hammerer first brought the texture bottleneck to their attention. Linden Lab claimed there was no problem-- until 2010 when they suddenly "discovered" texture loading problems... right where Balpien and I had been telling them for years they existed.
So trust me in this: there IS a texture loading bottleneck. I'm not sure exactly where, but when it takes an excessive amount of time for a single texture to load, there is a bottleneck. So long as this bottleneck continues to go unresolved it will hamper the growth of OpenSim. Most computer users, experienced or amateur, will not bother with any system that visibly has trouble loading textures. They get bored and find something that works better.
If OpenSim / virtual reality is to grow, this texture issue MUST be fixed asap.
|2016-07-03 20:34||Snoots Dwagon||New Issue|
|2016-07-05 01:51||UbitUmarov||Note Added: 0030869|
|2016-07-05 02:05||UbitUmarov||Note Added: 0030870|
|2016-07-05 05:16||Snoots Dwagon||Note Added: 0030871|
|2016-07-05 05:19||Snoots Dwagon||Note Added: 0030872|
|2016-07-05 05:22||Snoots Dwagon||Note Edited: 0030872||View Revisions|
|2016-07-05 05:24||Snoots Dwagon||Note Edited: 0030872||View Revisions|
|Copyright © 2000 - 2012 MantisBT Group|