Rhino Pointcloud Import Not Working as Expected

@dale, @stevebaer,

The first time I import a 9.5 GB Pointcloud in PLY format that contains points, normals, colors and intensities I get the following:

This has many points missing in the lower right. When I check properties, it says the cloud has 227,252,794 pts which is correct.

If I leave this on the screen and do the import again, then I get the expected result (the cloud above was hidden when capturing this picture):

If I unhide everything and select everything, Rhino says there are 2 pointclouds which is expected. When I check the properties of the bigger pointcloud, it again says correctly that there are 227,252,794 pts.

If I undo both imports and start again, the same thing happens again.

What is happening? There is less memory available for the second import and yet more of the cloud is displayed. Mind you, my computer is not running out of memory as I have 128 GB and the peak memory usage during the imports is 40 GB and 22.8 GB after the imports are done and no significant other programs are running:

If I import a cloud half this size this does not happen. If I import a version of the full-sized cloud without Normals and Intensity this does not happen.

If I use a Python/C++ script to import the full cloud the same thing happens in terms of what is displayed. But after importing the cloud a second time and selecting everything, Rhino says there is only 1 cloud. If I do one Undo once, I see the first partial cloud.

If I import smaller clouds twice, then both copies show up and are complete for both imports.

Very strange.

A display issue? But then why does the second import work as expected when the first import is still displayed?

The 9 GB cloud file is available here:

Sorry the cloud is so big but this issues only shows up with large clouds.


How much memory do you have on you GPU? A copy of the cloud data needs to reside there.

I won’t be able to really test this as I don’t have that big of a computer at my disposal during the days of covid


Thanks for your response.

I have 2 display adapters in my machine:
Nvidia GT 730 with 2.147 GB of display memory
Nvidia GTX 1080 ti with 11 GB of display memory

The result is the same with both cards.
The first import shows a partial cloud.
The second import shows the whole cloud.

The Windows Task Manager → Processes window shows Rhino using twice as much memory after the second import.

The cloud has 227,252,794 points of Points, Normals, Colors, Intensity which require 60 bytes per point or 13.635 GB. All this data is stored in the DRAM and its usage can be monitored in the Processes window.

I do not believe the graphics card needs as much memory as the object being displayed. My 4K monitor displays what is in a 8.3 MB frame buffer. Filling the frame buffer can be done from memory on the card or DRAM in the computer. For games, keeping all the graphics related data in the nearer, faster on-card VRAM is a better choice if you need a fast frame rate. But Rhino is not a high frame-rate game. Does Rhino try to duplicate all the cloud data in the VRAM in order to manipulate it for display? If so then why is the display behavior the same on both my little and big display cards?

Very strange.

Maybe the drivers need updating?


All of the points are stored both in main memory and in gpu memory (as floats with a single transform). We don’t stream arrays to the gpu anymore as that is not really what you do with modern OpenGL.


So how much memory would this large pointcloud consume in GPU memory?
Would the bytes for its point of X,Y,Z,Nx,Ny,Nz,R,G,B,I be counted as
4X, 4Y, 4Z, 4Nx, 4Ny, 4Nz, 4 for 32-bit color, 4I = 32 bytes per point
or 7.272 GB for the 227,252,794 points?

I watched the GPU memory usage (shown below) while the cloud was imported. It started at 0.727 GB and went to 7.9 GB when finished. The difference, 7.2 GB is about what I computed above. The interesting thing is when I do the import again, the usage only went up to 8.67 GB even though now there are 2 clouds in the display, the somewhat smaller initial cloud and the larger second cloud.


So the data seems to be fitting in the 11GB GPU VRAM. (As an aside: From the memory usage graph, I can see it takes about 2 sec to copy the 7.2 GB of data to the VRAM or about 3.6 GB/sec which is competitive with what I get using single-threaded memcpy in my C++ code.)

The import of this cloud could work on a computer with only 64 GB but maybe even 32 GB if this helps you find a machine for testing.

Very strange. It doesn’t fit but it does fit. It seems like something is going wrong with the buffering/copying to the GPU memory. The data is in the Rhino Document but only part of it is displayed after the first import. Then after the 2nd import, the rest of the data is sent to the GPU. Notice that sending the 2nd batch of data is slower, taking about 4 sec. Is this because it is comparing to what is already in the VRAM before it writes in the remaining data?

I did another check. If I drop the normals and intensities, then 16 B/pt are sent to the VRAM or 3.64 GB and all the points are displayed. If I add back the intensities, 20 B/pt are needed or 4.45 GB and not all the points are displayed (until a second import is done). So it seems like something under 4 GB can be sent to the VRAM. This is very close to the limit of uint32_t. I do not know how the data is packaged when it is sent to the VRAM but perhaps an array limit is causing the problem. Even if this were the case, it is hard to explain how a second import of the data results in all the points being displayed.


I wanted to test this on my RTX A6000 (48GB VRAM), but I think I’m not properly able to load it in Rhino, since I’ve got only 16GB RAM of system memory

Without further knowing the code involved your 4GB theory sounds plausible, though.

You’re assuming that GPU OpenGL drivers make sense. :slight_smile: There’s a possibility that the driver noticed it couldn’t fit everything in a linear array with the first cloud and then switched to some other technique for the second. Who knows.

Probably the best thing I can do is attempt to chunk massive clouds into a small number of OpenGL vertex buffers and draw multiple vertex buffers for a single cloud. This would give you the same visual effect and performance, but remove the requirement for such a massive array on the driver.


I am getting requests from the Lidar scanning community about importing their large clouds into Rhino. So far I have provided them a script that decimates the clouds to enable reviewing it. This will work for clouds with 30 billion points (assuming a maximum file size of 1TB for the cloud on a drive). But it does not allow viewing the full cloud. According to Steve’s comment, the Rhino limit is set by the size of the VRAM on the GPU card. But now I have found a lower limit of 4GB due to the way data is transferred to the VRAM. If this could be fixed and I only use a cloud with points and colors, then a cloud with 600 Mpts which takes up 9.6GB of memory, could be viewed with my Nvidia GTX 1080 ti GPU. This is over 2X the current limit. Also the Nvidia RTX 3090 has 24 GB of VRAM, enabling the display of clouds with 1.25 billion colored points. This is 5X the limit imposed by the transfer bottleneck.

Rhino can already do a lot. When I import my cloud twice to get all of it displayed with it taking up almost 9 GB of VRAM memory, Rhino can still reasonably rotate the view while showing the entire cloud. So bigger clouds could still be OK from a performance standpoint.

So I am hoping the current limit can be improved so that we can get more of the Lidar scanning community interested in using Rhino. I am providing them with a very fast cloud import script which takes only 9 sec to import the 9 GB cloud in PLY format with 227,252,794 points and which can decimate the cloud on the way in so very large clouds can be reviewed.

I am retired and have no commercial interest in my work. So all my scripts are free. But I want to do useful things and helping the Lidar group, which might also improve Rhino business, is so much fun.



That sounds interesting.

And will this approach scale to handle the 24 GB of VRAM in the RTX 3090? If so then we could view, for the first time, a billion+ point cloud in Rhino. As a single cloud I mean.


It depends on the driver. I would just be reducing the memory requirements for massive contiguous arrays. What the driver decides to do with this would remain unknown until we try.


I did another experiment. I imported the same 227,252,794 point cloud 3 times. So now 3 x 7.272 GB (as computed in my earlier post following your guidelines) of cloud data has been transferred to the VRAM but the amount of memory in use hardly changed; it went from 8.6 to 9.1 GB and then dropped back to 8.7 GB after a few minutes.

Rhino still rotates the view with small lag. Here is the other side of the Lidar scan of these buildings:

I tried loading a 4th copy and was able to see it in the view, but once I moved it, around Rhino basically came to a halt. So 3 work reasonably. That’s 681Mpts total in the 3 clouds. Pretty good. More than half way to a billion points. And the almost working 4-cloud experiment has 0.909 billion points.

Steve, working on improving the display of large point clouds should not be considered critical or high priority as, so far, only a few in the Lidar group have shown an interest. This is an interesting, isolated problem that requires a large machine for testing so I would expect it to be some time before it can be addressed.


Yep, I just made a feature request for this as a reminder of something to work on in the future

The best is yet to come. With your good work, it will happen sooner.

I will leave the large pointcloud on my Google Drive (link posted above) for the next couple of years so it can be used in your investigations.


This is still happening in Rhino 7 and it makes working with large point clouds difficult to impossible.

If there are any solutions out there, it would be great to hear about them!

Hi @Daniel_Innes,

What is still happening? This is a 3 year old thread - you’ll need to provide details.


– Dale

Hi Dale,

The issue is that large point clouds (I tried one 38Gb .e57) fail to import in their entirety. I found the import command finishes but I am getting rectangular holes in the loaded point cloud similar to Terry’s first image, assumingly due to insufficient memory for the size of point cloud.

Based on other threads, the workaround seems to be making the point cloud smaller by either decimating it or cutting it into chunks:

I would be keen to know about any updates or other approaches.

Thank you,

Hi @Daniel_Innes,

I am able to load all these in Rhino 7 for Windows.


Would you care to share your file? You can send it to me via our file upload system.


Send to dale@mcneel.com

Also, can you run Rhino’s SystemInfo command and post the results?


— Dale

Hi @dale,

Unfortunately I’m unable to send the file as it’s confidential. I can tell you the one I’m trying at the moment is a railway scan, spanning between XYZ 1811140, 5454847, 67 and 1812237, 5455839, 77; 11.7Gb total.

Sometimes reimporting the cloud with the first (failed) scan loaded will succeed as Terry suggested. This is the workaround I’m relying on now.

Here’s the system info as requested:
SystemInfo.txt (3.4 KB)

That is not the output generated by the Rhino command _SystemInfo. Please run type in Rhino _SystemInfo, then save the text generated by that and share that instead.