[Non officiel] Concours SCRIPT (GML CUP n°2)

Je comprends très bien ton point de vue, mais le débat était parti d'un algo d'encodage d'"images 3D", or ça n'existe pas (encore ?).
À moins de considérer un tableau tridimensionnel plutôt que bidimensionnel pour stocker les valeurs de couleur... Il y aurait alors la même différence entre cette image et un modèle accompagné de sa texture qu'entre une image matricielle standard et un dessin vectoriel.

Sinon, on peut bien évidemment projeter les images selon une troisième dimension pour les examiner simultanément (sur deux plans parallèles donc) mais ce n'est pas obligatoire étant donné que les images ont une taille finie : tu peux les juxtaposer sur le même plan sans intersection.

Houlà, que de réponses intéressantes !

Non, en fait, dans mon idée, on fessait un convertisseur de deux images, ou d'une image anaglyphe (ou autre je suis pas sectaire) vers une image "3D". Appelons ça 2D.5.

Il s'agirait d'une image (du genre affichée par les téléviseurs "3D" actuels) contenant une image "2D" classique et une couche de profondeur.

Et le programme utiliserait la couche de profondeur pour afficher une image 2D.5 selon la méthode voulue (anaglyphe, cross-eyes, entrelacement, etc.).

Le 'standard' porterait sur le format de fichier en lui même (image2D lisible normalement + couche 3D).

Pour ça, dans un premier temps je pensait compléter une image JPG ou PNG (on peut rajouter des champs; des plages de données, dans ces fichiers) puis créer de toute pièce un format d'image compressé (compression par ondelettes pour les 4 couches : H, S, V, Profondeur).

Voilà l'idée de base donc.

ouai enfin faire du traitement d'image avec GM voila quoi...

j'oserai même pas imaginer la lenteur du truc.

Ça va pas coller, désolé. J'dois pas être clair, ç'ma faute

L'astuce c'est que, tout le long du traitement (que ce soit le rendu numérique ou la prise de vue), ces images ne sont JAMAIS en 3D. Ce sont de bêtes images 2D qui sont juste groupées deux par deux (juste triées, pas interpolées). C'est le cerveau (notez bien, uniquement lui) qui fait tout le boulot quand on présente une image à chaque œil et que ça concorde, et là on a l'impression de 3D.

Pour ce qui est de l'algo, coder une image avec un champ de profondeur, well, pourquoi pas. En fait ça revient exactement à plaquer une texture sur une heightmap. Pas de souci pour l'encodage, on peut même détourner le canal alpha en canal profondeur pour pas trop se les casser, piece of cake.

Par contre, je pense pas que ce soit possible, enfin pas avec des résultats probants :
Imagine un cube pile face à toi, assez proche pour que ton œil gauche voie la face gauche en même temps que le droit voit la face droite. Impossible d'encoder les deux faces, puisque quand tu projetteras le cube sur un plan (la matrice de ton image) il sera strictement impossible de voir deux faces opposées.

D-z a écrit:

Ça va pas coller, désolé. J'dois pas être clair, ç'ma faute

L'astuce c'est que, tout le long du traitement (que ce soit le rendu numérique ou la prise de vue), ces images ne sont JAMAIS en 3D. Ce sont de bêtes images 2D qui sont juste groupées deux par deux (juste triées, pas interpolées). C'est le cerveau (notez bien, uniquement lui) qui fait tout le boulot quand on présente une image à chaque œil et que ça concorde, et là on a l'impression de 3D.

Oui, oui, sur ce point, pas de blems.

D-z a écrit:

Pour ce qui est de l'algo, coder une image avec un champ de profondeur, well, pourquoi pas. En fait ça revient exactement à plaquer une texture sur une heightmap. Pas de souci pour l'encodage, on peut même détourner le canal alpha en canal profondeur pour pas trop se les casser, piece of cake.

Oui, je pensait à ça pour un affichage 3D (mais juste une vue, où on aurait pu tourner autour de l'image, et voir qu'il ne s'agissait que d'une heightmap).
En revanche, un l'affichage anaglyphe, il y aura plus de boulot, puisqu'on partirait d'une profondeur et d'une image pour en générer deux.

D-z a écrit:

Par contre, je pense pas que ce soit possible, enfin pas avec des résultats probants :
Imagine un cube pile face à toi, assez proche pour que ton œil gauche voie la face gauche en même temps que le droit voit la face droite. Impossible d'encoder les deux faces, puisque quand tu projetteras le cube sur un plan (la matrice de ton image) il sera strictement impossible de voir deux faces opposées.

Yep. Ce pourquoi, le rendu anaglyphe ou entrelacé ou cross-eye reste moins destructif.
Et ce pourquoi stoker juste une couche de profondeur n'est pas suffisant.


@shm3A012B42FE3 & onilink_ :
Oui, je sais, mais c'est juste pour prototyper différents affichages .
Quand je voit la vitesse à laquelle je lit un chunck de minecraft sous GM, je sais bien que c'est pas possible un truc potable sous GM.
Mais le problème c'est qu'aucun compilateur ne marche chez moi >_<
(J'ai encore essayé d'installer GCC pour windows mais rien n'y fait, ça foire. Et pourtant, j'ai modifié les variables d'environnement é__è )

Utilise gcc/g++ en ligne de commande. Perso c'est ce que je fait, moi les linkage qui marchent pas et tout ça ça m'a vraiment trop emmerdé alors voila :

path_mingw\bin\g++ fichier.cpp fichier2.cpp [...] fichiern.cpp -o nom_out.exe [options]

pour les options tu peut mettre -s et -Os ça réduit le poids et optimise le code

ensuite pour choisir un chemin d'includes : -Ichemin
un chemin de libs : -Lchemin
linker une lib : -ltalib

Sans compter toutes les autres possibilitées.

Bon, je retire ce que j'ai dis plus haut.

Je ne participerais pas à cette compétition de TheDarkTiger. J'ai vraiment rien compris.

En plus, déjà que ça mettait trois plombes à s'afficher, mes machins en ray casting sous GM+Wine, alors, du traitement d'image pour ressortir des machins pseudo-3D.... Je crois que j'irais plus vite en les dessinant à la main quoi.

Pareil pour moi, là on ne boxe pas dans la même catégorie, c'est beaucoup trop de la "programmation pure" pour moi ...

Genre c'est possible avec GM

holà, détrompez vous !

je ne pensait an aucun cas faire un concours avec ce sujet (ou alors je me suis mal exprimé).
C'était juste une idée de sujet de réflexion. Voir ce que cous en pensiez, et qui serait assez fou pour essayer avec moi.
Mais de toutes façons, les vacances sont finies pour moi, donc, exit la prog pour quelques temps -__-'


Pour lancer un autre sujet de compétition, déjà, je vais attendre un peu, et ensuite, j'aurai plutôt pensé à des "Marching cubes" 2D (Marching squares ?). Mais pour l'instant , rien de définitif. Et surtout, ça sera fait que dans quelques temps ...

@onilink_ :
Oui, c'est comme ça que je faisait sur mon PC portable, et comme ça que j'aimerais faire sur mon PC fixe. Mais MinGW ne marche pas, pourtant, j'ai juste installé le compilateur (gcc pour windows quoi), mais ça plante ...

arf, au pire installe toi un ptit nunux, ou essaye une autre version de gcc ._.

Sinon dommage, moi je commençais a peine mes vacances :p

bha, je passe pour dire que, miraculeusement, ça marche maintenant (j'ai fixé les chemins en absolut par contre maintenant, tant pis é_è )

Et soit dit en passant, uDev à marché du premier coup ... va savoir

Bas content de te l'entendre dire, tu vas pouvoir t'éclater a faire du C/C++ maintenant

(perso je pourrais pas vivre sans ce compilo :p)

j'avoue que je tourne en rond depuis une semaine, car j'aimerais faire du GM, mais à chaque fois, il faut que je fasse un convertisseur en C avant (j'ai commencé à le faire en GM, en désespoir de cause, mais ça sert à rien, c'est bien trop lent -__-')

Ok, on attendra, pas de soucis

onilink_ a écrit:

Sinon dommage, moi je commençais a peine mes vacances :p

Moi j'en sors tout juste :'( ça me manque déjà

la rentrée arrive a grand pas T_T

Sinon vu que c'est le sujet je poste ici.
J'ai fait deux ptit raytracers en temps réel.
Le premier tourne a 35-40fps et le second a 15-20fps (sur mon pc : processeur 2.49GHz)
http://www.host-a.net/u/onilink_/raytracers.7z
C'est joli et léger, fait avec uDev++
(je posterais les codes source avec)
Sinon le concours ce finis un jour ? oupas ?

Ho yeay, porter du raytracer sous uDev, je voulait le faire le soir de sa sortie, mais y avait pas les fonctions ...

Je suis en dèche de temps, mais violent, alors, dès que j'ai du temps, je regarde ça

Et c'est du temps réel lol, alors qu'avec GM calculer une image me prenais 30 secondes xD


Ah le temps, c'est de plus en plus dur d'en avoir ._.
Sinon les sources je les ais pas encore posté , la c'est juste les exécutables (je mettrais les source avec la v1.2 ou je compte régler pas mal de trucs)

Puis pour le prochain concours, si uDev est suffisamment amélioré, ce serais ptêtre sympa de l'utiliser non ?
En plus je compte faire une méga doc avec des tuto sur la plupart des concepts de base du c++, donc ça pourrais en motiver certains
de s'y mettre :p

c'est bete : je ne peux pas voir ce qu'a fait oni (blackscreen)

Idem :/ Y'a quelque chose de particulier à faire ?

Bizarre, c'est des appli sdl+opengl , devrait pas y avoir de blem :/
Vous êtes sous quel os ?

edit : Je vais aller voir si ça marche sur le pc de ma sœur.
redit : ça fait pareil ._.
Je vais essayer de régler ça...

Voila, c'etait un problème de zbuffer qui ne fonctionne pas sur votre pc (je sais pas pourquoi)
De toute façon c'est pas grave, il servais a rien pour le moment, je comptait l'utiliser plus tard pour qu'on puisse blitter des sprites avec une certaine depth.

http://www.host-a.net/u/onilink_/raytracers.7z

La devrais pas y avoir de soucis, ça marche même sur le vieux pc de ma soeur :p

double post

Quadruple si compte les edit

Wow.

Ça fonctionne bien ? T'as combien en fps ?

Rooh, ça claque

Perso j'ai 45 FPS pour le 1er et 20 pour le second

50 FPS le premier et 20-30 FPS le second,entoucas ça rend bien :^D

Cool, content que ça fonctionne chez vous ^^
La source est dispo sur le topic d'uDev