CloudCompare forum

I've a White cloud and I've run PCV AO. The output is amazing, certainly feels like lightmaped from skylight.

The issue I've is that the dataset is divided into multiple chunks. If I compute 2 nearby chunks the AO is not seamless, in fact there is an impresive sean.

One chunk, for sean reference:
https://1drv.ms/i/s!AuliwwO_siw1ikPqc41Qk2zrL6p6

The nearby chunk with AO and visible seam, far
https://1drv.ms/i/s!AuliwwO_siw1ikSABuIqJaVzXI4D

Close up
https://1drv.ms/i/s!AuliwwO_siw1ikXp641cBTgPqGR9

The two chunks merged and recomputed AO. No seams betwen former chunks.
https://1drv.ms/i/s!AuliwwO_siw1ika0hoU6aa_ePGtW

I asume, since I can not select multiple clouds and click PCV AO option by doing individually it does not take into account nearby clouds. Any change I can make so without merging nearby clouds can be taken into consideration?

I did a test prior to this partial chunk AO computing by merging the whole cloud and runing AO, but IT had no much quality, later on I saw the resolution field. the thing is that it is very difficult to guess for the merged cloud what resolution should it target, and I asume it would take extremelly long. for a large cloud should I also increase the ray count or just the resolution? What would be the max recommended resolution?.

May be it would be desirable more generic value such a texels/m so you could tune up the desired resolution with an small chunk in texels/m and translate that resolution to the much bigger cloud.

So hope there is a trick for AO a cloud in chunks and if not please suggest me how to AO a big cloud without collapsing the PC :D

Talking of this topic with a person actually he had a great idea.

He told me that is a shame that it can not compute a selection considering a bigger bounday and actually what would make the pluging very scalable IMO would be a behaviour that tiles the exiting big point cloud into regions like n columns and m rows. Or simply squares . So the points that fall withing would have computed the AO but considering points in a larger boundary, like 30% bigger tan original box, after computing the AO that fall outside the original boundary is discarded and next cell computing starts. This would allow for big cloud AO and also Quality settings could be fine tuned as all cells would have same size and the output quality would be uniform.

Would the person you talked with be able to update the plugin in the way he/she described it? CloudCompare is an open-source tool so that anyone can improve its tools :D

The real problem in your case is that the 'sun' position (the source of all the light rays) depends on the selected cloud extents. Basically it is centered on the cloud (in the XY plane).This is how the ShadeVis algorithm currently works.

If you provide multiple clouds separately, they are all 'enlighted' with a different sun position, and this is also contributes to the seams that appear at the borders. And if you provide all the clouds at the same time (by merging them, but it would be the same if you could provide them as separate clouds) then:
- you should indeed increase the resolution and the number of rays to get the same amount of information per point as with a smaller cloud
- there will be only one sun light position (which is good, but the clouds far from the center will get potentially more shadows, therefore they may have less contrast as if they were 'enlighted' from above - at least the result will be different)

Regarding the 'resolution' parameter, this is due to how the 'ShadeVis' algorithm works... maybe the user could specify a pixel size instead (in the cloud coordinate units). I'll see what I can do.

I see...
The person I talked too does not know much (if any) of coding in CC :/. I wish I did but I'm much more of an artist.

TX I do now I understand what is going on..

In a case where data is chunked in equal sized pieces for output uniformity, what could be constant could be the dome. Like custom seted bounds and center position of the dome. As dome would be considerably bigger than cloud to be procesed (multiple chunks) may be would be neccesary to increase ray number but I think could work.

In plugin editor a checkbox that says "use custom dome" and fields for
center XYZ and a diameter/radius field.

I just had an idea to prove the common dome aproach could work :D

I'll create a helper cloud in .xyz format with 4 points in it. 4 points representing the corners of the complete cloud, up left up right... so I'll import a 2 clouds that are side by side and import twice the helper 2 point cloud, merge helper cloud with each of the nearby clouds and process the AO. There should be almost no seam, and the very Little seam that could occur should be due to some minimal z difference, but I bet will be unnoticeable if any.

OK did the testing... didnt work ...

two clouds and the outer box, later on to be merged
https://1drv.ms/i/s!AuliwwO_siw1iklU6xiF79ctK2Px

much lower resolution than without boundaries so the dome is much bigger.
https://1drv.ms/i/s!AuliwwO_siw1ikq_YlWfZZ-3xrLU

But even it is considering a much bigger dome there is a mega seam I was not especting that :º
https://1drv.ms/i/s!AuliwwO_siw1ikudQQK6iO9wIiK7

For comparison, same chunk with and without outer points, same AO settings, 512rays, 4096 resolution (max)
https://1drv.ms/i/s!AuliwwO_siw1ikyQAgL6rWwmgX97
https://1drv.ms/i/s!AuliwwO_siw1ik0hJrgSuYubQxsR

A lot of detail is loss.

I'm out of ideas so far :D

May be a planar sky? dunno...

What is the height of the ground? Because there are rays that come horizontally from Z = 0 (as they are sampled over a hemisphere.

after merging with the bound extender 4 points cloud the

box center is 15.21 (meters) and box dimensions are 30.429

box center is 14.98 (meters) and box dimensions are 29.97

I re did the clouds and displaced both upwards and I get same lighting

Ok, more testing

I used a different dataset. This dataset is mobile lidar dataset also but it comes chunked in grids of equal size 100x100,

This is are 2, 1km x 1km chunk composed of several subclouds "lightmaped" with the AO tool by selecting one by one and running the tool.

https://1drv.ms/i/s!AuliwwO_siw1ik9QYxE5nsRUgwAl
https://1drv.ms/i/s!AuliwwO_siw1ilAAeJkW02d08qKa

It is quite surprising that the seams ar much smaller/subtle than in the other dataset, I'm not sure why.

Still they're visible as I'll show after. The lighting is overall quite uniform, despite in small clouds dhad fall into a box corner and ar part of a road and end up being like a dark triangle. After running the AO I did check the model and merged a couple of ugly areas and re run AO.

closeup showing bounding boxes for seams reference and the box free
https://1drv.ms/i/s!AuliwwO_siw1ilE2Scnj-L2k0K99
https://1drv.ms/i/s!AuliwwO_siw1ilE2Scnj-L2k0K99

Some ugly áreas:
https://1drv.ms/i/s!AuliwwO_siw1ilMGyplWcJHl0uLk
https://1drv.ms/i/s!AuliwwO_siw1ilRd1cipyguD09ZS

For the seams, may be while ideal would be to have the real neighbour considered in teh computations of AO may be the easy approach could be to for each edge of the chunk to mirror the cloud and consider like n meters extra from the edge to compute the AO and this way get rid of the seam.

100x100 grids fall in the sweetspot of the default values of the tool as it is really fast computing and the output is cool. Usually even if proportionally raising values the output is quite too bright.

But overall I was quite satisfied of the ouput and if seams issue is solved the lighting would almost totally blend as by hiding the seam with a pen in front of the monitor shows Little lighting variations but on small chunks described before.

How muchh shall I donate so a modified version of PCV is released that generates no bright borders on cloud tile edge?

150€ would be enough?

In my view, there could be a checkbox like "avoid edge brightness" , and a distance value.

To avoid the issue I think the best option would be to mirror each edge of the tile till the input distance, like 10 meters for instance, use it (internally) for computing the PCV magic and once finished dispose the extra points.

You can see the issue in this, they are even visible from far away, close up is even more noticeable