Jump to content

Firestorm Render Glitch Fix?


Draconis Ahren
 Share

You are about to reply to a thread that has been inactive for 948 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello everyone me again, so a friend just told me that a major problem why I seem to see this issue is cause it could be Firestorm having a render glitch. I don't know what sort of setting to use to fix it, but my LOD distance is set to its maximum of 4.000, My Draw Distance is 576 meters. And i've tried every possible solution I can think of and it still does this

This version of Firestorm i'm using is 6.4.21.64531

 

As for what sort of GPU and CPU i'm using is its an AMD Ryzen 7 5800x, and a AMD Radeon 6600 XT for the Graphics Card.

 

I've been trying to get this fixed for a few days now, help? Also these are two prim objects atop of the other one. None of them are set to Alpha Masking or Alpha blending. And they're somewhat close to eachother, but not close enough that it should cause this issue.

 

 

Snapshot_004.thumb.png.09e0af4a0e3d798336b88134a46e14e8.png

Edited by Draconis Ahren
Link to comment
Share on other sites

Draw distance at 578? Are you wanting to burn up your GPU? Turn the DD down to no higher than 128 for GP and 256 for photography. You can adjust it a little higher or lower through quick prefs on FS as needed depending on the load a region is putting on your GPU.

 

No harm in having LOD set at 4. Mine has been set at 4 for over a decade now. In fact if I don't keep it set at 4 most objects in SL will collapse at a very close distance, spoiling the view and immersion.

Edited by Silent Mistwalker
  • Like 1
Link to comment
Share on other sites

47 minutes ago, panterapolnocy said:

I have turned it down many times before on different computers with different OSes and graphics cards. It's always the same. If I turn it down any lower I might as well not bother to ever log in again because nothing will look like it is supposed to. Just a bunch of collapsed triangles until I am standing right on top of the object. So don't complain to me, complain to the creators who don't optimize their work. I do not have any issues with lag and never have had any issues with lag due to having my LOD set at 4 and it's has been that way for me since I have in SL, 17 years.

From that blog post:

Quote

In the new release of Firestorm (5.0.11), the viewer will warn you if you have unusually high settings, and settings that are considered too high for general use will revert to defaults after a restart. This is done in the hope of improving the overall user experience by encouraging more creators to design efficient, well-behaved content. In 5.0.11 the limit for "normal" use will be 4; this may reduce further in the future.

Mine is set at 4 and will stay there. It is what works for me. 

  • Like 1
Link to comment
Share on other sites

56 minutes ago, panterapolnocy said:

I have turned it down many times before on different computers with different OSes and graphics cards. It's always the same. If I turn it down any lower I might as well not bother to ever log in again because nothing will look like it is supposed to. Just a bunch of collapsed triangles until I am standing right on top of the object. So don't complain to me, complain to the creators who don't optimize their work. I do not have any issues with lag and never have had any issues with lag due to having my LOD set at 4 and it's has been that way for me since I have in SL, 17 years.

From that blog post:

In the new release of Firestorm (5.0.11), the viewer will warn you if you have unusually high settings, and settings that are considered too high for general use will revert to defaults after a restart. This is done in the hope of improving the overall user experience by encouraging more creators to design efficient, well-behaved content. In 5.0.11 the limit for "normal" use will be 4; this may reduce further in the future.

Mine is set at 4 and will stay there. It is what works for me. I have never set it higher and never will.

Link to comment
Share on other sites

58 minutes ago, panterapolnocy said:

Apparently the mods don't like my answer since they have hidden two posts so far. 

Hopefully they will at least allow me to say I have mine set at 4 and it will remain there because it works for me. I have never set it higher and never will.

Link to comment
Share on other sites

@panterapolnocy

I have turned it down many times before on different computers with different OSes and graphics cards. It's always the same. If I turn it down any lower I might as well not bother to ever log in again because nothing will look like it is supposed to. Just a bunch of collapsed triangles until I am standing right on top of the object. So don't complain to me, complain to the creators who don't optimize their work. I do not have any issues with lag and never have had any issues with lag due to having my LOD set at 4 and it's has been that way for me since I have in SL, 17 years.

From that blog post:


In the new release of Firestorm (5.0.11), the viewer will warn you if you have unusually high settings, and settings that are considered too high for general use will revert to defaults after a restart. This is done in the hope of improving the overall user experience by encouraging more creators to design efficient, well-behaved content. In 5.0.11 the limit for "normal" use will be 4; this may reduce further in the future.

Mine is set at 4 and will stay there. It is what works for me. I have never set it higher and never will.

 

*****Finally after the mods hid 3 posts that were not against any forum rules. I guess they don't like me quoting you.

Edited by Silent Mistwalker
Link to comment
Share on other sites

I'm going to risk doing a Jethro Tull here and ask what exactly is it in the picture that I'm supposed to look at and go "Oh that's a glitch" ? Is it the difference in the grassy texture on the two adjacent prims? If so, it's similar to the times I've spent trying to get textures to align seamlessly only to find that one of the two prims is rotated/profile-cut/path-cut differently with respect to the other and so needs a different set of texture parameters. Or when I've got the wrong set of parameters for the bump-maps.

If no, then put me out of my misery, what's the burning issue? I can't sleep until I know now.

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

TMMI

What is your elevation?  How thick are the ground prims? What is the exact elevation of each prim?  What are the prim rotation values?  What is your camera angle? 

If you gave out the LM, someone with Firestorm could also confirm or not, what you are seeing.

 

 

Edited by Jaylinbridges
Link to comment
Share on other sites

Are shadows turned on? The big dark patches on the grass don't appear to be coming from your structures. As @Janet Voxel has mentioned, a sky platform somewhere above yours may be casting it's shadow down on you. This happens when you turn your draw distance really high and end up rendering a far away sky platform.

The grass textures look mixed up too. Not sure if that's the glitch you mean.

I'd turn down all graphics settings off or low and if the problem is fixed then slowly raise your graphics settings until you see the problem again. I agree that you don't need high LOD all the time or such a large draw distance.

Link to comment
Share on other sites

I see something like this effect when I have two parallel prims with different textures too close to each other, and I back off the camera distance and observe the prims at a steeper angle.  The prims are so close together that the viewer is having trouble deciding which prim is on top.  This is a old effect, which I think is related to not enough precision in the z-values for making accurate calculations at a distance and at certain camera angles.  The mixing pattern also changes depending on the angle and rotation of the camera around the two conflicting prims.  Both prims are parallel to each other, but only to the degree of precision possible in the LL calculations.  That is why I asked my questions earlier.  It would be helpful if you stated what the problem is though, since some are still guessing with no other information.

To avoid the mixing of the two prim textures, the solution is just separate the prims more.  Move the elevation of the top prim in 0.005 meter increments until the viewer is no longer giving inaccurate results.  The thickness of the top prim can be 0.01 or 0.02 m thick.

 

Edited by Jaylinbridges
Link to comment
Share on other sites

Quote

Alpha blending

Alpha blending is a technique commonly used to “blend” multiple semi-transparent polygons (or in Second Life’s context, “faces”) to resemble real-world semi-transparent surfaces. The rendering of alpha blended objects is not trivial, and puts more stress on the rendering pipeline to:

  1. Reorder the order of which every single semi-transparent object in the world gets rendered
  2. Render each face in back to front ordering
  3. Blend each rendered face with the previously rendered face

There are also a number of problems that semi-transparent objects cause on the hardware, such as not being able to discard fragments (or “potential” pixels) that are blocked from view before the renderer attempts to render them due to the nature of alpha blending. It’s also difficult to apply per-pixel lighting to these surfaces within the lighting & shadows renderer, instead requiring workarounds to apply the correct lighting to these surfaces.

As such, alpha blending should be used very sparingly, and avoided wherever possible.

Alpha masking

Alpha masking (or alpha testing for those of you familiar with the more technical term!) is a technique wherein each pixel in a texture map is “tested” for if it’s above a specific threshold or not. If the test passes, then that pixel is rendered as if it were fully opaque. If the test fails, then that pixel is discarded, or otherwise considered to be fully transparent.

Alpha masking allows us to take advantages of many of the optimization techniques available to us on most graphics hardware, and these surfaces can receive full lighting and shadows with no need for any workarounds. They perform very well, but at the cost of having much sharper edges where pixels are transparent. Since alpha masking relies on a simple test for if a pixel’s alpha channel falls above or below a given value, varying transparency values are not possible with this technique.

Alpha masking is also not subject to many of the flaws of alpha blending, such as different sorting errors that can arise due to overlapping faces and objects. It’s handled much like any other opaque surface, either the pixel is opaque, or it’s not; there is no inbetween.

So which should I use?

Although alpha masking may be much faster than alpha blending, you must consider how badly your surface needs varying transparency values. If you can make due with a surface that has sections that are either fully opaque or fully transparent, then always opt for alpha masking. If you can’t live without varying transparency values, then opt (very sparingly) for alpha blending.

Remember, your choice can have a significant impact on performance and quality of your content!

 

http://wiki.secondlife.com/wiki/Alpha_Modes_Do's_and_Don'ts

Link to comment
Share on other sites

The OP did take pains to state none of the prims used alpha-blending or alpha-masking.

I still think the best suggestion (JaylinBridges) is of other people TP-ing there to see if different Firestorm settings, or better still different viewers, might give a new insight into the issue.

Edited by Profaitchikenz Haiku
  • Like 1
Link to comment
Share on other sites

On 11/18/2021 at 9:35 PM, Draconis Ahren said:

okay this still doesn't answer if there's a fix for this, or if it's Firestorm's problem with the rendering

 

The fixes are - turn your draw distance to 128 or lower, turn LOD back to the default  2 instead of 4 and turn shadows off unless you are in the process of capturing a high-quality screenshot. This isn't a Firestorm bug, this is a "hardware can't handle the strain" issue.

If you need to use LOD 4 because the meshes are distorting at 2, that's because the meshes you are using are poorly made and need sending to trash. Buy better mesh and go back to LOD 2.

Edited by Maitimo
  • Like 1
Link to comment
Share on other sites

Like others, it is not clear to me what the problem the OP is reporting actually is,  there are a few anomalies to choose from none of which seem particularly unusual. The most likely one I see is the mismatched texturing but that may be intended. 

"These are two prim objects" immediately makes the discussion of LOD Factor somewhat moot, for while there is LOD behaviour in prims the behaviour is well defined and largely volume maintaining, features which good Mesh should aspire to.

Along with reducing DD and other general good practice, I would check how close to one another the two objects are that are problematic, there are well-documented issues with Second Life accuracy at altitude due to the rounding of numbers that occurs. Checking if this happens lower to the ground should be a part of any fault finding excursion. Certainly , as others have said, have some friends verify what you are seeing, is it just you, something about your settings or hardware or does everyone see it? Make sure to mix NVidia users with AMD users and see if you can determine a pattern. If there is a pattern (and that you haven't simply got the prim surfaces too  close, and altitude occlusion fighting happening) then it may well be worthy of a JIRA. https://jira.firestormviewer.org. for good measure, always check whether the same or similar happens on other viewer, in particular the LL viewer if so throw them a Jira too. 

 

OK deep breath..as we continue to hijack the OPs thread.

And so to the recurring LODFactor discussion...

I don't have much more to say on the LOD Factor argument. We clamped the setting back in 2018 to curtail the worst behaviours of lazy and ill-informed merchants, whilst not breaking things utterly for those who wish to take photographs and have to deal with the poor quality assets in the scene in some fashion. 

Meanwhile, those that ascribe to the "LOD 4 never did me no harm" are essentially missing the point (you may be justified in the observations, more on that later); at this stage a decade since we saw mesh introduced to SL, you really should not need to have your LOD high because there is no good reason for a creator to blame the viewer or SL for the crumpled garbage they sold you. There are many tutorials out there on what makes a good asset for real-time 3D engines, no credible creator can plead ignorance to this (and remain credible). Amateur and developing creators, of course, are still finding their way, the beauty of SL is in the democratisation of creativity, but at the same time, the keen amateur is not going to be the one flooding the market with poor assets, they are likely the only person ever to see what they make. It is the "big" commercial producers to which that blog was addressed and in particular those who excused their laziness by expecting you and your machine to work harder (and frequently slower) while they get busy on next month's product. 

Think before you buy. All the time people continue to buy sub-standard assets, other people will continue to make them (secretly laughing at you too I bet). 

The original reason for LODFactor hackery was to address the tendency of sculpties to explode into mangled triangles at the slightest distance, and since there were very limited means by which a lower LOD of any "volume maintaining"  substance could be presented, allowing people to force them to render at full detail for longer made sense. 

However....

We stand at an interesting juncture, which may pitch this discussion into new realms. There is a lot of work going on at the moment to improve the rendering speed of the viewer (I am about to post a new blog, inspired by this thread and some recent news) discussing some of the implications of the advances we are beginning to see. 

At the moment, the vast majority of us are CPU bound in SecondLife. If you have a dedicated GPU and it is of NVidia GTX 970/GTX980 or above quality, then the chances are that it rarely gets pushed to its limits. In many cases it will be pretty much idling while your poor CPU is choking to death on sliced and diced mesh bodies.

This may well change and with it will change the impact of LOD Factor.

Read my blog for the details (or not) but for now let's assume that a magic wand is being waved that could, for many of us, remove that CPU bottleneck to some extent and thus start to make those GPUs we paid so much for earn their keep.

It is here, on the GPU, that high LOD and dense mesh brings bad news. Your screen is made up of a finite number of pixels, and each of those can be just one colour at a time. When the viewer is sending stuff to be drawn it tries to optimise things so that we ideally only draw any given pixel once. Life is not ideal though and there is always some element of what is called "over draw" where pixels get drawn then redrawn. Every redraw is wasted time. Now... if you are sending a high triangle dense mesh through to the GPU to be drawn even though the item is just a small cluster of pixels on the screen then you can be certain significant overdraw time wastage is occurring, at some point the positions will switch around and we'll have the CPU twiddling its bits waiting for the GPU to "get on with its job already" as the GPU adds the 20th coat of pixel paint to the overdraw canvas. Some overdraw is inevitable, but Highly dense mesh, and high LOD factor (keeping dense mesh around when a simpler one would suffice) will add to the delays, slowing the GPU, and increasing the data that has to shuffle back and forth between the GPU and CPU etc.

I would argue quite strongly that LOD as we have it today is problematic. There are those that will argue the we should be slaves to the original Linden Viewer default LOD Factor and not the higher Firestorm default; I don't honestly believe that is the right discussion or the right argument to be having at all (it is rather moot at this stage). With screen resolution growing (and in some cases the physical dimensions too) the potential resolution/quality of a middle distance object is higher than it used to be, and while I could argue that this is a case for reviewing the default LOD Factors, the reality is that LOD factor based on virtual distance and scale is not the right solution, it probably never was. The entire LOD swap algorithm should be replaced with one that is based on the on screen scale and resolution of an object, thus adapting to the individual's machine and circumstances and by turn removing this arcane LODFactor lever once and for all.

So TL;DR summary....

Right now...LOD Factor is probably not affecting you too much, why? Because you are already hamstrung by other issues that dwarf that impact. As we pick off those issues, (and it is happening) this problem will return to bite us hard in a many-segmented densely triangulated arses. All that said, I might argue that it will be a nice problem to have. I long for the day when someone is complaining that they only get 50FPS in a nightclub 😄

  • Like 3
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 948 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...