daveperman:
quote:
monte carlo has nothing to do with radiosity. call it "perfect raytracing" if you want.
I dont understand it. I mean, if raytracing has nothing to do with radiosity, how am i suppose to calculate light transfer, and visibility between patches? And don''t say that Elias tut is the solution. Because, using hemicubes (this is what he does), isn''t how radiosity suppose to work. It''s just a speed up to the whole process, by using hardware acceleration! And, as Yann said, its not the best solution.
And about Monte Carlo. You said that it is not easy to compute, because of the 7 integrals. But, isn''t the solution of those integrals what Monte Carlo integration should do. I mean the whole algorithm is on how to compute those integrals (i don''t know if the initial goal was to compute 7 or 1 integrals). I think that Monte Carlo isn''t "perfect raytracing". In fact, it''s just a method of solving integrals, implemented for use with cg. It can be used anywhere, other than cg.
On BRDFs. This is what i meant when i said, that i need to learn many things. The only things i can find on those advance stuff mention only those things you said. I don''t say that your explanation is not good, but it is not enough. I''m searching for examples, comparissons etc.
Finally photon mapping. All these days i''m searching the net for global illumination algorithms and tutorials, i found many papers on photon mapping. I tried to read them, but you know... papers. Nothing for the beginner. Only advance techniques, and how to speed up a slower algorithm. So, i thought (because i didn''t understood what i was reading), photon mapping is the same as radiosity, from the point of view that both compute light intensities on surfaces, and storing those values to lightmaps (lightmaps = photon map, i thought). Now I see that i''m wrong. I wanted to know what it is, if you can explain!!! Is it requires a huge amount of back knowledge to get started? Are there any "getting started with photon mapping" tutorials? Are there any comparisons with radiosity? I mean, for example the same scene rendered with both of them.
From what you said, photon mapping treats light as little constant quantities (photons) which travels, bounce etc. on the enviroment.
Yann:
quote:
We''re talking about 60 fps.
No we aren''t. We''re talking about 100 or greater fps, if you want it to be a complete alive enviroment! If you just want to walk smoothly in an incredible cool well lighten enviroment, then 60 fps is fine. But if you want full interactivity with it, AI from the enemy to the fly (the bug i mean!!!!!)?????
quote:
Ok, sorry, we got a little carried away there.
Dont excuse yourself. As i said, i maybe learn something from this discussion. So continue...
Finally, about dynamic intensities. The first approach seams ok, but as you said it takes huge amount of memory. About the second approach. If i understood right, you suggest, making a map that is 32-bits but the texture you send to OpenGL will be 8-bit (or make it 24 - 32 bit again). I thought that because you said 4-light contributions in one map. And what about colored lightmaps ? And must i have to recalculate texture object (OpenGL) every time an intensity changes? In an editor, thats fine, but in game, where you want to have the lights break, or switched on off???
Thanks
HellRaiZer
). Photon mapping is great. We just need better hardware support for it, so that fully dynamic high quality realtime implementations on complex geometry become possible.
Yes, you can see a lightmap, as well as a set of SH coefficients, as an approximated GI solution for a specific set of static parameters. The fact that it doesn''t take dynamic or view-dependent parameters into account is irrelevant. It is a solution for a specific camera position, a specific light and material set. This solution can be statically encoded, as diffuse radiosity or even photon maps, as you already mentioned above. The way the solution is initially aquired does not really matter either (several algorithms are exchangeable).