Sun calculations #6
Conversation
…collision that gathers information for each bounce.
…k (method split into more module components so that code could be reused from non-multibounce case).
…on is only added when diffuse_intensity is not 0
…an then be used Allow normals to be passed as an input to models (gets around cached_property) and use vertex normals to determine direction of face normals. Add code using pywavefront to load obj (code using yggdrasil included, but commented out). Change directions/origins for orthographic ray tracer to be traitlets w/ default values in prep for generating rays from backwards face propagation. Update rotation method to allow rotation of ray or point (previous version did not shift to scene origin and so was only valid for rays). Add defaults for width and height that are set based on bounding points of the scene (to limit rays to just the scene and improve performance for complicated meshes). Pass scene bounding points to sun blaster initialization from get_sun_blaster scene method. Pass zenith in absolute units (includes ground). Queue additional rays generated at intersection (reflection/transmission), apply decrease in power according to input reflectance/transmittance, pop rays once the current ray decreases below a power threshold or does not hit the scene. Add sphere.obj example for obj testing
| self.ray_dir = np.empty((nray, maxbounce, 3), dtype="float32") | ||
| self.power = np.zeros((nray, maxbounce), dtype="float32") | ||
| self.nq = 0 | ||
| self.ray_queue = <RTCRay*>PyMem_Malloc(self.maxbounce * sizeof(RTCRay)) |
There was a problem hiding this comment.
We're using C++ anyway -- would it make sense to make this a vector?
There was a problem hiding this comment.
If we arn't reallocating then this can just be an array on stack. I had it dynamic originally and was adjusting the size as needed, but then realized that that required a dynamic location to store the rays as well for use outside the callback. Since this presents memory issues for low thresholds, I figured it would be easier to just assume a max number of additional rays (maxbounce). This has some issues since it might truncate significant rays in the current form which always follows the reflected ray first. I think it should probably follow the queued ray with the largest power first (implemented in the pop_ray method), but maybe there is a better way to do this.
This is all @langmm's work, but I'm opening the PR to check the tests and to update them here.