Jump to content


Member Since 04 Dec 2001
Offline Last Active Jan 16 2014 07:47 PM

Topics I've Started

Breaking a wall of stones

22 November 2013 - 10:23 AM

I want to add a bit of physics into my engine / games. I most certainly will not use any external library, and want to code it from scratch.


I expect a lot of code to be refactored progressively, and that's fine. The thing is, I have to avoid reading 5 books and 20 articles to extract just those few important bits and pieces of them. This is not a complex ragdoll physics.


Desired characteristics:

1. All I need is to be able to break the wall of stones (say, 20-30 big stones) and have them react realistically, depending on the force exerted.

2. Perhaps only 1 stone will fall out (and others will move a bit - kinda lean along the vector of the force), with the quadratic falloff based on distance from the center.

3. When you exert more force, more stones will fall out and when they collide, they should definitely react realistically - e.g. behave differently depending whether they fall on edge or a side.

4. My understanding is that I need to account for a friction, since if they just slid smoothly over one another, that would break the realism

5. Stones need to pile up

6. Stones will be aware of the gravity, so if enough of the stone is sticking out (without the support of the stone below and above), it will tip over itself and fall down.


So, how would I go about it and where would I start ? I remember having a physics subject at high school where we used to calculate all kinds of examples with heavy stones/friction/falling - but it was all just a single stone.


I'm not really looking for code examples, more like articles with game environment in mind.


Theoretically, it does not sound like a lot of work - perhaps 50-100 hrs would be my early guess ?



My early outline of things to experiment with:

1. Start with stone simply falling down (accounting for gravitation) and stopping when it hits floor.

2. Get two stones to react - when one falls on top of another - and let it react appropriatelly (either stay on top of it, or tip over and continue falling till it reaches floor)

3. Self-aware stones in the wall, sticking out a bit that will tip over based on how much they stick out.



Any specific ideas ?

[Metallica] [IMAX 3D] -> Anyone looking forward to it ?

24 September 2013 - 11:20 AM



Can't wait !


Few months ago (I think it was during the Elysium) I had a chance to experience the briliant trailer of the upcoming Through The Never in my local IMAX.


Since this was my first experience with the sound quality of a music performance in IMAX, I was pretty blown away. You'd never guess the IMAX's  audio system is THAT good just by seeing regular movies there ! The sound was incredibly clear ! Minimum distortion, maximum immersion :-)



So, any of you guys looking forward to it ?



Usefulness of Geometry Instancing

15 May 2007 - 06:00 AM

So far, I lived under assumption that Geometry Instancing saves number of DIP calls and abuse of vertex-shader units through some intelligent HW that knows which parts of VS should be reexecuted per given instance, thus raising the maximum vertex-throughput. But I just read this old paper (http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_SM3_Best_Practices.pdf) and it seems that the only performance benefit comes from savings in CPU overhead of DIP calls. Who would be so stupid that would be rendering a forest through 10.000 DIP calls anyway ? I mean, everybody is batching some-how. Thus, if your current system renders the items through up to 10 calls, there`s no performance reason to switch it to instancing, if memory is not an issue. And memory can`t be an issue, since even if your Vertex Buffer would contain 100.000 vertices, a separate stream containg indices to constant buffer (holding per-instance data) would be less than 0.4 MB. In fact, it might be a little bit slower, since there`s a fixed overhead when using instancing. So, instancing seems to be usefull only for cases, when one is lazy or must code a rendering routine of some huge crowd within 2 hours and has no time for optimizations. Which would be ridiculous, but that`s how it seems to be, since if instancing doesn`t save you from vertex-transforms, you could easily batch it yourself anyway. Am I therefore right, that each vertex of each instance goes through a vertex shader anyway ?

Alternatives to DXT texture compression

13 December 2006 - 12:18 AM

I`m using the DXT compression heavilly, but I wondered if there isn`t something even better (haven`t spotted anything else in DirectX). Or maybe there`s some other way around this ? I once noticed a texture decompression pixel shader discussion somewhere, but this has got to be slow since it`s not HW implemented, it`s just a shader. So are we going to be stuck with DXT forever, or is there something else that I`m unaware of ?

Relocation/Visas from Europe to Usa/Canada

11 December 2006 - 03:37 AM

Let`s say, I have a ~4 yrs experience on PC (DirectX/C++) developing several projects in areas like - Engine,Graphics,GamePlay,Front-End,AI - which could theoretically land me a job as a senior programmer or just a regular programmer. What is the current situation regarding obtaining the necessary VISAs for me (and my family) ? Does this happen at all (transfers from Europe into USA/Canada) ? I understand, that I would pay the costs of relocation (flight tickets) and VISAs on a monthly basis back to the company where I would work. But I found out that you need to wait 4 yrs before you can obtain PR status in Canada (from the time you submit the application). That is, only if you don`t get rejected. Employer can`t wait even 4 months, not 4 yrs. Is the situation any different if the employer shows to relevant organizations/offices (that issue the VISAs) that he wants to hire some specific applicant ? I mean, in this case they would immediatelly (i.e. within 2-3 months) issue the VISAs ?