Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Offline Last Active Yesterday, 09:57 PM

#5205442 Ambient Occlusion for Deforming Geometry

Posted by Promit on 19 January 2015 - 07:58 PM


Could ambient occlusion be used correctly on skinned models that are animating? It would seem that it only works on static objects that could be repositioned, rotated and scaled as a whole, but not when its geometry is deforming because the radiance map would have to be re-computed. Is this correct?


If by pre-baked ambient occlusion, then it's certainly used less on skinned models but is still used. Some will prebake only on areas that move less relative to each area. World of Warcraft, for example, has always used it on character models. Areas like armpits and etc. can still make use of it, and it's probably a good idea for any game still needing prebaked ambient occlusion.


I imagine that WoW and many other games are not prebaking AO but simply painting it into the diffuse/albedo maps by hand. That's something artists have done for decades. Centuries? Millenia?

#5202988 C# seems good, but....

Posted by Promit on 08 January 2015 - 08:53 PM

--While reading keep in mind I am in a mobile device--
C# seems to be really popular here, but I have heard it is slow and similar to java. I can read java code, but can kinda write it. I have messed around with c++ (which I kinda like so far), python and lua. So as I know when you begin, you should stay with one language. Should I just stick with c++ and learn a "pro" language first or continue on with Java. I have written a "black box" in java before and would not mind doing it again in any other language. I want to get into game programming and would like to start off with a language that is versatile and I can write faster (in the start of developing). What language should I start with and is the there any good ebooks/ text tutorials online that I can use with the corresponding language. I am open to almost any language that will be continued for a long time.
P.S. I really like game dev so far because on most dev forums your post get rejected because of stupid reasons cough *stack overflow*

> I'm new to driving a car. A lot of people seem to like the Toyota Camry, but I've heard it's very slow like a Hyundai. Should I just stick with a Lamborghini and drive a "pro" car first, or continue with my Hyundai?

If you try to drive a Lamborghini fast as your first car, you will wreck it and look like an idiot in the process.


C#, Java, and C++ can all be very fast if you know how to use them properly - or very slow if you don't. Most of these people talking about how fast C++ is, usually don't know jack squat about writing fast code in the first place. A few have some inkling but have never done it on a serious scale. Many are just blindly repeating what they heard in 2006. That said, I find Java's usability to be infuriating, and consider it easily the worst design of the traditional client languages. Graphics code in particular in Java is just awful looking.


In general my recommendation for newbies is C# or Python, with a strong lean towards C# if you don't have trouble learning it. C# is also the language that I personally would recommend for somebody who is trying to complete an indie game, even if that person's day job is professional game development in C++.

#5202415 do most games do a lot of dynamic memory allocation?

Posted by Promit on 06 January 2015 - 05:27 PM

Rather than engaging directly in the valuable discussion here, I'm going to share a couple vignettes from 'in the trenches', so to speak.


The last time I worked in AAA, that engine was using a lot of modern C++ features and was, by all accounts, cutting edge code for 2007. Cutting edge enough to break some compilers, in fact. This meant a lot of STL containers, a lot of allocation, entity component systems, all the fun stuff except for exceptions. This was a 360/PS3 title and did run on PC, though that was not the intended target.


In the last couple months, optimization work began in earnest. Allocation was a significant problem. First up? Tons of traffic in std::vector. A lot of the usual suspects - improper reservation sizes, unnecessary temporaries at function level, etc. Nothing terribly interesting, but a lot to go through in aggregate. Eventually std::vector was dropped in favor of a custom vector with broadly similar behavior but more tightly specified, pooled, and instrumented. After that and a few other low hanging fruits, things were much better but not perfect. I think a lot of small allocations were cleaned up to deal with fragmentation issues, and ultimately the memory allocator itself was replaced with some well known open source third party thing. I don't remember the specific advantages, but it got us to shipping without fragmentation/OOM issues.


I heard about another game in a relatively similar timeframe that used entirely static allocation of everything. It may have been Halo. The idea is not dissimilar to Norman's code, though obviously much more complex in practice. The usual issues arise - game behaves unceremoniously when designers exceed hard coded limits, etc. But I have one simple point to make.


Let's assume you have a hard limit of 10 MB of memory for your new game, Aardvark Crossing. This memory has to be shared between Aardvarks and Zebras. Level 1, 2, and 3 feature 4 MB of Aardvarks and 3 MB of Zebras. You set the pools at 4 and 3, and leave the rest open for later. Now your designer adds level 4 with way more Aardvarks - 8 MB of them. Problem! But the designer won't relent on Aardvarks, so now you resize the pools and Zebras have to be cut down to 2 MB in all other levels.


Things really become a problem, though, when you hit level 5. See, every five levels are the Zebra Bonus Level. It's 9 MB of just Zebras! Or it would've been, if your engine could actually be reconfigured that way in the first place. There's no way you can make the Zebras fit, and there's no way to cut back the Aardvarks in a game called Aardvark Crossing. So now you have to dynamically choose your pool sizes when each level loads. One thing after another falls victim to the dynamic allocation virus, and by the end of it every type of object has its own pool allocator and you're juggling two dozen pools.


The truth is dynamic allocation was not invented for laziness, and static allocation is not foolproof. My personal opinion is that it's necessary to have a mix of both, and more important to be able to track everything.

#5200000 Should I use std::cout or have using namespace std; ?

Posted by Promit on 25 December 2014 - 04:58 PM

Short version: Use using std::cout; at source level when appropriate, but avoid pulling in the whole namespace, or putting using statements in headers. Remember that using can be applied at function or class scope, not just file.

#5199907 How does one start off in programming?

Posted by Promit on 24 December 2014 - 05:00 PM

Don't start with C++. You'll get there in time; it's a terrible starting point. And don't trust anyone who says otherwise, frankly.


C# and Unity is an excellent way to get started nowadays; don't feel that you have to spend a lot of time getting a handle on C# first. A little, yes, but not a huge amount of time. Programming and game development are very much learn-by-doing and teach-yourself disciplines. Think of something reasonably sized you'd like to create, and then figure out the individual elements you need to learn or accomplish in order to create that thing. Then simply set about learning each of those things and assembling it all together. Google is your absolute best friend, as are the various communities out there - the Unity3D forums, StackOverflow, etc.


If it sounds lax and unstructured, good. This is not like classes, where you follow a syllabus chapter by chapter. Don't worry about it. Just start making things.

#5199293 Difference between clock tick and clock cycle?

Posted by Promit on 20 December 2014 - 01:33 PM

There are many, many different clocks in any given computing device. You always need to be clear about which clock you're talking about, or the terminology is pointless. Clock cycles typically refer to the clock signal driving a processor, usually the CPU or occasionally the GPU, but those are not the only clocks around. 

#5199037 C++ how to declare something that isn't declared?!?

Posted by Promit on 18 December 2014 - 07:12 PM

It can be written simpler still:

struct X { struct X* ptr; };

#5198376 Current-Gen Lighting

Posted by Promit on 15 December 2014 - 12:54 PM

Full conference proceedings are generally under paid subscriptions, not published for free. Not sure if SIGGRAPH in particular makes full recordings available; I know GDC does. But I strongly recommend you go through all the SIGGRAPH slides in detail, as well as looking up any materials they reference. There is a LOT in there. It might be easiest to start from 2012 and make your way forwards in time from there.


I also like the FilmicGames blog by John Hable.

#5198174 Getting Bounding Box For Sphere on Screen

Posted by Promit on 14 December 2014 - 01:41 PM

Either flip the culling mode when the viewpoint is inside the sphere, or else just use a regular full-screen quad for that case.

Nah, there's an easier way...

EDIT: Tried it and just remember why I decided not to use it. I rendered the geometry with additive blending and it doubled up because the back was showing through. I enabled back face culling, but when Im inside the sphere, it then culls out the sphere, so nothing is rendered. Any ideas?

Draw the back faces, not the front faces.

#5198083 Getting Bounding Box For Sphere on Screen

Posted by Promit on 14 December 2014 - 02:02 AM

Last time I did this, I just rendered a sphere biggrin.png I mean you're issuing a draw call anyway, who cares about a couple dozen extra polys...

#5197450 Physical Based Models

Posted by Promit on 10 December 2014 - 02:14 PM

Honestly I haven't seen enough consistency in what texture maps are expected by physically based renderers to be able to easily produce generic stock models that work well. Albedo is already somewhat variable, but the wide variety of specular/reflectance/rough maps in use nowadays is a tricky problem. A lot of engines are using oddball encodings, and there's not a particularly good way to distribute maps even as raw floating point.

#5196894 Does glMapBuffer() Allocate Client-Side Memory?

Posted by Promit on 07 December 2014 - 10:12 PM

Okay, let's break this down.

At first, I thought: "Great! Direct access to GPU memory


I got the suspicion that glMapBuffer() is really copying whatever data to a client-side pool, then copying the modified data back, and destroying the temporary pool once glUnmapBuffer()'s called.


At first, I thought glMapBuffer() actually returned a pointer to the GPU's memory, but now it sounds like glMapBuffer()'s doing behind-the-scenes client-side copying, depending on the driver. Is my suspicion correct?



So here's the deal: MapBuffer returns a pointer which you can write to. What this pointer actually refers to is the driver's discretion, but it's going to be client memory as a practical matter. (The platforms that can return direct memory won't do it through GL.) This may be memory that the GPU can access via DMA, which means that the GPU can initiate and manage the copy operation without the CPU/driver's participation. The driver also doesn't necessarily need to allocate this memory fresh, as it can keep reusing the same block of memory over and over as long as you remember to Unmap.

I thought operating systems typically provide ALL memory, regardless of where in the system it's located, its own unique range of memory addresses. For example, memory address 0x00000000 to 0x2000000 point to main system memory while 0x20000001 to 0x2800000 all point to the GPU's memory. These memory ranges are dictated by the amount of recognized system memory, and GPU memory (including virtual memory stored in page files).

Not so much. Windows Kernel 6.x (Vista) gained the ability to map GPU memory into the virtual address space of a particular process, but that's more about internal management of multitasking with the GPU than having much to do with application code. It's not going to live in the same physical memory address space used for main system memory, though, and you can't read/write to it arbitrarily.

#5196731 Why is math transformation taxing to most CPUs?

Posted by Promit on 06 December 2014 - 10:07 PM

Well, the author may need to replenish the oil in his lantern, if he wants to shed light on anything.

#5196698 What's the simplest method to implement "toon-style shading"?

Posted by Promit on 06 December 2014 - 04:08 PM

Step 1: quantize the N dot L lighting term. Simple as: ndotl = ndotl > 0.5 ? 0.2 : 0.7; And just toy with the threshold and result values there. You can do more clever stuff - try smoothstep rather than a hard transition. You can also quantize to more colors, say 4, but I never liked  how it looks.

Step 2: Outlined edges. Take the dot product of the normal and the view vector, and if it exceeds a threshold, set the output color to black and exit.

#5196564 Why is math transformation taxing to most CPUs?

Posted by Promit on 05 December 2014 - 11:43 PM

1) The computer must track all of the vertices of all of the objects in the 3-D world, including the ones you cannot currently see.
Question 1: When the book says the computer, do they really mean the program itself or the CPU that does the processing of the "addresses" or the RAM where the addresses are stored

The vertices have to be stored in RAM, of course. The program is responsible for managing that data.

2)  This calculation process is called transformation is extremely taxing to most CPUs.
Question 2: Is it because the CPU cannot process the address of the data quickly per frame? Does it lead to a slow frame-rate in the game?

GPUs were invented because CPUs can't keep up. Let's assume you have a million vertices (quite low nowadays) to deal with. Each one needs to multiply the vertex position by a matrix in order to transform it to 2D space, which means four multiply-add operations across four rows of four elements. Let's crudely call it 50 instructions to process each vertex, giving us 50M total per frame. Now we want to run at 60 frames per second, which puts us at 50M * 60 = 3 billion calculations per second. If we're optimistic and assume that we're getting one calculation per cycle out of a 3 GHz CPU (this is very unrealistically optimistic), we've pretty much consumed the entire amount of CPU that we had in doing just vertices. Let's not forget pixels need to be calculated, physics needs to be calculated, oh and the actual game needs to fit in there somewhere.