Mesh Deform
Blitz3D Forums/Blitz3D Programming/Mesh Deform
| ||
| I can and have coded my own mesh deform animations previously by manually manipulating vertices but i'd like to create properly rigged models with skeletal structures. I want to be able to make and link bones in code, but I dont see any commands related to vertice weighting in the mesh or surface categories of the help files, yet the B3D format apparently supports it. Is this something I just cannot do in Blitz or have I missed something? Will I need to delve into the memory block of a loaded .b3d mesh structure to do this? Am I missing something? |
| ||
| AFAIK: No. Hacking the Address and structure of a loaded mesh would be nice, although certainly not easy. |
| ||
| Sheeesh this is going to be a pig to figure, I suppose the place to start is figuring out the B3D format in memory. Has anyone already done any work on this or do I have to find stuff out by experimenting and ... dare I say it, deduction? |
| ||
| Even if you get the mem address of the loaded B3D, how are you going to access that memory in blitz? I guess you're gonna need a dll to do that. Yuk! This job sounds horrible. Good luck! :P |
| ||
| well I havn't started experimenting big10, but I assumed the pointer that loading the mesh returns would give me the memory address of the start of it and the poke/peek commands will allow me to take a snapshot, try to figure it out, then write it back - no? |
| ||
| There are no direct memory poke/peek commands in blitz - only for banks. And I'm pretty sure the handle returned when you load a B3D (or anything, for that matter) is a pointer to a control structure which itself will hold a pointer to the raw data in memory. |
| ||
| There are no direct memory poke/peek commands in blitz - only for banks Maybe i'm missing something here but you give peek/poke commands a memory address. Whilst this is usually the pointer to a bank with an offset why cannot it not be the pointer to something else instead? I think I will experiment later. |
| ||
As I said, handles returned by blitz are pointers to 'control structures' that blitz uses to manage them internally. You don't get pointers to the actual memory address where the raw data is stored - be it banks, meshes, whatever. Run this:bank1 = CreateBank(10000) bank2 = CreateBank(10000) Print "Bank 1 handle: " + bank1 Print "Bank 2 handle: " + bank2 Print " Difference: " + Abs(bank1 - bank2) WaitKey() End The difference between the two bank handles is only 64 so they can't possibly be pointing directly at the bank mem as each is 10000 bytes in size. :) Blitz is a language that appeals to beginners too, remember, so giving them the ability to randomly poke around *anywhere* in memory wouldn't be such a great idea. :) |
| ||
| That's annoying, even more reverse engineering to do. Why is it so complicated? All I want to do is set some vertice weights in code :( Dear Mr Mark sir, Please give me control over animation structures and i'll send you a naked picture of a lama in return. Thank you Becky |
| ||
| Maybe you are confusing him with Jeff Minter or something. Poking to absolute adresses is possible using userlib extensions, (RTMemoryMove thingy). But you need to hack two things first: the adress of the Animated Mesh and it's structure. While Mark may release a structure description, you need some more tricks to retrieve the adress. Maybe it was already hacked. check out the old Thread "BLitz was hacked!" (or something similar), I think it was a german Blitzer who listed a number of objects adresses (offsets), although not sure if Meshes were one of them. Maybe it would be easier to write your own import/animation code! |
| ||
| Who wrote Pacemaker? Assuming he used blitz to develop that tool, he must have figured out some trick here. |
| ||
| Maybe you are confusing him with Jeff Minter or something No, but Mark is registered on Jeff's forums... I think it's a sheep fettish thing... ;) |
| ||
| What's the matter with just writing a B3D-file with bones to disk and loading it in again? It's slow of course, but once the bones are in place, you can move/rotate them(and so the assigned vertices) in realtime. |
| ||
| I kinda agree with BIG BUG :o) |
| ||
| That is the best solution I see BigBug, although it rules out any realtime editing of the vertice weighting and I was hoping to be able to tinker with them on shot impacts when I distort the mesh, it would have been nice - but not essential I guess. |
| ||
| I dunno if writing to the hard drive really would be all that slow. I mean, what you write will sit in the hard drive's RAM buffer. Which--I would think--would be available to be re-read without having to actually retrieve it from the hard drive itself. I bet I'm wrong about that, but it's really got to be tested. |
| ||
| That is a good point barliesque but it's not what makes the process slow, altering a few vertices is just 1 command per vertice, but writing an entire file with animation is writing out an entire model file, possibly around 1mb, and reading it back in again, so rather than edit 1 vertice your effectively editing every vertice and all the animation data twice as you save it out and read it in again. It's certainly not something I see working well in a realtime environment :/ |
| ||
| The only reason why you would have to reload the model every time you made changes is if you are dependant on Blitz to perform the animation. You could write your own animation engine , after all joints are just pivots and vertices are points in space parented to those pivots. If you know the weighting values its possible to calculate their position when the "pivots" rotate. |
| ||
| I have done mesh deform animation before by directly editing vertices, infact i've got a game that will forever remain unreleased with 3 humanoid characters walking around entirely with vertexcoords commands. It would be so much nicer to change the vertice weighting of an object in realtime and then be able to forget about it though. The absense of this ability is a missing command as far as i'm concerned but I guess i'll have to wait for BMax-3D before it is resolved and I dont think any religions deity can work out how long that's going to be... |
| ||
| Of course we all agree that bone construction functions should have been a part of Blitz3D's command set, however... You shouldn't really have to modify vertex weighting dynamically. If your character is well-rigged to begin with, this shouldn't be an issue. Lots of very complex animation can be created with just one rigging setup. But then maybe you've got some wild and crazy effect in mind that can only be done in this way. To be honest, that seems a little unlikely. Maybe you can be more specific about what it is you want to achieve. |
| ||
| I've numerous uses i'd like to play as it goes: Firstly morphs; secondly impact damage; and lastly as I already create and/or edit every model I use in code and use vertice commands quite naturally I just wanted to go further by exploring animation more fully than I already have. |
| ||
| Its possible to deform boned meshs with vertexcommands too. for example: Your playercharacter gets hit in the face. So move its nose vertices a bit around. The bone animation itself isn't affected and the broken nose will stay. |
| ||
| The problem with doing anything with the vertices of a boned animated mesh is that you do not have access to the real positions of the vertices when the model is animating - you can only get the original static starting position with VertexX#() etc. Because of this you would have to track the position of each vertex manually taking into account that each vertex can be influenced by up to 4 joints. If you want to programatically animate using vertex manipulation I would just use a static mesh - trying to mix the two would cause too many headaches. |
| ||
| ...but then maybe Becky Rose LIKES doing things the hard way...? ;^) |
| ||
| Here's an idea: Let's say you want to morph a boned mesh that's in mid-animation, into some other shape. Firstly, as Smiff says, vertex positions will appear to be at their original positions. So as you morph the vertices from those positions to the starting positions of the new shape, simultaneously 'morph' the bones from wherever they are, back to their starting positions. Once the morph is complete, it should be seamless to simply replace it with a correctly boned version of the target shape--assuming you need a different rig for it. If, say, you wanted to morph facial expressions onto an animated character, then that's easily achieved simply be mixing boned animation and vertex manipulation. |
   |