As others said, are you sure that you need to visualize that many points interactively? Does that picture really tell you more than what you could see in data that has been reduced in some way?

However, if you really need many points, then it is generally a good idea to construct your own graphics objects with as few primitives as you can. Plotting functions are more flexible and make it easier to make the plot pretty. But won't perform as well.

Thus with

pts = RandomVariate[NormalDistribution[], {500000, 3}];

the following may perform better:

 Graphics3D[{AbsolutePointSize[1], Point[pts]}]

than any of the following two:

Graphics3D[{AbsolutePointSize[1], Point /@ pts}]
ListPointPlot3D[pts]

This is just a general performance tip, not a full solution to your problem. The key is to put all coordinates in a single graphics primitive (Point, Line, etc.), when supported.

Jim,

Thanks for your reply. I understand your argument. Trying to easily visualize the half-a-million points simply came up as something that would be helpful, and is really the tip of the iceberg.

The data do not quite represent a random process. They are the results of calculations of the behavior of a system using many different inputs for the starting conditions. The code I included in my post was really and example of a similar set of points. If our calculations really produced random results, then we would have a serious problem. In a sense, the details of the data generating process is not completely known (it is inside a complex code).

Questions come up when the surface has wiggles that do not seem real, or when the calculation of the system behavior seems to yield unreasonable low or high values for specific input values. As I said, I can get by with using the min's and max's in some bins, but the possibility of pushing the limit of the graphic interface seemed worth exploring.

There is nothing special for my problem about half-a-million. In some analyses a have significantly fewer points, in others, significantly more. Half-a-million seemed to be the point where the graph, the way I produce it, becomes too slow for interactive use. I thought there could be ways to push that limit. Thinking of RAM and CPU (at the current levels) half-a-million points does not seem like a whole lot. I think the key is the speed of interactively updating the rendering (user input, kernel, graphics card, display). But I am no expert in these matters, so I could be wrong. I can say that I have noticed the following about the speed of displaying an output:

1. If one produces a very large textual output (a large matrix, or text, etc.), then Mathematica will be finished with the calculation long before the result is printed to the screen (of course, normally I do not print those to the screen).

2. If one produces a 2D ListPlot with many data points (say ~15000), even if it is only one dataset, then using PlotMarkers->Automatic delays the display and even produces that dialog window that says that a very large output was produced and displays a part of it (although it displays the entire graph). The cause seems to be that with PlotMarkers->Automatic, Mathematica uses a different set of markers (they look slightly larger) than when no option is given.

In any event, it is clear that the ability to interactively rotate a graph must break at some point. I just thought that with a little more inside knowledge that limit could be pushed.

Thanks,

OL.

Thanks to all that have responded. If you notice, I am trying to see just points ({x,y,z} triples), not extended objects. In my understanding that should be faster than trying to render the same amount of any extended objects that take more information than points, but that it only intuition; I am no expert in graphics algorithms.

You can see something similar to what I want to rotate if you just run the code I included in the original posting using n=1000. In my case, I need something closer to n=500000 (half a million). I tried the table of pyramids. It took a little while to produce, but rotated OK. My list of 50000 points also rotates more or less OK, it is with half a million points that it won't rotate (takes about 19 sec. to create).

It is true that the half a million points form a dense cloud, but in my case I still should be able to see the surface because in reality, my surface is slightly below the cloud. Also my real surface has a little bit of ups and downs (it is not really flat) and I want to be able to judge visually how well these ups and downs correspond to the surface. I think my real cloud of points has a pretty sharply defined envelop.

I think the idea of creating bins (using, say, a 70 by 70 evenly spaced mesh) and taking the min and max in each bin can give me a good idea of what I am trying to see. Being able to see the whole thing would be nicer.

I am using Mathematica 11.0.0 Student edition on an hp Pavilion (64 bit) running ubuntu 15.10. It runs two cpu cores (I think it is an AMD i5 processor). I get similar results at work though, using version 9 on a different machine (also on Linux).

Thanks,

OL.

Even if you could smoothly rotate, or zoom, on a plot with 500,000 points it seems to me that the plot would be so dense that it would be difficult to extract information from it. One wouldn't even be able to see the surface. And what, precisely, is the information that should be extracted?

One technique in a case like this is to use multiple plots, or better multiple presentations in a dynamic display. One thing you could do is to take smaller random samples of the 500,000 points and display those. (Like 10000 points.) If you are interested in detailed behavior around some particular {x,y} position you could just select all points in a small domain and display those, effectively zooming in. You could have an overall plot, with a random sample of the data, and a zoomed plot next to it with the domain size and location controlled by sliders. You could use a Button to generate new random samples.

You have only a limited number of pixels available. But multiple presentations can do wonders.