Jump to content
  • Advertisement

lawnjelly

Member
  • Content count

    578
  • Joined

  • Last visited

  • Days Won

    8

lawnjelly last won the day on July 30

lawnjelly had the most liked content!

Community Reputation

1551 Excellent

6 Followers

About lawnjelly

  • Rank
    Advanced Member

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Static meshes are unlikely to work in the same way as a skinned mesh. Try with a skinned mesh, to see whether it is in the rest pose when you do not apply transformation. Assuming it is local space at the moment means nothing to me, vertices are defined either in bone space, or relative to the origin of the whole skeleton / mesh (rest pose space, which I think assimp is referring to as local space, as the local space of the node), I'm not sure what else local space could be referring to. The way that you can rotate one joint by 10 degrees and the child joint moves by this and its own 10 degrees is hierarchical scene structure or scene graph. You should understand this completely before attempting skinning, skinning builds on this. All skeletal animation / blending depends on an understanding of how these hierarchies work. In short you have a series of nodes (could be bones, empties, anything) in a tree structure, and each has a local transform. When animating you would animate the local transform, then by concatenation you recurse from the root node down through the tree and calculate the world transform by multiplying the parent world transform and the child local transform (this is forward kinematics). Calculating the bone transforms and bones animation is almost a separate topic from skinning, you can animate objects without using skinning for instance, although they are often used for animals to get movement of the skin to match the underlying bone structure. The reason the inverse rest pose is used is to get the vertex into the bone space of the bone in question, so it can be rotated using the correct origin. It is quite difficult to explain in words, you really need to follow some more tutorials and pics and videos, and eventually you will 'get it'. I am getting the impression you have followed some tutorials but not understood completely what was going on under the hood. Here is wikipedia: https://en.wikipedia.org/wiki/Skeletal_animation And don't feel bad, my first attempt at getting skinning working was 20 years ago, I remember very well it went horribly wrong and took me another couple of years before I had anything properly working!! (Not so many good tutorials and software back then!)
  2. http://ogldev.atspace.co.uk/www/tutorial38/tutorial38.html I've not used assimp but on glancing on this page it seems to suggest that the 'local space' IS the rest pose... The diagram on the linked web page doesn't indicate that vertices are associated with a bone, but with the mesh as a whole, which is what I would expect. I'm guessing they mean that if you draw it without transform you should see the rest pose (but the phrasing is rather vague). Have you tried drawing it without any transform and taking a screenshot for us? If you could do that it would help shed some light. Overall if it is not this, maybe someone who uses assimp can help. Often with this kind of matrix maths there may be multiple ways of achieving the same result and the workflow may be different.
  3. Local space is quite a vague term, and given that what you have doesn't seem to be working, it is better that we are explicit in descriptions. Bone space as I think TeaTreeTim and myself are referring to is the space where the origin of the bone around which rotations take place is at 0, 0, 0. It will have the bone heading out along one particular axis, the default axis, which will depend on your exporter / convention. The vertex should NOT start in 'local space' if you mean by that bone space. It should start in the rest pose position, i.e. if you drew the starting vertex positions with no transformation applied, you would get a character in the t-pose. The reason the vertices are defined (start from) in terms of the rest pose and not in terms of bonespace, is as I explained earlier, a vertex is not necessarily a child of only one bone, it can be influenced by several bones, and is not like other models in a scene graph. To get it working the first step would be to draw the skin with no transform and see what happens and see what you are working with. What method did you use to get export the bones / skin?
  4. lawnjelly

    Checking if a DLL is present

    If the DLL is your own (as in you have the source) maybe you can statically link it instead of use a DLL? Assuming you need to go with DLL, one way might be to use a small loader program that calls 'LoadLibrary' to dynamically load DLLs and check they are there, then if all is well load the main program. Or you could use LoadLibrary in the main program. (I forget the pros and cons of this, it is a while since I did this. There may be a better way! )
  5. This can be slightly confusing, you might want to refer to this thread: https://www.gamedev.net/forums/topic/694891-use-assimp-for-skeletal-animation-help/ Afaik, if you had a robot with fixed links and no weighted vertices (i.e. each vertex is hard assigned to a bone) you could load it in with each body part in 'bone space' (i.e. root at the origin and pointing out along the default axis). Then you apply the calculated bone transformation to these verts and you are done. However the reason we load the mesh in the 'rest pose' is because many of the vertices around joints will not be linked to just one bone but two or more, i.e. they have to go through the whole transformation process TWICE (or more), and thus they don't have just 1 bone space. So the inverse rest pose transform is to get a vertex from the rest pose position to bone space FOR THAT PARTICULAR BONE. Consider a forearm vertex in between forearm and bicep: Backtransform from rest pose A to 'forearm space', apply forearm animation matrix -> vertex position B Backtransform from rest pose A to 'upperarm space', apply upperarm animation matrix -> vertex position C Weighted blend between B and C to get final skinned position D So overall, as I understand it, the whole rest pose / inverse rest pose matrix thing is to allow skinning to work correctly, not bones animation, if that makes sense.
  6. I'm sure some AI specialists will chime in but some typical things you might want to look at are: spreading the path calculation over multiple frames hierarchical path finding sharing routes between units reusing path information if several are trying to get to the same goal To go further on the FPS not being a good measure, what you also want to avoid is 'frame spikes' where one frame takes a lot longer to complete than others, causing a dropped frame. This can often cause problems with things like AI, where you have a decent frame rate but you get stutters when particular frames do lots of calculations.
  7. After only Rutin did the baseball challenge, and the difficulty of coming up with ideas that will appeal to all, could it be an idea for us to use a crowd based system for deciding between challenge topics? How would it sound if either the organiser (or the group members) brainstormed a bunch of suggestions, and we used a poll to decide on the most popular choice? That way we could get as many as possible of us to have a go. Thoughts?
  8. I think Godot will be an excellent choice for starting. I'm just evaluating it to do my next mini-game, and have been working through tutorials / testing 3d skinned model import. I also used Unity for the previous mini-game and while Unity has many commendable properties (and a wealth of tutorials), the words I would use in comparison to Godot would be things like 'incoherent', 'bloated', 'slow', 'mess'. Perhaps this is partly because at the moment Unity has more features / custom addons which don't necessarily work well together, whereas Godot is younger, more focused and hasn't had the opportunity to make so many design mistakes as Unity. But it is hard to deny, putting on my 'software engineering' hat, Godot (to my eyes) simply seems a far more proficiently written piece of software. Godot also nicely wraps up everything into one simple package, the gd script editor is built in and has autocompletion, debugging etc, no need to install other editors / .net frameworks etc etc. I don't know about on windows, but on linux the entire thing (engine / editor / help files etc) is installed as an elegant single 49 meg .appimage, which is fantastic. That said, I haven't gone through a project life cycle with it yet, and am expecting to encounter bugs / the need for workarounds, particularly because I am using 3d which may be more in a state of flux (and hasn't been proven with a large number of games). The 2d part of the engine seems to get glowing reviews though.
  9. It is working fine under wine in linux so that is good. It has improved lots since the last build I tried. The tutorial is working well and managed to help me takeover an enemy ship. I was progressing fine until there was a point in the tutorial where it paused the game and wanted me to click on a tip (in the tavern?) but I had chosen to rest some days, and it put me back out to sea, while paused, and there was no way to continue the tutorial because I couldn't get to the tip screen. I suspect you need some way of limiting what the user can do during the tutorials (or at least unpausing, I couldn't work out how to do that). Overall I think it is a great effort, but I do fear that the copyright issues I mentioned in the earlier thread may limit you in terms of releasing to the wider public (as well as the images from google images, I recognised the song 'barrett's privateers' by stan rogers), so I would tread very carefully in this regard.
  10. Took this as an opportunity to update to the latest version of wine on my linux mint (as it wouldn't run on the old version I had due to ms runtimes missing) and by heck, it worked!! 🙂 A wise move I think using the text interface alongside the game view, to manage to complete the challenge in a short time despite it potentially being a very time consuming project. Well done! 🙂
  11. lawnjelly

    Metal without Mac

    Rather than supporting Metal directly, from the other thread on APIs some possibilities to investigate might be MoltenGL, MoltenVK, or an intermediate layer such as BGFX.
  12. This was my fear that it sounded quite involved, plus not being from the US I had no knowledge (or interest, if I'm honest!) in baseball. Well done it all looks like it is coming together! :)
  13. This is a minefield in my experience with OpenGL / ES, and why I think any API needs a set of conformance tests for drivers and hardware (like web browsers do), and at least some standardised hardware tiers. As I understand it, at the moment manufacturers can pick and choose what they support, one might support only up to 2048 textures, one might support only 10 bit precision in a pixel shader, some might not support branching in shader, etc etc, which is great in so far as you can manufacture exactly what is needed to make your device look good, but it makes it a nightmare to support for developers because your code has to have workarounds for all these cases. And then we have situations like this: https://gamedev.stackexchange.com/questions/77854/how-can-i-reliably-implement-gpu-skinning-in-android Personally I'd like to see a situation where you have e.g. OpenGL ES 2.0 and you have conformance testing for say 6 different tiers of support, you can then build your software to a lower tier then everything above that should support it.
  14. Certainly it is not all politics by any stretch of the imagination, and I agree that GL in particular has been plagued by a lot of historical cruft, however what I personally find notable is that DirectX has not been an open standard. It is a difficult problem, as the fundamental techniques used to create 3d graphics have changed so much over the years (and will no doubt continue to change). There seems to be both a need to have a stable longterm high level API where perhaps some performance / access to techniques could be sacrificed, and a need for a changing lower level API that can 'throw out the last version' and have the most suitable access to the latest hardware paradigm (or multiple high / low level APIs). My personal preference would be for some stable higher level APIs that 'translate' down to the some more changing lower level APIs that are also accessible. And for the APIs to be as open as possible, i.e. free to use and not patent encumbered, and not governed by any one company, although I understand the perils of design by committee. Another thing I would like is the option for standardised feature sets, so it would be possible to target a certain minimum feature set and be sure they were supported by the hardware.
  15. Hi Eddie I did get to try the early version, I think I read someone suggesting that you could have a graduated really easy small map to start people off to get them used to how it works before moving to bigger map with loads more towers, and I totally agree with that as it is a bit daunting for a beginner! It is looking really good, and getting feedback on all the playtesting is really worthwhile. Myself my tiny brain found it a little overwhelming with the sheer amount of towers and enemies and haven't had enough time to get the hang of it yet lol!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!