Distorted Sculpt

Right, so here is what I got after repeating the same loose experiment as last evening: I turned off everything in Advanced > Rendering > Types with the exception of 'Simple' and 'Volume' and activated 'Wireframe' to get a wireframe view of my sculpted window and the prim version in a void at 1,500 metres.

Note: The prim version consists of 13 box primitives. The sculpted version consists of two sculpt meshes, one of which is duplicated.

The readings for KTris Drawn on both versions were 8.3 per frame and between 740-755 per second.

After deleting the prim version, KTris Drawn dropped to 7.5 per frame and between 704-714 per second.

After deleting the sculpted version, KTris Drawn dropped to 1.3 per frame and between 129-130 per second.

I have no idea what those residual rates are about but it would appear that the sculpted window is roughly six times more 'expensive' to render than the prim version.

Bugger. What am I going to do now? Double glazing?

I just made a similar experiment to find out whats up here. I found slightly different and more consistent values though. So here is what i did:

1.) I removed all rendering options except simple and volume
2.) I repositioned my camera so that no objects are in view
3.) I found a residual rate of 0/sec and 0/frame.
4.) I added a simple cube. Now the Ktris value raises to about ~ 13.2/sec.
5.) The KTris per frame is 0.1. this sounds correct (108 tris are there)
6.) As long as a fraction of the cube is visible, Ktris/s and Ktris/f keep almost constant
7.) As soon as the cube gets completely out of sight, the rates drops to 0

So let me guess...

It looks like the number of Tris "drawn" is independent from the number of Tris "seen". It is always the total number of Tris from all objects which are currently laying at least partially in the camera focus. I do not see any culling here (hidden Tris are still counted). But i see LOD effects (when moving away from an object, the number opf Tris goes down as expected)


Some tet cases
==========

1.) Prim cube tests (A Prim cube has got 6*18 = 108 tris)

The Ktris/s rate is 13.2 k/sec on my system.
The Ktris/f rate is 0.1 (consistent with 108 Tris on the Cube ...)

I expect my frame rate to be: 13200[Ktris/s] / 108[Ktris/f] = 122 [f/sec]
This is fully consistent with the Framerate indicated in the viewer statistic bar


2.) Sculptie tests (A sculptie has 2048 Tris)

Now i see 244 Ktris/sec and 2.2 Ktris/f

Let's recalculate: 244000[Ktris/s] / 2200[Ktris/f] = 111[f/sec]
This is fully consistent with the Framerate indicated in the viewer statistic bar

3.) Object behind Object culling Tests

I added a secnd object and hided it completely behind the first one. ouch. No culling. All Tris get drawn as soon as they get into the camera focus independent from their visibility

4.) Many sculpties test

I created 72 sculpties and placed them all inside each other. now:

5950 Ktris/sec, 147.6 Ktris per frame -> 1683/147.6 = 40 fps

5.) Many Prims test

I created 72 cubes and placed them inside each other:

750 Ktris/sec, 7.9 KTRis/frame -> 95 fps

conclusions
=======

- The fact that on my system the fps does not drop significantly when i switch from cube to sculptie is maybe because the cube is so simple to draw, that the graphic card has decided to keep cool and not increase the framerate to 1000 fps or so or maybe it just can not go beyond 120 fps ? Or 120 fps is an upper limit, which does not make sense to be further increased ? Or there may be a property in the SL viewer, which limits the fps to 120 max...

on the other hand increasing number of sculpties "at one place" reduces the frame rate significantly. So do we have a lag caused by sculpties here ? I am not sure how to interpret the test results above, but the framerate drops seen in the tests 4 and 5 are making me a bit nervous... Any comments ?

Interesting numbers. But you haven't told us the Ktris/frame, which should be there as well as the Ktris/second. As far as I have seen, the Ktris/frame is much more constant, I suppose Ktris/second should be Ktris/frame * frames/second as long as rendering is the frame rate bottleneck. but it might not always be. I didn't check that.

I am surprised if you didn't see frame rate change when you zoomed out, as I certainly saw the Ktris/frame reduce to 1/4 on the first LOD step for my sculpty.

That's interesting. The Ktris/second seems to have dropped in parallel with the KTris/frame, certainly suggesting that something else is limiting the frame rate in these conditions.
Not sure we know enough yet. Certainly your sculpty version seems to be far more triangles, but until you have enough there to see it limiting the frame rate, that conclusion still depends on the assumption that the renedring time is proportional to the number of triangles, irrespective of their sizes/properties. We don't seem to have evidence for that assumption yet.

Exactly.

Processing each frame involves a lot more than rendering. In the SL client, virtually all the processing is synchronized with the frame. If you are rendering very little geometry (such as in Gaia's most recent report), your graphics card is probably idling most of the time, and when when it has work to do, it's mostly on rendering the UI. If you want to see what makes up the time for each frame, enable Advanced/Consoles/Frame Console. The light gray (RenderGeom) corresponds to the time spent rendering object triangles. If you've turned off most rendering options and are looking at only a few objects, that's likely to represent only a few percent of the total frame time. There'll be a much larger chunk of time spent rendering the UI, but most of the processing won't have anything to do with the graphics card.

If the question being asked is the rendering hit of sculpties vs traditional prims, I think the experiments should be done with lots of copies of each, so that the geometry rendering is a large percentage of the total frame time. This is what Drongle did in his test, but he didn't report frame times. (The question he was asking was not about overall performance, but whether degenerate triangles were getting removed before the tri stats were computed.)

I performed an experiment which seems to say that (on my machine) there is very little performance difference between degenerate and non-degenerate tris.

What I did was this:

* Created and imported two sculpty bitmaps, one with 31x31x2 non-degenerate tris, the other with only 2 non-degenerate tris.

* Created a single prim with a simple script that listens on chat channel 100 for a UUID, and uses that UUID as the sculpty bitmap.

* Moved the prim up to the sky and duplicated it multiple tims until I had 992 copies, all at least partially visible.

* Turned off all the rendering but Simple and Volume and brought up the Statics window.

Zooming in and out to change LOD, I could control the number of tris drawn, and it was always the same for both sculpt maps, as expected given Drongle's results. However, to my surprise, the frame rate was essentially the same for both scultp maps, as well. For example, with 507.4 ktris per frame being drawn, the typical frame rate was 18.0 fps for the mostly degenerate case vs 18.1 fps for the other. At lower LOD and 126.8 ktris per frame, the frame rates were 38.6 fps for the mostly degenerate case vs 37.5 fps for the other.

For all I know, the results could be very different for differernt hardware. (My machine has a relatively high-powered CPU, but a low-powered graphics adapter.) If anyone wants to replicate this test on their machine, IM me and I'll drop the collection of 992 prims on you next time I'm in-world. To change the sculpt map between the two textures I was using, use the commands

/100 c06b4112-af4d-7468-2e8d-b6f1cc9ccb05

for the mostly degenerate case and

/100 7fc68256-c42f-801e-2e91-56009b012d3c

for the mostly non-degenerate case.

That was my mistake. I see LOD effects, so the Ktris rate gets lower when i go away from the object. I should have better written this:


1.) It looks like the number of meshes "drawn" is independent from the number of Tris "seen". It is always the total number of Tris rendered for all objects which are currently at least partial in the camera focus.

2.) I have updated my post #52 from earlier this day. Now i include some more claculations there and i also published the Ktris/frame values.


I hope that helps others to understand/interpret what goes on. I lost the track

I repeated Omei's experiment. With normal rendering, I got qualitatively similar results: KTris*fps = KTris/sec in all cases. At 507.8 Ktris, fps was 55 for the non-degenerate and 61 for the mostly degenerate cases. So again there is little difference. Note that 507.8 = 992*2048/4, so this is the second LOD step*. Had to zoom out to that to get them all in view. Zooming in I could get 1400 Ktris, seeing only s segment of the sculpty array. (There was a strange effect. The fps flipped betwen two rates, four-fold different. I don't understabnd that.)

I also did the experiment in wireframe mode, and the results were very different. The mostly degenerate case (33fps) was about 5 times higher fps than the non degenerate case (5.7 fps), but that is because it has to draw very many less wireframe lines. So the wireframe results are misleading and should not be used for these investigations.

*Also evident from the subsequent steps, 1/4 then 9/16 (lod steps are 32x32, 16x16, 8x8, 6x6).

I did the same experiment again with 240 copies of four sculpties (one at a time!). All rendering off except simple & volume, not wireframe, 2000m+. The 240 copies were non-overlapping and all in view. All were 5x257 vertex maps in a 8x512 bitmap. First a set that all looked the same, a simple square section tyube, but made very differently. (1) 256 square sections all along - 2048 non-degenerate triangles. (2) The whole tube in one section with the remaining vertices spaced along a straight line - about 12 non-degenerate triangles and the remainder all with two zero dimensions and one non-zero. (3) Same as 2, but now all the remaining vertices in one point - 12 non-degenerate and the remainder with all dimensions zero. Lastly, (4) my 128 tetrahedron sculpty - 512 non-degenerate triangles, remainder a combination of the two degenerate types.

The results are quite boring. Basically, they all beheved the same, indicating only a small difference in the resource consumption for degenerate and non-degenerate triangles. At highest LOD there were 491.6 Ktris, and frame rates were 42 (1) to 47 (4). However, I did notice a couple of unexpected things...

As reported before, all except (2) exhibited occasional flips to a four-fold lower frame rate, and then flipped back again. I could not discerne anything that was causing this (zooming, panning etc.). I can't say that (2) doesn't do the same, only that it didn't while I was observing it.

I had forgotten that (4) had shiny turned on. It appears that the consequence of this is (that the statistics reports) twice the expected number of triangles. I guess it renders a shine triangle over each normal one? Fortunately, this reverts when you turn Rendering|Bumps off (Why?).

The conclusion seems to be that there are only small effects of passing degenerate triangles to opengl. It is possible that is why the degenerate triangle culling code seems not to be called. Perhaps they found that the culling slowed things down more than any gain from the shorter queues.

In the flexi-sculpty jira, I saw stuff about cacheing sculpt maps and/or vertices being needed to make the performance hit acceptable.If they could cache triangle lists instead, then maybe the culling would be worthwhile?

I was also struck by the fact that rendering 240 complex sculpties at the highest LOD left me with a frame rate better than I ever get anywhere in normal SL. To me this says that sculpties are no where near as responsible for client lag as many people seem to think......until they release the flexi ones that is!