VertexBone()
Blitz3D Forums/Blitz3D Programming/VertexBone()
| ||
| This is absolutely necessary, since VertexX,Y,Z() don't consider animation when returning values, and for other reasons. |
| ||
| Do you mean a command to determine what bones a given vertex is weighted to? |
| ||
| Er actually it would now be CountVertexBones(surf,v), VertexWeight(surf,v,index), and VertexBone(surf,v,index). I am programming projectors like the Unreal engine has, but can't get the true position of the vertex without knowing what bone it is attached to. |
| ||
| TFormPoint x#, y#, z#, entity, 0 This should return the REAL current coordinates of the vertex. |
| ||
| Are you sure? I haven't ever tested it, but I seem to recall hearing at some point that what you posted specifically does not work, that there is no way using Blitz commands to get the true position of vertices in a skeletal animated mesh. |
| ||
| All the verts to a boned mesh are within the first 'mesh', while the bones are seperate pivot points. So there's no way to get updated positions even if you know where the bones are. Though saying that, the .b3d format does(obviously) contain a list of verts for each bone, so it's not impossible without mark's help. |
| ||
| Why would you want to know where a verticy is? There are far too many to do anything useful with in realtime. |
| ||
| It's a very useful request Skid. I've lost count the amount of times I've hit the wall in frustration over this. The most obvious example is linepicking..it's impossible with an animated b3d, and that's just absurd. (In zombie apocalypse 3 for example, I had to actually skin the mesh with cubes and mirror the limbs positions every frame).. which was fine for that situration, but hardly ideal. It took me hours to manually scale and position the cubes(Not being an artist) But imagine a lightmapper...with animated geo..something most modern games need. Currently no way of doing it, back to the line picking problem. Going even further, in vivid3D, it's currently impossible to convert animated b3ds in memory, because there's no way of retaining this info. sure it can got from file, but it's still another example of it being needed. And as for too slow for real-time, what's to stop someone from writing a user lib that works on the data too? It's vital. |
| ||
| I would assume most modern games do their lighting with the GPU, expecting the CPU to do anything clever with 100K+ of animated verts/tris is just wrong. As for collisions, parenting a bunch of collision pivots along each bone would be a cheap and I would imagine cheerful solution to animated body collisions in Blitz. |
| ||
| I never said anything about in game lighting. Lightmapping is done pre-run-time. The biggest issue still remains linepicks. That wouldn't any slower either, it's not like you have to transform each vert, you can just instead transform the linepick's origin and vector into the local space of the limb, and then do the regular check. Which is basically adding around 5-15 funcs per linepick, none of which are even remotely slow. And for this you finally have a blitz3D that's useful with animated characters..at present, it's not for anything but the most simple collision set-ups.(linepicks are a god-sent when they work.) It's not like it's a hard thing to add either, it's only gotta return an index! :) |
| ||
| "Why would you want to know where a verticy is? There are far too many to do anything useful with in realtime." Well for one, my shadow system has to approximate the bounding sphere of an entity. With bone animations this isn't very accurate if the person who made the animation makes the character move quite a ways, as happened in Anime Bowling Babes. If one could read the positions of the vertcies then one could play the animation once in a coarse way and find a much more realistic set of extents for them. For another, there is not neccessarily so many that you can't do anyhting with them. Take for example, normal mapping. You take a low polygon model and apply a normal map, but you have to change the colors of the vertcies according to their position in space at any point of the animation. Since the model is low poly, you could do this in realtime, and the normal map would do the work of making the model look detailed. Of course in addition to Halo's suggested commands, I really think Blitz should just tell us where the vertex is when we ask and provide a special parameter on the vertexx,y,z call. And it would be really nice if we could add bones and weights manually. It would be useful for modeling apps, and it would be useful for other things as well. Making folks write the data out to a B3D and then reimport it is crazy, and really limits what you can do with bones. |
| ||
| Of course you can find out the real positions of vertices. I do it all the time in Character Shop. You take the relative position and transform it from the bone to the target entity. Simon, you have 100,000+ poly characters? Wow, that is pretty impressive. |
| ||
| Umm...if you can do it why do you need it? You just parsing the .b3d file or did you 'hack' into the entity structure again? |
| ||
| I manually position vertices in Character Shop, since the whole thing is dynamic. It's a lot slower than bones. It would be nice to use the real bones routine, instead of throwing out a Blitz feature and replacing it with a workaround. |
| ||
| This would be very handy for normal mapping, as sswift mentions :) |
| ||
| Of course you can find out the real positions of vertices. I do it all the time in Character Shop. You take the relative position and transform it from the bone to the target entity. That's fine with rigid vertex assignment - with vertex weighting it gets much more complicated. Each vertex can be influenced by up to 4 bones so working out its final position is difficult without knowing the exact formula used. |
| ||
| Ummmmm, (weightA#*positionA)+(weightB#*positionB). |
   |