Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Thu Mar 28, 2024 10:03 pm

All times are UTC




Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Sep 08, 2008 8:41 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

Attention les objets crées heritent de l'autodisable du world.

J'ai fais la manip suivante sur test6.

depose de quelques caisse. Mode normal.

dans la console php activation de l'autodisable.

Ajout de caisses: les nouvelles passent bien en autodisable. Les premières restent activées tout le temps.

Bonne journée
Ouille.


Top
 Profile  
 
PostPosted: Mon Sep 08, 2008 8:53 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

Après quelques tests et la mise jour de ode à la version 0.7

Ca marche aussi avec ode 0.7 sous windows.

Je vais essayer de faire quelques mesures des performances.

Bonne journée
Ouille.


Top
 Profile  
 
PostPosted: Mon Sep 08, 2008 9:18 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Stop stop stop ! On arrête tout !

Je suis un gros bêta ... Ta phrase "Attention les objets crées héritent de l'autodisable du world." vient de me sauter au visage ... C'est évidement la cause de tout ça, puisque j'ai bêtement activé l'autodisable sur une scène déjà crée ! :/

Mes sincères excuses pour la perte de temps causée par ma ... précipitation, en fait ! À défaut de sources, voilà une belle démonstration ! :)

Étape suivante pour éviter des bourdes horribles du genre : se débrouiller pour que la fonction raydium_ode_autodisable_set() (ou une autre fonction amie) puisse changer l'état des éléments existants (ceux pour qui c'est intéressant en tout cas [pas les STATICs, ...]). M'en occupe (éventuellement) sous peu si j'arrive a me trouver un peu de temps.


Top
 Profile  
 
PostPosted: Mon Sep 08, 2008 10:13 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

Voici après quelques tests (assez sommaire).
Programme: test6, 50 boite sont lachée au rythme 1 toutes les 250ms.
Le test environ 6 secondes.


SOR_LCP: Le solveur d'ode gain de 54% en vitesse, il represente à peu pres 20% du temps total.
Collider: gain 5% (16% du temps total). Ce n'est pas surprenant. Peu d'effet sur les collisons, la separation des espace (objets) est plus utile.
raydium_texture_find_by_name : gain 6% a mon avis ne reprsente rien si ce n'est la dispersion des tests. par contre 3% du temps total.
raydium_ode_callback: 50% plus lent (pas tres significatif) 5% du temps total.

Les mesures ne sont pas très precises, j'aurais préféré des cycles, je fais avec ce que j'ai.

On gagne donc pas mal au niveau du solveur :D . Et c'est à peu près tout. :(
Par contre on peut aussi balayer devant notre porte, certaines fonctions raydium sont appelées de façon très intensives, a optimiser (au moins un peu).

J'ai a peu près identifié le problème avec odenet. Lorsqu'un objet se desactive, on n'envoie plus d'infos sur kle reseau. Du coup l'objet distant continue avec la dernière vitesse lineaire et angulaire envoyée.
Il faudrait un evenèment reseau pour indiquer que l'objet se desactive. Avec update de la position rotation et desactivation sur la machine cliente.

Enfin toutes les primitives d'ajout de force ne peuvent marcher au travers de la couche reseau, puisque la physique des objets est calculé par une machine et les forces appliquées par une autre. (sauf bien sur pour les objets locaux a une instance de raydium), suis je clair ?

Un ajout de force devra donc etre forcement un fonction plannifiée reseau dès le depart.

Bonne soirée
Ouille


Top
 Profile  
 
PostPosted: Tue Sep 09, 2008 9:24 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Post très intéressant (au delà même de tes mesures) puisque :

- Oui certaines fonctions Raydium se trouvent utilisées très intensément et ne disposent pour certaines d'aucune optimisation. L'utilisation de tables de hachages pour les recherches par nom devraient être utilisées (encore une chose qui traine dans ma TODO depuis perpet' ...). Donc, a faire, effectivement.

- RayODE est construit autour des notions d'objets locaux et distants. Un client n'est pas sensé appliquer directement des ordres (ajout de forces par exemple) sur des objets distants, puisqu'il n'en est pas le propriétaire (et qu'il ne possède de toutes façons que des informations très approximatives de la réelle position/rotation de l'objet en question). Ces fonctions ne sont donc pas supposés êtres "applicables" aux objets distant. Ce qui n'empêche pas l'application de gérer ça à son niveau à l'aide d'un simple netcall.

- Effectivement, ODENet fonctionne avec un système de timeout qui n'est pas compatible avec l'autodisable actuellement. Il est cependant assez simple de contourner ce problème, même si je me permet de me réserver cette partie du travail, car ODENet reste une API particulièrement sensible aux modifications.

- Enfin, en tant que spécialiste de l'autodisable :) , l'idée que raydium_ode_autodisable_set() s'applique automatiquement à tous les éléments déjà existants dans la scène ne te semble pas une complète aberration ? (cf mon précédent post).


Top
 Profile  
 
PostPosted: Wed Sep 10, 2008 10:12 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour

1) La palme d'or est raydium_ode_element_isvalid avec un nombre d'appel phénoménal. Peut être un define ou à mettre en __inline.
Il faut noter cependant que la répercussion sur les performances globales restent faibles.

2) Ok on a la même analyse.

3) J'ai déjà commencé un peu, je garde les bouts de codes sous le coude.

Quote:
- Enfin, en tant que spécialiste de l'autodisable :)


4) Faut pas abuser quand meme.
A mon avis:
Appli non reseau: on peut d'ores et déjà tout passer en autodisable. Ca ne devrait pas poser de problèmes. Les collisions restent activent sur tout les objets.

Appli reseau: plus complexe, une gestion fine de l'auto disable sur les clients serait peut être a évaluer. Il faudra par contre forcement adapter odenet à cette fonctionnalité.
Peut être à implanter en meme temps qu'un dead reckoning.

Je ne vois pas trop pourquoi sur une simple machine ce serait aberrant ? Peux tu détailler ?

Bonne journée
Ouille


Top
 Profile  
 
PostPosted: Wed Sep 10, 2008 10:27 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
La formulation de mon post n'est pas claire. Je ne me pose pas spécialement de questions sur le fait d'activer l'autodisable par défaut ou non (pour moi la réponse est non pour l'instant, pour des raisons très classiques de compatibilité), mais de savoir si tu ne voit pas un effet de bord particulier à changer le comportement de raydium_ode_autodisable_set(). Je m'explique.

Lors du test de l'autodisable, j'ai cru par mégarde que cela ne fonctionnait pas. L'erreur étant dû au fait, comme tu me l'a fait remarquer, que j'avais appelé la fonction raydium_ode_autodisable_set() sur une scène déjà crée (mes caisses étaient déjà spawnées), et que cet appel n'a donc eu aucun impact sur les performances. L'idée est donc tout simplement de modifier le comportement de raydium_ode_autodisable_set() pour qu'en plus de son rôle actuel, elle parcoure l'ensemble des éléments déjà créés, pour changer leur attribut autodisable.

Donc : cela te semble t-il susceptible de poser des problèmes particuliers ? :)

PS : n'aurait tu pas tout simplement raté mon précédent post ? :)


Top
 Profile  
 
PostPosted: Wed Sep 10, 2008 4:13 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

Décidément on a du mal a se comprendre :(

Pour le coup tu as parfaitement raison, c'est fait dans le commit 730.

Le fonctionnement est maintenant bien plus logique.

Les resultats sur test6 sont alors très impressionnants: :shock:
Avec l'auto disable à un j'ai encore 60fps avec 80 boites :D . Je peux meme tirer un missile dans le tas de boites, ca reste fluide :lol:
Par contre en desactivant l'auto disable le frame rate passe à 2fps. :(
Ces resultats sont bien plus encourageants que me premiers tests.

Bonne journée
Ouille.


Top
 Profile  
 
PostPosted: Wed Sep 10, 2008 7:08 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Je viens d'en faire l'expérience, c'est effectivement extrêmement sympathique :) Bien joué !

Il serait intéressant qu'on se penche un petit peu sur les seuils de sensibilité, car sur le test que je viens de réaliser, un certain nombre de caisses ne passaient pas en disabled (probablement à cause de "micro-mouvements" d'autres caisses qui déclenchaient des collisions). C'est du détail, mais ça risque de rendre le tout encore plus efficace.

Autre point, il m'est assez souvent arrivé de tomber sur des bugs très choquants dans divers jeux (commerciaux en particulier, j'entends) utilisant ce mécanisme d'auto-disable. Le cas typique est celui d'un empilement d'éléments dont un élément supérieur reste bêtement en l'air alors que ceux d'en dessous, pour une raison ou une autre ne sont plus présents. En effet, si ce départ se produit sans collision, l'élément (par exemple) en haut de la pile ne se réactive pas.

Une solution toute bête pourrait consister à réveiller tout élément endormi de temps en temps, histoire de valider que cet état est toujours cohérent par rapport à la scène. Reste a déterminer (empiriquement à mon avis) la fréquence de ce réveil par rapport à la complexité de la scène (nombre d'éléments présents).


Top
 Profile  
 
PostPosted: Wed Sep 10, 2008 7:15 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Bonjour,

Concernant les paramêtres d'autodisable j'avais prevu de regarder ca (les lignes sont commentées dans le commit).
Mais comme les valeurs par defaut semblait fonctionner très bien je n'ai pas cherché plus loin.
De toutes les facons ce sera facile à ajouter.

Concernant un enable periodique, j'y avais pensé mais pas pour les memes raisons, mais plutot pour odenet afin d'eviter le timeout d'un objet.

Mais effectivement ca serait une bonne solution.

Bonne journée
Ouille


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 37 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group