consider changing C_Interface to use floats

[cadop]

Another idea I had was to simplify another data conversion on the c++ side. What is the rationale behind the conversions in lines 273 & 274?

dhart/src/Cinterface/raytracer_C.cpp

Lines 271 to 279 in 30648be

 C_INTERFACE CastOcclusionRays(EmbreeRayTracer* ert, const float* origins, const float* directions, int origin_size, int direction_size, float max_distance, bool* result_array) 
 { 
 	auto origin_array = ConvertRawFloatArrayToPoints(origins, origin_size); 
 	auto direction_array = ConvertRawFloatArrayToPoints(directions, direction_size); 
 	const auto results = ert->Occlusions(origin_array, direction_array, max_distance, true); 
  
 	std::copy(results.begin(), results.end(), result_array); 
 	return OK; 
 } 

In the end, we need float values anyway:

dhart/src/Cpp/raytracer/src/embree_raytracer.cpp

Lines 621 to 626 in 30648be

 bool EmbreeRayTracer::Occluded_IMPL(float x, float y, float z, float dx, float dy, float dz, float distance, int mesh_id) 
 { 
 	auto ray = ConstructRay(x, y, z, dx, dy, dz, distance); 
 	rtcOccluded1(scene, &context, &ray); 
 	return ray.tfar == -INFINITY; 
 } 

If it's only to make looping over data more convenient, then it could be restructured to operating directly on a pointer to the float array we pass from c#. This could shave off another few ms per call.

Originally posted by @mariuszhermansdorfer in #33 (reply in thread)

[cadop]

The steps in between these two functions seems to be the main motivation and reason to have this structure. Its not just about looping over points, but also checking the sizes of the sets to determine which method to use, and how to parallelize it using omp parallel.