PCV custom bounding box size

[PablerasBCN]

Hi.

I discused the issue in the past, could not find the thread, and I've seen other users having the same issue.

with PCV, on the edges it gets brighter and if you've a tile set, you'll notice seams in the lighting. This is really breaking the continuity of my dataset.

I whanted to propose a possibel solution .

Since the effect of the issue fades few meters away the edge, have in the dialog screen the hability to input a custom bounding box size, so we can find the value that makes our tilesets seamless, yes ate the cost of quality or at the cost of having to increase the context resolution/ray count, but at least the output would be seamless.

[daniel]

I'm not sure to understand the exact process? (what CC would have to do with this bounding-box).

[PablerasBCN]

May be I wrongly understande the code, I did attemp to read it but is somewhat alien language.

What I mean is that since the edges of the cloud get considerabily brighter, this means to me that if the volumen to be lit is considered bigger, the real edges of the cloud will not be affected as they're now.

May be is the sphere size and the bounding box what needs to be made bigger and not the bounding box.

But the idea is that at the cost of resolution/quality/time you get a seamless AO across a tileset.

[daniel]

No the issue is due to how the lighting simulation works. You are trying to look at the cloud from multiple directions (either from a hemisphere or a sphere). And each time, we check if the points are visible or hidden. If they are visible, the virtual 'light' they receive is increased by 1. And as the points on the border of the cloud are much more visible, they get virtually more 'light' at the end of the process.

While this works well with a single object, if you have a cropped cloud, of course the points on the border will get much more energy than what they should receive. One would have to develop a much more complex algorithm to be able to compute piece-wise PCV (where you split the cloud with overlapping parts, compute the light but ignore the values on the borders, and properly merge everything. But even with that approach, you might get strange resulsts...

[PablerasBCN]

aaaah, that explains a lot

of course I come here with my cheese solution.

An option that would internally, for the PCV computation only, extend the borders by 10m or whatever value is input by user, simply last known value repeated till 10m +, and once PCV is complete delete theese extra points.

as a curiosity, PCV leaves this trippy pattern on a plane. I noticed this first when I ran PCV on a tile that had sea.

[PablerasBCN]

I would also be oke if there is a way to PAINT in the scalar field but I can´t figure out any hack.

May be I would need to segment out the bright areas and run an arithmetic operation. But still it would be hard to handle the gradient effect.

The only way to paint I see is to rasterize, modify, and project into a new cloud, then convert to SF, and finally interpolate SF. it's a trip.

[PablerasBCN]

Hello Daniel,

I've found a solution to my issue.

My case was particularly problematic because I'm using road scanner data, hence, the road sometimes traversed the grid just from a corner so the seams from the PCV lightingn are very often visible.

Moreover, unlike in terrain grids, the size of the road, as said sometimes is small sometimes goes from one end of the grid to another end. PCV also varies "brightness" depending on the size of the cloud so I can´t even evenly lit sets, despite of the edge issue.

CONTEXT
I'm heavily editing the road because there are a lot of blending artifacts, hence I run the enhance with intensities wich "wipes the lighting", hence I need to somehow "restore" it. WHat I was doing was to compute PCV prior to segmenting the road, so the ground would have PCV lighting taking nearby objects in consideration. Then I would merge it and overall the ressult was quite convincing for a single tile, yet the issues exposed before would ruin the workflow for a grid type dataset.

SOLUTION:

I've been able to come out with a solution.

Notice that this particular dataset is captured in full cloud condition, somehat like PCV conditions with complete light spread with no sunlight hotspots (yet I belive would work as spected).

Convert RGB to Composite SF.

Decimate by distance, in my caset 25cm does the job, have not yet tested other values yet.

SF- Gaussian filter. Sigma 2.2

Boom,

PCV:


PROPOSED ALTERNATIVE OUTPUT


I've tested with sequential tiles of different sizes and ressults are seamless and seems evenly lit and without the edge overbrightness issue.

edit: testing with "dip direction 0-360" constatn SF I can notice some seam edge, still it's really ssmall. I wonder if could be possible to get rid of it in the process without having to touch manually levels and eyeballing.... will keep testing

edit: seems the small sema between tiles happens after applying the smooth filtering. Some test will drop the proper values, but overall I'm really happy with the outcome

[daniel]

Thanks for the feedback.

And I like the trippy pattern ;)