Cool VL Viewer forum

This could make sense on a 64bits system, since I don't think the 64bits Tcl/Tk runtime gets packaged by the installer (that is configured to output a 32bits installation)... In this case, installing the 64bits Tcl/Tk libraries should solve the issue.

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

This will literally break billions of L$ worth of existing content in the medium to long run. Isn't SL fun?

The funny part is that some of the library AVs still use invisiprims for a proper look. Way to go!

Love,
Lia

Lots of shoes and stuff you can fix, when it is editable... just remove the invisiprim from the linkset and use a proper alpha texture with it.

Lots of shoe demos etc. are coming with alpha textures, I save them all in a separate folder, you never know when you need one specific one.

Some additional feedback with the new renderer:

A forum tip posted here, to use Debug Settings to move RenderShadowBlurSize from 0.7 to 3.0 has smoothed out the shadow "static" or "noise" I was seeing in some parts of the shadows.

I had just assumed this was artifacting from something in the new render pipeline, but it was really the SSAO feature doing what it was supposed to.
Tuning it for softer shadows made it look more "natural" on my system, and is the last "side effect" I'd seen with the renderer change.
So, it at this point - 1.26.5.2 is *only* improvements over 1.26.4.x and just took some light tuning.

I turned off driver forced aniso and AA, and using just the maxed viewer settings and see 11-23fps @ 1920x1200 depending on amount of geometry in scene.

Still amazed how you've been able to merge and blend current viewer code with the 1.x viewer code and continue to generate the most stable and usable viewer out there.

This pack should cover all your needs

hm..what can i say? i tried it today on one of the os grids and got AMAZED.
now thats what my video card was built for!
sorry. i dont have any bugs to report by this time.
maybe some would show later. but for now i am happy like little boy at christmas!

keep up the good work!

ev

ok
now that i tested it a bit more thoroughly i noticed two things.

there is a big difference on the behaviour of the viewer between an os grid i am a regular in and secondlife.
while the viewer is doing exceptionally well on the os grid it is getting extremely slow on sl and textures will take ages to load or even fail to load on sl.
i didnt try the tzhe idea about the privatepools thing yet, but i'll keep you posted about it.
furthermore i am experiencing freezes sometimes, very randomly, usually at the beginning of a session after logging in on sl.
no idea what that could be. but thats how it is.
have a good week,
ev

I didn't notice any change in texture speed loading here, and the texture fetching code is absolutely identical to v1.26.4 (only the renderer changed, nothing else !)... If you are seeing an effect, this is probably due to the ParcelOverlay message spamming bug in SL, that arised two weeks ago and that eats up a lot of bandwidth (not a problem for someone with 20Mbps bandwidth like mine, but definitely an issue for 4Mbps and smaller bandwidth links).

hm...so probably nowt to do about it, eh? oh well...lets see what lindens will come up with as a solution.
-.-
thanks anyways
ev

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.