Actually, it has been shown that photon mapping scales better than MCRT in almost ALL cases (when considering rendering time and memory). Certainly vanilla PM is not that scalable, but throw importance mapping into the mix, and PM becomes a lot more efficient. The memory and time requirements of importance-biased photon mapping scale in O(r log s) where r is the number of cast rays and s is the number of intersectable surfaces. MCRT can''t come close to this due to the inherent oversampling behavior of Monte Carlo methods. Compare 4 samples per pixel (antialiased photon mapping) with over 10,000 samples per pixel (MCRT/path tracing) to get roughly equal results in complex scenes. The Mies van der Rohe scene from Jensen''s site was rendered using MCRT, and took 1,000 samples per pixel just to start cleaning out the noise from the image; even 10,000 samples per pixel still left a lot of noise (this is cited in his book). I doubt any fully Monte Carlo based methods will ever take over photon mapping, because PM is simply much more efficient in terms of time. In fact, photon mapping has been applied quite successfully as a sort of importance map for MCRT - but even then, MCRT leaves a lot of noise in the rendered scene, which photon mapping eliminates via density estimation kernels. In the long run, photon mapping gives more visually pleasing results, and there''s just no way around that.

I think it is more likely that photon mapping will tend towards using millions of photons per scene to maximize accuracy than to rely on inherently noisy solutions like MCRT. We''ll probably also start seeing programmable B*DF support in third or fourth generation raytracing hardware. Personally, I think the prospect of programmable B*DFs and perhaps even wavelength-based rendering (instead of RGB channelling) will take rendering to some very, very exciting places. As uutee mentioned, competition will really drive this forward.

Also, for one more mention:

quote:Original post by ApochPiQ
The trick is, as I alluded to earlier, that RT hardware will be feasible over the PCI bus - which means the RT system won''t need inherent rasterizer compatibility. Anyone with a spare PCI port can play with it. Granted, this will be a tiny bit slower than raytracing straight to video memory, but the point is that compatibility exists, and this will help people adopt the product in the short term, because they don''t have to lose their brand new GeForce card to play with raytracing.

The idea of developing a dedicated video card with raytracing support just isn''t feasible right now. RTRT will come on a separate card at first, and perhaps later come on a dual rasterizer/raytracer video card; but while rasterizers still control so much of the graphics world, RT hardware simply won''t fill our AGP slots.



ArtVPS has been around for quite a while, but as has been said, they aren''t geared for realtime solutions. IMHO anyone who takes the trouble to focus on the games industry will hold a major trump card in terms of marketability; generalized solutions like ArtVPS and OpenRT have potential, but in the long run, raytracing will make its money in games - so a proper focus on gaming and good support for developers (free SDK anyone?) will be a major selling point.

looking at the speed of the ArtVPS compared to the software rendered versions of the images, i guess for scenes we can trace today in some seconds, ArtVPS could rock:D

well, i wasn''t able to test the extreme situations till now with photonmappings.. but i''m interested how well photonmapping would work if you simulate a whole planet (== one sphere) in real size, put one house onto it, with one window, and put the sun at correct distance to it, and then use photonmapping to global-illuminate the actual room..

that would be hell of a pinhole-shooter for the photonmapper to get a good amount of photons into the window.. montecarlo would solve that faster, i think..

but in the end, it will only be a balance-act.. how detailed photonmapping, how much montecarlo samples into the map, etc..


for now, we''ll be happy with ordinary tracing of 1 ray per pixel realtime, not? :D



If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

yeah..

i think the gi solution of openrt could work rather promising for this..

but i''m not sure about it..



If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

quote:Original post by uutee
If we define a MC method to be non-hack if it converges to the correct solution as more samples are used, then radiosity (finite elements) is also non-hacked, because as the patch size approaches zero, the radiosity solution approaches to the actual solution.

ps, uutee: thats exactly the reason why radiosity IS a hack, if used as full global illumination: it doesn''t converge to a full solution. only to a full solution if ALL materials are COMPLETELY diffuse reflecting. only then. and this, in reality, is NOT true for ANY surface, ant not even close to a lot of surfaces. this is why radiosity is NOT a gi solution. it''s only a part of it. you can use it for that part, and it works well for that part. but stating that it is a full global illumination solution is just plain wrong.

radiosity converges to a full solution of complete diffuse interreflections of all surfaces.
montecarlo converges to a full solution of all lighting effects existing in real world: direct illumination, shadows soft and hard, indirect illumination, both specular (reflections,glossmaps) and diffuse (radiosity style), caustics, subsurface scattering, volumetric objects (subsurface scattering big style, aka fog,clouds,water,etc), and all others..
photonmapping solves all those, too.

photonmapping is there to correctly illuminate a scene. montecarlo style gathering of that photonmap is required to rather fast get a good image. sending out trillions^xxx photons just to have enough hitting your camera is simply not practical.. so you make those two algos meet somewhere in the middle.. and that is very fast converging to a good solution.

you can see "pure" photon mapping as full light-to-cam montecarlo raytracing, and "pure" montecarlo raytracing as the exactly the same, from the view of the cam.

well well.. something like that:D



If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

davepermen:
This is why one uses projection maps and importance sampling. As I said, vanilla photon mapping can''t deal with that kind of scene, but in practice nobody uses vanilla photon mapping. Its kind of like trying to haul 10-ton rocks with a bicycle. Its not feasible, and nobody with a good mind tries to do it


uutee:
When I say "photon mapping" I''m referring to the Monte Carlo particle tracing portion, and specifically the geometry-independent storage of irradiance. There are considerably better ways to visualize a photon map than using a distribution raytracer, by the way.

sure.



If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

I found this most enlightening as to the debate between rasterization and ray-tracing:
http://online.cs.nps.navy.mil/DistanceEducation/online.siggraph.org/2002/Panels/01_WhenWillRayTracingReplaceRasterization/cdrom.pdf

Very interesting whitepaper, but please note that this topic has been quiet for several months. You may want to start a new thread about the paper as I''m sure a moderator will be along presently to close this thread.