New commands for blitz3d!
Blitz3D Forums/Blitz3D Programming/New commands for blitz3d!
| ||
| hello! well, after reading a bit in the forums i noticed that a bunch of people wat some commands like EntityRed() or CameraNearRange()... i know there is a dll somewhere in here, and i have got this dll on my harddisk, but wouldnt it be easier above all for noobs, to make such commands? mark sibly? i would have some ideas: EntityRed(entity) EntityGreen(entity) EntityBlue(entity) GetCameraZoom(entity) GetCameraNearRange(entity) GetCameraFarRange(entity) if you have any idea for additional commands in blitz, please post them here :) |
| ||
| I don't think commands of this nature are going to be worth Marks while when there are simple workarounds. For example .... Type RGB field R, G, B End Type MyMesh = createsphere() EntityCol( MyMesh, 200,50,150 ) Red = EntityRed( MyMesh ) ;============================== ;============================== Function EntityCol ( Entity, r, g, b ) This.RGB = new RGB This\R = r This\G = g This\B = b entitycolor r, g, b nameentity Entity, Handle( This ) End function Function EntityRed( Entity ) This.RGB = object.RGB( entityname( Entity ) ) return This\R end function This isn't much effort on anyones part. Features such as stencil shadows are far higher on my wish list and probably alot of others. Stevie |
| ||
| well, i don't think that blitz3d will have stencil shadows... rather bmx would have! but i know how to workarround these things, but wouldnt it be much more easier to make these commands? what do you say mark sibly? |
| ||
| BEWARE! Some of the functions may be broken, use at own risk! I've been meaning to go fix it, will do that soon. Check decls for list I mainly use it for the memory peek/poke. Check the entity system too (source should be there) www.tomspeed.com/memorylib/ |
| ||
| thx, but i allready have this libary... i tried to help the community by praying makr sibly to make these commands... |
| ||
| hu, what happened to your page tom? all i get is a little "Nosey!". hacked? |
| ||
| Tom, what's the difference between your peek/poke functions and Blitz's own ones? Are yours faster??? Thanks, D. |
| ||
| Blitz's own ones only work on banks. :) |
| ||
| ^^' ... maybe a "AnimatedVertexCoord()" would be nice... and what about a "GetvertexWeight()" to get the weight of each vertex affected by bones ... mmm... maybe i dream ! |
| ||
| Hi Tom, great work on the Render to texture stuff - you think you could add some 3d line and pixel render commands? cheers, Roy |
| ||
| yes, the animated vertex coords would be a nice idea :) helpful at least for me, and the oter stencil-shadow-system-develpoer-who-cannot-access-animated-vertex-coords... |
| ||
I believe you can get the animated vertex position by setting the parent to 0:
;these contain the vertex x,y,z position
Global xx#, yy#, zz#
;call this function with the handle to the mesh (the actual child mesh that you need the coords from)
;followed by the surface index and the vertex index
Function GetVertexCoords(obj%, surfaceindex%, vertexindex%)
local oldp%
oldp = GetParent(obj)
EntityParent obj, 0
surf = GetSurface(obj, surfaceindex)
xx# = VertexX(surf, vertexindex)
yy# = VertexY(surf, vertexindex)
zz# = VertexZ(surf, vertexindex)
TFormPoint xx, yy, zz, obj, 0
xx# = TFormedX()
yy# = TFormedY()
zz# = TFormedZ()
EntityParent obj, oldp
End Function
I used the mak_running.x model from the examples to test it: |
| ||
| worth checking out :) but it would be easier to acces them via blitz, mark? |
| ||
WOW never realized this is so easy!Function SetAnimShadowMesh(ent) SetShadowMesh(ent) cnt_children = CountChildren(ent) If cnt_children = 0 Then Return For i = 1 To cnt_children SetAnimShadowMesh(GetChild(ent, i)) Next End Function thx bram! now mark sibly, what about these ideas? why not replying? |
| ||
| @Bram32 : Problem is that you don't know how vertices are affected by bones transformations. If the weight of the bone you move is set to 0.5, the vertex will not have coordinates you get with your function. And, notice that, you don't know which vertex is affected by which bones. So if you try to get vertex coordinates with TFormPoint, yu 'll have to know before is the vertex is really affected by the bone. |
| ||
| I don't know .. are all bones alike ? The "mak_running.x" model has elements called 'bone', which behave like pivots. I don't know if other models work the same. |
| ||
| I don't remember, but x files do not support more than one bone per vertex. in b3d format, you can set up to 4 bones per vertex ( not sure, but i really think it's something like this ). And I thought about getting coords of vertex form Mesh that have more than one bone in the hierarchy. if the whole mesh use only one bone, it's simple as using TFormPoint. But if the mesh has lot of bones, how can you know which vertex of the surface of the mesh will move with bone ? In blitz3d, for the moment, this is not supported. We maybe can use an alternate strutur using type, and preloading the AnimMesh with the readfile command in the way to ripp the hierarchy and register weights of all the vertices, but it should be easier if Blitz3D made it ... ( really sorry for my bad english... => i'm french ! ) |
| ||
| Aha, I understand .. I've never used animated .B3D's before. Thanks for your explanation |
| ||
| I don't think the DX7 .X files (which B3D uses) support bones at all, they just animate the geometry. |
| ||
| *.3ds and *.x are working animated on my shadow system, but NOT B3D *.x and *.3ds are BONE animated, that is like pivots - you just have to declare each bone as a shadow caster for itself! *.b3d are VERTEX animated, thats the second kind of animation, wich is much more popular and in use, but it is not that easy! the shadow system from andreymans fx-libary supports *.3ds only! like my one! As soon as my upload problems are solved and the shadow system gets some sort of beta, i will upload it :) ! |
| ||
| I may be misunderstanding. For me B3D files support bones. Move the bones and the attached vertices move using their weights, with the bone. DirectX 7 .X files just store rotation/position information at key frames, don't they? I always thought bone animation was the newer way- you could animate bones and the vertices would follow, with the vertex weights allowing you to "skin" the models, whereas vertex animated models were the old way- you have no way to control them easily and just have to use the animation they are given in the models. I like animating the top half of an entity differently to the bottom half you see- Like in the Prince of Persia series of games :) |
| ||
| there are two kinds of animations: bone-aninations (3ds, x) and vertex animations(b3d) mostly used is b3d vertex-animations, but this is not so easy to implement into s shadow system. 3ds and x are the easy ones, but the are not very popular.. |
| ||
| Cygnus is right. Bone animation is a kind of vertex animation and works exactly as explained and is only supported by B3D files. MD2 is another format that supports vertex animation. Unlike B3D it's frame based(each keyframe contains the whole mesh), so there is no need for bones. I don't know how to call that animation by 3ds & X(maybe Position or Object Animation??), but it's definitly not using Bones. |
| ||
| hierarchy animation. |
| ||
| I've been trying to work something out to find b3d vertex positions. It works up to a point on the model i tested it with. But the arms are still wrong, they somehow stay in their original position and move only a bit. I've used the emo girl from clownhunters emo game 2. http://www.codersworkshop.com/viewpost.php?id=78609 (if i post a direct link, the codebox get scrambled) I've used this method: (1) parse file, search all parents for the vertices and the amount/weight (2) place a pivot on each vertex for every parent it uses and connect it to this parent, thus creating several "versions" of each vertex. (3) on runtime, calculate the average position between each version of the vertex, taking in account their weights. |
| ||
| furious but not fast LOL For the moment, it 's the only one that can return vertex weight ! Good work. But i try to understand two things : - if you parse the file, you'll get directly the vertices weights. So why all this stuff ? - if you parent a pivot to a bone , you move the pivot at the position of one vertex ( you make this operation for each vertex and each bones ), you turn the bone => you 'll know if the pivot has moved. like this, you'll know if the vertex weight, calculating the difference between the angles and the distance from the vertex to the Bone. And as far as i know, you'll not have to parse the file ... So, I don't understand why you do the 2 method for the same result ? [edit] Ok, i realise that i'm so stupid :) => If we parent the pivot to the bone, of course the pivot will move with it. So we'll never know if the vertex is "attached" to the bone... so it doesn't mind anything to do what i said... just a loss of time . Don't care about my post :-s |
| ||
| I found a part of your problem , but it seems this is not a good method ! => Rotations are not setted to 0,0,0 when you place the pivot replace with this : ;create a pivot for each vertex, for each parent For i = 0 To cv% - 1 For j = 0 To max(i) cursor(i, j) = CreatePivot(ocursor) ;place it on vertex PositionEntity cursor(i, j), VertexX(surf, i), VertexY(surf, i), VertexZ(surf, i) l_parent% = enumChild(parents(i, j)) l_rx# = EntityPitch(l_parent,1) l_ry# = EntityYaw(l_parent,1) l_rz# = EntityRoll(l_parent,1) RotateEntity l_parent,0,0,0,1 EntityParent cursor(i, j),l_parent RotateEntity l_parent,l_rx,l_ry,l_rz,1 Next Next But there will still have a probleme for the scale. It's not sure the scale has not been modified during Keyframes . So initial position will may be wrong. And that don't really want say the bones have 0,0,0 angles at the first frame... but i'm currently asking if => we could directly get the weights and vertex pos from the b3d file no ? I'm trying to do it. but here, I go and sleep, tomorrow, i will try to finish ! |
| ||
| I notice that when you're parsing for NODE you only parse out the "name" of the node, yet there is other vital information such as animation keys contained in the NODE chunk. Check for any animation keys contained in the parent node of the arms as this will undoubtedly affect the final orientation, etc. of the children. Kevin |
| ||
| Thanks, Bobysait! I've updated the code with your routine. I've been trying to do something similair with the scaling, but it didn't work out. Kevin, I will try parsing the animkeys. However I don't understand the b3d format too well. |
| ||
| Sorry to revive an old topic, but it looks like this discussion turned away from the entityred, entitygreen, and entityblue question. Stevie G's code: I don't think commands of this nature are going to be worth Marks while when there are simple workarounds. For example .... Type RGB field R, G, B End Type MyMesh = createsphere() EntityCol( MyMesh, 200,50,150 ) Red = EntityRed( MyMesh ) ;============================== ;============================== Function EntityCol ( Entity, r, g, b ) This.RGB = new RGB This\R = r This\G = g This\B = b entitycolor r, g, b nameentity Entity, Handle( This ) End function Function EntityRed( Entity ) This.RGB = object.RGB( entityname( Entity ) ) return This\R end function This isn't much effort on anyones part. Features such as stencil shadows are far higher on my wish list and probably alot of others. Stevie While this works, it is hardly a "simple workaround" as it involves the undocumented Object keyword, and at least intermediate Blitz knowledge besides. Most Blitz programmers would not understand the code above, let alone be able to write it. I mean, there are simple workarounds to things like not having a glove compartment in a car, or not having a handle on a refridgerator, but try selling products without them. In Blitz3d you can set an entity's color, but you can't read it back without creating a whole new data structure and learning new functions you might never have to use otherwise. That's just silly. It's clearly an oversight that will eventually (hopefully?) be fixed. |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=75711 |
| ||
| Awesome! Such a small file too. (If I were being picky I would just say that most of those commands aren't really necessary for the sake of completeness; they are useful extras. Reading an entity's color is more basic and probably ought to be included in the next update. As I say that would be nit-picking and I would never do such a thing.) Thanks Ojay. |
| ||
| Stevie G's code: i could have figured that out by myself. Ojays code link to that dll seems much more like it.now sleep tight little thread... |
   |