Bacterius

But how's your knowledge of Lagrangian mechanics? Poisson distributions? Standard deviation? The rules of integration and differentiation? Pipelined architectures? Data structures? Computational efficiency? BN notation? Colour theory? The physics behind lenses? Mutexs? Locks? Lock-free code? SIMD? Solutions to sparse matrices? Can you dervie the equations to convert a quaternion to a matrix from scratch?

 

Yeah, it's probably not necessary to be an expert in every single mathematical and engineering subject to be a good game programmer. Most of the stuff you cited can be looked up on the internet or in a book without needing to remember it. Sure, knowing calculus is very useful, having a good grasp of geometric optics and how pipelined processors work helps a lot, but if someone asks me to spit out the computational complexity of [insert obscure datastructure here] or to evaluate [insert complex integral here], I'm not going to waste my time trying to recall that information or spend fifteen minutes integrating by parts and starting over because I made a sign error, I'm just going to look it up on google/give it to mathematica respectively. It's not being lazy, it's being pragmatic.

 

Never memorize something you can look up. Oh, and another one I like: the important stuff is never on exams. So learn in your own time, if possible before you cover it in class, and use high school/university to guide you to your next topic and patch up any holes you might have missed during your self-learning (that last point is very important! if you don't regularly recalibrate your own knowledge with some reference curriculum you will crash and burn very quickly! and remember to practice what you learned as well, just "knowing" is useless). That's always worked for me, so I recommend it though people vary in how they learn so YMMV.

Mmh, I never had cracks in Marching Cubes with constant level of detail, at least I don't remember having any. That said, cracks do occur when you try and implement LOD, in that case a smoothing or stitching algorithm is required (another alternative is the transvoxel algorithm by E. Lengyel, though I am not sure if it's patented, it is iirc)

Yes, scattering critically contributes to a lot of existing materials. Without it, you simply cannot accurately render stuff like milk, marble, skin, etc.. or it just looks opaque and fake. That said, most weakly scattering materials (all materials scatter, to some extent) can be approximated with BRDF's. And if the material absorbs sufficiently, you can probably ignore the deep scattering part of the equation.

 

 

What kind of interaction between light and matters leads to wavelength dependend absorbtion?

 

Pretty much, electrons inside the material are excited by photons of a particular set of frequencies, and absorb them, possibly re-emitting them. Though I believe the photon is re-emitted in a random direction in any case, so in this case perhaps the lattice structure of the material's atomic composition would seem to be responsible for the intricate scattering phase functions? Just a guess, I don't really know what happens at such a low level.

 

@Hodgman: I think scattering of waves makes sense when you think about diffraction, after all, a light wave coming into contact with a very small particle would diffract and interfere with itself, and I believe this is what we see. Though the particle explanation is more intuitive, yeah.

If the server is going to be freely available then obviously you need to decouple account logic from server logic, unless you want people to register a new account for every server they join. At that point, all the accounts need to be stored in a separate database, upon account creation you must:

 

- have the user generate a random, sufficiently long salt, say 16 bytes

- have the user hash his password using the salt (do not use MD5, SHA256, SHA512, .. use bcrypt, scrypt, or at the very least, PBKDF2, properly configured, this is CRITICAL)

- securely receive the salt, and the hash generated by the user (and his username, too..). This is far from trivial already, since you will need some sort of secure connection to the server, best is probably to do the registration online via an HTTPS form (SSL/TLS), of course if you want to avoid MITM you'll need to purchase an SSL certificate which is.. let's say it's not free, but you can do that later on. If you cannot securely transport the password to the server, you have zero security.

- perform a cheap final hash on the received hash, say SHA256, and store that along with the salt (CRITICAL)

 

Now upon login, you need a secure connection (if you don't, anyone can intercept the stuff you send and impersonate you via a replay attack), and then:

- client sends his username, and asks the server for his salt

- client receives salt, computes the same hash using the salt, and sends it off to the server

- server does the cheap hash on the received hash, and checks if it matches the hash in the database, if it doesn't, access denied

 

This is the basic password authentication protocol. A better approach is to use a protocol called SRP (no, that's not single responsibility principle, it stands for Secure Remote Password) which is considerably better than this, and, in fact, disallows brute force attacks assuming the server can authenticate itself (via an SSL certificate or whatever). Although it's more complicated, harder to deploy, and probably overkill.

 

All in all, you should probably use an existing password storage solution. In fact, if you were storing more sensitive information than just game accounts, say, credit card stuff, you would need to be PCI-DSS certified, but there is no moral reason not to approach game account passwords with the same care. Many people wrongly use the same password everywhere, and you do not want to deal with the legal issues you may end up facing if your account database fails.

 

At this point, there are two points of attack:

- on the password database, this is not a problem if the client properly configured the hash

- during account creation, this doesn't work because all the server gets is a salt and the password hashed using this salt, so unless the password is extremely weak to begin with, he won't be able to brute-force it, especially if you use a slow hash as recommended

 

This will fulfill your original requirement of protecting against unscrupulous server owners, however you MUST be able to set up a secure channel between the server and the client when the hash is sent over the network, because otherwise, your password will be safe, but won't actually protect anything. Anyone can snoop on the hash, and then send it himself at a later time, and boom! he has access to the user's account.

Oh, you mean delta_u.

 

Nah, too long, "du" is used everywhere in mathematics as notation so it's a perfect candidate as a variable name. On the other hand, more complicated rates of change could use better variable names, "d3udv3" doesn't work out so well 

remap(ai,aj,ak,ci,cj,ck,x,y,z,ijk);
vc.find_voronoi_cell(x,y,z,ci,cj,ck,ijk,w,mrs);

This code has to be generated by a machine. Or he did a search & replace at the very end. No sane human can make sense of this.

If you want to check your assumptions, but without computing the integrals by hand, you can always resort to numeric integration using monte carlo sampling. I'm pretty sure, boost comes with a random number generator the produces evenly distributed random directions.

No need for random directions - just use spherical coordinates (and if your BRDF is isotropic, you only need the elevation). Every time you use dot(L, N) in your shader, use cos(theta), and so on. And then you can just integrate it numerically in Mathematica or something.

And that dot product lighting in video games bypasses the concept of radiance and defines lights in terms of irradiance

What? No, the solid angle is always taken into account in direct light sampling (which is what games usually do). See that division by the distance to the point light squared? That's the solid angle part. The cosine term (dot product) does happen to cancel out for most BRDF's, though. Radiance and irradiance are two completely different concepts, irradiance does not take direction into account, it's simply the radiant energy flux density (i.e. per unit area) emitted by a surface (in every direction).

Your calculation using irradiance is technically correct for diffuse surfaces, but the only reason this is true is because such surfaces have constant reflectance (for diffuse surfaces, irradiance is equal to reflectance, this is what light baking actually does but it only works for diffuse-only surfaces, or generally surfaces where the reflectance happens to be independent of view angle). It does not work for more complex reflectance functions (BRDF's), this is what simple pixel shaders do:

set the lighting term to zero
calculate the surface normal N

for every point light in the world:
-- calculate the distance D from the light to this pixel
-- calculate the view vector V (camera to pixel) and the light vector L (pixel to light source)
-- evaluate the BRDF for (L, V) as reflectance ratio R (both for diffuse and specular)
-- divide everything by D^2 (inverse square law) and multiply/divide by dot(N, L), PI, as needed
-- add this to your "lighting term"

add ambient, light-independent stuff
modify your pixel's color depending on the lighting term calculated
 

Computer graphics shaders aren't a role model of clarity, generally they are not concerned with making sense, they just need to be fast and correct. Sometimes you'll see things like the inverse square division missing as it was accounted for elsewhere, the PI division was baked outside the shader, and so on.. shaders probably aren't the best way to learn radiometry.

I think it's really the notion of BRDF that you are missing here, diffuse surfaces aren't everything and tend to simplify a lot of stuff which is actually relevant for every other type of surface. As for the BRDF, the concept is fairly simple, if a bit abstract - for a light vector L and a view vector V, the BRDF returns the fraction of light incident to the surface along vector L (note this is radiance) which will be reflected along vector V.

PS: in the pseudocode above you also need to check if the point light is occluded by geometry, if so you need to cast a shadow instead. And you will notice this is not physically accurate, as it is ignoring the light contribution from light bouncing around the world and only considering direct lighting contribution from the point light sources themselves.

Area lights are in theory handled like an infinite number of point lights clumped together (but in computer graphics different methods are used, obviously).

Luminance isn't a radiometric quantity. It's basically radiance weighted by an observer's luminosity function. If you compare the definition of radiance and luminance, you will see they are exactly the same with the exception that radiance uses watts whereas luminance uses candelas (which are just watts weighted by "perceived brightness", loosely stated).

 

I have to agree with Juliean, this is probably not the definition of luminance you were thinking of, and I think what you are looking for is pretty much just what you already know - it's just radiance, weighted to match our tristimulus color matching functions (this is what photometry is about - how humans and other species perceive light, not just a radiometric physical interpretation of it)

Is there a way to prevent anti-virus from false flagging my program?

Yes. Whitelist the program in your antivirus, report it as a false positive to the antivirus developers and be on your way. Unless you really want to hack your way around this particular antivirus (and run the risk of being flagged by another one).

im learning about arrays and lists in java and i come across linked lists and i have yet to think of a useful way of using them... mabe im not fully understanding their capabilites? if anyone could clear this up greatly appreciated!

 

Linked lists are good when you are doing a lot of random insertions, in a linked list this operation is very cheap whereas in an array you need to shuffle things around. For instance, say you have an array with one billion items in it, and you want to insert some item right in the middle. You will need to take the 500 million items after the insertion point, and shift them up 1 place up the array to make space for the element you're about to insert. In a linked list? No problem, find the element before and the element after where you want to insert your element, and simply modify their "next element" (and "previous element", if applicable) pointers, which naturally inserts the new element into the list without touching any element other than the two surrounding the insertion point.

 

On the other hand, you cannot have random access in a traditional linked list - if you want to read the Nth element, you need to walk through the linked list until you reach it, costing you N operations, instead of 1 operation for an array, since you can just directly get the element you want in an array. As you can see, they both have pros and cons.

 

The way you use the list is exactly the same, because they ultimately perform the same function (they are both lists) but depending on what you do with the list - what kind of operations, what sort of data you're manipulating - you should select the most appropriate one for your particular situation to optimize performance.

 

It is worth noting that unless you are in a very particular situation, linked lists do not win over arrays, simply because arrays are faster in modern hardware due to cache coherency and sequential memory access, whereas linked list traversal tends to jump all over memory. So the places where you would realistically use a linked list, other than for learning, are quite limited.

Hello, I am not trying to start a language war here.

Unfortunately that's not how it works. Language war initiated... 

 

I am looking to learn a second language and use it for things like making GUI applications quicker and easier than c++.  The type of application that absolute speed of the application is not paramount, but making it quickly and easily is more important.

 

So it seems like for general purpose languages that strive for productivity, C# and Java are the top 2.  Which is the easiest to use for making general purpose programs with GUI's?

 

From my limited experience, I've found C# to be more straightforward to create nice-looking GUI apps, and I still have nightmares about Java's horrible "swing" UI and painful implementation. I hear C# inherits some UI development aspects from Delphi (since it's the same guy behind both languages) and so I'd be more inclined to pick that one if I had to choose, but this is subjective. But I'm sure they both have good libraries and tools to create UI's. Have you tried giving each of them a little trial?

I agree with the first statement. But the second statement seems odd, wouldn't the method work all the time for that following condition. A screen width can be an integer value of 580 which is always certainly greater than an arbitrary value of 20 hearts.

 

Yes, but what if you want more than 20 hearts later on? Or add more things (like armor, ammo indicators, which also take up screen space and reduce the amount of screen estate available for showing life)? I believe this is what was meant.

I think there's a graphics engine that supports marching cubes and hence arbitrary terrain destruction.. C4 engine by Eric Lengyel. An extra feature is it supports LOD without cracks, which is difficult to get right. The author is a member here too  It's a bit expensive though but it's what first popped into my mind when you mentioned fully destructible terrain.

Well it depends on your programming language, what I usually have, for C or C++, is as follows:

 

project
 |- bin/           (for binaries and required DLLs.. you can also have a lib folder)
 |   |- debug/
 |   |- release/
 |- data/          (for assets, such as databases, images, sounds, and so on)
 |   |- images/    
 |   |- sounds/
 |- doc/           (for your documentation, either generated or written)
 |   |- html/
 |   |- pdf/
 |- src/           (for the source code files, organize in subfolders)
 |   |- folder1/
 |   |- folder2/
 |- include/       (for the header code files, if applicable)
 |   |- folder1/
 |   |- folder2/
 |- misc/          (anything left that you want to include)

 

 

When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

 

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

 

This also applies to resources to some extent, so for release you probably don't want a bin/ folder.

 

If you use an installer you can make things more consistent, but this is more advanced.