For 1a):
	Perhaps the best place to start is a standard list of wide ranging (ior  
material 1=a, ior material g=f) values which can be validated  
independently. Then when we agree upon a list<T> where T=IOR values, we  
can plug those into the pov model to determine the phase space of the  
f(x)...and so as such may be able to reverse engineer the requisite  
diffuse, etc.. parameters. If such a model can be completed, where the  
f(x) can be defined, then any IOR x (and some parameters ??) should result  
in the corresponding missing values. I have used this tactic in the  
financial sector with great success...so...maybe a good strategy for this  
problem as well?

Ian

On Tue, 21 Dec 2010 21:55:41 -0500, [GDS|Entropy]  
<gdsHYentropyAThotmailDTcom> wrote:

> Ok...I will respond to myself due to the sheer volume of comments. :)
>
> I like what I have seen from the community...especially the more  
> advanced concepts; however one must have a starting point before going  
> that far...and this looks like it. I have lusted after many of these  
> values for a long time...shame it never occurred to me to just Google it  
> before now... >__<
>
> 1)	Where would we get the missing parameters accompanying these IOR  
> values?
> 	1a)	It seems the povray params for these missing values should be an  
> f(x); we have some data points already...is there a decent way to  
> produce the governing function, so we 				could just write a program and  
> dump the output? Given the pov model exists and is not randomly  
> variable, determining the function should be possible...though I do not  
> 					claim to be able to do so, at least without more research than my  
> current project load would allow.
> 2)	How do we reach a consensus on the dubious IOR values?
> 3)	Regarding magic numbers....being a programmer I have an inherent  
> dislike for such things...however, having a number of reference points  
> extrinsic to any particular gfx package, 		with which my current known  
> list of IOR values match up to, lends some credence to at least those  
> values which are easily confirmed by multiple sources. Margins of error  
> are a 		fact of life in any business unit, and if a software engineer  
> should spend the time required to eliminate all of it, I seriously doubt  
> he would get much programming done. 				Sometimes it is best to take  
> what you have, make something with it, and correct the errors later. I  
> don't like it either...but it is the way of life... :|
>
> Ian


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message