[Simil Miles]

http://www.cubeoverload.com/
http://www.cubesque.com/

http://www.secondlifeinsider.com/200...stery-at-hand/
http://forums.secondlife.com/showthread.php?t=179531
http://forums.secondcitizen.com/showthread.php?t=11718




En bref, la création 3D dans SL est à l'aube d'un grand changement qui devrait être annoncé demain (vendredi 27 Avril).
Linden Lab a laissé filtrer quelques informations sous forme d'énigmes, on n'en sait pas beaucoup plus, mais il semble que le changement consiste en la possibilité de créer des formes plus libres.

[Old Lodge Skins]

Intéréssant...
Avec un peu de chance cela glissera peut-être vers la possibilité d'importer des objets réalisés avec des softs externes. C'est l'amateur de Blender qui parle là... Je sais bien qu'il existe déjà une méthode pour importer des scènes créées avec Blender mais cela se limite à l'utilisation de primitives tout comme dans SL - logique - d'où un intérêt très limité.

Seb.

Selon les rumeurs, ce serait un programmeur Linden qui serait derrière tout cela.
http://www.qarl.com/qLab/?p=47

Edit, il semblerait bien que ce soit qarl Linden, développeur dans les bureaux de San Francisco qui soit à l'origine de ce truc (http://www.qarl.com/menu/).

[Simil Miles]

Citation :

Publié par Old Lodge Skins

Je sais bien qu'il existe déjà une méthode pour importer des scènes créées avec Blender mais cela se limite à l'utilisation de primitives tout comme dans SL - logique - d'où un intérêt très limité.

Seb.

A ce propos, j'ai réalisé un outils permettant d'exporter de SL vers Prim.Blender et SLPrims.
Si les données de ces nouvelles formes peuvent être récupérées par LSL...

[T_T]

ca me parait bizarre a mon avis c un encore un canulard...

[Nibb]

Je suis un peu de l'avis de matt. Si jamais c'était vrai, ce serait une révolution: plus de la moitié des objets dans SL seront obsoletes parce qu'on pourra faire mieux avec moins de prims. Ensuite, comment appliquer une texture à ce genre de prims ? Il faudra aussi un nouvel éditeur ? Et des interfaces pour scripter ces objets ?

Au mieux, c'est peut-être une bidouille au niveau du nouveau client open-source, mais je doute que ce soit transposé sur le main grid avant un moment.

Ou alors, c'est encore un développeur de Linden qui a choisi de bosser sur un truc parce que c'est cool, au lieu de se pencher sur les vrais problèmes (1.15: mes pantalons sont encore moulants)

[~#Nyc#~]

//HS: Nibb je les aime moi, tes pantalons moulants^^ //Fin du HS

Le bug des "pantalons serrés" est vraiment étrange. Beaucoup de joueurs le subissaient (comme moi et pas mal d'amis) mais le passage à une version suivante semblait l'avoir définitivement supprimé.
Pour preuve, ce bug ne remonte plus sur le bug tracker JIRA (ce qui ne veut pas dire qu'il soit résolu, je le sais) ni sur les forums et je n'ai eu aucune autre info dessus depuis un bon mois:
https://jira.secondlife.com/browse/VWR-37

Je me demandes si il ne s'agit pas d'un bug résiduel sur certaines configurations mais d'un point de vue général, il ne semble plus affecter grand monde.
Je suis désolé si quelques résidents en souffrent encore mais peut-être faut-il chercher une correction au cas par cas.

[Simil Miles]

Citation :

Publié par Nibb

Je suis un peu de l'avis de matt.

Haha on ne veut pas y croire hein.
J'ai écris un grand changement mais j'aurais tout aussi bien pus écrire une petite révolution.
Pour l'application des textures je ne sais pas, peut être bien que ça sera comme les avatars avec une carte.
On ne sait pas encore quelle est la technologie utilisée, si c'est de la manipulation 3D directe ou si il faut passer par une texture comme pour les terrains.

Le fait est qu'il y a déjà un nouvel éditeur partiellement implémenté dans le client.
Vu à quand remonte les dernières avancées et depuis combien de temps ils travaillent sur celle ci, je crois que c'est pour très bientôt.

Pourquoi des interfaces pour scripter ces objets ? Tu voulais peut être dire des fonctions, là oui j'espère bien qu'il y en aura.

D'après les différents liens, cela semble bien être l'oeuvre d'une poignée de Linden.
Je ne vois pas quels vrais problèmes feraient le poids face à cet avancement, à part la perte d'inventaire. Donc les pantalons moulants...

[DD Ra]

De toute façon soyons clair, à chaque mise a jour Linden Labs (LL) fait craquer les coutures de Second Life un peu plus.

La dernière réelle amélioration, First Look, a été longuement testée mais sa mise en application n'a pas été sans mal (passage a la 1.14)

Si LL ne résout pas ses problèmes d'incapacité à accueillir sur la grille plus de monde, et les bugs sans fin des systèmes de communication, transport, construction, ne stabilise pas un tant soit peu les fonctionnalités de script (au moins pour des périodes fixées en prévenant à l'avance) peu importe que de "super avancées" soit faites.

Bien au contraire, toutes les "avancées" décidées par LL on le plus souvent pour effet de mettre à mal un peu plus la machine, et / ou de perturber l'économie et le tissus social fragilisé du metaverse.

Ne nous leurrons pas, le "hype" Second Life ne sera pas éternel, et fonctionne pour beaucoup parce que le coût d'une présence sur SL est faible du point de vue d'une grosse boite, en terme de pub (surtout quand on fait principalement de l'effet d'annonce)

Si LL ne réussis pas rapidement à reprendre en main le metaverse en respectant la vie de ses résidents... et bien un jeu en ligne aura disparu et une expérience sera enterrée. Et pour beaucoup d'entre nous, se sera la douloureuse perte d'une deuxième vie aussi belle qu'éphémère.

Il fait beau dehors... je vais aller y faire un tour, il ne faut pas que j'en perde trop l'habitude, au cas ou.

Bises.

DD Ra.

[buttbadger Mirabeau]

omg!!! faites que ça soit pas un fake!!!

ça ça va ouvrir de nouvelles voies!! *essaie d'imaginer avec excitation ce qu'il peut réaliser avec ces possibilités*

[Simil Miles]

HORS SUJET
Le problème avec SL vient du fait que (je me demande pourquoi) LL a changé de politique en sortant des nouvelles versions plus souvent ce qui empêche tous les bugs d'être fixés à temps.

En fait si il y avait plus de monde plus souvent sur la beta grid, il y aurait moins de bug sur la main grid.
HORS SUJET

[Old Lodge Skins]

Je ne saisis pas ce qui vous gêne tous avec les textures...
Comment croyez-vous que les développeurs 3D fassent? Quand je crée une scène je ne me contente pas de primitives, bien au contraire... J'extrude, je découpe, je déforme... Cela ne m'empêche pas de texturer mes objets! Donc je ne vois pas pourquoi cela devrait être différent dans SL, s'ils peuvent gérer des formes plus complexes alors ils doivent pouvoir appliquer les textures comme il faut...

Seb.

[Simil Miles]

Citation :

Publié par Old Lodge Skins

Je ne saisis pas ce qui vous gêne tous avec les textures...
Comment croyez-vous que les développeurs 3D fassent? Quand je crée une scène je ne me contente pas de primitives, bien au contraire... J'extrude, je découpe, je déforme... Cela ne m'empêche pas de texturer mes objets! Donc je ne vois pas pourquoi cela devrait être différent dans SL, s'ils peuvent gérer des formes plus complexes alors ils doivent pouvoir appliquer les textures comme il faut...

Seb.

Ben je crois qu'on est pas dev 3D.
"comme il faut" ne veut pas dire "facilement".
Dis nous donc comment tu appliquerais une texture différente à chaque bras de patrik l'étoile de mer s'il n'a qu'une seule face.

Plusieurs personnes parlent de displacement mapping: http://en.wikipedia.org/wiki/Displacement_mapping

[master71]

en créant une texture composite comme celles utilisées pour les avatars?

Plus sérieusement.
si pour régler le fond du problème, à savoir le lag et la charge serveur, LL décide de réduire le nombre de prims gérés par les serveurs, et de réduire sérieusement les prims inutiles qui ne servent qu'à la déco.

Et bah LL a choisi de créer des prims hybrides, nouvelles, l'avantage moins de charge serveur, plus de charge client, l'ancien est préservé, et le nouveau pose moins de soucis.

un autre choix de fond aurait été de revoir totalement la gestion des prims, leur codage, stockage, aussi bien côté client que coté serveur.

alors déjà que Nibb rouspète parce qu'une bonne partie des objets seraient obsolètes, mais si il fallait faire table rase de tous les objets existants, j'imagine même pas la fin du monde... :chu=

[Alan Seungmo]

l'anpe va avoir du boulot lol

[Old Lodge Skins]

Citation :

Publié par Simil Miles

Ben je crois qu'on est pas dev 3D.
"comme il faut" ne veut pas dire "facilement".
Dis nous donc comment tu appliquerais une texture différente à chaque bras de patrik l'étoile de mer s'il n'a qu'une seule face.

... Faudrait d'abord que tu m'expliques comment tu peux obtenir un objet avec une seule face?
Même un vulgaire plan a deux faces. Un recto et un verso.

Tiens voici un exemple de scène qui n'a plus rien à voir avec des primitives... La plupart des pièces sont extrudées à partir de cylindres - mais elles n'ont plus grand-chose à voir avec les formes d'origine - et si je me souviens bien j'ai réalisé les cavaliers à partir de courbes 2D... L'échiquier est un cube aux bords arrondis, chaque case a sa propre texture en fonction de sa position, même chose pour le bord... Toute cette complexité ne m'a pas empêché de texturer la chose, cela n'a même pas été très difficile...




Je n'ose pas imaginer le nombre de primitives que cela nécessiterait avec SL, probablement 3 à 4 fois plus que je n'ai d'objets dans ma scène. Donc en effet comme master71 l'a dit la possibilité d'utiliser des objets plus complexes, et non plus de simples primitives, diminuerait certainement la charge serveur... Et les capacités de texturage dépendent à mon sens surtout de l'implémentation par LL.

edit: et pour répondre d'une façon un peu plus précise à la question d'origine... Pour texturer efficacement un objet complexe, en-dehors de la nécéssité d'avoir les textures ad'hoc - ce qui est normal, à chacun de préparer ses textures - il suffit de pouvoir sélectionner des "régions" (je simplifie...). Ceci semblera peut-être plus parlant: les faces de l'échiquier en rose sont celles actuellement sélectionnées... Un seul et même objet, mais de nombreuses faces.

[Iceman Arkin]

Citation :

Publié par Old Lodge Skins

... Faudrait d'abord que tu m'expliques comment tu peux obtenir un objet avec une seule face?
Même un vulgaire plan a deux faces. Un recto et un verso.

Tiens voici un exemple de scène qui n'a plus rien à voir avec des primitives... La plupart des pièces sont extrudées à partir de cylindres - mais elles n'ont plus grand-chose à voir avec les formes d'origine - et si je me souviens bien j'ai réalisé les cavaliers à partir de courbes 2D... L'échiquier est un cube aux bords arrondis, chaque case a sa propre texture en fonction de sa position, même chose pour le bord... Toute cette complexité ne m'a pas empêché de texturer la chose, cela n'a même pas été très difficile...




Je n'ose pas imaginer le nombre de primitives que cela nécessiterait avec SL, probablement 3 à 4 fois plus que je n'ai d'objets dans ma scène. Donc en effet comme master71 l'a dit la possibilité d'utiliser des objets plus complexes, et non plus de simples primitives, diminuerait certainement la charge serveur... Et les capacités de texturage dépendent à mon sens surtout de l'implémentation par LL.

Je suis tout a fait d'accord!!!!
Je suis plus spécialisée dans les bases de données, mais C une évidence : si on n'utilise plus qu'une prim complexe au lieu de 2 simples (par exemple), on a un peu alourdir la gestion de la prim (donc son temps de traitement), mais on aura divisé par 2 le nombre de prims à gérer.

En gros, même si les prims complexes coûtent 30% de temps de calcul en plus, 1,30 est très inférieur à 2!!!

Et je ne parle là que de passer d'une structure pas trop compliquée à une plus simple !!!

Imaginez, pour un objet contenant 13 prims, si on passe à une complexe, on divise par 10 (eh oui !!!) le temps de traitement.

Tout le monde y gagnera !!!

Pourvu que ça ne soit pas un canular et que ça fonctionne vite !!!

[Simil Miles]

Citation :

Publié par Old Lodge Skins

... Faudrait d'abord que tu m'expliques comment tu peux obtenir un objet avec une seule face?

heh ben la sphère et le torus ont 1 seule face.

Le patrik etoile de mer semble avoir été fait à partir d'une sphère, si on eut peut définir des zones à texturer tant mieux, sinon ça va être la même galère que pour les avatars avec les cartes UVW pour afficher ce qu'on veut où l'on veut.

Citation :

Publié par Old Lodge Skins

chaque case a sa propre texture en fonction de sa position,

Hm mais comment tu définies la position de chaque texture ? à la main ? et si la forme n'es pas homogène/symétrique.

Citation :

Publié par master71

Et bah LL a choisi de créer des prims hybrides, nouvelles, l'avantage moins de charge serveur, plus de charge client, l'ancien est préservé, et le nouveau pose moins de soucis.

Citation :

Publié par Iceman Arkin

Imaginez, pour un objet contenant 13 prims, si on passe à une complexe, on divise par 10 (eh oui !!!) le temps de traitement.

Tout le monde y gagnera !!!

La vraie question c'est : est ce que le lag serveur perdu vaudra le lag client gagné, j'en doute, c'est assurément LL qui y gagnera - ils détestent qu'il y ai une charge trop lourde sur leur base de données /réseau.

Citation :

Publié par Iceman Arkin

Pourvu que ça ne soit pas un canular et que ça fonctionne vite !!!

Dans 1h précise on devrait être fixé.
La prochaine beta pourrait inclure quelque chose fonctionnel...

[master71]

Citation :

Publié par Simil Miles

La vraie question c'est : est ce que le lag serveur perdu vaudra le lag client gagné, j'en doute, c'est assurément LL qui y gagnera - ils détestent qu'il y ai une charge trop lourde sur leur base de données /réseau.

ne pas confondre laguer et ramer.
si la plate-forme lague moins le client lague moins, si il y a plus de traitements côté client, ça ramera peut-être plus, mais ça ne laguera pas.

Et il suffira de cocher une case ou de bouger un truc pour que ça ne rame plus chez le client, tandis que le lag, c'est pas une case à cocher.

[Nibb]

Citation :

Publié par master71

Et bah LL a choisi de créer des prims hybrides, nouvelles, l'avantage moins de charge serveur, plus de charge client, l'ancien est préservé, et le nouveau pose moins de soucis.

Je n'en suis pas si sûr. L'intéret des prims actuels, c'est que chaque prim est défini par une vingtaine de paramètres "float" qui sont transmis au viewer. C'est le viewer qui s'occupe de dessiner chaque prim.

Une prim comme le barbapapa là haut doit utiliser au minimum 10 fois plus de paramètres pour le définir, ce qui veut dire 10 fois plus long à transmettre au viewer, 10 fois plus d'espace serveur, 10 fois de calcul au niveau du client avec le même moteur d'affichage qui a déjà beaucoup de mal à suivre.

Sans compter que ça remet en cause la valeur de la véritable "matière première" de SL, les prims. Le principal business de SL, c'est l'hebergement de données, dont l'unité de calcul est la prim. Autoriser des formes complexes là où les gens payaient pour utiliser 10 ou 20 prims, ça change la donne économique pour LL.

En fait, si LL voulait réduire le nombre de prims, le moyen le plus simple serait de lever quelques limitations artificielles comme la limite de 10m. L'existence de Méga prims prouve que cette limite n'existe que pour que LL puisse facturer un maximum de prims.

[Old Lodge Skins]

Citation :

Publié par Simil Miles

heh ben la sphère et le torus ont 1 seule face.

Perdu, il y en a deux... Une a l'intérieur, que la plupart du temps on ne voit pas à moins de rentrer dans l'objet, et une à l'extérieur. Et encore je simplifie en appelant "faces" ce qui est, en réalité, constitué d'une multitude de faces constituant une surface. Mais avec SL cela n'est pas visible - pour l'instant.

Citation :

Publié par Simil Miles

Hm mais comment tu définies la position de chaque texture ? à la main ? et si la forme n'es pas homogène/symétrique.

Voir ma capture d'écran de Blender dans le post que tu cites... Je pense qu'elle doit être assez explicite en elle-même. Le maillage en fil de fer est visible (car ici cette pièce est en mode édition), chaque vertice (les "points" que tu voies) est un point clé manipulable. Plusieurs vertices connectées entre elles forment une face - ici des quadrilatères car j'ai appris qu'il fallait éviter les triangles. Chaque vertice peut se voir appliquer une texture... Quand toutes les vertices d'une face ont la même texture alors cette face prend la texture en question.

Naturellement je ne dis pas que cette façon de faire est transposable sur SL... Je ne fais pas partie de l'équipe de développement. Je fais juste état de ce que je connais.

[master71]

Citation :

Publié par Nibb

Je n'en suis pas si sûr. L'intéret des prims actuels, c'est que chaque prim est défini par une vingtaine de paramètres "float" qui sont transmis au viewer. C'est le viewer qui s'occupe de dessiner chaque prim.

40 paramètres dont 8 chaînes, juste pour les textures et les couleurs sur un tore, donc 20 c'est en dessous de la réalité.
ensuite, les dimensions d'un prim étant de 0 à 10 par pas de 0.001, quand c'est pas de 0 à 1, il suffit de 14 bits pour les coder, ils sont donc plus que probablement stocké en FP16, et pas gourmand en taille.

Citation :

Une prim comme le barbapapa là haut doit utiliser au minimum 10 fois plus de paramètres pour le définir, ce qui veut dire 10 fois plus long à transmettre au viewer, 10 fois plus d'espace serveur, 10 fois de calcul au niveau du client avec le même moteur d'affichage qui a déjà beaucoup de mal à suivre.

Ce qui donne du mal à ton viewer, c'est pas la complexité des prims, c'est le temps de tout rattraper et télécharger.
je le vois bien, quand j'arrive sur une zone, j'ai toujours au moins 30 à 40 frame/s, mais je vois les bâtiments et autres objets se charger en temps réel par ce que le serveur lag et ne transmet pas assez vite les données.
Alors si un prim complexe comme l'étoile comporte une 100aine de paramètres, comme ça en remplace une 10aine, ça allège beaucoup.

Citation :

Sans compter que ça remet en cause la valeur de la véritable "matière première" de SL, les prims. Le principal business de SL, c'est l'hebergement de données, dont l'unité de calcul est la prim. Autoriser des formes complexes là où les gens payaient pour utiliser 10 ou 20 prims, ça change la donne économique pour LL.

c'est bien ce que je pensais, tu veux régler les soucis de SL, mais pas au prix de changer le système.
mais le jour ou SL se penchera sur une version 2 plus légère, plus optimisée, plus performante, plus ouverte, faudra faire table rase.

Citation :

En fait, si LL voulait réduire le nombre de prims, le moyen le plus simple serait de lever quelques limitations artificielles comme la limite de 10m. L'existence de Méga prims prouve que cette limite n'existe que pour que LL puisse facturer un maximum de prims.

ou par bug exploit.
et désolé mais, LL facture non pas sur les prims, mais sur les terrains et les îles...
ce qu'il y a dessus, ils s'en foutent, les nombres de prims sont donnés par ce que peut supporter un serveur comme charge.

[Old Lodge Skins]

J'ajouterai que le comptage du nombre de prims n'est pas nécessairement la méthode la plus efficace...

Si je reprends mes explications précédentes, et dans l'hypothèse où il serait possible de créer des objets complexes sans limites (c'est juste une hypothèse de travail, hein!) alors il n'est plus intéréssant de compter le nombre d'objets (qui ne sont donc plus des primitives)... Au lieu de cela il suffit de compter le nombre de vertices par objet.

Plus il y a de vertices, plus l'objet est complexe et lourd à gérer... Donc au lieu d'avoir un nombre maximum d'objets par terrain il y aura un nombre maximum de vertices. Que ce soit en un seul ou en mille objets... Ce qui permet de continuer à insérer des limitations portant sur la complexité.

Seb.