• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1296 Excellent


About lawnjelly

  • Rank

Personal Information

  1. Problem with sleep

    Agree with addressing your diet and exercise. Be aware that lots of food additives are stimulants. You may be more sensitive to these than you realise. Try only having caffeine on waking, and only drinking decaf tea / coffee during the day. Little / no liquids in the evening helps, as it can prevent you waking needing the loo. Chocolate is also a stimulant, especially darker choc, and certain brands can have additives to the shell etc. And stay away from fizzy drinks etc these are loaded with stimulants. Another trick is to not use curtains / blinds so sunlight wakes you regularly in the morning. And yeah, wind down with tv / book, don't program before bed in my opinion, it will be on your mind, and your code will be awful.
  2. How that kind of textures is made?

    I had to implement this a year ago. If you want to do it yourself, the basic idea of how I did it was pretty simple. Just go through the pixels of your image, and for each pixel that has zero alpha, set the colour to the nearest non-zero alpha pixel. You could use euclidean distance, manhattan distance etc. Note that this is pretty slow, you will probably want to optimize it if you are using bigger textures. Here is a thread on optimization: https://www.gamedev.net/forums/topic/685357-uv-padding/
  3. As swiftcoder says, it is most likely you are fillrate bound. You may also be calling OpenGL in a sub-optimal way but that is less likely to be causing the 24fps. Android (and mobile devices in general) tends to have far lower fill rates than desktop (and also use tiled rendering). This is afaik partly to keep power use low and conserve battery. A lot of thought has to go into optimizing shaders, overdraw, transparency etc to minimize fill. Many techniques that you might take for granted on desktop are not feasible on mobile. A lot of devices just about have the horsepower to fill the screen once, and that's it. I would highly advise you to get hold of several older, low end devices to develop / test on, as your lowest targets will give you a better idea of bottlenecks as you go along, and certain shaders will malfunction / simply not work on some devices. Precision in shaders in particular becomes a key issue in my experience. You may also have to introduce different codepaths / shaders depending on device caps. https://www.facebook.com/permalink.php?story_fbid=1923486231219218&id=100006735798590 https://www.gamedev.net/blogs/entry/2264243-android-build-and-performance/
  4. Just a guess but the stride may be wrong for your packed vertex format, hence every few is coming out with the vertex position correct. If so this may be at fault: int stride = (3 + 4 + 2) * 4; I tend to use the sizeof operator instead of explicitly stating size, because the compiler may choose to use a different size from what you expect (and this can be e.g. different when compiling a PC build versus NDK build). You may also want to look into '#pragma pack' for your structures if you are not using it.
  5. For a long time I had been delaying finding a solution to feet etc interpenetrating terrain in my game. Finally I asked for suggestions here, and came to the conclusion that Inverse Kinematics (IK) was probably the best solution. https://www.gamedev.net/forums/topic/694967-animating-characters-on-sloping-ground/ There seem to be quite a few 'ready built' solutions for Unity and Unreal, but I'm doing this from scratch so had to figure it out myself. I will detail here the first foray into getting IK working, some more steps are remaining to make it into a working solution. Inverse Kinematics - how is it done? The two main techniques for IK seem to be an iterative approach such as CCD or FABRIK, or an analytical solution where you directly calculate the solution. After some research CCD and FABRIK looked pretty simple, and I will probably implement one of these later. However for a simple 2 bone chain such as a leg, I decided that the analytical solution would probably do the job, and possibly be more efficient to calculate. The idea is that based on some school maths, we can calculate the change in angle of the knee joint in order for the foot to reach a required destination. The formula I used was based on the 'law of cosines': https://en.wikipedia.org/wiki/Law_of_cosines I will not detail here but it is easy enough to look up. For the foot itself I used a different system, I calculated the normal of the ground under the foot in the collision detection, then matched the orientation of the foot to the ground. My test case was to turn off the animation and just have animals in an idle pose, and get the IK system to try to match the feet to the ground as I move them around. The end effect is like ice skating over the terrain. First I attempted to get it working with the main hero character. Implementing The biggest hurdle was not understanding IK itself, but in implementing it within an existing skeletal animation system. At first I considered changing the positions of the bones in local space (relative to the joint), but then realised it would be better to calculate the IK in world space (actually model space in my case), then somehow interpolate between the local space animation rotations and the world space IK solution. I was quite successful in getting it working until I came to blending between the animation solution and the IK solution. The problems I was having seemed to be stemming from my animation system concatenating transforms using matrices, rather than quaternions and translates. As a result, I was ending up trying to decompose a matrix to a quaternion in order to perform blends to and from IK. This seemed a bit ridiculous, and I had always been meaning to see whether I could totally work the animation system using quaternion / translate pairs rather than matrices, and it would clearly make things much easier for IK. So I went about converting the animation system. I wasn't even absolutely sure it would work, but after some fiddling, yay! It was working. I now do all the animation blending / concatenation / IK as quaternions & translates, then only as a final stage convert the quaternion/translate pairs to matrices, for faster skinning. This made it far easier in particular to rotate the foot to match the terrain. Another snag I found was that blender seemed to be exporting some bones with an 'extra' rotation, i.e. if you use an identity local rotation the skin doesn't always point along the bone axis. I did some tests with an ultra simple 3 bone rig, trying to figure out what was causing this (perhaps I had set up my rig wrong?) but no joy. It is kind of hard to explain and I'm sure there is good reason for it. But I had to compensate for this in my foot rotation code. Making it generic To run the IK on legs, I set up each animal with a number of legs, and the foot bone ID, number of bones in the chain etc. Thus I could reuse the same IK routines for different animals just changing these IK chain lists. I also had to change the polarity of IK angles in some animals .. maybe because some legs work 'back to front' (look at the anatomy of e.g. a horse rear leg). The IK now appears to be working on most of the animals I have tested. This basic solution simply bends the knees when the ground level is higher than the foot placed by the animation. This works passably with 2 legged creatures but it is clear that with 4 legged creatures such as elephant I will also have to rotate the back / pelvis to match the terrain gradient, and perhaps adjust the leg angles correspondingly to line up with gravity. At the moment the elephant looks like it is sliding in snow down hills. Blending To blend the IK solution with the animation is kind of tricky to get to look perfect. It is clear when the foot from the animation is at ground level or below, the IK solution should be blended in fully. At a small height above the ground I gradually blend back from the IK into the animation. This 'kind of' works, but doesn't look as good as the original animation, I'm sure I will tweak it. Another issue is that when one leg is on an 'overhang', you can end up with a situation where the fully outstretched leg cannot reach the ground. I have seen that others offset the skeleton downwards in these cases, which I will experiment with. Of course this means that the other leg may have a knee bent further than physically possible. So there are limits to what can be achieved without rotating the animals pelvis / back. Anyway this is just description of the trials I had, hopefully helpful to those who haven't done IK, and maybe will generate some tips from those of you that have already solved these problems.
  6. Use assimp for skeletal animation HELP!

    If it helps this is what I do: // local bone combined matrix matBoneLocal = matBoneLocalTrans * matBoneLocalRot; // global bone matrix is combined with parent matrix matBone = matParent * matBoneLocal; // the skinning matrix also combines back transform to get vertices into 'bone space' matSkin = matBone * matRestInverse; That last step probably isn't necessary if you store your skin verts in 'bonespace', i.e. pretransform them back to be rooted from the origin and pointing along the default axis. You can find out whether you need this by just drawing the skin with identity matrix and seeing what it looks like, whether it looks like the character in rest pose, or all the bones on top of each other.
  7. Use assimp for skeletal animation HELP!

    Make it even simpler I think, why is the root bone (which is the root?) moving at all? Put the root bone start from the origin pointing along one axis, and only move the second bone, perhaps at 0 degrees (straight) (should be just a translate, no rotate component), 45 and 90. It kind of looks like the order of translate / rotate might be wrong, but it will be easier to see with more simplified. (I'm not even looking at the code, there's too many permutations for my tiny brain lol).
  8. https://www.youtube.com/watch?v=2772HKIsf1M http://www.darwin3d.com/gdm1998.htm It turns out I'd actually done stuff similar to the CCD algorithm in the past.. although the constraints will be fun, one suggestion was to convert to euler angles, do the constraints, than back to quaternions. First I'll try the 2 bone analytical solution though, as it might work for leg heights and I would guess is the most efficient. It has inspired me I might use a similar technique to animate the snake in game!
  9. Thanks guys! I've found some IK example source code and it doesn't look as frightening as I feared. So I'll try and have a go when I get some spare time!
  10. Anecdotally yes, based on the very little I know about the security model. Providing you don't desire the latest graphics, and can live with optimizing for lower power machines then Android (and iOS) make a lot of sense imo. Far easier to deploy. One of my testers is an expert at installing / uninstalling, and he's 5 years old.
  11. It was me first being suspicious! There were 2 things at play here though I didn't realise the itch was not your game (never underestimate the stupidity of your audience ) You released no screenshots or video of your game, no tech requirements Aside from warnings about unsigned software, as far as this kind of thing, it is all about reputation as the others say. The more screenshots / video / explanations / feedback you have, the more trust you get. With none of these, no one wants to risk their windows installation getting hosed. This is particularly a problem with windows imo as the OS is hopeless at installation / uninstallation issues, so things are more likely to get borked. So zip files are better than install files, no registry hosing, you can see what you are getting / dependencies etc. On a related note I've found I'm testing shedloads more software now I'm on linux and can sandbox windows stuff in WINE. A virtual machine would probably be good too. Also I'm testing plenty android stuff .. painless install / uninstall etc.
  12. I did try this (just with pitch rather than taking into account roll, but the effect was similar). It 'kinda' works but it looks a bit wierd (as gravity no longer seems to be pointing downward). I guess I may end up partly using a milder version of this as part of a solution.
  13. Anyone have any suggestions for ways of animating characters on varying slopes on landscapes? I've no idea what are standard ways of dealing with this, and have been putting this off to some extent. The issues are mainly with larger animals cutting through the terrain on slopes. I've tried raising animals up higher above the land, but they look obviously 'in the air' in certain positions. I've also tried putting 2 land height probes at the front and rear, so that they change height according to their orientation, but that looks silly with strange changes in elevation as they move. I've also tried changing the pitch angle when rendered, this looks a bit silly (but not out of question lol). Another possibility is to turn off depth testing against the landscape, but I would have to figure a way of still having it working when they are behind mountains. Perhaps if I push back the depth value of the land this will work. I have read this article on mechwarrior 4: https://www.gamasutra.com/view/feature/131863/animation_blending_achieving_.php and I see they deal with it by having a flat animation, left and right and up and down slope animations, and blending between them. I can do this, but it sounds like a lot of extra animations for a one man team, and it also means I'd probably have to use a lower / upper body split for all animations, rather than be able to use full body. Plus use some performance for the blending (this is on mobiles). I've not really used IK before in game, is this a realistic / practical solution? Or can I use a simpler system, make some standard poses on flat, and slopes, then measure knee etc angle offset, then blend in these offsets with some scaling at runtime to make the legs more bent or extended? Another solution is to just design around the problem and make the large animals only able to move over flat ground. I guess this is more what happens in real life, I haven't seen many crocodiles climbing up slopes on nature progs lol. Any thoughts, experiences on this would be welcome.
  14. DX11 Shadow Map Details

    That is exactly what an orthographic camera does. If you hold the direction same, changing the position of the camera does not change the 'image', only where the view is centred. This is the closest I could find to an ortho depth map pulled off google. If direction is the same and you move the camera position, you would just be scrolling up and down through a portion of e.g. the following image. If you move the camera further away, there is no effect, as the rays are parallel in an ortho camera. I would encourage you to try moving an ortho camera in e.g. blender to see how it works, before trying to use it in shadow mapping. I'm guessing the 128x128 figure you are quoting is the scale of the camera, which determines how much is fitted into the view. Fit more in and each object is going to be smaller.
  15. Voronoi Shatters results

    Are you are asking whether there are always flat poly edges rather than curved, if so, yup I believe so. I've not done 3d but I assume it is the same as 2d. They should all be convex. https://en.wikipedia.org/wiki/Voronoi_diagram
  • Advertisement