Will Not Fix Textures reloading due to LOD
- Thread starter Tampa
- Start date
- Status
Why is Fetch textures and inventory with http turned off? - Does your grid not support it?
Also on your graphics settings, hit reset and dial up slowly and see if there is a certain level it starts at. Most likely with the settings you have (including the 480m draw distance), there is not sufficient graphics memory and you have trashing.
Also on your graphics settings, hit reset and dial up slowly and see if there is a certain level it starts at. Most likely with the settings you have (including the 480m draw distance), there is not sufficient graphics memory and you have trashing.
Tampa
Member
The graphics settings are setup the same way as I do for the other viewers, Firestorm and Singularity. I experimented with the http stuff, but apparently broke it in the process so I went back to standard OpenSim.
I have a 1080 so plenty of vram to go around. I see 700mb still available when standing on that region. I'll try resetting graphics settings, will report back if that fixes it, but far as I am aware is has always been doing that.
I have a 1080 so plenty of vram to go around. I see 700mb still available when standing on that region. I'll try resetting graphics settings, will report back if that fixes it, but far as I am aware is has always been doing that.
Fetch textures and inventory with http IS standard Opensim since version 0.9.x
That you have graphics memory free does not mean this viewer (Dayturn) can use it. As a matter of fact it has the exact same limitations as the SL viewer and cannot use more than 512 MB texture memory for the 32-bit build. Firestorm and Singu has various hacks to use more memory that makes it more difficult use the LL rendering code which this viewer is 100% dependent on.
So setting it like those two viewers will get you into trouble.
That you have graphics memory free does not mean this viewer (Dayturn) can use it. As a matter of fact it has the exact same limitations as the SL viewer and cannot use more than 512 MB texture memory for the 32-bit build. Firestorm and Singu has various hacks to use more memory that makes it more difficult use the LL rendering code which this viewer is 100% dependent on.
So setting it like those two viewers will get you into trouble.
They are not hacks in isolation, but they are hacks in relation to the already very flaky rendering code that all the viewers rely on.
Despite the fact that LL has had professional rendering engineers on the job, they spent close to 1 1/2 years on what in reality are nominal changes to the renderer in the EEP code. This code does of course include memory management and allocation.
To add TPV additions to the renderer makes it a nightmare to maintain, and I think it is symptomatic that TVP developers who have made such additions have all but one yet to release an EEP capable viewer.
To my knowledge LL have not even started on making the changes needed for the (announced by Apple in 2018) eventuality of OpenGL completely being removed from macOS later this year.
OZ Linden did a very long interview back in April where he clearly stated that video games graphics quality in SecondLife is simply not possible for a very long time. I am sorry to disappoint you there. 0
Despite the fact that LL has had professional rendering engineers on the job, they spent close to 1 1/2 years on what in reality are nominal changes to the renderer in the EEP code. This code does of course include memory management and allocation.
To add TPV additions to the renderer makes it a nightmare to maintain, and I think it is symptomatic that TVP developers who have made such additions have all but one yet to release an EEP capable viewer.
To my knowledge LL have not even started on making the changes needed for the (announced by Apple in 2018) eventuality of OpenGL completely being removed from macOS later this year.
OZ Linden did a very long interview back in April where he clearly stated that video games graphics quality in SecondLife is simply not possible for a very long time. I am sorry to disappoint you there. 0
Tampa
Member
I don't expect those levels of graphics no, I may be a dreamer, but not deluded. I merely see an issue that I would like to see resolved, ideally of course in the proper manner according to coding standards and such, but if not through means already explored and working. Like you I hate hacking stuff together, but it sometimes can't be avoided. We have to make due with what we have. If you go by what should be then touching viewer code at all stops making sense and you enter the "needs a rewrite" territory anyways. I'm on your side there no doubt, but we need to pick our battles or lose the war entirely.
Anyways, I did what you asked and reset graphics, even reinstalled again deleting all settings. Compiled a stock OpenSim and enabled http again. Still the same results as in the video. That means on default settings this happens for the viewer. I tried turning graphics down, still the same, but vram is at 800mb used overall, so plenty left still, can't be that. It even happens turning graphics almost entirely off.
As much as I hate doing it, I will update graphics drivers next. Beyond that I don't know what else to try.
Anyways, I did what you asked and reset graphics, even reinstalled again deleting all settings. Compiled a stock OpenSim and enabled http again. Still the same results as in the video. That means on default settings this happens for the viewer. I tried turning graphics down, still the same, but vram is at 800mb used overall, so plenty left still, can't be that. It even happens turning graphics almost entirely off.
As much as I hate doing it, I will update graphics drivers next. Beyond that I don't know what else to try.
Remove your settings.xml file in user_settings and start that one too from scratch pls.
I can't repo the issue at all.
I can't repo the issue at all.
There are tons of LOD related debug settings, but I have never bothered much testing them out as opensim did not send LODs at all until very recently. The full mesh resolution was sent anyway. (search settings.xml for all the options). They are all set to be as the default SL viewer. Try set RendervolLODfactor to 4 at a minimum as the default is most likely 1.25
It might also be some odd interaction with your Windows driver. Note that Windows 7 is neither tested or supported at all any more.
I have tested it to work fine on the Windows 10 1909 and 2004 updates.
It might also be some odd interaction with your Windows driver. Note that Windows 7 is neither tested or supported at all any more.
I have tested it to work fine on the Windows 10 1909 and 2004 updates.
Tampa
Member
Win7 still receives security updates through ESU for the next couple years. Also, over 35% of folks are still on it.
Set it to 4 and increased all the way to 200, no change.
Is missing from my settings file, apparently is part of the settings file on the repo however. I added it and set it to enabled. That stopped the console spam at least, but the texture rebaking is still present.
Set it to 4 and increased all the way to 200, no change.
Code:
<key>DebugObjectLODs</key>
<map>
<key>Comment</key>
<string>Show info related to lod calculations for attached or animated objects</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>Is missing from my settings file, apparently is part of the settings file on the repo however. I added it and set it to enabled. That stopped the console spam at least, but the texture rebaking is still present.
Tampa
Member
If I enabled Full Res Textures in debug the problem goes away, but that setting does not stick between viewer restarts for some reason.
The texture that was reloading was 2048 in size, perhaps it discards everything over 1024 causing reloads?
Also any idea why that setting won't stick?
The texture that was reloading was 2048 in size, perhaps it discards everything over 1024 causing reloads?
Also any idea why that setting won't stick?
A lot of debug settings won't stick simply because they are not meant to, so when you restart the viewer you restart with a clean slate and don't have to begin cleaning up all debug settings you may or may not have set in a debugging session. (if you can remember)
If the texture is 2048 it is guaranteed to create issues, even though older portions of code supports it, but it is not consistent throughout.
There will be a new Windows version uploaded in a few hours with a number of optimizations and fixes carried over from the macOS version.
If the texture is 2048 it is guaranteed to create issues, even though older portions of code supports it, but it is not consistent throughout.
There will be a new Windows version uploaded in a few hours with a number of optimizations and fixes carried over from the macOS version.
Tampa
Member
I tried adding the
to the settings and avatar settings, but it seems to only affect the debug setting not the develop->rendering fullrestexture setting which is a bit odd. Setting the debug setting to false unhooks that, but doesn't set it when set to true. Guess those are different things?
I know textures are the biggest load burden on rendering and data, but on lower resolutions displaying any sort of text more than two sentences becomes impossibly pixelated. I even been thinking about writing a direct-to-asset uploader to upload textures at even greater resolutions, because texture detail is, I find, the biggest ugly-factor of most builds these days.
Anyways, thanks for the quick fix as always!
Code:
<key>TextureLoadFullRes</key>
<map>
<key>Comment</key>
<string>If TRUE, always load textures at full resolution (discard = 0)</string>
<key>Persist</key>
<integer>0</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>to the settings and avatar settings, but it seems to only affect the debug setting not the develop->rendering fullrestexture setting which is a bit odd. Setting the debug setting to false unhooks that, but doesn't set it when set to true. Guess those are different things?
I know textures are the biggest load burden on rendering and data, but on lower resolutions displaying any sort of text more than two sentences becomes impossibly pixelated. I even been thinking about writing a direct-to-asset uploader to upload textures at even greater resolutions, because texture detail is, I find, the biggest ugly-factor of most builds these days.
Anyways, thanks for the quick fix as always!
On lower resolution displays if zoomed into the text should be as visible as on any other display. You just have to teach such users to zoom.
Also for OpenSim you have the option of generating dynamic textures with text that might look better than an uploaded texture. Finally there is the choice of font where some fonts reads much better than others when pixelated.
I would love to have 2048 or 4096 textures for use as texture atlases for meshes which would avoid the ridiculous amount of 1024 textures used on many meshes. But of course giving everyone the ability to upload larger textures are bound to make them used everywhere, so it is a double edged sword.
Also for OpenSim you have the option of generating dynamic textures with text that might look better than an uploaded texture. Finally there is the choice of font where some fonts reads much better than others when pixelated.
I would love to have 2048 or 4096 textures for use as texture atlases for meshes which would avoid the ridiculous amount of 1024 textures used on many meshes. But of course giving everyone the ability to upload larger textures are bound to make them used everywhere, so it is a double edged sword.
Tampa
Member
I just installed 1.7.3, nuking the appdata settings and it is still the same unfortunately. Selecting Full Res Textures in Rendering still the way to fix it. I will try a full reinstall next perhaps some old files were not overwritten.
You can test yourself, I opened the region up hg.zetaworlds.com:Events
I noticed that it is also reloading textures from the OpenSim Library, so textures only 512 in size, so not sure what change the Full Res Textures has, but it seems to not only affect larger textures loading. It even unloads the skybox.
The setting at least seems to stick between restarts now so that's good.
You can test yourself, I opened the region up hg.zetaworlds.com:Events
I noticed that it is also reloading textures from the OpenSim Library, so textures only 512 in size, so not sure what change the Full Res Textures has, but it seems to not only affect larger textures loading. It even unloads the skybox.
The setting at least seems to stick between restarts now so that's good.
Last edited:
I visited with both the macOS and Windows versions with default settings, and they both behaved identical with no issues with texturing.
Tampa
Member
Well I am stumped, I made another video of the current version. It seems to just be discarding textures at random over the course of a couple of minutes it reloads them, eventually it stops leaving textures farther away unbaked.
I will test another computer and see if I can find someone to replicate the issue, if not I guess it must be something strange with my local system. At least the Full Res settings sticks between restarts now so I can at least work around it
EDIT: I tried a newly installed Win7 that never had Dayturn installed, same thing, even worn textures on mesh get unloaded.
I will test another computer and see if I can find someone to replicate the issue, if not I guess it must be something strange with my local system. At least the Full Res settings sticks between restarts now so I can at least work around it
EDIT: I tried a newly installed Win7 that never had Dayturn installed, same thing, even worn textures on mesh get unloaded.
Last edited:
I am closing this thread because a) you experience the issue on an unsupported version of Windows b) I cannot reproduce the issue on Windows 10 c) you are using oversize textures that the viewer may or may not support.
- Status