Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 21:43:08



Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Feedback for the NEW experimental branch with v3.3 renderer. 
Author Message

Joined: 2010-03-14 21:12:58
Posts: 86
Reply with quote
Henri Beauchamp wrote:
Amalia Illios wrote:
Henri Beauchamp wrote:
This will depend entirely on LL's willingness to fix this issue in their own viewer, I'm afraid... [...]
Well, just for the record, it seems they have just recently demonstrated their unwillingness by closing https://jira.secondlife.com/browse/MAINT-1299 as Expected Behaviour :roll:
I had a quick look at the code as it was implemented in former renderers, and decided to give a try at reenabling similar code with the v3.4 renderer (in fact, using the exact same code to render invisprims in both non-deferred and deferred rendering modes)... Good news: it works just as well (and just as bad, i.e. full bright prims disappear behind invisprims while they should not) as it did in v2.6 !... I therefore re-enabled invisiprims deferred rendering in v1.26.5.9 and added a toggle for it in the "Advanced" -> "Rendering" -> "Deferred Rendering" menu.


I stumbled across this the other day: http://wiki.secondlife.com/wiki/Invisiprim which said:

Quote:
Why invisiprims won't work with deferred rendering

Invisiprims work by rendering to the depth buffer (but not the color buffer) before avatars but after prims. With deferred rendering, the depth information is used for lighting, so any invisiprim would change the position of prims behind it for lighting (it just looks broken).

Also, all fullbright objects are rendered after avatars with deferred rendering, so invisiprims would also occlude fullbright objects.


I havn't looked at the code but am guessing that it applies here.

BTW, can someone give a short description of what MAINT-1299 is about? I get a "Permession error" when I try to open that Jira and can't see any of it.


2012-09-16 02:50:49
Profile

Joined: 2011-08-27 17:31:05
Posts: 98
Reply with quote
This is fixable of course. But you would have to create a separate depth-buffer for invisiprims, have the actual shader for invisiprims render to the new buffer, and change the shader for the avatar to also check the new depth-buffer. So while it can be done, I doubt that it would be worth the effort. Just my opinion.


2012-09-16 09:11:36
Profile

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
Hm, compared to the stable client the experimental client seems to have some mesh rendering issues. There are some meshes that just don't come up. TPing out and back doesnt help most often, only relog seems to help. For example I got a mesh hair demo, parts of it never rezzed, only relog finally helped.

The stable client seems not to have a problem with it.

I am a bit unsure about the exact circumstances, have to investigate further.

Btw. is More/Refresh on other avatars more than the usual rebake, as rebake only rebakes the body textures, right? If it's more, is there a way to add it for 'self', too?


2012-09-29 12:32:11
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Tillie wrote:
Hm, compared to the stable client the experimental client seems to have some mesh rendering issues. There are some meshes that just don't come up. TPing out and back doesnt help most often, only relog seems to help. For example I got a mesh hair demo, parts of it never rezzed, only relog finally helped.
The stable client seems not to have a problem with it.
I am a bit unsure about the exact circumstances, have to investigate further.
*All* mesh viewers are affected by that bug. Sometimes, the mesh asset server (which is a HTTP server) simply fails to deliver the data and causes an non-"retryable" error (i.e. the viewer gives up and doesn't retry to retrieve the mesh data). I might have a look, sometime, and see if a manual retry ("refresh") feature could be implemented for such cases.

Quote:
Btw. is More/Refresh on other avatars more than the usual rebake, as rebake only rebakes the body textures, right? If it's more, is there a way to add it for 'self', too?
The "Refresh" on other avatars causes the viewer to trash the cached baked textures and to re-request them from the sim server. In case of corrupted textures, it allows to get the avatar to rez fully, but if the bake failed on the avatar's viewer side, it can't solve the issue (only the other avatar's owner can solve it by rebaking on their side). There is no point to add a "Refresh" for self, since the proper action is then to rebake your avatar.


2012-09-29 16:17:04
Profile WWW

Joined: 2010-03-14 21:12:58
Posts: 86
Reply with quote
Henri Beauchamp wrote:
Tillie wrote:
Hm, compared to the stable client the experimental client seems to have some mesh rendering issues. There are some meshes that just don't come up. TPing out and back doesnt help most often, only relog seems to help. For example I got a mesh hair demo, parts of it never rezzed, only relog finally helped.
The stable client seems not to have a problem with it.
I am a bit unsure about the exact circumstances, have to investigate further.
*All* mesh viewers are affected by that bug. Sometimes, the mesh asset server (which is a HTTP server) simply fails to deliver the data and causes an non-"retryable" error (i.e. the viewer gives up and doesn't retry to retrieve the mesh data). I might have a look, sometime, and see if a manual retry ("refresh") feature could be implemented for such cases.


Yes! Please! Pretty please with sugar on top! I get hit by this glitch several times every day.


2012-09-29 18:17:27
Profile

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Hi Henri,

a quick observation re the tcmalloc vs. non-tcmalloc viewer. The non-tcmalloc viewer causes file dialog issues on my system (so far only tried batch, not the other options) again, this time in the way that there is either no return from it (No "after" message ever logged, viewer freezes with no repaint, i.e. a black rectangle where the window was), or with the ominous supposed libcairo issue I already described elsewhere.

The version with tcmalloc does not show that behaviour and is running as perfectly fine as its predecessor.

I'll try to get some gdb results as soon as I find the time.

Love,
Lia


2012-10-07 13:42:24
Profile

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
Tried the notcmalloc version this weekend, it survived a model contest with around 50 people in viewrange (on two sims).

Only issue is that often mesh doesnt load at all (staying invisible, showing a glowing mesh ball when clicking it), but I guess that's a general issue with mesh, not with this client version. But if there was an easy way to force a reload of mesh it would be really helpful. For some stuff even using a deruth-rocket and TPing out and back (both often helps) didn't work this time.

After all the years of textures not loading and having this cleaned up almost completely we seem to be stuck with the same problem on meshes now.

I guess rebake and rightclick/reload on others only reloads textures, not meshes, right?


2012-10-08 11:31:39
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Amalia Illios wrote:
The non-tcmalloc viewer causes file dialog issues on my system (so far only tried batch, not the other options) again, this time in the way that there is either no return from it (No "after" message ever logged, viewer freezes with no repaint, i.e. a black rectangle where the window was), or with the ominous supposed libcairo issue I already described elsewhere.

The version with tcmalloc does not show that behaviour and is running as perfectly fine as its predecessor.
This simply *cannot* be tcmalloc-related... My guess is that it's an issue with the order in which the shared libraries get loaded (which would also explain why the GTK issue vanished for you in latest releases while I did *nothing* to attempt and correct it). Try loading the culprit library (pcre, was it ?) with LD_PRELOAD (e.g. export LD_PRELOAD=/usr/lib32/libpcre.so) prior to launching the viewer (from the same terminal, or by adding the export LD_PRELOAD to the cool_vl_viewer wrapper script) and see what happens...


2012-10-08 13:54:10
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Tillie wrote:
Tried the notcmalloc version this weekend, it survived a model contest with around 50 people in viewrange (on two sims).

Only issue is that often mesh doesnt load at all (staying invisible, showing a glowing mesh ball when clicking it), but I guess that's a general issue with mesh, not with this client version.
Yes, it's a general issue which however seems getting worst lately (probably overloaded servers at LL's).

Quote:
But if there was an easy way to force a reload of mesh it would be really helpful.
Before implementing a hack, I'll see if the latest fixes to LLCurl can solve at least a part of this issue...

Quote:
After all the years of textures not loading and having this cleaned up almost completely we seem to be stuck with the same problem on meshes now.

I guess rebake and rightclick/reload on others only reloads textures, not meshes, right?
Nope, it doesn't affect attachments neither rigged meshes.


2012-10-08 14:11:33
Profile WWW

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Hi again Henri,

Henri Beauchamp wrote:
This simply *cannot* be tcmalloc-related... My guess is that it's an issue with the order in which the shared libraries get loaded (which would also explain why the GTK issue vanished for you in latest releases while I did *nothing* to attempt and correct it).
I wasn't implying it was related to tcmalloc as such. No less, we have the two builds, one with, one without, which obviously behave very differently in that specific regard on my system. So obviously there is some difference there. And the possible explanation you're pointing to is certainly providing food for thought, even though (see below) it was triggered by an incorrect assumption.

The reason I provided the feedback up front without hard information was in fact to probe your mind as to potential differences in the builds which could then indeed trigger some oddity about the GTK mess that is obviously Precise Pangolin (and that is unlikely to get fixed the way Ubuntu is going).

Henri Beauchamp wrote:
Try loading the culprit library (pcre, was it ?) with LD_PRELOAD (e.g. export LD_PRELOAD=/usr/lib32/libpcre.so) prior to launching the viewer (from the same terminal, or by adding the export LD_PRELOAD to the cool_vl_viewer wrapper script) and see what happens...
I'm afraid you're mixing things up here. I don't blame you, since there seem to be several issues surrounding the viewer's interfacing to GTK. The PCRE issue is solved for me, as are any other oddities which would produce any messages on the console.

No less, thank you for the pointer, I may have a look-see in the specific direction of loaded shared library differences and holler if I see something interesting -- as always, time permitting.

Love,
Lia


2012-10-08 19:07:07
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 53 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: No registered users and 23 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.