   Raytracing speed
  I''ve been using my mesh raytracer for a time now, and I know it to be less than optimal, and since I''m planning on rewriting it, I was wondering just how fast it would be possible to shoot rays at geometry. By possible I mean attainable without selling my soul to the ray devil.If those of you who have written raytracers could give me some benchmark results. I would be grateful. It''s no competition. the dataset must contain at least 100 000 primitives. It''s just to know if I am largely under par.Currently I can send 50000 to 100000 rays per second at a 200 000 triangle object (Athlon 2400+). The rays are random. The triangles are in 32Bit floating point, and the data is structured in a kd-tree. 
  Raytracing speed is mostly dependant on you ray intersection code and the speed of whatever spatial algorithm you use. Try using SSE to recurse 4 rays at once on your Athlon. ;  thanks for the info, but I was looking for numbers. I just want to have an idea of how fast things can get to see if it''s worthwhile to invest more time in my raytracer.saying that raytracing speed is mostly dependent of ray intersection code and spacial algorithm code, is, well, obvious, since sending rays in a  scene is just that! ;  How fast you go depends entirely on how many sacrifices you are willing to make - i.e. how much quality and accuracy you are willing to lose in order to gain speed. Every raytracer is different, and the differences are such that you can''t just throw out numbers and expect them to mean anything. I could say that my raytracer traces 1 ray every 30 seconds on the Athlon 2400+ system you mentioned, or 50,000,000 rays a second. Neither one means anything without a context - how much quality is achieved, and what is being raytraced in the first place.   PiQ Software  -  Tiny KeyCounter  -  Freon 2/7 Raytracing Accelerator;  How many rays per second can typically be refered to as a a ray being source to hit. So, as an example, a completely diffuse scene (no reflection) is effectively 1 ray per pixel (assume no AA or anything fancy/adaptive). Doing a diffuse scene with a shadow is 2 rays (one for the object hit, one for the shadow). The number of rays cast is effectively the number of times "TraceRay" is called in a recursive ray tracer.Ideally then, the number of rays per second is in fact independent of the scene, anti-aliasing technique and so fourth. The number of rays per pixel however is *very* scene dependent, even with no AA.With that being said, I have no numbers to quote, but the "standard" for performance seems to be the OpenRT guys, which spawned from the ray tracing research from Saarland University in Germany. They have tons of papers on their site (http://graphics.cs.uni-sb.de/RTRT/, http://www.openrt.de).;  Sorry, no comparison.My (mandatory, everybody else was doing it) raytracer did spheres ok, and sometimes worked with infinite planes.  Oh yeah, grayscale.  Oh, and no reflection.I am so ashamed.[8^)lonesock Piranha are people too. ;  Sorry if I''m being a bit rude, but I''m not getting answers.I''ve been working in computer imaging for tens of thousands of hours, and yes, I know ray shooting speed depends on ray distribution, scene characteristics, etc...I was talking about random rays send from one point of the bbox of the scene toward any other random point. (I could formlized it more, nut please spare me that). What I really wanted to have is just INFORMAL figures from those who have coded triangle mesh raytracers.OpenRT figures are interesting; they dit a great job, but their ray shooting speed largely depends on shooting coherent rays, whereas the technique I explore largely depend on shooting rather not coherent rays, because coherent rays usually carry less information. They are good for primary rays and hard shadowing, but after that, methods like stratified Monte Carlo do not produce coherent rays, or even predictable rays, since the rays that are to shot depend on the result from rays that were shot.If I really wanted precise numbers, then we would have to have a benchmark, and anyone willing to provide input would have to conform to the benchmark dataset ; some would even argue that the dataset is biased, and I would definitely never get numbers (considering the number of replies with numbers I already received!!). So please, if you have numbers, and you do not want/have to hide them, provide them alogon with the an explanation of which dataset and ray distribution you use. Thanks.;  Try this:http://citeseer.nj.nec.com/wald01interactive.htmlThis gives an idea of the possible speedup due to cache and algorithm optimzation and use of SIMD (such as SSE). Wald achieved 200,000 to 1.5 million primary rays per second (more specific figures are available in the paper).By highly optimizing their ray tracer they were able to render scenes from 11 to 15x as fast as raytracers such as POV-Ray and Rayshade. ;  Well, if you''re desperate for some numbers...About 50-100,000 rays a second, coherent rays (i.e. left->right per-scanline), against hand.ply, (~600k vertices) stored in a kd-tree (split heuristic from Havran), and using Moller ray/tri intersection.One oddity: my kd-tree was very unoptimal (shared triangles stored at splitting node) but happened to fit that particular mesh very well, so I don''t know if those numbers are really meaningful for more realistic datasets.If you''re interested, I have more recent numbers, but they''re against point clouds rather than triangles (got bored of em :]).Tim (tim.fov120.org) ;  Whoops, forgot to say: Athlon Thunderbird 850, all code C++ compiled with gcc 2.95.something.If you''re really interested I can send you can old backup copy of the source, but it''s a complete mess and probably not even buildable :]Tim (tim.fov120.com) 