Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Christer Ericson

Member Since 05 Sep 2004
Offline Last Active Dec 30 2011 05:08 PM

#4898063 Per pixel point light: interpolating vertex world pos

Posted by Christer Ericson on 29 December 2011 - 11:44 PM

You will get the same results by interpolating the positing and then computing the light direction in the pixel shader...this is because vertex positions can be linearly interpolated. So you don't have anything to worry about.

I don't think you meant to say "same results", Matt. Interpolating the vertex positions and computing a light direction in the pixel shader will not give the same result as computing a light direction at each vertex and interpolating these vectors over the triangle. The former is correct while the latter is incorrect, in the sense of the resulting vector accurately pointing at the light source. You might say "similar results" in that interpolating the direction vectors isn't grossly inaccurate (for some definition of grossly).


#3838289 STL on PS3/Wii/360

Posted by Christer Ericson on 02 December 2006 - 07:32 PM

Quote:
Original post by Palidine
Quote:
Original post by frob
Although they exist and we use them on our tools, I don't know of console projects that use the STL container classes or STL streams inside their console projects.

Heh. Again it breaks down along "religious" lines. I haven't seen a single console title that _doesn't_ use the STL. In the 3 titles i've shipped and in the one i'm about to ship we use STL with custom allocators.
In our games:
  • we need to be 100% in control of memory
  • we want code that is cache efficient (beyond just being algorithmically efficient)
  • we want code that is straightforward and not overengineered
  • we want code that you can read and step through
  • we want code that gives clear error messages
  • etc.
In my opinion, STL, in its default form, fails to deliver on all of these. You can fix some issues by e.g. providing STL with custom allocators but that still leaves plenty of other issues. Furthermore, the mere fact that you have to "fix" something before it even remotely begins to conform to your required usage mode should be a cause for concern.

Some people may not care about one or more of these issues or have other needs, which is fine; that's their choice after all. However, none of the titles I've ever worked on (all console games, except one) has used STL for the aforementioned reasons. (This refers to STL in the game; we've used STL in the tools.) For us, our decision is commonsense, not religion, but to each his own.

Finally, I take objection to your claim that "No, there is no reason to avoid the STL on console development if you know what you're doing." That's you claiming that the team of programmers that I work with don't know what we're doing, and it's total flamebait. I won't rise to it, but I think the games we've done speak for themselves and I'll let others judge your statement in that light.



#3146528 good introdution book on Fuzzy Logic

Posted by Christer Ericson on 09 July 2005 - 12:56 PM

Quote:
Original post by MichaelWeber
I am looking for a good book about Fuzzy logic in games.
Few games use fuzzy logic, so there's little to go by. Those that do, hardly stray from the "standard" fuzzy logic, so you might as well go with a standard fuzzy logic book, IMO. I'm not an expert on what fuzzy logic books are out there, but one book I have and like is:

Reznik, Leonid. Fuzzy Controllers

It's not a traditional (and stuffy) textbook, so it's quite readable. As the title suggests, the focus is on controllers, i.e. control units of embedded systems, so while it doesn't cover games as such, the fact that it talks about controllers makes is particularly relevant to games-like applications. It does lack the worked examples that you'd find in a textbook, but it's not a big flaw.



#2978654 Ray-AABB intersection

Posted by Christer Ericson on 28 March 2005 - 08:31 PM

Quote:
Original post by Endar
Okay, so far, I've got that the ray is = o + td, where o is the origin point of the ray and d is a direction vector, and I'm assuming that t is a scaling factor of some sort. With the AABB box, it has two points amax and amin and that aimin <= aimax where i is x,y and z in a 3d point. Am I right so far?


Mostly right. The ray is written in what is known as parameterized form. So you can think of the ray as being the set of points obtained by setting t to all possible values t >= 0.

The important realization, I think, to grokking how the algorithm works is this.

An AABB can be described as the intersection volume of three perpendicular slabs, where a slab is the (infinite) volume between two parallel planes. Thus, a ray intersects an AABB if and only if a point of the ray simultaneously lies inside all three slabs.

What the algorithm does is intersecting the ray against each slab in turn, finding the t values at which the ray enters and exits the slab. The largest t value for entering and the smallest t value for exiting then describes the part of the ray inside the AABB.

If the largest entering value is larger than the smallest exiting value, the ray does not intersect the AABB (as the interval described by the two t values is empty).

I hope that helps you understand the algorithm description better.



PARTNERS