alpha/intersect with AnimMesh

Blitz3D Forums/Blitz3D Programming/alpha/intersect with AnimMesh

Neraj(Posted 2005) [#1]
Neihter EntityAlpha nor MeshesInteresect are working with animated meshes for me. Is this a known issue? If yes, any other way to do these things (especially RntityAlpha)?

Thanks for your help.


Shambler(Posted 2005) [#2]
For alpha you have to traverse the child meshes, ripped from my engine,
Function Recursive_Alpha(mesh%,alpha#)
Local c%
Local count%=CountChildren(mesh%)

EntityAlpha mesh%,alpha#

If count%>0
For c%=1 To count%
Recursive_Alpha(GetChild(mesh%,c%),alpha#)
Next 
EndIf

End Function 

No experience with meshes intersect but it may have a similar solution.


Neraj(Posted 2005) [#3]
Thanks for your help Shambler, its working fine with your function, hope you dont mind if i use it in my project?
Instead of intersecting every child i'll use a collision box, would have done that anyway i think, was more a gerneral question.

regards, Neraj


Shambler(Posted 2005) [#4]

hope you dont mind if i use it in my project?



You can use it, its standard stuff.


Ross C(Posted 2005) [#5]
I think the meshinteresect command will only detect the collision of the mesh, in it's unanimated pose. There's no way really of detecting collisions between animated meshes.


big10p(Posted 2005) [#6]
A minor point about you function, Shambler: the "If count%>0" test is redundant and can be removed because even if 'count' is zero or less, the for/next loop won't be executed. Sorry to be a pedant but I have a thing about culling unnecessary stuff from code. Old habits die hard. :)


Gabriel(Posted 2005) [#7]
I think the meshinteresect command will only detect the collision of the mesh, in it's unanimated pose. There's no way really of detecting collisions between animated meshes.


This is correct. Blitz does not keep track of vertex positions at all during skeletal animation so there is no way to know where they are and no way to do the collisions. If there was, I suspect it would be horrendously slow.


t3K|Mac(Posted 2005) [#8]
isn't this the death of blitz3d? i mean animated characters and collisions are essential.....

do i have to create hitboxes and re-position them every animstep? ugly ugly..... lots of work.


Panno(Posted 2005) [#9]
first i think i have a solution but now iam test it with no luck

anyone a good idea

mfg panno


Ross C(Posted 2005) [#10]
What you could do, is parent pivots to the bones of the mesh. this should register collisions, as long as the other mesh it's colliding against isn't moving. It's it's two moving meshes, then you could do a distance check between them.


Gabriel(Posted 2005) [#11]
isn't this the death of blitz3d?


Bit melodramatic, don't you think?

i mean animated characters and collisions are essential.....


I've completed 6 games in Blitz3d without ever needing them, as have many others. So they're clearly not essential. Even big retail games rarely do real poly-poly collisions with animated meshes. It's slow and unnecessary. There are perfectly good workarounds which are almost as accurate and much faster.

do i have to create hitboxes and re-position them every animstep? ugly ugly..... lots of work.


Lots of work? It's about another 10-20 lines of code. And no, you don't even have to do that. Parent them to the bones like Ross said. Then, not only do you have collisions with animated meshes, you can even tell which part of the body has been hit and react accordingly. Many retail shooters make a big thing of this feature.


t3K|Mac(Posted 2005) [#12]
many retail shooters use hitboxes - and i dont like that idea at all. if you play fps regularly you will notice strange behavior in hit detection sometimes. and thats really annoying (depends on the games).

but what bothers me most is the fact that you have lots of "workarounds" in bb3d. hope blitzmax (with dx9 engine) will do better...

"lots of code": i didn't think about parenting.... with parenting its easy, you're right.