Matias Goldberg

Hi! You are using wrong with terms.


"Key frame animation" is about interpolating values across time, while just defining a few "key" values at specific moments. This is still widely used.

The MD2 file used key-framed "vertex animation". This is rarely used nowadays because it's not flexible & eats a lot of memory and bandwidth. The only exception are facial expressions, where usually a "delta" variation of the technique is used. Anyways vertex animation is pretty simple to learn.

"Vertex animation" was dropped in favour of "skeletal animation"; which is probably a bit harder to understand at the beginning, but more powerful, flexible; and replaces the Memory consumption with more CPU/GPU consumption (which is a good thing; computational power grows faster than memory size and bandwidth)


In both cases (vertex & skeletal animations) key frames are used.

Edit: Some modern games (i.e. Assassin's Creed & Uncharted) also use IK (inverse kinematics) in real time in addition to keyframe animation. This makes the animation a lot more interactive & unique. However IK is definitely not for beginners.



Cheers & Merry xmas to you too
Dark Sylinc

I had a whitepaper that clearly explained how that magic works, but you'll have to excuse me as I can't find it. At least I may point you some directions, Dijkstra's algorithm has to do with it. Follow the link to "routing" in Wikipedia.

*cough*

For more reading you might want to look up BGP (Border Gateway Protocol), which is mostly how ISPs communicate with each other. For comparison you may want to look up interior gateway protocols like OSPF or IS-IS.

Sorry. I was feeling guilty for going off topic starting with my 2nd post, with little contribution to the original questions (it was unclear whether he was doubting about how routing works, or how communications are made internationally); so I had to throw something.

Edit: It's sad to see Eelco's and my post both with -1; it makes it look like we've both thumbed us down each other. Thumbing Eelco's post up.

99% of all traffic going through underseas cables makes them neither 'backup' nor 'secondary'. If anything, it is the other way around, if you take the generous interpretation of calling less than one percent of capacity a meaningful backup, that is.

Hi, this has the potential of becoming a flame war, so I'll be brief.
The article in Wikipedia fails to cite that quote. There are two citations in that parragraph, and neither of them talk about the 1% vs 99%. Furthermore Wikipedia talks about cables as if they were all already made and links to articles about underwater cables, some which have actually started working last year, and some others yet operational.
Despite this, there's a shift to submarine cables, that's true; but I'll like to see reliable sources regarding the traffic comparison.
Optic fibers offer significantly lower latency and more bandwidth, but they're very expensive; and have their own set of problems: underwater earthquakes, shark bites, and anchor damage.

Well, enough getting out of topic. Regardless of whether satellite or cable is used, the story is the same. Client -> ISP -> Wholesale -> ***magic*** -> Wholesale -> ISP -> Client.
I had a whitepaper that clearly explained how that magic works, but you'll have to excuse me as I can't find it. At least I may point you some directions, Dijkstra's algorithm has to do with it. Follow the link to "routing" in Wikipedia.
We use a derived version from Dijkstra's in games BTW, called "A*" which is used for pathfinding.

Why is it not possible to connect my router to this "source" and bypass the ISP?

It is. Just hook up a cable to that "source" and you'll be done.
Problem is, that source may be on the other side of the world, so that must've been hell of a long cable. It is very expensive and inefficient for you (the only gain you'll get is direct access). We pay ISPs, many ISP just actually pay to the (usually) same wholesale provider; which sell by bandwidth.

With this system costs are reduced significantly and those wholesale providers are wired together. Sometimes these "providers" depends on the Government, that varies per Country.

Usually the communication is done all through satellite, with optical fiber cables going underground/underwater as a backup (satellite communication can be very unstable, depends on weather conditions on the ground, environmental hostility (i.e. a bird nest inside the satellite, I'm not kidding this happens too often), proper orientation, satellite availability and outer space conditions (i.e. solar flares).
Optical fibers are used as a backup because they are very expensive to maintain (underwater cables are somehow specially attractive for some creatures) and don't usually provide the same level of bandwidth. Not to mention it requires signal strength to be mantained, the longer it is, the more expensive it becomes.

Feel free to pay a giant bill to hook my router to yours if you want direct access to my PC. It's not a server so you won't find it very interesting though.

How the ISP knows which ISP to query to contact it's client , which will be the "source", based on just the IP number is a completely different question, and has to do about how the IP (Internet Protocol) works. TCP and UDP are built on IP as it's base.
Beware though, IP is an old protocol and works much more chaotic than one would think. Often people who know how it works ask themselves how the internet manages to hold together and stay functioning.

Cheers
Dark Sylinc

Edit:
To summarize, the connection goes (usually!) like this:

• PC -> ISP A
• ISP A -> Wholesale provider X
• Wholesale provider X -> Wholesale provider Y
• Wholesale provider Y -> ISP B
• ISP B -> PC "Source"

There aren't many providers (typically 1 to 3 per country). This communication is overly simplified since the IP protocol actually asks a lot of people before reaching the end, jumping (wasting) on a lot of computers first before reaching what you've called the "source". And the communication back may not follow the same route. Not even the same packet you've sent may follow the same route. Your ISP A doesn't magically know ISP B is your source's provider, so it has to start asking. And sometimes, those who have been asked don't know the answer but are aware of someone who may know, so they ask them too...

Similar schedule (from the original thread) here. Although I do find that sometimes I'm even more productive going early to bed and then waking up early (6-7 am), calmly drinking coffee and then going to the PC.

That having said, the time at which I'm serisously productive is after drinking a tiny glass of licour or whisky (or any other beberage with high alcohol in a small dose). It seems to grant me superhuman coding abilities. And I'm actually not kidding. My brightest lockless and highly scalable parallel algorithms have been coded under the influence of alcohol. Not only I write more code in fewer time, but the code itself contains less bugs than usual.
The xkcd's joke about Ballmer's peak may actually be true. I don't do this often though.

Hi, I haven't read your code, but I will answer your basic question; which is more important for you to understand your problem.

My first issue is that I don't fully understand the idea of rendering a sphere for a point light, take a look at this shot right from my program

Point lights have attenuation, at some point attenuation is so strong, that the light contribution is nearly zero.

Because of this, a sphere big enough that encloses until the last pixel that is lit by the light becomes a performance optimization.

Suppose you have a 1440x900 image, that's 1.296.000 pixels to parse. If the point light is very small (high attenuation), the sphere will also be very small; and if it's seen from far away; it will probably only lit a few thousand pixels. So the pixel shader is run on those pixels, rather on more than a million just to lit a few thousands.




NOW, if your attenuation parameters aren't carefully chosen, your point light will probably contribute light to the entire scene. Because of this, you'll need a very big sphere; which will probably occupy the entire screen. When this happens, then there's no actual performance gain. In terms of performance, Many little lights = One big light

Apparently in your screenshot, your attenuation is too weak (or the formula is wrong), and the sphere is too small for those parameters.

Furthermore very big spheres introduce another problem, which is what happens when the camera is inside the sphere. To account for that, you'll need to identify the situation from your C++ code and reverse the culling mode and set the Z function to Greater or equal for that sphere(s). But let's just solve one problem at a time.




Also note when the opposite happens, that is you have very strong attenuation and a big sphere; you may not notice it but you'll be wasting GPU cycles.

Cheers

Dark Sylinc

May be it was just a typo? You know, authors & editors do make mistakes. If you change "never return type void" with "never return type void*" then it just makes perfect sense.

Still no. Not quite. While you generally shouldn't do it, there are definitely times when it's needed, like a GetUserData() function, as has been discussed.

The fact that there are exceptions doesn't mean it's not bad practice. Down casting is another bad practice but sometimes it's necessary, specially when working with third party APIs.
For getters/setters users data, some use C++ objects to encapsulate (some name it "any_object"). Lately I've seen Ogre even goes as far as doing a template "any_cast"
I'm not particularly keen on that kind of bloat, but rather using just plain void*
Set/GetUserData is like yelling "I'm not touching that, be exteremely carefull with it and you're responsible for it"

malloc is another example that comes quickly to mind where you're forced to use void*

But on the general case, it's bad practice to work with void*

May be the "never return blah blah" is what sounds too strong. I thought the never means "ok, there may be exceptions" was implicit.
An advice on programming advices, never a sentence containing the word "never" can be interpreted as absolute. That includes this advice. Same happens with the word "always"

Cheers

Edit: The Google keyword that will help you find more information is "Code smell"

Ok, I see. You never talked about a volumetric texture (or any texture at all) so hardly think I could be referring to downsizing the vol. texture.

Funny the article talks about Real Time Simulation of 3D fluids and 2 seconds per frame is not real time.

Reducing the backbuffer's dimensions will greatly improve your performance as the pixel shader is run less.
However, reducing your volumetric texture's size may actually help, because of better cache usage. Just try what's best.

Btw. the technique in that article doesn't render directly to the backbuffer. It applies your raymarching shader to a much smaller offscreen render target and then mix the results with the backbuffer.

But the scarcity is represented by high price, not by lack of goods. It's not that there are no diamonds in shops for you to buy, it's that their price is very high and you can't afford them

My God!! No.
There actually are intentional attempts from individuals with dominance in the market or powerful influences try to alter the supply in order to keep prices high. Diamonds is exactly that case.

But commonly, it's the other way around, it's because there are not enough diamonds in the shop that the price is too high.

In the basic microeconomic model (which is really, really simplified; but the principle still drives it), the price is driven by the maximum profit the seller can make. Which means the equation Price - Cost = Maximum.
The diamond shop will prefer to sell 900 peanuts at $200 each, rather than selling his entire stock of 1800 peanuts at $50 each. He could try selling at $80 each, but then he may only sell 1000 peanuts. It's called elasticity (see demand's elasticity).

900 * 200 = $180.000
1800 * 50 = $90.000
1000 * 80 = $80.000

More units solds != more profit.
But in the end, elasticity is indirectly driven by scarcity; elementary goods like food are highly inelastic because of their scarcity and lacks of substitutes; while goods like diamonds are highly elastic.

But we've just analyzed it from a demand perspective.
Seeing it from the supply point of view is a whole different side (see how availability of raw materials is listed as one of the determinants).

If the owner can sell his entire stock of 1800 peanutes at $30 each, and he can still sell them at $40; he'll sell it for $40.
If his stock is now 20.000; and he invested an insane amount of money, he'll need to recover it, and may end up selling it as fast as he can at the lowest possible price.

How this all plays depends on the market you're in. Monopoly vs Perfect Competition; and we're usually in the in between.
If you look at Real Life ™, it uses a market closer to a monopoly (try counting how many CPU makers are, how many dominant GPU vendors exist, how many milk derivatives manufacturers exist that don't actually all belong to the same company, etc); but I recommend you to implement a more perfect competition system because it's the one everyone understand most, it's usually more fair (specially in a video game!, where you want to prevent frustration) and we somehow tend to think reality resembles more to a Perfect Competition (may be we're naive? light hearted?).

Cheers
Dark Sylinc

geometry shadering is the new and improved way of doing intsancing , so you need to declare D3D10_INPUT_PER_VERTEX_DATA and send it via the geometry shader

Nope. You got your facts wrong.

The Geometry shader is a way to generate more vertices/triangles from a given triangle. The geometry shader, unlike the vertex shader, can look at all three vertices, not to just a single one. Although geometry shaders can be used to emulate instancing, it's highly innefficient; since Geometry shader's performance drops quickly as the ratio output/input increases.

Geometry shaders is cool for point particles, other billboards (i.e. trees in the distance), and some cool effects . It has been a big dissappointment imho. The most intuitive thing to do was to use it for tesselation, but performance was horrible. That's why DX11 came with a tesselation stage. The medusa demo from NVIDIA shows a way to use geometry shaders for cool effects (the green energy in the part where the guy gets turned into stone).

If you play it nice, mixing hardware instancing with geometry shaders, it is possible to render an environment map in much less than 6 passes, therefore making it faster. If you play it wrong, it will be slower. There's been a lot of papers about different methods to draw to an env. map in less than 6 passes using geometry shaders. In fact IIRC there was paper published here in GD.Net

But a replacement for HW Instancing? No, that's not really it.

Cheers
Dark Sylinc

Hi! Watch out that if your loop gets unrolled, there's also an instruction slot count limit. It's GPU-dependant, but you have a minimum guaranteed of 512 instruction slots in Shader Model 3.0

You have to watch out of these because usually the Ati X1000 series have the bare minimum, and if you use more, your shaders will unexpectedly fail to load (with little information about the cause).
This is the kind of problem that makes a shader run in one GPU, and fail in another. Even though they are both SM 3.0 capable.
They're strange though, since you rarely hit the mark (specially since any DX10 capable HW can do a lot more); but it's disorienting when it happens; usually triggered by loops being unrolled.

Cheers
Dark Sylinc

Sorry but no. His point was that we couldn't accurately analyze three gravitationally bound bodies in terms of physics. This isn't true. At any point we can see the resultant forces, center of gravity, momentums of every component and subset of an n-body situation. We just don't have the mathematical tools to model them with closed expressions. His point was correct in that we do not have a perfect knowledge of physics. His example was incorrect. We do have perfect knowledge of the 3, 4, or even n-body problem. We just don't have the mathematical tools to model it with a closed expression.

a. It was already established one of the root causes was our lack of understanding the physics. And he pointed out we can't yet solve the 3-body problem.

b. The butterfly effect is a subset of the chaos theory. And when we go into Chaos Theory, we find out we don't know yet whether real life™ is deterministic or not. Should we scientifically prove God plays dice once just for fun in a while causing the universe to be non-deterministic, then our simulation becomes flawed, since PCs are inherently deterministic. We can try to play with entropy data from the outside or go multi core and hope the quantum mechanics break the determinism we need. But even then we wouldn't be able to introduce the same randomness "God" put into our life; being us unable to reproduce reality accurately. Furthermore, happen our world to be non-deterministic; many simulations would actually fail to produce life even if we knew all physics equations and had a 100% understanding. I'm cheering for a deterministic world therefore, just to think that there isn't something impossible; but we have to recognize there's a chance it may not be possible.

c. It's already established we need infinite processing power to simulate perfectly; since our simulated world may want to start it's own simulation just like we're trying. Or may be we shouldn't try it!!! Otherwise real life will stall until our simulation we just started stops (tip: if the scientist from simland decide to simulate their "real life", their world will stall too)

With a powerful enough computer you could even simulate them accurately

You meant an infinitely powerful enough computer? Unless all results are round numbers, "accurate" becomes truncated/rounded numbers with translated errors. You're waaaaay underestimating the butterfly effect, which leads us to...

The butterfly effect is exactly the same deal

You mean a computer with infinite RAM? Well then, since I have a very simple task for you: Compute the number PI with 100% accuracy. All decimals included. Then use it in your simulation.

Pro tip: If you miss one decimal, the butterfly effect will sooner or later kick you in the balls. Seriously. Try to debug THAT.


I miss when Gamedev automatically locket threads down after 2 weeks. Someone please lock this madness. One trivial comment bumps the thread after which soon 3 troll/flamewar/pointless/endless threads follow.

Out of curiosity, does your art use a lot of solid color fills or gradients (such as 2D cell shading)? This is an area where texture compression artifacts can actually be noticed fairly easily, and it's common to just bite the bullet on memory and use full res uncompressed textures if these textures are relatively static and viewport aligned.

Far from. I already stated that the issue is closer to that of a stippling pattern (adjacent pixels have vastly different contrasts). The results of the various dxt compressors we have tried have in all cases 'smudged' the contrasted pixels out, or messing up the other areas. Worse comes to worst, we'll just programattical pick out dxt-blocks based on their correctness of multiple compressors and stitch them together. Though, thats gonna be a painfully slow automated process! ;)

FWIW: Gradients are an easy enough case to support DXT compression - normalise your channels and upload the white/black values in your shader to denormalize them for max precision.

Sounds like the source is high frequency data. This means you have pixels very different one from another. DXT isn't very good at it.
Just like PNG vs Jpeg. Jpeg sucks when compressing computer-made graphs (i.e. MS Excel graphs) text, etc.

You may find this explanation very interesting for your artists so they know how to arrange the colours. What to do and what to avoid. Note how the first image is close to the original, while in the second one, no compressed colour except 1 pixel actually matches the original (DXT works in 4x4 blocks)

One final note: What is the memory budget and how much is used? there's little point in using DXT if you have plenty of unused VRAM and the memory bandwidth isn't saturated. Often though, DXT is used preemptively to max out the number of assets that can be included.
Tools like NVPerfHUD (NVIDIA); GPU PerfStudio 2 (ATI) & Intel GPA (Intel, works on other cards too, with less info) will tell you the GPU's memory & bandwidth usage.

Edit: GIMP's dds plugin comes with 3 different methods to select colours for dxt interpolation, plus a "dithering" option. That's 6 combinations in total. You may want to give them a try.

Good luck on your problem
Dark Sylinc

I'm fairly certain thats *not* the case, as that would make it 16:1 compression, not 4:1 compression as is documented everywhere

DXT2-5 has a 4:1 ratio; DXT1 achieves 8:1 ratio (against a 32-bit image). If you don't use alpha, DXT1 is your preferred choice.

My apologies though, as you're right 512x512 vs 2048x2048 is indeed 16:1; done my math wrong. There's no power of two downscaled resolution that can mantain the same aspect ratio, so let's say 512x1024 for explanatory purposes; but it's probably not a good idea to downscale in such way in a production environment.

I probably should have mentioned that our source art before compression is already at a higher resolution

I'm a bit confused.
"Source material -> downscale -> DXTn" vs "Source -> downscale -> store uncompressed"? right?

we are accustomed to appropriately creating individual mip levels to retain clarity.

The DDS format allows using custom mips; however if you use DXTn they'll be subject to compression too. I'm not sure if your problem lies in that you think you're forced to automatic mip map generation by using dxtn, or you don't like the artifacts caused on your custom mips (which is totally understandable, like I said, DXTn becomes weaker at lower resolutions).
Note however mipmaps solve two problems:

• Bandwidth usage.
• Filtering quality in very specific situations.

Therefore, by using DXTn you're getting automatic bandwidth reduction (reducing the need to switch lod at close distances). As for filtering quality, you can't solve that, but I'm pretty sure you won't notice it as the situations are very specific and tend to appear at steep angles (when you don't have anisotropic filtering to save the day) or when you have high frequency images at distant places (a. they're distant and hard to see, b. DXTn compression tends to suck with high frequency information anyway, just like Jpeg does).

You may have valid concerns that the mipmaps may not look the way you want in your artwork, but you should be asking yourself whether those artifacts in the mipmaps are actually going to be visible/noticeable once displayed in the 3D render (again, depends on the case).

Cheers
Dark Sylinc

Indeed, a DXT1 2048x2048 equals a 512x512 uncompressed. And no, DXT5 isn't superior to DXT1, it's just DXT1 with alpha channel stored interpolated.
There is a colour loss, but isn't generally much worse than regular JPEG artifacts (tip: don't ever, ever, EVER compress to Jpeg then to DXT1, always work your originals in lossless formats before going DXTn).

Specially on large objects (i.e. terrain textures) any loss on colour is way overcompensated by sharpness, lack of aliasing (due to giant-scaling the texture in the model), and detail conservation.

DXTn isn't suited for all kinds of applications, so you have to be well aware of how it works, and have some practical experience.
For instance, if your original image is 128x128 it's size in VRAM will be 64kb (nothing compared to 256/512/1024 MB current GPU have) and then all you have to lose there is colour (at such resolution, detail and sharpness won't be noticeable even in the original) therefore it will look "just ok" in DXT1 where you could easily use the uncompressed image as is, without downsampling.

Edit: Another example: If you're doing particles, it's usually better to use a grayscaled texture then colour manipulating the emissive compoment. Therefore, you can use L8 textures getting a 4:1 lossless "compression" ratio (A8L8 for alpha, you get 2:1). Almost no need to use DXTn; it may actually yield higher compression ratios, but the quality difference starts becoming too tempting.
A few particle FXs may need coloured textures though. You'll see, you have to be smart, know your texture formats, and decide on a per case basis.