Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Apr 2006
Offline Last Active Yesterday, 01:52 PM

#5029019 +4 bones vertex skinning

Posted by jmakitalo on 05 February 2013 - 07:00 AM

I'm confused. Is was under the impression that in fact this is the "bind pose approach" - these weight positions are provided only in bind pose (scratch that, they are pose independant, they only inform about mesh "volume", combined with bones, bind pose or not, they give the final result) and I also have bind pose skeleton provided. So how do I get rid of these weight positions? What's the usual approach here? Right now I have bind pose skeleton but in fact I don't use it while animating. It's only helpful when "unpacking" animation (skeleton) frames but it looks like there's a reason it's there. I have no idea if Doom3 uses these weight positions in shaders. I just followed mentioned tutorial and ended up here.


I animate MD5 meshes in a way C0lumbo implied. Post multiply your animation pose matrices with the inverse bind pose. Then you can just send the bind posed vertices to the GPU.


I'm not sure how animating is done in Doom 3, but maybe it is possible that they did not use GPU skinning, because they needed the transformed vertices for constructing shadow volumes. Then it should be faster to have the vertices in weight space so that post multiplication by inverse bind pose is avoided.

#5029016 Trouble with very slow rendering with nvidia under Linux

Posted by jmakitalo on 05 February 2013 - 06:52 AM

Which drivers are you using? The default open source drivers have poor 3D performance, so make sure you have the nvidia's closed drivers installed.

#5021147 Losing interest in game development...

Posted by jmakitalo on 13 January 2013 - 12:15 PM

I can relate to this topic very well, and I can share bits of my story:


Game programming has interested me ever since I got my first computer. At the beginning of high school, many years ago, I started learning OpenGL and more advanced graphics techniques. With a few friends, we started a very ambitious first person shooter project with very little experience. I thought I could implement all the fancy stuff I read about, such as per-pixel lighting, dynamic shadows and so on, even though these were emerging techniques at the time and robust implementation was very challenging. The focus started shifting more and more towards making a 3D engine, not a game. I wrote a lot of code. Not having a good idea of how things will eventually connect, I often ended up with a bloated and non-inspiring code base. Then I rewrote all. Then I rewrote all again. And again.


There were many times when I just fed up with not completing the engine or a game and I decided to stop. Designing and programming games, however, always kept lingering in my head, and eventually I have returned to the topic.


Two years ago, after having some break again, I decided that I will start a new 3D game project and I will keep it small and finish it. I wanted to have something complete to show that I can do game programming. The project is still under active development, but I managed to keep it graphically very simple at the beginning, and actually wrote a lot of game related stuff. Then I succeeded in having a playable version running, before starting to add fancy graphics. This is what I should have done many many years ago. But I think I learned a huge amount of stuff and I learned what it will take to implement certain techniques. So when I started this particular project from scratch, I had a pretty good idea how things work.


I guess that the thing about game programming and programming in general, that keeps me being interested in it, is that you can be creative. You can come up with some cool idea, design it, code it and when you get to see your creation, the feeling can be very satisfying.


The other thing, that pinebanana also brought up, is deciding the level to work on. There are so many game and graphics engines, that making your own from scratch can be difficult to justify. Of course, if the aim is to learn and if the game does not need that much technology, making most of the stuff yourself can still be reasonable. But to me it seems that saying "I made this game all by myself" might carry a different weight depending on just how many libraries I used or if I used an existing engine.


I'm not sure If it is a problem for any of you guys, but to me it has started to be increasingly important that a code and a program is usable after, say, 10 years. It seems that 3D graphics schemes and API:s evolve at a huge pace, so ensuring future compatibility can be difficult. If I doubt that the code might not compile or  the program might not run in the near future, this is a major discouragement.

#4986302 Improving Terrain Textures (getting banding)

Posted by jmakitalo on 03 October 2012 - 12:35 AM

I've also been working on terrain texturing lately and the greatest problem has been avoiding noticable tiling. Basically I have an array of textures, four noise channels and a mask for up to four "painted" textures. In addition to these pained textures, there is a base texture, cliff texture whose weight is determined by slope and a shore texture whose weight is determined by height. At the moment, I use two slightly different texture maps for each texture type and use carefully chosen noise to mix these. This gives quite nice results and makes tiling quite difficult to notice, but the noise must be well adjusted. The noise should be quite high contrast and patches of 0.0 and 1.0 should occur on the scale of the texture period. I basically used a cloud filter in Gimp and made the contrast higher.

Previously I tried mixing the same texture with different scales. This made tiling much less apparent, but it also makes the texture fuzzy and close up detail is pretty much lost.

As to the banding, it seems that you use slope to smoothly blend between textures, but a strict if condition to switch textures by height. Make some transition height ranges to smoothly blend by height. Insted of if(heightPercentage < 0.05f), define two height values around 0.05f and interpolate two textures along these values.

#4953018 Don't start yet another voxel project

Posted by jmakitalo on 26 June 2012 - 08:06 AM

I have been doing 3D graphics programming as a hobby for around 10 years, though I haven't done anything with voxels. My work involves electromagnetic theory and modeling and I have used also finite-difference schemes to model propagation of optical electromagnetic waves. This "voxel" approach is useful, because the fixed cell size, depending on material properties, can lead to implicit time stepping, where only a diagonal matrix needs to be "inverted" at each step. In more geometrically general finite-element methods, matrices are not diagonal (even though they may be sparse) and this has significant computational cost. Although it is possible to locally refine the spatial representation of the fields in finite-difference schemes, it becomes really cumbersome. The same goes for attempting to represent curved material interfaces by either refining the starcasing or somehow "bending" the cells. So although the voxel approach seems at first glance simple and fast, it gets really tedious and ugly when you try to improve it to a level that would really cover the cases that you are interested in. The content creation approach works similarly here as in 3D graphics: it's really easy, in principle, to define a shape by just marking some cells as dielectric, metal, vacuum etc. Creating corresponding shapes with a 3D modeling software by using some n-simplices is more involved.