@TomcatViP
Thanks for your post Tomcat!
I've to admit that I've some difficulties following your argument entirely, I'm asking to one of my teammates to explain some parts of it in Italian. Shame on me.
Anyway as I said in the post above my target is not to have a 100% fidelity with reality, so I tried to keep the things simple. Of course a more detailed algorithm is gladly welcomed!
If I understand correctly CoVL heavily depend also on the observer's speed/altitude and these are the main factor for the tunnel vision. I think that it should be simulated. In terms of CPU usage we should test what it's better: a formula that uses all the real time values (CPU) or a model based on tables with defined and fixed values and approximations (RAM).
The part about the target shape is already explained in the first page of the thread, where is a formula (provided by one teammate of mine) to have the max distance based on aspect ratio.
Also camo is being taken in account in the initial analysis here:
http://forum.1cpublishing.eu/showpos...3&postcount=44
For the part about "relative motion" I think your argument is valid (at least the part I've understood, but I've faith in your work) and its the matter I was mostly concerned about.
As you can note there most of the things are not detailed (for example I don't take care about camo design but only the colors of the skin in that aspect, but it can always be a parameter linked to the skin itself) but IMO they are enough to give us a semi realistic output.
If you focus at the part about contrast you see that it's a function only lightly based on real time values and it's not related to the video drivers (to answer at GRAthos about video driver issues): the algorithm I was thinking runs around a parallel 3d world (matrix here) there the data are mostly fixed and its affected in real time only by really few variables.
For example the part about "contrast":
We constantly have the matrix of plane aspects (A): this one contains the reflections value for each aspect and mostly the ratios of colors of the skin in that aspect. This are not real time calculated values and I would put it on directly the plane model package.
We have constantly the map matrix (B): the map is divided in sectors (area has to be defined) and each one has an array with "ratios of colors" similar to the one the plane has.
A and B (but really only a fraction of A, the array corresponding to the plane aspect) are affected by lighting in real time. Here you compare the resulting colors. The plane is not "spotted" if it exactly passes over a street or a lake like in RL, that would be very difficult to calculate IMO, but if the difference of the colors between actual aspect and map sector gives us a probability value (high difference = 100%, no difference in colors = 0% and some ratios).
Because we have 2 main problems: CPU usage and mainly there are too many variables to calculate in RL and both can be avoided by approximations (data tables) and sadly in this case you have to use the concept of "probability".
This is the reason I used rand() functions (or optimized ones): today is not anymore a cpu consuming function. I read that today it is possible to have 1,000,000 random numbers on less then 50ms. In my algorithm a rand() is called for every plane at the end of algorithm, and
only if the conditions are the right ones (if the plane can be really be spotted and it inside the dynamic CoVL).
Then running this algorithm in a different thread (requested every 100ms for example, asynchronous at the main process) and on another core you can have good performance IMO. We actually have PC with high end CPU chipset and 6-8-12Gb of RAM: I think that performance are not a problem anymore.
We all know that today the majority of the issues of a videogame are on the video matter: I think that anything can be done in these days... look at that MODs did with IL2 1946. The biggest part I was annoyed about CloD after the release was the very limited CPU usage and really little RAM needed (but not VRAM...).
The most important thing to remember is that not everything can be simulated and so we need to work by approximations. Your analysis about realitive motion and RP seems very valid and useful for this matter, above all because is the part that mostly scared me.
@GRAthos
Of course this can be complicated above all because working by approximations needs a lot of tweaking and beta testing. But it's in no way related to video driver.
Sincerely it could be in some parts as the one about camo, but here the developers should work like they did for the epilepsy filter (reading the output IIRC): knowing the result of their effort I think that it's not the road to head on (or maybe it is... it could be that it's impossibile or that the developer was not skilled enough, who knows).
Anyway I hope you agree with me that something like this would take this WW2 sim to
another level of realism.
I apologize with all the readers for my bad english: I use always the same words. I'm bad in Italian too... Again, shame on me...