[Elenia Boucher]

Bonjour

Cela fait longtemps que j'ai envie d'offrir à la communauté slienne un outil scripté, en full perm et GPL, quelque chose d'utile comme la ZHAO ou le MLP.

Ma première idée était de faire un organiseur de texture. J'ai commencé et abandonné car c'est trop de travail et que ma motivation s'est cassé la gueule quand j'ai vu la pléthore qu'il y a sur le marché en freebie.

Le défi de Best et le piston de Sextan m'ont donné l'idée d'un nouveau sujet: faire un prim animator, aussi bon que le célébre produit commercial Puppeeter. Je lui ai même trouvé un nom: le Priam.

Ma 1ére expérience m'a montré que je ne suis pas capable de le faire seule, surtout sur un sujet comme ça où les calculs mathématiques vont pas être piqués des vers avec les fonctions que j'envisage.

Aussi je demande ici si d'autres souhaiteraient collaborer à ce projet, dans un esprit collégial: tout peut être discuté y compris le nom. Si on arrive à réunir une équipe, on y va.

Il nous faudrait :
- Au moins 3 scripteurs
- Un testeur builder (et un peu scripteur ça aidera pour comprendre le fonctionnement) rédacteur du mode d'emploi (anglais indispensable )
- Un testeur builder candide (en script ).
- Un textureur pour faire un zoli hud et quelques belles images pour la distribution.

Enfin, j'aimerais le fournir avec quelques exemples: des builders/sculpteurs capable de faire 3 ou 4 zolis objets ou bestioles à animer sont bienvenus (autrement on devra trouver quelques freebies full perm).

Bien sur une personne peut tenir plusieurs rôles mais attention à la surcharge. Mon propos est de diviser le boulot pour que cela soit ni fastidieux ni décourageant. J'ai une idée précise de la division du boulot pour les scripteurs.

Alors bien sur il faut gérer ça comme un vrai projet, c'est à dire se donner les moyens et les outils. Je pense qu'il va falloir se créer un site web avec forum pour ne pas polluer ici avec nos discussions techniques, et se fixer une date butoir (je verrais bien ça en cadeau de Noël), quitte à la réviser si on y arrive pas : s'agit pas de bosser comme des bêtes, mais d'avancer régulièrement tous ensemble.

Cela vous branche ? Alors on s'inscrit ici.

Si il y en a qui veulent des éclaircissements ici, demander ici aussi: je préciserais le cahier des charges et vous montrerez ma maquette de HUD (faut que je les avance, mais je le ferais que s'il y a des personnes intéressées).

[Abracadabra *pooft*]

Ce produit existe déjà gratuitement , miss Trouvetout l'a trouvé en fouillant tout SL , c'est l'ancêtre du puppeeter et je m'en sers pour animer des p'tits trucs .

Mais parce que j'admire Todd qui est vraiment hyper sympa je me tairai , je trouve dommage de lui casser son marché .

T'as pas une autre idée stp stp ........

[Elenia Boucher]

Oui il existe quelques produits gratuits, comme le Prim Animator Lite (qui n'a plus l'air distribué) et que j'utilise. Mais ils sont trop limités et pas pratiques.

Et il n'est pas question de casser le marché: les produits commerciaux et libres cohabitent très bien : exemple: le MLP et les nombreux autres générateurs de ball, ou encore Gimp et photoshop.

Pourquoi pas un jeux a la places? genre un Uno avec une table.


Le puppeteer de todd est déja très complets il y a mème des Api

[black cats]

J'ai un peu de temps ces jours-ci, mais ce n'est pas toujours le cas. Et je suis plutôt du genre "je bosse dans mon coin". Donc, un mauvais candidat pour un projet d'équipe qui demande un engagement sur la durée.

En revanche, si tu as besoin d'un coup de main ponctuel sur l'aspect théorique, mouvements de solides ou autre, c'est quand tu veux, et avec plaisir

[Abracadabra *pooft*]

Citation :

Publié par Elenia Boucher

Oui il existe quelques produits gratuits, comme le Prim Animator Lite (qui n'a plus l'air distribué) et que j'utilise. Mais ils sont trop limités et pas pratiques.

Et il n'est pas question de casser le marché: les produits commerciaux et libres cohabitent très bien : exemple: le MLP et les nombreux autres générateurs de ball, ou encore Gimp et photoshop.

T'as raison , de toute façon SL recèle de tant de merveilles gratuites que quoi que tu fasses ça trouvera sa place .

PurplePanda a une bonne idée : un jeu serait la bienvenue . Je les collectionnais il y a longtemps et je me rappelle d'un mahjong que j'appréciais vraiment (perdu au fonds du gouffre de mon inventaire ) . Etant plus que nulle en scripts je n'ai aucune idée du niveau de difficulté pour en faire un .

Bonne chance dans ton projet et cela quel qu'il soit .

[bestmomo]

C'est un joli rêve Elenia. Le projet est en soi assez vaste et déjà sa définition me paraît délicate. Concerne-t-il uniquement des prims liées ? Il n'y a rien de plus mouvant que des objets qui bougent, surtout dans l'espace et quand on voit la difficulté pour se comprendre lorsqu'on décrit un mouvement j'imagine les données d'entrée . J'ai expérimenté un certain nombre de formules dans ce domaine : fixation d'étapes avec calcul d'interpolation , calculs de trajectoire... Mais chaque fois ce n'avait rien d'universel. Je pense que déjà une discussion sur la définition des possibilités envisagées pourrait déterminer les vocations .

[Ahuri Serenity]

Citation :

Publié par bestmomo

je pense que déjà une discussion sur la définition des possibilités envisagées pourrait déterminer les vocations .

+1

[Constance Brinner]

Citation :

Publié par Elenia Boucher

Bonjour

Cela fait longtemps que j'ai envie d'offrir à la communauté slienne un outil scripté, en full perm et GPL, quelque chose d'utile comme la ZHAO ou le MLP.

Ma première idée était de faire un organiseur de texture. J'ai commencé et abandonné car c'est trop de travail et que ma motivation s'est cassé la gueule quand j'ai vu la pléthore qu'il y a sur le marché en freebie.

Bonjour,

Non, il n'y a pas pléthore d'organiseur de textures bien fichu, free et full perm. Et même, ça manque carrément. Il y a grand organiseur de textures, thématique, qui est transférable, mais dans lequel on ne peut ni ajouter, ni retirer de texture. Il en existe plusieurs versions, avec la même interface, mais pas avec les mêmes textures dedans.

Et il y a un petit organiseur de textures, full perm, mais sans onglet thématique, ce qui fait que passé un certain nombre de textures, on ne sait plus ce qu'il y a dedans, sauf à faire défiler les textures indéfiniment.

Ormis ces deux là, à ma connaissance, il n'y a rien...

Constance

[Ahuri Serenity]

Moi j'imaginerai bien des organiseurs de texture qui manipulent des textures présentes dans une base de données centralisée. L'idée serait qu'un utilisateur lambda puisse rajouter à tout moment ses textures et qu'elles soient instantanément accessibles par tous les autres utilisateurs. C'est facilement utilisable grâce au système de clés. Après reste à gérer les dossiers et les catégories mais quoi de plus simple si on classe la texture au moment de l'ajout !

[black cats]

Pour le système "universel" d'animation de prims.

Je vois deux principes fondamentalement différents :

1) quelque chose de similaire à ce que l'on fait lorsqu'on définit une trajectoire par des "way point" :
demander à l'utilisateur de positionner manuellement les différentes primitives les unes par rapport aux autres, enregistrer les positions, déplacer toutes les prims, enregistrer, etc
Ensuite, le script devra faire des interpolations pour calculer les positions intermédiaires entre deux positions enregistrées.
Je suppose que c'est ça dont tu parles, Best ? "fixation d'étapes avec calcul d'interpolation".

Ca me semble faisable. Pas simple, mais faisable.

2) Autre principe : indiquer au logiciel des contraintes géométriques que l'on souhaite imposer, et laisser le logiciel se débrouiller pour calculer les positions des prims pour respecter ces contraintes.
Si je reprends l'exemple du bielle-manivelle :
- le vilebrequin est articulé en A avec le bâti
- la bielle est articulée en B avec le vilebrequin
- le piston est articulé en C avec la bielle
- le piston est en liaison glissière de direction Z avec le bâti (translation)
Faire quelque chose d'"universel" sur ce principe là, même en se limitant à des mouvements relatifs très simples, est du domaine de l'impossible avec le peu de moyens que nous accorde LL (limitation de la mémoire du script, sans parler du langage).

Si on veut simuler un mécanisme à partir de la première méthode, ça ne sera pas parfait, car les liaisons vont se "disloquer" légèrement entre deux way-points. Ça ne se verra pas trop si les way points sont suffisamment rapprochés.
Si on veut quelque chose de plus propre, il faudra toujours un script spécifique au problème.

Citation :

Publié par Constance Brinner

Bonjour,

Non, il n'y a pas pléthore d'organiseur de textures bien fichu, free et full perm. Et même, ça manque carrément. Il y a grand organiseur de textures, thématique, qui est transférable, mais dans lequel on ne peut ni ajouter, ni retirer de texture. Il en existe plusieurs versions, avec la même interface, mais pas avec les mêmes textures dedans.

Et il y a un petit organiseur de textures, full perm, mais sans onglet thématique, ce qui fait que passé un certain nombre de textures, on ne sait plus ce qu'il y a dedans, sauf à faire défiler les textures indéfiniment.

Ormis ces deux là, à ma connaissance, il n'y a rien...

Constance

Il y a celui de (creawling) FullP mais les scripts no mod, il est très pratique il est divisée en plusieurs catégorie donc on peut façilement rangée et classée,il y a celui de Soph oh je crois,il y en a d'autre FullP.

les marché sont saturée de Freebies. FullP

[black cats]

Citation :

Publié par Ahuri Serenity

Moi j'imaginerai bien des organiseurs de texture qui manipulent des textures présentes dans une base de données centralisée. L'idée serait qu'un utilisateur lambda puisse rajouter à tout moment ses textures et qu'elles soient instantanément accessibles par tous les autres utilisateurs. C'est facilement utilisable grâce au système de clés. Après reste à gérer les dossiers et les catégories mais quoi de plus simple si on classe la texture au moment de l'ajout !

Ca, ca serait fantastique.
Avec la possibilité de se faire envoyer la texture elle-même, et non seulement sa clé. C'est très pénible lorsqu'on construit, et qu'on essaye des textures pour voir celle qui va bien, d'utiliser un script à chaque fois qu'on veut remplacer la texture.

Quelque chose dans ce genre-là peut-être (pour des textures au lieu des mega-prims) ?
http://megaprim.sl/
Se poserait cependant un problème, qui ne se pose pas avec des mega-prims : la gestion des catégories.
- Le site devrait proposer un système de catégories (avec sous-catégories) judicieux
- il faudra faire confiance à l'utilisateur lambda qui ajoute une texture, pour qu'il affecte correctement sa texture à la bonne catégorie, sinon c'est le b***el

Mais peut-être qu'on s'éloigne du type de projet auquel pensait Elenia, à savoir un objet comparable au ZHAO qui se distribuerait in world.

En attendant, un tel service n'existe pas, et ferait certainement des milliers d'heureux.

[bestmomo]

Citation :

Publié par Ahuri Serenity

Moi j'imaginerai bien des organiseurs de texture qui manipulent des textures présentes dans une base de données centralisée. L'idée serait qu'un utilisateur lambda puisse rajouter à tout moment ses textures et qu'elles soient instantanément accessibles par tous les autres utilisateurs. C'est facilement utilisable grâce au système de clés. Après reste à gérer les dossiers et les catégories mais quoi de plus simple si on classe la texture au moment de l'ajout !

Un organisateur de textures interne à SL sera toujours pénible à cause du temps de chargement. La seule solution efficace serait d'avoir une base externe mais évidemment ça pose d'autres problèmes : création et alimentation de la base et création d'une interface.

[Ahuri Serenity]

Citation :

Publié par black cats

- il faudra faire confiance à l'utilisateur lambda qui ajoute une texture, pour qu'il affecte correctement sa texture à la bonne catégorie, sinon c'est le b***el

Effectivement, et aussi sur le droit à l'image, car à partir du moment où ton service distribue des images je me demande si tu ne peux pas être attaqué si quelqu'un s'amuse à placer dedans des textures non libres de droit voir des photos personnelles

Cela semble d'un coup plus compliqué

[Ahuri Serenity]

Citation :

Publié par bestmomo

Un organisateur de textures interne à SL sera toujours pénible à cause du temps de chargement. La seule solution efficace serait d'avoir une base externe mais évidemment ça pose d'autres problèmes : création et alimentation de la base et création d'une interface.

Qui a dit qu'elle serait interne ! Moi je pensais externe bien sur. Tous mes projets fonctionnent sur une base externe c'est pas pour rien, sur un projet tel que celui ci cela prend tout son sens

[bestmomo]

Citation :

Publié par black cats

1) quelque chose de similaire à ce que l'on fait lorsqu'on définit une trajectoire par des "way point" :
demander à l'utilisateur de positionner manuellement les différentes primitives les unes par rapport aux autres, enregistrer les positions, déplacer toutes les prims, enregistrer, etc
Ensuite, le script devra faire des interpolations pour calculer les positions intermédiaires entre deux positions enregistrées.
Je suppose que c'est ça dont tu parles, Best ? "fixation d'étapes avec calcul d'interpolation".

Ca me semble faisable. Pas simple, mais faisable.

Oui c'est exactement ça. Le gros souci c'est de définir la nature de l'interpolation : linéaire, cos, forme de la trajectoire... Je me suis posé ce genre de question déjà. Par exemple une simple porte avec les deux positions ouverte et fermée, l'interpolation n'est pas facile parce que la position de la porte doit suivre une courbe qu'il n'est pas aisé de définir. Et si l'utilisateur doit fixer plusieurs étapes intermédiaires il va avoir du mal. On en arrive rapidement à un système de définition de trajectoire matérialisé par des prims ou des particules. J'ai fait ça pour mon véhicule automatisé et je me suis rendu compte de la difficulté.

Ceci dit un tel outil manque vraiment et si nous arrivions ne serait-ce qu'à définir un type de fonctionnement ce serait déjà une grande réussite.

[black cats]

Citation :

Publié par bestmomo

Un organisateur de textures interne à SL sera toujours pénible à cause du temps de chargement. La seule solution efficace serait d'avoir une base externe mais évidemment ça pose d'autres problèmes : création et alimentation de la base et création d'une interface.

+1
C'est pourquoi une base de données externe, couplée à une base interne me semblait sympa.

Mais le problème de l'alimentation par l'utilisateur lambda reste posé. On rencontre (en pire) tous le problèmes qu'on rencontre individuellement lorsqu'on cherche à organiser les textures nombreuses qu'on a dans son inventaire : à quelle catégorie l'affecter, mais aussi, gestion des doublons etc...

[bestmomo]

Citation :

Publié par Ahuri Serenity

Qui a dit qu'elle serait interne ! Moi je pensais externe bien sur. Tous mes projets fonctionnent sur une base externe c'est pas pour rien, sur un projet tel que celui ci cela prend tout son sens

+1 c'était pas évident dans ton post

J'ai aussi tendance à externaliser mais pour un projet partagé se pose le problème du serveur.

[black cats]

Ca c'est du post populaire !!!
Le temps que l'on réponde à une intervention, trois autres arrivent.

[black cats]

Citation :

Publié par Ahuri Serenity

voire des photos personnelles

hm, on imagine les dérives

Bon , pour résumer, LE gros problème est l'alimentation libre de la base de données, pour moult raisons.

[Ahuri Serenity]

Citation :

Publié par black cats

Bon , pour résumer, LE gros problème est l'alimentation libre de la base de données, pour moult raisons.

MDR ! Si la principale qualité du truc est aussi son plus grand défaut on fait quoi ? ? ?

Bah on laisse tomber c'est tout

[black cats]

Citation :

Publié par bestmomo

Oui c'est exactement ça. Le gros souci c'est de définir la nature de l'interpolation : linéaire, cos, forme de la trajectoire... Je me suis posé ce genre de question déjà. Par exemple une simple porte avec les deux positions ouverte et fermée, l'interpolation n'est pas facile parce que la position de la porte doit suivre une courbe qu'il n'est pas aisé de définir. Et si l'utilisateur doit fixer plusieurs étapes intermédiaires il va avoir du mal. On en arrive rapidement à un système de définition de trajectoire matérialisé par des prims ou des particules. J'ai fait ça pour mon véhicule automatisé et je me suis rendu compte de la difficulté.

Ceci dit un tel outil manque vraiment et si nous arrivions ne serait-ce qu'à définir un type de fonctionnement ce serait déjà une grande réussite.

Je pense que pour un outil universel, ca ne marchera jamais si l'utilisateur espère saisir uniquement une position initiale et une position finale.
Pour avoir une interpolation un tant soit peu suffisante pour des positions tellement éloignées, il faudrait intégrer une fonction "boule de cristal" pour que le script choisisse l'interpolation qui donne le mouvement le plus proche de ce qu'attend l'utilisateur (pour deux positons extrêmes identiques, deux utilisateurs différents peuvent attendre un comportement intermédiaire différent). A moins de se limiter à un type très restreint de mouvements.
Ou encore, utiliser des interpolations plus sophistiquées genre "spline cubique". Mais ça, en plus de solliciter plus fortement la puissance de calcul du sim, est justement basé sur la prise en compte de plusieurs points successifs en non seulement 2. Ce qui exclut encore une fois la saisie des positions extrêmes seulement.

Point de salut alors, en dehors d’un nombre suffisant de positions saisies.
Ca résoudrait du coup le problème du choix de l’interpolation. Une interpolation linéaire suffirait.

Dans le cas d'une porte par exemple, ça peut donner un résultat acceptable, si l'utilisateur veut bien faire l'effort de définir au moins 5 ou 10 positions intermédiaires.
Encore une fois, un script spécifique donnera toujours un résultat plus propre. Je pense qu’on est d’accord pour dire qu’une porte serait une mauvaise utilisation d’un script universel, l'intérêt étant seulement de tester ce genre de script sur un cas simple.

En ce qui concerne la méthode générale pour interpoler les positions, il faudrait à tout prix commencer par lever tout ambiguïté sur ce qu’on appelle « position ».
Par « position d’un solide », j’entends sa position globale (incluant l’orientation, pour être plus clair), définie par 6 paramètres.
De même, ne pas raisonner en terme de « trajectoire », qui ne peut concerner qu’un point d’un solide (sous-entendu : le point défini par LL, et qu’ils appellent le centre), mais bien de variation simultanée des 6 paramètres de position.

Il y aurait beaucoup à dire là dessus, mais une des plus grosses difficultés est de se débarrasser des réflexes hérités de la cinématique du point.

[Elenia Boucher]

Le principe de mon projet est simple: on décompose le mouvement en frame de préférence courtes.

Pour chaque frame, on modifie la position des prims : rotation et position (et éventuellement texture all_sides) avec les outils de build. Quand on a fini, on clicque sur le bouton Record du hud et on enregistre les prims qui ont bougées pour la frame en question: cela impose que le script ai en mémoire toutes les positions précédentes et compare une à une avec les nouvelles positions. Par contre, on ne mémorise dans la frame que les prims qui ont bougées, et on relit le tout pour comparer avec la frame suivante.

Quand c'est fini, on clicque sur le bouton Notecard : on crache dans le chat n°de frame:N°prim<position><rotation>texture;N°prim<.... Plus qu'a recopier dans une notecard à mettre dans l'objet. Ajouter [LOOP] à la fin de la notecard si on veut une animation loopée ou one-shot. Je ne sais pas encore si on enregistre dans le hud (gros dialogue) ou plutot je pense dans un script record dans l'objet qu'on efface une fois la notecard faites pour alléger l'objet.

Je prévois des tas de fonction dans le hud: pouvoir insérer des frames, jouer l'animation que l'on est en train de faire, faire une série de x frames interpoler entre 2, faire un miroir suivant un plan d'une frame (plus d'une c'est trop compliqué)....

Et une fois la notecard faites, on ajoute des scripts trigger dans l'objet pour déclencher l'animation sur événement: on choisit le(les) script suivant ce que l'on veut : sur touch, sur radar, sur commande chat, ... trigger on_off, trigger one_shot avec reverse, ....

Joint: projet de hud pas encore fini

[black cats]

Citation :

Publié par Elenia Boucher

Le principe de mon projet est simple: on décompose le mouvement en frame de préférence courtes.

Le terme "frame" est bien moins ambigu que le "waypoint" que j'ai utilisé, mais on parle bien de la même chose.

Ca m'a l'air faisable.
Avec une interpolation simple, dans un premier temps.

Pour les "positions" (vecteur position des "centres"), il suffirait de faire la différence entre les vecteurs position finale et initiale, et diviser par le nombre de pas désiré entre deux frames.
ce qui donnerait entre deux frames :
vector step = (vectorfinal-vectorinitial)/N
puis répéter N fois
pos += step

Pour les rotations, je pense qu'un méthode similaire peut marcher :
utiliser llRotBetween(rotfinal, rotinitial)
En revanche, pour trouver les incréments de rotation, ça demande un peu plus de réflexion.

Une fois que ça marche, rien n'empêche d'apporter des améliorations dans le futur, sur les interpolations.

Concrètement : interpoler les trajectoires des centres (personne ne rit, je sais bien que je suis en contradiction avec une de mes remarques sur les trajectoires ) avec des polynômes du troisième degré, en prenant en compte plusieurs frames à la fois.
Ça demanderait un peu plus de temps de calcul, mais on pourrait avoir un mouvement plus joli avec moins de frames.
Ca pourrait compenser le surcroit de temps de calcul, et surtout, ça serait plus commode pour l'utilisateur d'avoir moins de frames à saisir.