@Mauricio
Il ne te reste plus qu'à créer une nouvelle gamme de compos... tous circulaires !
( Et t'as intérêt à ce que le code tourne rond ! ;)


@Fredelem
« Mais puisque ton algorithme est plus simple, je vais essayer de le mettre en couleurs. Est-ce que ça te paraît possible ou est-ce désespéré ? »

A priori, si tu veux présenter un choix de couleur sur un disque, cet algo est le seul qui te permette de le faire de façon smple et sans trou.

En fait, je suppose que tu penses à faire un cercle chromatique ?
- Pourquoi pas.
A condition de diviser ce cercle en 8 couleurs primaires et de présenter ces couleurs de façon discrète et non pas continue; car l'algo d'Andres ne se prête pas bien à une représentation continue. Voir :
http://fr.wikipedia.org/wiki/Cercle_chromatique
Cet algo calcule  les pixels de façon dynamique et non pas statique. En effet, la position de chaque pixel dépend d'un pixel calculé précédemment, mais cette relation ne recouvre pas toujours une position logique dans le plan.
Pour s'en convaicre, il suffit de dessiner un cercle avec cet algo, en choisissant une couleur différente pour chaque octant et en le faisant dessiner pixel par pixel avec des Sleep() bien placés (c'est la meilleure méthode pour comprendre la logique de l'algo).

Tu verras que dessiner un cercle chromatique de façon continue sera très difficile.
En revanche Andres se prête bien à un dessin de cercle secteur par secteur...

Bonjour à tous ( et bonne année ! :),

« PS: je note une perte de vitesse évidente de traitement chaque fois que j' utilise la récursivité! »

Effectivement. La dé-récursivation fait partie de l'optimisation.
Mais on optimise toujours un code qui fonctionne bien, et il est sans doute encore trop tôt pour le faire ici.
Cela dit, ce n'est peut-être pas la peine de chercher à implémenter des routines récursives à ce stade de développement.

Le problème de la récursivité est le même que celui dont parle Cirec au début de la discussion. Il faut en effet éviter de multiplier les appels à des méthodes extérieures depuis l'intérieur des routines, particulièrement dans les boucles.
Et la récusivation consiste en fait à appeler la fonction depuis l'intérieur de cette même fonction. Cela a donc un coût !

Dans le même ordre d'idée, Bactérius pourrait supprimer des procéduress un peu inutiles comme :
procedure IncPtr(var P: Pointer; const N: Longword); { Increments P by N bytes. }
et
procedure DecPtr(var P: Pointer; const N: Longword); { Decrements P by N bytes. }
dont l'appel est coûteux, et pourrait être remplacé par une seule ligne de code.

Puisque tu en es là, je te fais part d'une petite réflexion personnelle (sans jeu de mot) au sujet de la réflexion diffuse.

J'imagine que la distribution spatiale des rayons réfléchis n'est pas homogène et qu'elle comporte des directions privilégiées (comme la normale, par exemple). Je suppose aussi que cette distribution doit + ou - suivre une distribution gaussienne. Alors je te signale une fonction de l'unité Math bien pratique :
RandG()
Elle fournit des nombres pseudo-aléatoires selon cette distribution gaussienne.

Tu peux t'en servir directement avec le générateur de Delphi ou créer ta propre fonction avec le générateur que tu as implémenté dans ton application.

Mais la réflexion est un phénomène que je ne maîtrise pas très bien, donc tout cela est à vérifier.

Bon courage !

« Il existe en fait aussi un support pour le depth-of-field (l'effet de flou pour les objets proches et distants comme pour une vraie camera... »

Le parallèle qu'on peut faire entre Nicéphore Niepce, le 1er photographe, et Bacteius est saisissant !  ^ ^


En effet, le premier appareil photographique n'avait pas le problème de la profondeur de champ. L'image obtenue était parfaitement nette sur tous les plans. Cela était dû aux avantages du sténopé.

VOIR:  http://fr.wikipedia.org/wiki/St%C3%A9nop%C3%A9

L'inconvénient du sténopé était le temps de pose extrêmement long (8 heures !). C'est pareil pour Bacterius : image très nette mais un temps de traitement qui peut paraître excessif. C'est amusant...

Tout ça pour dire que je trouve que si on veut introduire un effet de flou, il faudrait que cela ait pour conséquence une réduction du temps de traitement. Là, ce serait intellectuellement acceptable, je pense.
En effet, le problème de profondeur de champ n'est pas une réalité de la physique mais un défaut de l'oeil humain et de nos apareils photo (même principe).

Il est à noter que l'on commence à trouver sur le marché des appareils photo pouvant donner une image nette à toutes les distances : les appareils photographiques plénoptiques de Raytrix.

VOIR:  http://www.reportagesphotos.fr/A2447-raytrix-r11-premier-boitier-numerique-plenoptic-du-marche.html

C'est vrai que le sujet de Bacterius est très "technique", et donc les commentaires aussi.

Mais bon... C'est un peu un passage obligé dans ce genre de développement.



Je voudrais quand même insister sur ce que je trouve "génial" dans le résultat du travail de Bactérius ( et il me pardonnera certainement de le faire sa place ;) en essayant de parler simplement :

Il suffit de regarder attentivement la capture.

De remarquer le léger reflet sur le plafond dû à la boule transparente.

Ce reflet est en fait dû à la tache de lumière blanche et intense que l'on peut voir sur le sol, devant cette boule et provoqué par cette même boule dans un premier temps (comme une loupe). Puis cette lumière repasse dans la boule pour provoquer ces légers reflets sur le plafond...

Ce qui me paraît extraordinaire, perso, c'est que cet effet super-réaliste n'a pas eu besoin d'être programmé ni prévu par Bacterius.  C'est simplement le résultat d'une technique humaine qui, reproduisant le monde réel de façon particulière (et en 2D !), aboutit exactement au même résultat que la Nature.

Parfois, en programmation, on approche le divin. Non ?   ^ ^

Et surtout !  N'oublions jamais cette sentence de Thomas d'Aquin :

« Il est plus beau d'éclairer que de briller ».

^ ^

Rendu réaliste !
Bravo ! Car ce n'est pas toujours évident (n'est-ce pas ?).  ^ ^
C'est magnifique !


Je n'ai pas encore testé la vitesse, mais comme tu l'indiques dans ton intro, ce n'était pas ton but...

Très bon travail et très bonne réaction aux critiques => 10/10

Petite précision :
ce que tu appelles "variance" se nomme en fait "discrépance". En graphisme, on utilise souvent une discrépance un peu particulière basée sur le rectangne et notée D* (= discrépance étoile). Ca se calcule assez bien pour un ensemble de points donné.

La configuration quasi-aléatoire est, par définition, une configuration conçue pour minimiser la discrépance et permet une convergence plus rapide que la configuration strictement aléatoire dans certains problèmes, mais pas dans tous !

Les études actuelles en mathématiques et en algorithmique essaient justement d'identifier les problèmes pouvant en bénéficier de ceux qui en pâtiraient.
Mais cela dépasse de très loin mes compétences, et même ma curiosité.  ^ ^

Pour le lancer de rayon, je sais que beaucoup de gens y travaillent actuellement afin d'améliorer les performances à l'aide d'algos très sophistiqués.
Et c'est tout le mérite de ton post de nous présenter les principes d'une méthode qui semble promettre beaucoup.

Je te parle physique et tu me réponds programmation. On ne risque pas de tomber d'accord.  :)

Sinon :
« Le resultat de la methode Monte-Carlo convergera vers le resultat du processus deterministe, a la meme vitesse »
Pas du tout !
Certes, les résultats convergent, mais jamais à la même vitesse !
C'est beaucoup plus lent en aléatoire.
C'est pour cet inconvénient qu'on utilise de plus en plus la méthode dite de Quasi-Monte Carlo dans certains calculs financiers, par exemple. Et la force de la méthode Quasi-Monte Carlo est de ne pas utiliser de nombres pseudo-aléatoires, justement.

Puisqu'on en est à la théorie grâce à Francky, petite mise au point pour éviter les confusions et les commentaires de code inappropriés :

Les effets d'optique dûs à des détails microscopiques ne relèvent pas du tout de la mécanique quantique !
Prenons pour exemple l'aspect de notre Lune dans le ciel. Son aspect serait totalement différent si sa surface était plus lisse... Pourtant le comportement des rayons lumineux  dû à la surface de la Lune n'a rien à voir avec sa composition atomique. Ce sont les lois de la réflexion classique qui s'appliquent. Tout comme à la surface d'une sphère de verre dépolie, par exemple.

Le mode aléatoire dont tu te sers ne sert qu'à simplifier l'opération. Tu pourrais aussi bien utiliser une méthode complétement déterministe comme une suite de Van Der Corput, par exemple (et qui serait certainement plus proche de la réalié).

En optique, il n'y a qu'un seul domaine où la mécanique quantique est inévitable (et encore !), c'est le domaine de la photoluminescence où tout se passe au niveau atomique.

@Francky
« Quand Bactérius dit qu'on a pu observer visuellement des phénomènes quantiques c'est totalement faux. »

Non ! Ce n'est pas faux. Les lois quantiques s'appliquent à tout et à toutes les échelles de taille, même si souvent, mais pas toujours, leurs manifestations passent inaperçues.
Par exemple la "boussole" dans le cerveau des oiseaux migrateurs, les cristaux de certains sels, et j'en passe ..!
Tu peux même rendre l'effet d'ondes de surface et de mémoire d'onde de façon macroscopique dans ta cuisine (ça te changera du chili con carne !). ^ ^


Pour la sucette, ce sera parfum caramel pour moi.
Tu sais,  les Pierrot Gourmand...  mdr