Reprise du message précédent :
laposte.net, c'est de la merde en boite

 
... aux lettres

 
laposte.net -> La poste pas nette !

 
oui j'y ai pensé aussi, et ca me semblait trop marrant pour que ca soit moi qui la fasse, merci a toi

 
putain elle était bonne en plus

on est en train de chanter des trucs débiles dans le bureau

bordel, 1/2 heure que j'essaie de joindre un pdf de 1,16 Mo à mon mail, et ça marche pas

Ah ca y est je me rapelle de ma question (crefieu)
 
Bon, imaginez un arbre qui a soit 4 fils a chaque noeud, soit aucun. Un quadtree donc .
Maintenant a chacun de ses noeuds on a pas 2 floats et un int qui se battent en duel, mais un bon gros tableau balourd de 512x512 entier. Un gros mastoc quoi, d'autant plus que l'arbre risque d'etre assez...volumineux.
La grosse feinte, c'est que pour calculer le tableau d'un noeud on a besoin du tableau de ses 4 fils (sauf pour les feuilles, bien sur). Bon, hop recursivité, en faisant bien le menage derriere soit ca devrait passer peinard sans trop saturer la RAM. (tiens jme demande, ca serait fait en C++ le truc, mais en Java je risque pas d'avoir des pb de RAM si le GC passe pas assez rapidement pour vider mes saloperies ? Ouais nan chui con si manque de RAM il doit forcement etre appelé pour essayer de grapillé ce qu'il peut. heuh bon bref)
 
Pb : Comment stocker un tel bestiau sur disque de facon a ce qu'il soit facile et rapide de retrouver un noeud N ? Sachant que, pour faire simple, au moment ou je vais avoir besoin de l'arbre je vais avoir besoin des racines en premier, et ensuite de descendre dans l'arbre. Bref l'inverse de comment il est stocké sur disque (a priori, vu l'ordre de calcul). Et faut que le loading bourre, ca va etre en run time, donc laissons tomber les seeks a tout va.
 
J'verrais bien un gros arbre d'index (eg le meme arbre que le gros avec les 512x512 sauf que l'on stocke juste l'offset ou se trouve ledit 512x512) stockée en cul de fichier et chargé integralement au lancement du prog, mais y'a ptet plus fin ?

question subsidiaire : un algo de compression d'image qui :
->compresse bien
->compresse aussi l'alpha
->decompresse vite
 
vous avez ca sous la main ?

déjà pour stocker ton arbre tu peux faire une BD... les SGBD sont justement super rapides pour ce genre d'exercices

Arbre -> XML

 
eurf, tu me demande d'installer une BD ?
C pour un moteur 3d, je me vois pas trop demandé a l'utilisateur d'installer un sgbd

 
et j'y met quoi dans ton XML ?

SQLite

Bof
Vu la taille du truc, je pense pas que ça soit top

 
bin ton arbre

 
   
 
edit: je voulais mettre le pokemon , cette journée est vraiment pourrie....

 
si il passe par du SAX pour relire le bourzin y a moyen

Mais vous êtes fous, avec votre XML

 

 
L'a interet a etre couillu le parseur hein
 
dites je veux pas charger mn arbre avec les 512x512 dans son integralité, sinon le type il a interet a avoir un foutu paquet de memoire

 
jme viens deja bien stocker mes images en ASCII moi

 
mais SAX tu connais? Si c'est l'occupation mémoire qui le gêne, c'est la méthode à utiliser.
 
Et bon son arbre il doit le rendre persistent d'une manière ou d'une autre non?

 
bin justement avec SAX tu ne prends que ce qui t'intéresse et tu skippes le reste

je t'avouerais etre reticent a l'idée d'utiliser un format ascii pour stocker mes données furieusement binaire. L'engin a la fin risque deja d'etre hyper volumineux en binaire alors en ascii....

Vala, c'est ça que j'dis. OK, SAX c'est jouli tout plein pour la mémoire, m'enfin des grosses textures bien binaires, tu les fous comment dans ton XML ? Encodées en Base64 ?

Question plus balaise pour ceusse qui s'y connaissent en imagerie (moktar non )
 
mes 512x512 c'est un bitmap.
le bitmap d'un Noeud N c'est juste le bitmap de 1024x1024 formé par ses 4 fils, retaillé en 512x512. D'ou forte correlation.
N'y a t'il pas moyen d'utiliser ce fait pour reduire la place utilisée sur disque ? ca me fait peur, des trucs genre 400Mo de texture
 
avec un truc a dictionnaire genre VQ y'aurait ptet moyen nan ?

 
euh j'ai pas tout compris
un noeud = 1 bitmap 512x512
et chacun des fils c'est quoi? si ce sont 4 bitmaps de 512x512 tu te reconstruis une image 1024x1024 genre
1 2
3 4
c'est ça?
sachant qu'un fils peut être un bitmap tout con, ou alors une reconstruction 1024x1024 (réduite en 512) d'autres fils

antp >> pourquoi cette recherche ne me renvoie qu'une partie infime des topics blabla@prog existants ? y'a eu un plantage ou quoi ?
 
http://forum.hardware.fr/forum1.ph [...] =2&subcat=

 
tu pars du bas, des feuilles. Pour une feuille tu construis le bitmap a coup de perlin noise et autre conneries que je passe.
Ensuite tu vas au pere des 4 feuilles que tu viens de construire, tu fous les bitmaps comme t'as decris et tu filtre pour redescendre en 512x512. et hop tu retourne au pere du pere et tu remet ca, jusqu'a etre a la racine
 
Stun arbre de bitmap quoi

 
Et 20 Millions d'années plus tard t'as une image en 512*512 c'est çà ?

Pourquoi stocker l'arbre complet ?
Tout ce qui t'intéresse, c'est le résultat de la racine non ?

 
qqes heure, tout au plus.
Maintenant regarde l'interet : tu pars du pere. Donc t'as une 512x512 qui approxime tout ce qu'il y a en dessous. vu de loin ca fait son petit effet. ensuite au fur et a mesure que tu t'approches, tu descend dans ton arbre, et les details apparaissent.
 
Conclu    : la classe
Conclu 2  : buy a new HD . le stockage me fout les chtouilles
 

 
j'ai bien une idée, en jouant uniquement avec des pointeurs sur les bitmaps stockées dans tes feuilles et à gros coup de modulo quand tu remonte... comme ça tu ne gardes que tes feuilles et l'image finale... je vais nager là, je réfléchirais mieux la tête au frais

 
ok, pas de pb, mais oublie pas que j'ai la petyte contrainte que c'est en run time, c'est a dire que bpc de tps CPU va etre utilisé a afficher une image, et si j'en bouffe trop en parrallele pour mes calculs ca va ramer et on va encore dire que c'est codé avec les pieds gnagnagna
(et toute les feuilles ne seront pas en memoire because trop lourd)
 
thks

1- Calcule toutes les images enregistre les en jpg.
2- Fait un MJPEG/RAR/ZIP/DIVX... de toutes tes images
3- Un fichier XML avec ton arbre et l'offset et position de l'image de chaque noeud dans le MJPEG/RAR/ZIP/DIVX...
 

while( Body.hungry )
{
     Body.feed();
}

 
   
 
 
(nan mais y a pas de static pour les membres d'une classe en php.. va falloir attendre php5..   )

la piscine est fermée cette semaine    
bon bah c'est mon chef qui va être content, du coup je faire du rab...

T'as qu'à faire du VRML!

(mon boss est lourd...vendredi il voulait à tout prix éviter de passer en ADO, aujourd'hui il veut surtout pas rester en DAO...:pt1cable

 
y a pas que lui