Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


jmakitalo

Member Since 05 Apr 2006
Offline Last Active Today, 12:13 PM

#5185116 Is upper division Linear Algebra a good idea or necessary?

Posted by jmakitalo on 05 October 2014 - 07:27 AM

They're all useful. Number theory tends to be a little more essoteric, but is useful for understanding things like the minimum number of bits needed to store (complex) information, or, in understanding how much accuracy you can rely on maintaining through a series of floating-point operations (and strategies to maximize accuracy by ordering operations differently).
 


The exact cource contents vary between colleges/universities but usually Number theory is about integers, e.g., prime numbers and such. In my university, a course that deals with floating point approximations of real numbers and the like is named Numerical analysis.


#5180637 Advanced heightfields in Bullet physics

Posted by jmakitalo on 16 September 2014 - 01:19 AM

At the moment I'm using Bullet for physics and collision detection with a basic heightfield terrain. The heightmap is 2048*2048 and so cannot yield very high resolution for my roughly 8 km x 8 km terrain.

 

I'm using a vertex shader for some portions of the terrain, which locally masks another heightmap, which is repeated 100 times, over the terrain. The heightmaps and mask are read in vertex shader to displace the terrain grid. The grid itself can be quite dense, so that the additional information from the masked heightmap is visibly utilized. This way I can achieve nice bumpy appearance for, e.g., forests and fields.

 

The problem is communicating this masked heightfield to the physics part of the game. My quick hack was to make a higher resolution map, say 4096x4096, where the two heightmaps are combined, and pass it to the Bullet physics. Of course this has still insufficient resolution in some cases and it wastes memory.

 

I started wondering if it would be easy to modify Bullet's btHeightfieldTerrainShape.cpp module to allow for such additional masked heightmap. A quick look gave me the idea that Bullet just samples the given heightmap on demand and doesn't do any costly pre-processing or caching. This suggests that I could add my masked heightmap easily by modifying getRawHeightFieldValue function and storing the other heightmap and mask in btHeightfieldTerrainShape. Can anyone confirm this?

 

Another related topic is that in the future, I may want to divide my terrain into, say 1 km x 1 km blocks that have their own heightmaps. The heightmaps would then be stored at varying resolutions and streamed from the disk. I would need to be able to update the Bullet heightfield quickly after a stream is complete and this requires that Bullet does not do any heavy processing on heightfield updates. Has anyone experience with anything similar?

 

Thank you in advance.




#5171358 multiple source files and global varaibles.......................

Posted by jmakitalo on 04 August 2014 - 12:49 AM

I recognize that you are still learning basic programming, but I still would like to give one design hint: don't use global variables. It will eventually lead to errors that are very difficult to trace and it will also make the code difficult to read. For instance, if I take a look at Function.cpp and its function clip_tiles(). It seems to reference the array clips, but it is not at all clear to the reader where this array is defined. Try to construct your functions so that they only act on the given arguments and have no reference to global things, except for global constants. Global constants are ok.

 

I remember the time when I was a beginner programmer and global variables seemed like an ok way to do things (I had also Basic background). I though it was impossible to write a big real life program without global variables. Boy was I wrong. It's very much possible to construct your game with something like

int main()
{
 CGame game;

 game.initialize();

 while(game.isRunning()){
  game.updateAwsomeness();
 }

 game.close();

 return 0;
}

No globals needed, everything is contained in class CGame. Some might say that this is not the best approach either, but it is certainly an improvement to using a number of global variables.




#5164871 object space normals and skinning?

Posted by jmakitalo on 05 July 2014 - 07:35 AM

I'm using object space normal maps with skinned meshes and at least I think it works just fine. 

 

I pass an object space light vector to the vertex shader. This is then more precisely in the object bind pose space. Then I transform that by the transposes of the bone matrices (which transform from bind pose to skin pose) in the vertex shader and pass that to fragment shader, where a dot product is calculated with the object space normal sampled from a texture.

 

To see how this works mathematically, say that n is object space (bind pose) normal and L is light vector in the object space (also bind pose). Let S be a bone matrix for one bone that transforms from bind pose to skin pose. We want to evaluate dot(Sn,L). This is just dot(Sn,L) = dot(n,S^T L). This is done for all bone matrices that affect the vertex in question and a weighted sum is calculated.




#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.


PARTNERS