Indigo Renderer Forum

i was doing some personal research on how calculators graph trigonometric functions recently (or more specificaly what algorythem a trig function imposed on a number) and then started wondering about which method of trig calculations indigo uses. does indigo use the programing language's internal trig calculator to calculate trig functions, or does it have its own faster method? if it doesnt, you might want to consider coding your own quicker method of loading a table into the memory and calculating between numbers the inacurite way.

under normal single calculation circumstances, the exact way of triging numbers seems incredibly quick, however in an unbiased raytracer like indigo the massive number of trig calculations calculated would slow it down considerably, i imagine that even a method that is quicker by one nanosecond would speed up renders great amounts. so even if it biases the calculations a bit, i imagine a method that uses a table calculation within the ram would be much quicker than calculating the trig from scratch each time.

i have some wiki pages on how this is done for anybody not realizing why this is important or what i am talking about.

http://en.wikipedia.org/wiki/Discrete_Fourier_transform

http://en.wikipedia.org/wiki/Discrete_Fourier_transform

http://en.wikipedia.org/wiki/Generating ... ric_tables

this question might sound a little noobish to you more experienced programers or might be genious, i have no idea, as i am completely ignorant of other peoples knowing in this area.

More than likely, the inherent inaccuracies with a simple LUT would pile up, over time.

i never implied that it had to be the simplest calculations, just possibly simpler than the already existing ones. this might be for example the reason for any speed differences between indigo and maxwell that some might have noticed although probably not the greatest example as the speed differences are so little there are almost none. however, you could possibly make a system where the trig values are dependent on the number of ray bounces, for example on the first ray bounce it would use the more acurite trig value since that bounce is effects the other bounces the most, and then for the second bounce you would use a less accurite method of calculating the angle as it is less dependent on the angle of the view and so on.
rather than programing multiple methods for calculating the value, you could in theory only program two methods, one would be the exact value, which would be used on the first two or three bounces, and the other would be a method which can be refined so that after one bounce it would use refinement to a higher degree and then bounces after that would refine to a lesser degree. most likely this method is not very efficient as the methods would have to be alternated in the ram for every ray. more likely just the refinable setup would be used.

however although probably requiring a vast amount of changes to the internal engine, it could be done in refinement passes so that all rays are shot at one bounce and then the data of where they are and there angle would be set to the ram, then the trig calculator alternated and all further bounces would be done with that one. this cycle would continue untill all the rays have either died or reached max bounces because indigo is an unbiased raytracer, this cycle woud repeat an infinite number of times. although i guess setting would still be inefficiant

perhaps the most efficiant way would be to load both methods into ram and have them be switchable easily, however i imagine this would take up way too much ram.

oodmb wrote:http://en.wikipedia.org/wiki/Discrete_Fourier_transform

The FFT and DFT are widely used in data compression, spectrum analysis and the solving of problems involve PDEs, but not in ray tracing.

I think using a look-up table would increase rendering speed, but not by much. A well-programmed GI ray tracer shouldn't need to perform that many trigonometric operations anyway. Most of the cost of rendering is taken up by geometry intersection testing so it would probably be more worthwhile to concentrate in optimising these areas.

oodmb:
I think trig functions take up only a few percent of indigo execution time at most. So I don't think i'll get big speedups from optimising them.