Nonlinear processes can have seemingly probabilistic behavior but still be completely deterministic... no need for wave collapse at all. I must admit no one has actually formulated a fully functional nonlinear QM theory though:)
With a standard raytracer that would only work with something like monte carlo sampling which is just not very efficient (not realtime by a long shot). If there is only a couple of those reflective surfaces you could hack it and turn them into separate windowed lightsources, but then you could do the same thing with a rasterizer.
Realtime raytracing uses one first hit ray per pixel and one shadow ray per intersection per lightsource, no more... the days of realtime and practical global illumination are still a ways off.
I'm guessing you are replying to me... the problem with intersecting something is that it's easier said than done. The calculation is iterative for interesting curved surfaces, for instance with newton's method (lets ignore quadrics and other toy surface descriptions never used in the real world). The difference between an iterative solution and tessellation is very small, either can be done to an arbitrary precision... but there is one important difference, you can more easily cache the tessellation and reuse it for other rays.
Most of the time raytracers will do something even more low tech though... they just tessellate curved surfaces down to a user requested precision before they even start rendering the scene.
Or at least they won't be replaced by simple geometric solids, even with constructive geometry they just aren't expressive enough 99% of the time. Nice for CAD/CAM, useless for modeling the real world. The kind of curved surfaces suited for describing natural surfaces can't be analytically intersected (so in the end you usually subdivide them before intersecting them, you guess what you subdivide them into).
The only way that starts to matter is if the density of the vertices when projected to the screen starts to significantly exceed the sample density on average (if there are not objects to ignore there is no potential speed up). In practice we just aren't there yet, at least not for games which drive 3D technology, so this theoretical advantage isn't relevant for the moment.
It might get relevant in the future... but in the end you can use the same tricks as raytracing uses to ignore irrelevant geometry. Rasterization switched away from rendering everything to rendering everything visible from the camera, ie. using occlusion culling, if it needs to it can switch away from rendering everything visible from the camera to only rendering everything relevant (ie. actually sampled).
It depends on the percentage of time taken up by first hits and simple shadowing, as long as those two still take up a large percentage of the time rasterization will stick around... since it can do them better. When Global Illumination becomes standard raytracing will become standard, simply because what rasterization is good at won't take up enough time to justify special handling.
For meshes which don't have vertex density higher than pixel density hierarchical occlusion culling will give you the same complexity as raytracing (you already have to use hierarchical acceleration structures for raytracing too to get to O(log n) so this is a fair comparison).
For the Boeing model this would still leave you with O(n) (where n is the visible geometry). That is not to say you could not get it lower though, it's just that in practice we aren't too interested in highly aliased rendering of overly dense meshes. You could add hierarchical irrelevancy culling which simply ignored all geometry in bounding volumes which fall in between samples. That way you would end up with the exact same complexity as raytracing.
Raytracing is useful where faster algorithms simply don't exist to "fake" what you can do with raytracing at the quality you want... unfortunately for realtime there is not a lot which you can't "fake" better without raytracing (this isn't just about hardware, there is a good reason so many of the offline rendering packages still have scan conversion to accelerate rendering).
PS. of course it's all fake... raytracing is a little more physically accurate than most scan conversion based shadow, refraction and reflection algorithms (although it's completely the same for first hits, including the theoretical complexity). For lighting in general it needs hacks and fakery just as badly though. Forwards raytracing from the light sources to the camera is more accurate than normal raytracing, and wave tracing (quantum mechanics) is even more accurate than that. In the end all practical rendering is about fakery and hacks, as true for raytracing as it is for anything else.
A person shall be entitled to a patent unless-- (a) the invention was known or used by others in this country, or patented or described in a printed publication in this or a foreign country, before the invention thereof by the applicant for patent, or (b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of the application for patent in the United States, or
Slashdot Mirror
Nonlinear processes can have seemingly probabilistic behavior but still be completely deterministic ... no need for wave collapse at all. I must admit no one has actually formulated a fully functional nonlinear QM theory though :)
With a standard raytracer that would only work with something like monte carlo sampling which is just not very efficient (not realtime by a long shot). If there is only a couple of those reflective surfaces you could hack it and turn them into separate windowed lightsources, but then you could do the same thing with a rasterizer.
... the days of realtime and practical global illumination are still a ways off.
Realtime raytracing uses one first hit ray per pixel and one shadow ray per intersection per lightsource, no more
I'm guessing you are replying to me ... the problem with intersecting something is that it's easier said than done. The calculation is iterative for interesting curved surfaces, for instance with newton's method (lets ignore quadrics and other toy surface descriptions never used in the real world). The difference between an iterative solution and tessellation is very small, either can be done to an arbitrary precision ... but there is one important difference, you can more easily cache the tessellation and reuse it for other rays.
... they just tessellate curved surfaces down to a user requested precision before they even start rendering the scene.
Most of the time raytracers will do something even more low tech though
Or at least they won't be replaced by simple geometric solids, even with constructive geometry they just aren't expressive enough 99% of the time. Nice for CAD/CAM, useless for modeling the real world. The kind of curved surfaces suited for describing natural surfaces can't be analytically intersected (so in the end you usually subdivide them before intersecting them, you guess what you subdivide them into).
The only way that starts to matter is if the density of the vertices when projected to the screen starts to significantly exceed the sample density on average (if there are not objects to ignore there is no potential speed up). In practice we just aren't there yet, at least not for games which drive 3D technology, so this theoretical advantage isn't relevant for the moment.
... but in the end you can use the same tricks as raytracing uses to ignore irrelevant geometry. Rasterization switched away from rendering everything to rendering everything visible from the camera, ie. using occlusion culling, if it needs to it can switch away from rendering everything visible from the camera to only rendering everything relevant (ie. actually sampled).
... since it can do them better. When Global Illumination becomes standard raytracing will become standard, simply because what rasterization is good at won't take up enough time to justify special handling.
It might get relevant in the future
It depends on the percentage of time taken up by first hits and simple shadowing, as long as those two still take up a large percentage of the time rasterization will stick around
For meshes which don't have vertex density higher than pixel density hierarchical occlusion culling will give you the same complexity as raytracing (you already have to use hierarchical acceleration structures for raytracing too to get to O(log n) so this is a fair comparison).
For the Boeing model this would still leave you with O(n) (where n is the visible geometry). That is not to say you could not get it lower though, it's just that in practice we aren't too interested in highly aliased rendering of overly dense meshes. You could add hierarchical irrelevancy culling which simply ignored all geometry in bounding volumes which fall in between samples. That way you would end up with the exact same complexity as raytracing.
Raytracing is useful where faster algorithms simply don't exist to "fake" what you can do with raytracing at the quality you want ... unfortunately for realtime there is not a lot which you can't "fake" better without raytracing (this isn't just about hardware, there is a good reason so many of the offline rendering packages still have scan conversion to accelerate rendering).
... raytracing is a little more physically accurate than most scan conversion based shadow, refraction and reflection algorithms (although it's completely the same for first hits, including the theoretical complexity). For lighting in general it needs hacks and fakery just as badly though. Forwards raytracing from the light sources to the camera is more accurate than normal raytracing, and wave tracing (quantum mechanics) is even more accurate than that. In the end all practical rendering is about fakery and hacks, as true for raytracing as it is for anything else.
PS. of course it's all fake
Nuff Said.
A person shall be entitled to a patent unless--
(a)
the invention was known or used by others in this country, or patented or described in a printed publication in this or a foreign country, before the invention thereof by the applicant for patent, or
(b)
the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of the application for patent in the United States, or
Anything you publish becomes prior art, after which you are the only one who can patent it anymore (inside the grace period).