Ray tracer to sky dome for solar potential problems

Hi Team,
I have a ray tracer written in VTK that uses Intel TBB to determine if a pixel on a building mesh has a clear line of sight to a pixel in the sky dome mesh (building geometry at ground level and a hemispherical sky dome above- all pixels on the meshes are triangles). I generate a matrix delta function that is m (number of building pixels) by n (number of sky pixels) with 0 if a building pixel is blocked from the sky pixel, and 1 if clear line of sight.

I can generate the 3D geometry in OBJ format and would like to know if it would be possible to use OptiX to replicate the generation of this matrix? The current implementation is CPU only and can be very slow for complex geometries. Any tips on how to go about this would be much appreciated.

Regards,
Martin
PS, this is an implementation of a solar energy model that will be used to solve solar potential problems for deployment of solar panel systems in urban areas.

That is basically an ambient occlusion or shadow testing algorithm and there should be no problem to implement that with OptiX.
Testing visibility between two points or along a direction is one of the fastest things to do in OptiX because such a ray type only needs an any_hit program which immediately terminates the ray traversal when anything is hit along the ray interval.

What are the dimensions of the numbers m and n in your simulation?
Depending on the amount of rays needed by your simulation, it’s recommended to implement this as a progressive approach to prevent possible timeouts if you’re using a Windows OS system and no NVIDIA Tesla board. This would also allow an arbitrary high number of directions into the sky dome.

If the directions to your sky dome are a fixed set, it would also be faster to check all building pixels against one (or a few) of these to get better convergence in the ray directions which will result in improved performance per launch, sometimes up to a factor of two from my experiences.

OptiX device programs for a very simple progressive ambient occlusion implementation can be found here:
[url]Exceptions when using occlusion rays - OptiX - NVIDIA Developer Forums
You would need to change the ray generation program to use the building pixels as origins and generate the directions to your sky dome as needed and store the results into the proper matrix locations.

The OptiX SDK examples contain a simple OBJ loader. Search for MeshLoader inside the the *.cpp sources.
You would only need the geometry and would need to replace the parts which handle the materials for your simple visibility tests which would use the same material for everything.

Next steps for such a simulation of solar panel placement in urban areas would be the reflection behavior over the sun location in the whole year to see if there are any lighting issues. That’s also a very straightforward use case for ray tracing which would also not be difficult to implement with OptiX.

Hi Detlef,

Thanks for the reply. m can range anywhere from 20K to 200K pixels for a building, n is around 3000 for the number of sky pixels. It is quite high resolution as irradiance varies from different parts of the sky and each part of the building will receive different levels of solar irradiance throughout the year. This drives the solar energy calculations. And most of the simulations are done on a Windows workstation.

I’ll look into the resources you suggest. Many thanks again for your help.

Regards,
Martin

Ok, a maximum of 600 million shadow rays using OptiX shouldn’t take more than a few seconds, depending on the scene size and GPU.
To be able to scale the workload to any underlying GPU, I would still recommend to start implementing a progressive approach where your launch size is m and the number of iterations is n to fill one row of your visibility matrix with values.
With just 20k to 200k rays per launch that will work easily on any GPU supported by OptiX (if the scene fits).
20k shadow rays will actually be too few to saturate current high end GPUs. You should be able to control the number of sky directions you process in each launch. That would allow to control the workload to the underlying hardware even better.