PureBasic

grabiller a écrit : Pour ce dont je parle, non il ne s'agit pas de 'post-effect' dans le cas d'un raytracer mais bien de features inhérentes au moteur de rendu. Tu parles de 'tricks' utilisés avec les moteurs OpenGL/DirectX pour simuler ce genre de features. Dans le cas d'un raytracer, le DOF, le motion blur, le volumic se font au niveau du sampling, pas une fois que l'image est rendu ou avec des effets de superpositions. Avec les moteurs de jeu 'ça le fait' mais pour une images films la qualité n'est pas suffisante et ces 'tricks' sont facilement visibles.

Ca deviens assez pointu , en gros , tu veut faire un renderer complet ? c'est un travail titanesque , pour la lumière volumétrique , la première chose qui me viens à l'esprit , c'est l'utilisation d'un volume 3D , que tu divises en milliers de zone plus petite (grid3d) , chaque zone peu être percue comme "un atome" avec ses propres propriétés ( comment un rayon agit avec la collision d'un atome ) , plus les subdivision sont petites plus l'objet volumetrique est précis , tu peut simulé des fluides ( sph ) , la fumée et la poussière sont aussi des fluides, mais en plus d'être bon en prog , il faut taquiner un peu la physique

Je l'ai essayé et je n'ai pas eu le rendu arrivé a 100% dans la console. Une chose sympa serait que le rendu apparaisse a chaque %age de la console.
En tout cas, j'ai mis plus d'une demi heure sur mon portable pour arriver a 100%

SPH a écrit :Je l'ai essayé et je n'ai pas eu le rendu arrivé a 100% dans la console. Une chose sympa serait que le rendu apparaisse a chaque %age de la console.

Pouvoir le régler serait plus intéressant, par exemple, tu règles l'image visible tous les 10% ou tous les 20%.

De mon côté ce qui m'intéresse c'est de créer des images pour des films (même avec une approche Machinima qui m'intéresse particulièrement).

Une chose que je ne saisis pas complètement, tu parles de créer des images de films, mais il faut bien charger ta scène, dans quelle format comptes-tu charger ça ?

Ou alors, tu ne comptes pas utiliser ce début de RT comme produit final, c'est juste des tests pour apprendre en gros comment tout ça fonctionne ?

du reste , il existe des produits pro comme Maya,3dSmax, et j'en passe (meme un produit cree par Pixar de memoire )
qui disposent de renderer qu'un programme fait en Purebasic n'arrivera jamais a atteindre ... (je crois pas au pere Noel )

bien sur c'est de la "post production" (j'ai mis entre guillemets , car souvent le développement des scènes (le Mat Painting par ex) se fait même
en parallèle , du tournage ...)

je ne sais pas trop ou grabiller veut en venir , ces codes sont intéressants , mais je ne rapprocherai pas ça, même de loin
avec ce qui se fait en Production Cinématographique .....

un mec tout seul deja , c'est utopique de le voir développer un outils (quelque soit le langage) , qui rivaliserai ce qui se fait deja dans le cinéma

les mecs de chez Pixar développent des pluggins, ou bien même des outils complets de calcul, mais je pense deja qu'ils sont plusieurs
a le faire (une equipe ) .....

grabiller a peut etre des talents cachés .... mais pour le moment, j'attends de voir ....
entre l'envie,et le possible , la différence est grande .... comme l'univers

C'est un outil pour des besoins spécifiques, et je suis bien content de voir ça codé en PB, pourvu que ça dure

Le raytracing me fait toujours rêver ! Et même si les moteurs de rendu ont une qualité qui tend à se rapprocher de la perfection, il est encore possible de voir de subtiles différences, et les discussions techniques sont passionnantes... Dommage que je n'ai pas le niveau !

blendman a écrit :Une chose que je ne saisis pas complètement, tu parles de créer des images de films, mais il faut bien charger ta scène, dans quelle format comptes-tu charger ça ?
Ou alors, tu ne comptes pas utiliser ce début de RT comme produit final, c'est juste des tests pour apprendre en gros comment tout ça fonctionne ?

Comme expliqué dans mon premier message, ce port de smallpt en PureBasic est avant tout fait pour expérimenter autour du Monte Carlo path tracing, et effectivement pour apprendre, tester, explorer et partager avec ceux que cela intéresse.

Par la suite, rien n'empêche d'aller plus loin. Rien n'est ultra compliqué quand on comprend exactement ce qu'il se passe. Mais il faut commencer par comprendre ce qu'il se passe. Pour y arriver, chacun s'y prend comme il veut/peut. Par contre, ensuite c'est du temps, parfois beaucoup de temps.

D'autres préfèrent les procès d'intention plutôt que le code lui-même, c'est une autre manière de dépenser son temps

@Grabiller : j'ai saisi ta démarche , donc c'est surtout pour mieux comprendre comment tout cela fonctionne plutôt que d'avoir un outil finalisé. En tout cas, c'est super intéressant de voir qu'en PB on peut faire ce genre de choses. Et merci beaucoup de partager ton code, ça permet effectivement de comprendre comment ça fonctionne. Même si ce n'est pas de mon niveau, c'est très intéressant .

Je ne sais pas du tout comment il faudrait s'y prendre pour charger une scène ou des meshs, s'il faut charger chaque info de la scène point par point ou si c'est faisable en utilisant par exemple le système 3D de pb (donc ogre) et lié ça avec ce RayTracer, mais ça me fait rêver rien que d'imaginer ça. Hélas, je n'ai pas le niveau pour faire ce genre de chose. J'avais commencé un éditeur de niveau 3D (pour jeu) à une époque, mais je ne sais pas du tout comment on pourrait charger un obj 3D et le rendre avec ton moteur ^^. Je regarderai à l'occasion pour voir si je trouve des pistes, mais je doute que ce soit à ma portée.

En tout cas, encore merci pour les explications

blendman a écrit :Je ne sais pas du tout comment il faudrait s'y prendre pour charger une scène ou des meshs, s'il faut charger chaque info de la scène point par point ou si c'est faisable en utilisant par exemple le système 3D de pb (donc ogre) et lié ça avec ce RayTracer, mais ça me fait rêver rien que d'imaginer ça../..

En fait, à ce stade d'expérimentation avec ce code, charger une 'scène' ou des objets quelconques n'a que peu d'intérêt car c'est un problème indépendant des algorithmes de raytracing, path tracing etc.. et fait appel à un autre domaine: le partitionnement spatial (les structures d'accélération d'intersection).

En gros dans le code publié plus haut il suffirait d'implémenter une autre version de la fonction 'intersect' prenant en charge d'autres types d'objets que des sphères (et ajouter quelque modifs pour que cette fonction retourne d'une manière générale les informations concernant le point d'intersection: position, normal, uv, dérivatives, etc..).

Mais en terme de raytracing/pathtracing pure, surtout au niveau des algorithmes de sampling, de lighting, de shading, de denoising, etc.. c'est tout à fait secondaire pour l'instant, en tout cas pour ma part, tant que je n'ai pas testé les algorithmes qui m'intéressent.

Avant de construire une maison, il faut des fondations solides, et pour l'instant je n'en suis qu'à ces fondations.

blendman a écrit :

SPH a écrit :Je l'ai essayé et je n'ai pas eu le rendu arrivé a 100% dans la console. Une chose sympa serait que le rendu apparaisse a chaque %age de la console.

Pouvoir le régler serait plus intéressant, par exemple, tu règles l'image visible tous les 10% ou tous les 20%.

Oui ça serait plus sympa d'afficher l'image au fur et à mesure mais cela implique un travail sur l'UI qui dépasse le cadre de ces expérimentations avec purept.

Mais à terme c'est bien ce que j'ai l'intention de faire avec raafal.

D'autant que cet algo ne s'intéresse qu'à des objets "purs" mathématiquement, comme la sphère. Mais les objets modélisés sont souvent composés (ou plutôt décomposés d'autres types d'objets, il faudrait au minimum qu'il prenne en charge les triangles, puis d'autres types de polygones, les nurbs et autres, déjà ça c'est du boulot ! Comme le dit grabiller, il faut bien réfléchir et avoir de bonnes fondations. M'enfin à notre époque il y a déjà beaucoup de code tout fait pour ces tâches pas très amusantes. L'aspect rendu est plus fun

Au fait, pour G-Rom: http://igad.nhtv.nl/~bikker/ (la page des download foire un peu, mais on peut voir facilement tous les fichiers)

Un très bon article sur l'art du rendu 3D : http://www.fxguide.com/featured/the-art-of-rendering/

grabiller a écrit :D'autres préfèrent les procès d'intention plutôt que le code lui-même, c'est une autre manière de dépenser son temps

Je rejoins ce qu'a dit Dobro , car même si le raytracing est simple en lui même , tout se qu'il y a tout autour et très long à développé. si c'est mal conçu dès le départ , il faut recommencer , etc...
Tu n'a pas non plus l'air d'être un lapin de 6 semaines , je pense que tout ça tu le sais déjà
Pour ton projet raafal , tu en est ou ?

djes a écrit :Au fait, pour G-Rom: http://igad.nhtv.nl/~bikker/ (la page des download foire un peu, mais on peut voir facilement tous les fichiers)
Un très bon article sur l'art du rendu 3D : http://www.fxguide.com/featured/the-art-of-rendering/

Merci , je vais jeté un oeil.

D'autres préfèrent les procès d'intention plutôt que le code lui-même, c'est une autre manière de dépenser son temps

j'ai hésité a répondre a ça , parceque la partie "plutôt que le code lui-même" est ambigue ...

parles t"il du fait que je ne post pas de code ?
non parceque .... m'enfin ... non rien , on va encore dire que ....

bon je sort

Dobro a écrit :

D'autres préfèrent les procès d'intention plutôt que le code lui-même, c'est une autre manière de dépenser son temps

j'ai hésité a répondre a ça , parceque la partie "plutôt que le code lui-même" est ambigue ...
parles t"il du fait que je ne post pas de code ?
non parceque .... m'enfin ... non rien , on va encore dire que ....
bon je sort

C'est juste que je me demande ce que ce genre de remarques vient faire dans la discussion:

Dobro a écrit :../..du reste , il existe des produits pro comme Maya,3dSmax, et j'en passe (meme un produit cree par Pixar de memoire )
qui disposent de renderer qu'un programme fait en Purebasic n'arrivera jamais a atteindre ... (je crois pas au pere Noel )../..

Dobro a écrit :../..je ne sais pas trop ou grabiller veut en venir , ces codes sont intéressants , mais je ne rapprocherai pas ça, même de loin
avec ce qui se fait en Production Cinématographique ...../..

Dobro a écrit :../..un mec tout seul deja , c'est utopique de le voir développer un outils (quelque soit le langage) , qui rivaliserai ce qui se fait deja dans le cinéma../..

Dobro a écrit :../..grabiller a peut etre des talents cachés .... mais pour le moment, j'attends de voir ....
entre l'envie,et le possible , la différence est grande .... comme l'univers

Et ?

C'est ce que j'appelle un procès d'intention. Juger du bien fondé ou non d'une démarche parce qu'à tes yeux cela paraît bien ou pas, possible ou pas.. Comme si j'avais à te prouver quelque chose ou t'en rendre-compte. Pardonnes-moi Dobro, mais on s'en fout un peu.

L'intérêt d'un tel thread c'est plutôt de parler du code lui-même, non ? On est tous fan de PureBasic, on se fait plaisir, on expérimente, on partage, on discute.

Parles-moi plutôt du code. As-tu détecté des erreurs ? Y-a-t-il des parties où j'aurai pu m'y prendre d'une meilleure façon ? As-tu des suggestions pour l'améliorer ? Mon portage n'est certainement pas ce qu'il y a de plus parfait il y a certainement des choses à discuter, bien que je n'ai pas chercher vraiment l'optimisation. A mon sens, c'est cela qui est intéressant.

Si ce code ne t'intéresse pas, il n'y a pas de soucis, mais à ce moment là quel intérêt de venir faire le rabat-joie ?

G-Rom a écrit :../.. Pour ton projet raafal , tu en est ou ? ../..

Exactement à ce point:
http://www.purebasic.fr/french/viewtopi ... 36#p155736