Page 24 sur 48
Publié : dim. 28/juin/2009 18:44
par Anonyme
Pour les triangles ( je peut pas lire les chm sous ubuntu )
le code est certainement faux :
Code : Tout sélectionner
*Cube = iCreateCube(1)
iPositionNode(*Cube,0,0,3)
iRotateNode(*Cube,45,45,45)
*geo.i = iMeshGeometry(*Cube)
Count = iMeshBufferPolyCount(*geo)
Dim *TriangleBuffer.i(Count)
*TriangleBuffer() = iMeshBufferIndicesBuffer(*geo)
*Triangle.VECTOR3 = *TriangleBuffer(0)
Debug *Triangle\x
Debug *Triangle\y
Debug *Triangle\z
si tu pouvais m'aiguiller
Publié : dim. 28/juin/2009 20:00
par venom
je peut pas lire les chm sous ubuntu
tiens très pratique
@++
Publié : dim. 28/juin/2009 20:09
par tmyke
Bon, je viens de faire de nouveau une mise à jour des sources et du package PB.
Le petit code que tu donne ci-dessus ne fonctionne pas je pense.
Voici d'une manière simple ce que j'écrirais:
Code : Tout sélectionner
Count = iMeshBufferPolyCount(*geo)
*TriangleBuffer.w
*TriangleBuffer = iMeshBufferIndicesBuffer(*geo)
; première face:
Debug PeekW(*TriangleBuffer)
Debug PeekW(*TriangleBuffer+2)
Debug PeekW(*TriangleBuffer+4)
Sinon, avec les ajouts de la dernière mise à jour, on peux écrire:
Code : Tout sélectionner
*meshbuf.IMeshBuffer = iMeshGeometry(*cube)
; récupère le nombre de triangles
num.l = iMeshBufferPolyCount.l(*meshbuf)
Global v0.l, v1.l, v2.l
Global vert.VECTOR3
; parcour tous les triangles
For i = 0 To num-1
iMeshBufferFace(*meshbuf, i, @v0, @v1, @v2)
; les 3 vertices de la face
Debug v0
Debug v1
Debug v2
; récupère chaqu'un des 3 vertex
iMeshBufferVertex(*meshbuf, @vert, v0)
vv0$ = StrF(vert\x)+" "+StrF(vert\y)+" "+StrF(vert\z)
iMeshBufferVertex(*meshbuf, @vert, v1)
vv1$ = StrF(vert\x)+" "+StrF(vert\y)+" "+StrF(vert\z)
iMeshBufferVertex(*meshbuf, @vert, v2)
vv2$ = StrF(vert\x)+" "+StrF(vert\y)+" "+StrF(vert\z)
Debug vv0$
Debug vv1$
Debug vv2$
Next
Voilà. Faut aussi penser que Irrlicht travail en u16 pour ces indices, autrement dit du
'unsigned short' soit des données en 16 bits non signées.
Publié : dim. 28/juin/2009 20:22
par Anonyme
Impecable , sauf que j'ai besoin des vertex des triangles "tranformé" après rotation / translation
ca doit bien être stocké quelque part
Publié : dim. 28/juin/2009 20:25
par tmyke
Arrfff. C'est tout a fait possible, mais il n'y a pas de fonction directe pour cela, mais je vais
pondre un truc
Publié : dim. 28/juin/2009 20:42
par tmyke
bon, voici une petite procedure qui transforme chaque vertex (sous forme d'un vecteur)
en fonction de la position du node
Code : Tout sélectionner
Procedure TransformVertex(*node.IMesh, *v.VECTOR3)
Protected mat.MATRIX
iNodeTransformation(*node, @mat\m[0])
Matrix_TransformVect(*v, @mat\m[0] )
EndProcedure
*v contient le vertex à transformer mais aussi le résultat après le traitement.
Cela devrait correspondre à ce que tu cherches
Publié : dim. 28/juin/2009 20:43
par Anonyme
pas trop gros , ca va te faire mal...
sinon ,
ca plante ici
Exemple 35 :
*node.INode = iPickCamera(*cam, iGetMouseX(), iGetMouseY(), #ENT_PICKFACE)
et ici :
Exemple 36 :
res.l = iCollisionPoint(Lstart\x, Lstart\y, Lstart\z, Lend\x, Lend\y, Lend\z, *mesh)
le 41 fonctionne correctement.
Publié : dim. 28/juin/2009 20:50
par tmyke
Cpl.Bator a écrit :pas trop gros , ca va te faire mal...
C'est pour cela que je me suis cantoné à 5 lignes (deux post au dessus).
Cpl.Bator a écrit :
sinon ,
ca plante ici
Exemple 35 :
*node.INode = iPickCamera(*cam, iGetMouseX(), iGetMouseY(), #ENT_PICKFACE)
et ici :
Exemple 36 :
res.l = iCollisionPoint(Lstart\x, Lstart\y, Lstart\z, Lend\x, Lend\y, Lend\z, *mesh)
le 41 fonctionne correctement.
Le soucis, c'est que chez moi cela tourne sans soucis, et sur 3 machines, sous Window par contre
Publié : dim. 28/juin/2009 20:53
par Anonyme
Tu as du faire des modifs des sources , je ne peut même plus utilisé mes source du shooter.
pour ta petite fonction , elle ne transforme rien. :/
Ca reste tel quelle.
Publié : dim. 28/juin/2009 21:00
par tmyke
Cpl.Bator a écrit :Tu as du faire des modifs des sources , je ne peut même plus utilisé mes source du shooter.
Pas plus que cela, mais des fois il suffit d'un rien. Je ferais des tests en rentrant demain soir pour
voir ce qui peut éventuellement clocher, et tout remettre à plat.
Cpl.Bator a écrit :pour ta petite fonction , elle ne transforme rien. :/
Ca reste tel quelle.
Hmm, chez moi cela fonctionne nickel, je vais finir par croire que l'on ne teste pas le même chose
La nuit permet d'aérer et oxygéner les méninges, je serais plus clairvoyant demain
Publié : dim. 28/juin/2009 21:29
par Anonyme
tu as raisons , on ne teste pas la même chose.
j'ai vérifier les fonctions matricielle une par une , le code source... etc...
pas d'erreurs... et en dernier ( comme d'hab ) un éclair !
Il fallait que la scene soit rendu au moins une fois , sinon les matrices ne sont pas à jour... je suis vraiment un crétin par fois...
Te casse pas la tête , penche toi vers Xeffects
Publié : dim. 28/juin/2009 21:48
par tmyke
Cpl.Bator a écrit :tu as raisons , on ne teste pas la même chose.
j'ai vérifier les fonctions matricielle une par une , le code source... etc...
pas d'erreurs... et en dernier ( comme d'hab ) un éclair !
Il fallait que la scene soit rendu au moins une fois , sinon les matrices ne sont pas à jour... je suis vraiment un crétin par fois...
L'essentiel est d'arriver à trouver ou sont les failles, et puis parfois nous sommes tellement pris par
ce que nous faisons, que nous n'avons plus le recul nécessaire à une certaine clairvoyance
Je ferais un tour de N3xtD demain, je re-testerais tous les samples ,et ce sur au moins 3 ou 4 machines,
a tête reposé
Cpl.Bator a écrit :Te casse pas la tête , penche toi vers Xeffects
J'ai malgrés tout un peu commencé. Le code compile bien, je n'ai plus qu'a écrire les fonctions externe
pour mettre en oeuvre le truc. Je ne suis pas sûr que cela sera prèt dès demains, mais dans les tous prochain jours par contre , cela devrais le faire
Bonne nuit, et à demain soir.
Publié : lun. 29/juin/2009 0:49
par cha0s
il serait bien de bloquer le fps pour le shooter car bon dur de tester quand on meurt en une seconde
. Quelqu'un a fait un bench sur les perfs des sprite3D de next contre ceux de pure ?
@Tmyke : c'est cool que l'on puisse charger directement a partir de la mémoire mais mhhh je trouve pas dans la doc pour les sprites ^^'.
Pour info c'est ce jeu la que j'aimerais convertir en next :
(Proto-Type le 9 ème)
http://ajva-online.com/modules/smartsec ... ?itemid=17
Publié : lun. 29/juin/2009 2:35
par poshu
Bon, faut que je teste la nouvelle version aussi, mais cpl.bator est tellement sur la brèche que les versions fix s'enchainent trop vite xD
Publié : lun. 29/juin/2009 18:01
par tmyke
cha0s a écrit :il serait bien de bloquer le fps pour le shooter car bon dur de tester quand on meurt en une seconde
. Quelqu'un a fait
un bench sur les perfs des sprite3D de next contre ceux de pure ?
Dans les exemples fournis dans le package, normalement tu as la synchro d'activé, ce qui limite la vitesse d'afichage.
cha0s a écrit :@Tmyke : c'est cool que l'on puisse charger directement a partir de la mémoire mais mhhh je trouve pas dans la doc pour les sprites ^^'.
En fait, dans l'exemple 010 tu as un petit exemple, à la ligne 39 il y a une ligne commentée ( iAddZipFileArchive() ). C'est grace
à cette instruction que tu charge des media qui seront directement exploitable dans ton code.
Sympa comme objectif, et accessible en plus, ce qui a son importance. Les fonctions 2D natives
de PB pourraient largement suffire, non ?
Sinon, j'ai uploadé les package avec une remise à plat et les tests qui vont bien. Y compris sur Shooter,
le tout sous Windows pour ce qui me concerne