I graduated 5 years ago with the intention of becoming a game developer, my career got sidetracked and although this sidetrack led to an ultimately comfortable existence and a lot of life lessons learned, I'm now at the point where my career as a Flash / Flex developer is stagnating. It may also be coming to a forced end as more and more of my employer's clients move away from Flash each month. I've been keeping up with the times, and doing a lot of graphics programming on the side using nVidia's CG shader programming language and OpenGL. 

I'm looking for a little insight into what skill level you expect entry level, and reasonably competent graphics programmers (i.e. qualifying as something above 'junior' in their job title, even if that's just the omission of the word) to be at, and the difference between the two. By skill level, I mean knowledge base, for example implementing certain shader routines (e.g. normal mapping) and grasp of mathematics. Before I enter the job search proper, I want to make absolutely sure that my skills are in fact up to par as I understand that graphics programming positions in particular are highly competitive. For example, I know that one area I lack skill in is using shader functions built for DirectX 10 and above - by virtue of me still using an XP machine (GPU is DX10 capable though, reeeally need to upgrade), and I suspect that not being knowledgeable about, say, tessellation using the GPU would swiftly kill any application I would make for a graphics programmer role that paid more than free lunches. 

On the other hand, this may not be the case, which is why I'm sending this out to you better informed guys for a little feedback.

- Tommy

  Thanks for the reply. A convex hull technique is definitely overkill for most situations. My idea may be a bit convoluted in light of other techniques but the idea was exactly that, to create a simple convex hull offline that can be transformed in game and then used to create the AABB. I am currently using a simple pre-created convex spline around the base of a model that fits the mesh projected onto the ground plane plus the height for objects that only rotate around the Y axis. The spline can be rotated and the AABB re-calculated and that was fast but then I got to thinking about objects with arbitrary orientations. I will investigate the K-dop, it sounds like what I was envisioning in my mind and it appears to resolve many of the problems that I was having with my approach. I agree that for culling purposes it makes no sense to offset the gains from culling with excessive work. Thanks again for the insight.

Brian

> From: sweng-gamedev-request <at> lists.midnightryder.com
> Subject: Sweng-Gamedev Digest, Vol 65, Issue 1
> To: sweng-gamedev <at> lists.midnightryder.com
> Date: Tue, 7 Jun 2011 13:43:11 -0700
>
> Send Sweng-Gamedev mailing list submissions to
> sweng-gamedev <at> lists.midnightryder.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
> or, via email, send a message with subject or body 'help' to
> sweng-gamedev-request <at> lists.midnightryder.com
>
> You can reach the person managing the list at
> sweng-gamedev-owner <at> lists.midnightryder.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Sweng-Gamedev digest..."
>
>
> Today's Topics:
>
> 1. Creating enclosing convex meshes for AABB calculation
> (BRIAN LIVINGSTON)
> 2. Re: Creating enclosing convex meshes for AABB calculation
> (Fabian Giesen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 7 Jun 2011 00:52:29 +0000
> From: BRIAN LIVINGSTON <noizhead <at> msn.com>
> To: <sweng-gamedev <at> lists.midnightryder.com>
> Subject: [Sweng-Gamedev] Creating enclosing convex meshes for AABB
> calculation
> Message-ID: <SNT123-w46304D5ACF4C478A953A2ADF630 <at> phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hello, I am aspiring game developer. I am using AABB trees for all sorts of stuff in a scene graph. The problem is that we need to quickly calculate a new AABB when an object moves. Therefore I am working on an algorithm for generating vastly simplified convex meshes for fast(ish) AABB calculation for objects that can have an arbitrary orientation. The basic idea is to sort of fit a geodesic sphere over an object to produce a low-poly convex blob that contains the significant maximum extent information from any arbitrary orientation. The geodesic sphere is just a tool for discovering the maximum extent within a solid angle that radiates outward from an origin from within a mesh model. A geodesic sphere has the property that it is constructed from tetrahedrons. Therefore discovery of the maximum extent within each solid angle can occur with a barycentric coordinate evaluation. I am abusing the term solid angle here to mean the volume within a sphere which is a tetrahedron t
> hat has one vertex on the sphere origin and three vertices on the surface of the sphere. Once we have the maximum extent point field the question is: how do we approach building a new triangle mesh? We have the adjacency knowledge because each triangle face of the sphere is a bucket that either contains the vertices (1-N) that share the maximum distance from the origin. So if we split the sphere into 2 hemispheres we can use a hybrid 2D algorithm for constructing a plane from a point cloud. We should also have a step that further reduces the set of vertices in the point cloud by removing the entries for faces on the sphere that are now essentially concave. Note that we start with a sphere that totally encloses the object and now we have a sphere that has random faces pushed in to meet with the maximum extent for that solid angle. Note that the final result will not be spherical because we are not introducing new points and there may be a singular feature of the original m
> esh that juts out at an extreme angle. It seems like we can use a path finding algorithm on the graph where each face that contains maximal points is a node on the graph multiplied by the number of maximal points and now we need to walk the graph in a clockwise (winding order) direction until we form a loop and then subdivide if need be and then start again keeping track of edges so that we don't create the same edge twice (vertex 0 to vertex 5 is not the same edge as vertex 5 to vertex 0 for our purposes so that we can use the same two points for two adjacent polygons. Hopefully this question will be seen as an interesting puzzle and not as a why don't you post this elsewhere kind of submission. I am also curious how the pro's calculate AABB's on the fly in the cheapest (in processing) and tightest (in fit) manner. Do the pro's use low poly versions of meshes for bounding box calculations?
> - Thanks in advance- Brian Livingston
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.midnightryder.com/private.cgi/sweng-gamedev-midnightryder.com/attachments/20110607/c39ca256/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 06 Jun 2011 22:28:30 -0700
> From: Fabian Giesen <ryg <at> gmx.net>
> To: sweng-gamedev <at> midnightryder.com
> Subject: Re: [Sweng-Gamedev] Creating enclosing convex meshes for AABB
> calculation
> Message-ID: <4DEDB6FE.8010607 <at> gmx.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 06.06.2011 17:52, BRIAN LIVINGSTON wrote:
> > Hello,
> > I am aspiring game developer. I am using AABB trees for all sorts of
> > stuff in a scene graph. The problem is that we need to quickly calculate
> > a new AABB when an object moves.
>
> If you're using AABBs, you already get a relatively loose fit (depending
> on the shape of the object). If you really care about getting a tight
> fit around the object, use the convex hull which you can then transform
> directly. Conversely, if you don't care about tightness that much,
> there's no point getting fancy about it; you can either build a new AABB
> from the transformed original AABB, or use something with a tighter fit
> like a general OBB, transform it, and then use the AABB of that. This is
> very easy, fast, and totally fine for e.g. culling purposes.
>
> > Therefore I am working on an algorithm for generating vastly simplified
> > convex meshes for fast(ish) AABB calculation for objects that can have
> > an arbitrary orientation. The basic idea is to sort of fit a geodesic
> > sphere over an object to produce a low-poly convex blob that contains
> > the significant maximum extent information from any arbitrary
> > orientation. The geodesic sphere is just a tool for discovering the
> > maximum extent within a solid angle that radiates outward from an origin
> > from within a mesh model. A geodesic sphere has the property that it is
> > constructed from tetrahedrons. Therefore discovery of the maximum extent
> > within each solid angle can occur with a barycentric coordinate
> > evaluation. I am abusing the term solid angle here to mean the volume
> > within a sphere which is a tetrahedron that has one vertex on the sphere
> > origin and three vertices on the surface of the sphere.
> > Once we have the maximum extent point field the question is: how do we
> > approach building a new triangle mesh? We have the adjacency knowledge
> > because each triangle face of the sphere is a bucket that either
> > contains the vertices (1-N) that share the maximum distance from the
> > origin. So if we split the sphere into 2 hemispheres we can use a hybrid
> > 2D algorithm for constructing a plane from a point cloud. We should also
> > have a step that further reduces the set of vertices in the point cloud
> > by removing the entries for faces on the sphere that are now essentially
> > concave.
> > [..]
>
> Why not use a convex hull algorithm to construct the exact convex hull
> and use that if you want a tight fit?
>
> What you describe seems like an incredibly roundabout way of attacking
> the problem. And the fact that your multi-step algorithm may later
> produce concavities shows that it's an inherently flawed way of
> organizing the computation.
>
> The sane variant of this approach is to build what's commonly called a
> k-DOP (Discrete Oriented Polytope); effectively a volume described by
> the intersection of the negative half-spaces of k planes.
>
> Sounds fancy but is incredibly easy. Pick any direction vector d. Now
> compute the dot product of all vertex positions with d, and keep track
> of the minimum (min_d) and maximum (max_d). Clearly, the mesh is within
> the half-spaces
>
> dot(P, d) <= max_d
> dot(P, d) >= min_d
>
> which immediately gives you two planes that enclose the object from
> opposing sides (that's why in practice you always pick k=even, since you
> get the second plane for any direction almost for free).
>
> If you want to generate a mesh from that, the easiest way to do it is
> probably to take the AABB for the object and then clip it against all of
> the planes. But again, storing a mesh (even if it's a small one) just to
> generate updated bounding volumes from is probably overkill! And again,
> if you want a good approximation of the object, use its convex hull;
> there's no point in using an approximation that ends up being hairier
> than the original thing!
>
> > I am also curious how the pro's calculate AABB's on the fly in the
> > cheapest (in processing) and tightest (in fit) manner. Do the pro's use
> > low poly versions of meshes for bounding box calculations?
>
> Don't know what others do, but for stuff where tight fit doesn't matter
> much, I normally just store a model-space AABB for everything and use
> the worldspace AABB around that if I need one. This is really easy (note
> you don't expand the AABB into 8 vertices, you can solve this directly!).
>
> If you do care about tightness of fit, use an OBB or the convex hull
> (the latter is useful for physics and collision queries, but its
> variable size and test cost make it fairly unsuitable for anything but
> the leaves of some tree). Both of these transform easily and don't lose
> any tightness of fit.
>
> -Fabian
>
>
> ------------------------------
>
> _______________________________________________
> Sweng-Gamedev mailing list
> Sweng-Gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>
> End of Sweng-Gamedev Digest, Vol 65, Issue 1
> ********************************************

  I am aspiring game developer. I am using AABB trees for all sorts of stuff in a scene graph. The problem is that we need to quickly calculate a new AABB when an object moves. 

  Therefore I am working on an algorithm for generating vastly simplified convex meshes for fast(ish) AABB calculation for objects that can have an arbitrary orientation. The basic idea is to sort of fit a geodesic sphere over an object to produce a low-poly convex blob that contains the significant maximum extent information from any arbitrary orientation. The geodesic sphere is just a tool for discovering the maximum extent within a solid angle that radiates outward from an origin from within a mesh model. A geodesic sphere has the property that it is constructed from tetrahedrons. Therefore discovery of the maximum extent within each solid angle can occur with a barycentric coordinate evaluation. I am abusing the term solid angle here to mean the volume within a sphere which is a tetrahedron that has one vertex on the sphere origin and three vertices on the surface of the sphere.

  Once we have the maximum extent point field the question is: how do we approach building a new triangle mesh? We have the adjacency knowledge because each triangle face of the sphere is a bucket that either contains the vertices (1-N) that share the maximum distance from the origin. So if we split the sphere into 2 hemispheres we can use a hybrid 2D algorithm for constructing a plane from a point cloud. We should also have a step that further reduces the set of vertices in the point cloud by removing the entries for faces on the sphere that are now essentially concave.

  Note that we start with a sphere that totally encloses the object and now we have a sphere that has random faces pushed in to meet with the maximum extent for that solid angle.

  Note that the final result will not be spherical because we are not introducing new points and there may be a singular feature of the original mesh that juts out at an extreme angle.

  It seems like we can use a path finding algorithm on the graph where each face that contains maximal points is a node on the graph multiplied by the number of maximal points and now we need to walk the graph in a clockwise (winding order) direction until we form a loop and then subdivide if need be and then start again keeping track of edges so that we don't create the same edge twice (vertex 0 to vertex 5 is not the same edge as vertex 5 to vertex 0 for our purposes so that we can use the same two points for two adjacent polygons.

  Hopefully this question will be seen as an interesting puzzle and not as a why don't you post this elsewhere kind of submission.

  I am also curious how the pro's calculate AABB's on the fly in the cheapest (in processing) and tightest (in fit) manner. Do the pro's use low poly versions of meshes for bounding box calculations?

- Thanks in advance

- Brian Livingston

I've been working as an AS3 programmer / animator for the last 3.5 years, and have the strongest desire to leave the marketing industry behind and pursue my original intended career as a games programmer, which I sidelined due to a very coincidental series of events. To this end, I've been (slowly) building a graphics engine using C++, OpenGL and nVidia CG which renders very large chunks of terrain using GPU Clipmaps. The idea is that eventually it will render planets with atmosphere and real time shadows, or die trying, and in any case will serve as my main portfolio piece when I eventually start applying for positions. Because I've been outside of my programming comfort zone for so long it's been slow going, but now that I've finally got a firm grasp on shaders and the OpenGL pipeline it's time to look to the future. 

This is where my problem lies; although there are many examples on the 'net showing me how to animate the most beautiful normal mapped cobbled cube, or tutorials on specific rendering / culling / lighting algorithms, I've yet to find a resource beside Michael Abrash's Graphics Programming Black Book (which sits on my desk, reminding me of what I should have been doing all along) which goes into the subject of writing a graphics engine. See although I can write perfectly passable C++, and thanks to my AS3 programming experience which has frequently required that I get my projects right 'the first time', I'm fairly adept at planning and designing my classes before I begin... But from a C++ standpoint, I'm somewhat in the dark. What are the best practices for building a graphics engine in C++? Exactly how OOP should I go? How should I handle the use of multiple shaders on chunks of geometry? There's just this giant multitude of questions, and although I have a knack for over engineering things, I really want to have a better picture of what I'm aiming for before I start, or I'll end up with the monstrosity that is my terrain prototype (it runs, but it's so, so ugly).

Currently my idea for a graphics engine involves something like an engine class that takes render packets of data, has some sort of ability to sort them into an order that best facilitates speedy rendering, and changes its state depending on the information in the packets. E.g. one packet might be a chunk of terrain, and could include information about what shaders to use, how to determine its potential visible set, and the type of collision detection to use (though this deviates a little from the graphics engine part). There might be an arbitrary number of terrain packets, followed by some character models or buildings using a different type of culling algorithm. My worry aside from the obvious problem of the whole idea possibly being crap, is that it's too general. How could I possibly create an engine that handles every possible rendering type, shouldn't I perhaps start with the assertion that I'm building a terrain engine, and base everything around rendering sphere like chunks of geometry with varying levels of detail? But on the same token, I don't just want to end up with another terrain engine prototype as seen on youtube(tm).

So I suppose what I'm looking for are book suggestions, or perhaps open-sourced graphics engines that I could look at and learn from, or maybe I should just try and get a position as a junior-something-programmer and learn by doing (the trouble is there aren't any such positions available where I live, and relocation would be difficult to justify based upon the possibly low salary expectations of a junior position, I'd like at least some leverage). Ideas? Suggestions? Is this even the right place to ask such broad questions? I'm all ears.

- Tommy

Hi everybody,

    just curious about the possibility to render the grass shadow in realtime on consoles.

Are you aware of some game that has this feature?

I was wandering if there is some kind of screenspace possibility to exploit, or do you have other ideas.

 

 

Thanks!