Intel Node Manager allows data center managers to monitor server power and thermal behavior in real time. Using this technology, data center managers can set upper limits on the server power to maximize the rack density with confidence that rack power budgets will not be exceeded. During a power or thermal emergency, Intel Node Manager can automatically limit server power consumption and extend service uptime from stand-by power sources. Server power and thermal information can also be used to maximize overall data center efficiency by moving workloads, extending the life of stand-by power resources, etc.

The Intel® Node Manager Programmer's Reference Kit contains the source code (C and C++), test application, and documents to manage servers that are Intel Node Manager capable. The Kit simplifies the complex IPMI encoding and decoding for commands and responses, hides the protocol details, and provides simple application programming interfaces (APIs) to monitor and control power and thermal capabilities on Intel Node Manager capable platforms.

DOWNLOAD NOW: Intel® Node Manager Programmer's Reference Kit

Intel has three versions of server management technology: Intel Node Manager, Intel Node Manager Basic Edition, and Intel Node Manager Extended Edition. Intel Node Manager provides platform power and thermal capabilities to the baseboard management controller (BMC). Intel Node Manager Basic Edition provides simple management capabilities and does not need platform BMC. Intel Node Manager Extended Edition provides simple platform management capabilities along with power and thermal capabilities and does not need platform BMC. Intel® Node Manager Programmer's Reference Kit supports all three versions.

For more information about Intel Node Manager technology:

Intel® Node Manager

Data Center Power Management with Intel® Node Manager

Intel® Node Manager Specification

1. Video 1 - HTML5 Screencasts: Introduction - This video will give you an introduction to HTML5. Why it is an important evolution of web technology, and an overview of the features.
     8:20
2. Video 2 - HTML5 Markup - This video will give you an overview of the markup changes in HTML5
     9:10
3. Video 3 - HTML5 and CSS3 - This video will give you an introduction to CSS three and how it's used in HTML5 application
     13:32
4. Video 4 - HTML5 Interactivity - This video gives you an introduction to manipulating the DOM 
     8:32
5. Video 5 - HTML5 Forms - This video is an overview of HTML 5 forms including input types, new on attributes and client side validation.
     9:29
6. Video 6 - HTML5 Graphics - This video is an overview of SVG, web fonts and the canvas tag.
     17:01
7. Video 7 - HTML5 Audio and Video - This video shows you the basics of audio and video in HTML5 application. 
     4:46
8. Video 8 - HTML5 Communications: Part 1 - Ajax and Cross Origin Requests
     27:05
9. Video 9 - HTML5 Communications: Part 2 - Cross-Document messaging and Web Workers
     9:10
10. Video 10 - HTML5 Communications: Part 3 - Server-Sent Events and WebSocket
      10:12
11. Video 11 - HTML5 Storage - The video gives an overview of local storage, indexdb and WebSQL
      19:55
12. Video 12 - HTML5 Device Access - This video talks about how an HTML5 application uses Geolocation, Audio input, accelerometers, webcamera and file system access.
      10:46
13. Video 13 - Offline and Packaging for AppUp - This video give the application developer an overview of how to package a web application and submit it to the Intel AppUp Center.
      8:50

Learn more about developing apps for Ultrabooks as well as other HTML5 tools and packaging solutions for monetizing and distribution HTML5 apps to Ultrabook devices at our Ultrabook Community.

Crossing platforms and boundaries with mobile applications

Soma Games and Code-Monkeys change the application game

70%: Do what makes your heart come alive.

30%: Go where it takes you.

Is this utopia, or the business plan of two thriving development companies?

Read on and spend time in the alternate, but very real, universe of Soma Games and Code-Monkeys.

Nuts & Bolts

Entering the Game

Games depend on a compelling storyline and split-second decisions at each unanticipated fork in the road. Great play draws upon uncertainty, risk, an intuitive analysis of multiple variables, and resolute action. All of this describes the innovative creations and pioneering outlook of the founders of Soma Games and Code-Monkeys, sibling companies that have found the sweet spot in development for mobile platforms and are definitely enjoying every step of the ride.

"Making a game is an architectural work, not an individual sport."

— John Bergquist
Communications Director, Soma Games and Code-Monkeys

"We are going to be able to blend the virtual with the real world in ways never conceived before."

— Chris Skaggs
CTO, Soma Games and Code-Monkeys

Soma expected to jump into video game development for consoles, such as PlayStation* and Xbox*, but the barrier to entry—a development process too slow, cumbersome, and costly to keep up with creative potential and market demand—was a catalyst to explore other options. A move to applications for mobile platforms that could be designed, developed, and brought to market faster was a natural step. Cross-platform game development brought its own learning curve, one that also inspired Soma's sibling company, Code-Monkeys. Its developers collaborate with application creators at any and every level of the process, from building out application concepts to fine-tuning complex code.

The Story of Soma's Success

CTO of Soma Games and Code-Monkeys, Chris Skaggs, entered the industry because he wanted to tell compelling stories. He started with the broad strokes of multiple stories, but some of the most interesting turns of plot, character, and levels have come about through the process of development, and the exchange with active—and expressive— player communities. Says Skaggs, "Each story builds a life of its own that you discover while making it."

Another creative route has been the fabrication of a story world around an existing character. This is the origin of Bok Choy Boy*, which taps into an established consumer culture of ready-made symbols with exciting effect. Soma had to convince the toy company to convert to the virtual space, then deliver results through effective cross-vending and marketing.

Being both technically and marketing savvy comes naturally to the staff of Soma and Code-Monkeys, where curiosity and passion, rather than resumés, drive business growth. This cultivation of open- ended possibility and willingness to jump into untried areas has helped them to take advantage of a relatively new market for mobile game applications, do work that inspires them, and be profitable.

A team-based development approach is a natural outgrowth of this philosophy. Communications Director John Bergquist emphasizes the importance of forming a team with diverse talents, whether technical or artistic, "Making a game is an architectural work, not an individual sport." Soma has found creative people eager to use their talents and contribute to the whole.

Connecting with Community

Bergquist sees a direct link between interesting, surprising story content and building community, "Content is king. The storyline creates endless things to share and talk about with players."

Bergquist makes full use of digital communications, from Facebook* and blogs to YouTube* and the Internet, to build and sustain community. He places a high value on direct interaction with the full demographic of players. Gamers have responded to this personal approach, and are even enthusiastically engaged in game-related content creation, such as sending G*-like LEGO* ships to Soma.

Multi-Platform as the Standard

Soma and Code-Monkeys have embraced multi-platform development from the start. Their foresight is paying off as the market is rapidly positioning cross-platform play as a requirement. They favor tools that allow them to efficiently create and publish an engine on multiple platforms, such as Unity 3D*, HTML 5*, and Adobe Air*. The knowledge base is out there for novices. Says Skaggs, "Any developer with passion and drive can make a multi-platform game." Visibility can be immediate, Skaggs continues, "Distribution is the magic bullet. Tens of millions of people can access your application overnight."

Cross-platform design impacts technical decisions along the way. New technologies can spark retooling of game logic; for example, the introduction of Microsoft Kinnect* allowed for story interactions on the gameplay level.

Soma developers also take advantage of the Web for a relatively low-tech solution to the complexity of providing a multilayered game experience that extends past game boundaries. The Web potential is tapped for games such as G to support slick interactions between applications, cohesion across games, and tracking of "career" scores and level states.

Mobile Inspiration

For Soma, the capabilities and limitations of mobile platforms are waiting to be exploited for gameplay. The Finger-Twister* game was designed to turn multi-touch into a game experience. Accelerometers, which tilt and shift screens automatically based on user motion, allow devices to be used like "fishing rods." Location-based GPS services offer yet more creative possibilities. Skaggs sees more opportunity for innovation ahead, "We are going to be able to blend the virtual with the real world in ways never conceived before."

Bergquist values the opportunity to participate in thought leadership in technology innovation and mobile device usage, as well as in game development. As the mobile space explodes, he finds room for innovation and ample freedom to experiment. Skagg echoes this, seeing mobile as a profound change which is altering daily consumer behavior and expectations on a wide scale. Simply being able to bring games outside or use smartphones to manipulate a virtual reality expands a gamer's universe from the home console to the multi-player universe of a mobile world.

Collaborating with the Intel AppUp^SM and the Ultrabook™ Developer community

Soma Games and Code-Monkeys find Intel software engineers share their passion for creating quality applications, and value this commitment. Bergquist explains, “The Intel AppUp team cares who we are as developers, and is supportive of our work and the communities we’re building.”

Intel AppUpSM
appdeveloper.intel.com

To learn more about Soma Games and Code-Monkeys, visit www.somagames.com and www.code-monkeys.com.

This article has been republished here, and was originally published on appdeveloper.intel.com on November 16, 2011

1. Introduction

Scalable Vector Graphics* (SVG) is a family of specifications of an XML-based file format for two-dimensional vector graphics, both static and dynamic (i.e., interactive or animated), text or embedded raster graphics. The SVG specification is a royalty-free vendor-neutral open standard that has been under development by the World Wide Web Consortium* (W3C) since 1999.

SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted and, if required, compressed. As XML files, SVG images can be created and edited with any text editor.

SVG files are compact and provide high-quality graphics on the Web, in print, and on resource-limited handheld devices. In addition, SVG supports scripting and animation, so is ideal for interactive, data-driven, personalized graphics.

Using SVG has many benefits. First, you don't need to have pictures in different resolutions, no need to scale. Second, SVG is an XML file, so its size is much smaller than the raster size format for the same image. This also helps to change the picture on the fly.

SVG allows three types of graphic objects: vector graphics, raster graphics, and text. Graphical objects, including PNG and JPEG raster images, can be grouped, styled, transformed, and composited into previously rendered objects.

Native Android* applications do not support SVG XML files. But SVG XML files could be parsed in browsers starting with Android 3.0. This paper integrates the svg-android open source library into codebase and provides an example application on Intel® architecture (IA) Android Ice Cream Sandwich (ICS).

1.a SVG Functionality

The SVG 1.1 specification defines 14 functional areas of feature sets, which are:

• Paths
• Basic shapes
• Text
• Painting
• Color
• Gradients and patterns
• Clipping, masking, and compositing
• Filter effects
• Interactivity
• Linking
• Scripting
• Animation
• Font
• Metadata

1.b SVG Shapes

SVG's predefined shape elements are:

• Rectangle <rect>

<svg>
<rect x="50" y="20" width="150" height="150"  />
</svg>

• Circle <circle>

<svg >
<circle cx="100" cy="50" r="40" stroke="black" stroke-width="2"
fill="red" />
</svg>

• Ellipse <ellipse>
• Line <line>
• Polyline <polyline>
• Polygon <polygon>
• Path <path>

<svg xmlns="http://www.w3.org/2000/svg" version="1.1">
 <path d="M150 0 L75 200 L225 200 Z" />
</svg>

2. SVG Library Integration

Create a file named svgandroid.xml to describe svgandroid.jar. Place svgandroid.jar in /system/framework folder and svgandroid.xml in the /etc/permissions folder. Applications will discover svgandroid.jar library through svgandroid.xml.

Put the following code into the svgandroid.xml:

<?xml version="1.0" encoding="utf-8">
<permissions>
<libraryname="svgandroid" file="/system/framework/svgandroid.jar"/>
</permissions>

Use the <use-library> declaration in the AndroidManifest.xml file. This method loads the svgandroid packages. They will not be loaded automatically.

<uses-library android:name="svgandroid" android:required="true" />

Set android:required="true". The Android system would not permit an application on a device without this library.

If this application is installed on Android devices without this library, the following error message occurs:

Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]

This element also affects the availability of the application on Market. The Android device could not list this application on Market without the library.

3. Render a File Using Revised SVG

3.a Why Use SAX?

3.b How to implement SAX parser in Android:

When implementing SAX parser, the class need to inherit “DefaultHandler". And there are a few methodsthat need to be overridden when inherit “DefaultHandler"—default base class for SAX2 event handlers—in Android. These methods include startElement, endElement, startDocument, endDocument, etc. You can easily see what each function does by its name. For example, startDocument means when the SAX starts to parse the document, it will trigger the event and call the startDocument method.. Once the SAX parses any tag of XML file, it will call startElement, so you can get the tag name, attribute, and some other information relevant to the tag. The other methods, endDocument, startElement, and endElement, are self-explanatory.

3.c Why Revise the Original SVG Library?

Since the original library can't render the SVG file with attributes in the group tag (<g>), we must add a register to store the style attribute with a <g> tag. If there is already a style attribute in the inner render element, the style attribute will replace the one in the <g> tag.

We recommend using SAX to parse the SVG file. When we parsing the <g> tag, we retrieve the entire attribute into the instance –g_prop, which is an internal class of the properties.

public void startElement(String namespaceURI, String localName, String qName, Attributes atts) throws SAXException 

{
            			……
	} else if (localName.equals("g")) {
        	……
                pushTransform(atts);
                g_prop = new Properties(atts); 
	}
		……
}

When we parse the <rectangle>, <path> or any other rendering tags, we need to check if there is any style associated with the tag. If there is, we need to get the attributes. The methods doFill, doStroke help to initiate the style of fill and stroke of the canvas. After these methods are invoked, we can draw the parsed element onto the canvas.

Properties props = new Properties(atts);
                if (doFill(props, gradientMap)) 
    {
                    doLimits(p);
                    canvas.drawPath(p, paint);
                }
                else
                {
                	if(g_prop != null)
                	{
                		if(doFill(g_prop, gradientMap))
                		{
		                	doLimits(p);
		                	canvas.drawPath(p, paint);
                		}
                	}
                }
                
                if (doStroke(props))
                    canvas.drawPath(p, paint);
                else
                {
                	if(g_prop != null)
                	{
                		if(doStroke(g_prop))
                			canvas.drawPath(p, paint);
                	}
                }
                popTransform();
}

3.d SVG XML File with Attributes in the Rendering Tag

<path display="none" fill="#FFFFFF" d="M268.461,471.01c2.526,0,4.575,2.048,4.575,4.571c0,2.529-2.049,4.576-4.575,4.576
c-2.525,0-4.574-2.047-4.574-4.576C263.887,473.058,265.936,471.01,268.461,471.01z"/>

3.e SVG XML File with Attributes in Group Tag

<g >
<path d="M-122.304 84.285C-122.304 84.285 -122.203 86.179 -123.027 86.16C-123.851 86.141 -140.305 38.066 -160.833 40.309C-160.833 40.309 -143.05 32.956 -122.304 84.285z"/>
</g>

References

• http://code.google.com/p/svg-android/
• http://www.w3.org/TR/SVG/
• http://www.megginson.com/downloads/SAX/
• http://www.w3schools.com/svg/
• http://en.wikipedia.org/wiki/Scalable_Vector_Graphics
• http://en.wikipedia.org/wiki/Simple_API_for_XML

Downloads

Figure 1. Convex polyhedra interacting with a vortex particle fluid

Convex Obstacles

Video games are compelling because they are interactive. Even visual effects should respond to other entities in the environment, especially those the user controls. Particle effects, including fluids, should therefore respond to rigid bodies of any shape. Those shapes should include airfoils that can experience lift.

This article—the thirteenth in a series—describes how to augment the fluid particle system described earlier, interact with rigid bodies with any polyhedral shape, and generate a lift-like force on those bodies. Part 1 summarized fluid dynamics; part 2 surveyed fluid simulation techniques. Part 3 and part 4 presented a vortex-particle fluid simulation with two-way fluid–body interactions that runs in real time. Part 5 profiled and optimized that simulation code. Part 6 described a differential method for computing velocity from vorticity, and part 7 showed how to integrate a fluid simulation into a typical particle system. Part 8 explained how a vortex-based fluid simulation handles variable density in a fluid; part 9 described how to approximate buoyant and gravitational forces on a body immersed in a fluid with varying density. Part 10 described how density varies with temperature, how heat transfers throughout a fluid, and how heat transfers between bodies and fluid. Part 11 added combustion, a chemical reaction that generates heat. Part 12 explained how improper sampling caused unwanted jerky motion and described how to mitigate it.

Collision Detection

Detecting collisions between objects first entails computing the distance between them. Video games model most shapes with planar, polygonal faces and treat particles as though they have spherical shape. You therefore need to compute the distance between planes and spheres.

A plane is a two-dimensional surface in a three-dimensional space. You can define a plane in various ways. One convenient representation uses a normal vector and a distance, d. The plane equation has this formulation:

All points with coordinates that satisfy this equation lie within the plane. When has unit length (), d is the distance of the plane from the origin. You can use this value to represent a plane as a vector with four components (that is, a 4-vector plane): or .

The distance, D, of a point from the plane is:

Notice that this equation has the same form as the equation for the plane, except that instead of equating it to zero, the formula tells you the distance of the point to the plane. This is obviously consistent because if a point has zero distance to the plane, then the point lies in the plane.

But wait a moment! This formula could result in negative values. For example, choose the point and the plane with and d = 1. The formula claims that point has negative distance from the plane. What the heck is negative distance?

A plane divides all of space into two halves. A half-space is the region of space on one side of a plane. The signed distance formula tells you whether a point lies in the positive half-space or the negative half-space of a plane, as Figure 2 depicts.

Figure 2. Planes and half-spaces

Think of a plane as facing in the direction of its normal. Points behind the plane have negative distance. Points in front of the plane have positive distance. When a point lies behind a plane, we call its distance (which is negative) the penetration depth.

The Plane class shows an implementation of the planar formulae that builds upon a 4-vector class (Vec4):

You can compute the distance of a sphere from a plane by computing the distance of the sphere's center (a point) from the plane, then subtracting the sphere's radius.

Note: Technically, planes exist in other dimensions. For example, in a two-dimensional space, a plane is also a line. In a four-dimensional space, a plane is a three-dimensional hyperplane. But this article discusses three-dimensional spaces, where planes are two dimensional.

Planes Make Convex Hulls

A polytope is a shape with flat sides. In two dimensions, polytopes are called polygons. In three dimensions, polytopes are called polyhedra.

A convex shape is one where any line segment between any two points in the shape is also in that shape. So, a convex polytope is such a shape with flat sides, as shown in Figure 3.

An array of planes can represent a convex polyhedron. You can describe each face, i, of the polyhedron using a plane representation, . This is called a half-space representation (or H-representation).

Figure 3. Convex versus non-convex polytopes

To determine whether a point is inside a polyhedron, compute the distance of that point to each face plane of the polyhedron. If all distances are negative, the point lies inside the polyhedron.

As Figure 4 depicts, computing the distance between a stationary point (or sphere) and the planes of a polytope does not always give an unambiguous measure of distance or penetration depth. Sometimes, the best measure of distance could be from an edge or vertex of the polytope. But the distance formula will always correctly tell whether a point (or sphere) is inside, outside, or overlapping a polytope.

Alternative Method

The point-to-plane method suffices when detecting collisions between particles and polytopes. Other algorithms exist to compute the distance between two convex shapes. One of the most famous and useful, especially among game developers, is the Gilbert–Johnson–Keerthi (GJK) distance algorithm. Although its code is fast and simple, the concepts are not easy to explain and are not in the scope of this article. Furthermore, determining penetration depth can be even more problematic and usually entails more sophisticated approaches, such as the Expanding Polytope Algorithm (EPA). See the "For Further Study" section at the end of this article for more information.

Collision Detection

Detecting a collision between objects entails computing their separation distance or penetration depth. Also, when objects collide, you usually want to know the region of contact and contact normals—that is, the direction along which to apply force or displacement to separate the objects.

Although the point-to-plane distance formula will tell you whether a point lies inside a polytope, it will not unambiguously tell you its distance or penetration depth. In addition to the edge cases described earlier, determining penetration depth entails the relative direction of travel of the two objects. The correct answer depends on the configuration of objects before and after the collision. If objects lie inside each other (or if a particle lies inside a polytope), then you have detected the collision after it occurred. This is called interpenetration, and it should be avoided or corrected when it happens.

For visual effects involving hundreds or thousands of tiny particles, you can get adequate results by using the following simple algorithm:

1. Given a query point, a polytope, its position and orientation, initialize largestDistance to an extremely large negative value.
2. For each plane in the polytope:
   1. Compute the distance between the query point and the plane.
   2. If that distance exceeds largestDistance, then:
      1. Assign largestDistance to that distance
      2. Remember this plane index
3. Return the plane index and largestDistance.

For spheres, subtract their radius from the returned largest distance to get the separation distance. If that value is negative, the sphere interpenetrates the polytope.

From that information, you can compute a contact point and normal:

Given a query point, a plane, a polytope orientation, and the largest distance:

1. Reorient the plane normal to world space.
2. Scale the normal for the returned plane index by the largest distance to get a penetration vector.
3. Subtract the penetration vector from the query point to get the contact point.

Although this algorithm does not accurately measure distance for the edge cases, the distance and normal it returns yield sufficiently close results to work for collision response.

The ConvexPolytope class implements these algorithms. (See the demonstration code that accompanies these articles for more details.)

The routine ContactPoint uses information computed by ContactDistance:

Broad Phase

The ContactDistance algorithm iterates over every face in a polyhedron. That process can get expensive. You can reduce that expense in a few ways:

• Only compute ContactDistance when the query point lies within a coarse bounding volume (such as a bounding sphere) that contains the polytope. That computation is much faster and can let you skip the more expensive ContactDistance until the query point is somewhat near the polytope. The accompanying code uses this technique.
• If you only care about interpenetration, you can change ContactDistance to return immediately when it finds any distance-to-plane that is positive. The returned value will not necessarily be the largest distance, but when positive, you don’t care. Note that if you want to compute the distance to a sphere instead of to a point, then you would have to pass in the sphere radius and take that into account. The accompanying code includes a routine that uses this technique.

To further reduce CPU cost , but at the expense of memory and complexity you can:

• Remember the plane from the previous iteration, and reuse that for the next attempt. If it’s still positive, there is no collision, and you can bail out after testing one plane. Note that this would entail storing another integer per particle. Because there can be tens of thousands of particles, that can add up.
• Store face connectivity information and only visit adjacent faces whose distance would increase largestDistance. Doing so can significantly reduce the number of faces visited. Also, game engines often include such adjacency information. You might be able to exploit that information for particle collisions.

Deepening Penetration

If a particle penetrates an object, it could end up closer to the opposite side of the object rather than the side it penetrated, as Figure 5 shows. This could happen for thin objects or fast particles. It is therefore useful to consider only those planes for which particles are moving farther behind.

Figure 5. Measuring collision depth between a moving spherical particle and polytope

The demo code accompanying this article contains a routine, ConvexPolytope::CollisionDistance, that implements this idea.

Continuous Collision Detection

The most accurate way to determine contacts would entail continuous collision detection (CCD)—that is, detecting the collision just as it happens (instead of after the fact). CCD involves computing a time of impact (TOI) and either advancing the simulation up to that point or rewinding back to it. One way to approximate CCD to estimate TOI is to move into a reference frame where only the object moves. The other object will still be in motion. Now, sweep that moving object across space to span the region it would occupy at all points during the test interval. If the swept shape intersects with the stationary shape, the two objects probably collided during that interval.

Sweeping a shape is relatively easy if its motion is pure translation but more difficult if its motion includes rotation. Video games therefore either treat only linear motion for continuous collision detection or simply use discrete collision detection and allow objects to interpenetrate.

For spherical shapes, like particles, the swept shape is a line segment with hemispherical caps, also known as a capsule or sausage. You can compute intersections between capsules and planes using simple formulae. But particle effects for video games do not need that level of sophistication, and it takes longer to compute than most games budget for effects.

Concave Shapes

The technique described in this article applies directly to convex shapes. To apply to concave shapes, you can either compute the convex hull of that shape or decompose the shape into convex components. See the "For Further Study" section for more information.

Collision Response

When the detection phase indicates that a particle interpenetrated an obstacle, the simulation must resolve the collision. In other words, it must push the particle outside the obstacle and adjust the fluid flow to satisfy boundary conditions.

Part 1, part 2, and part 4 explain boundary conditions and one way to solve them approximately, so I will not repeat that here. This article only describes changes that facilitate particles interacting with convex polyhedra.

Simplified Vorton Interaction with Planes

The routine SolveBoundaryConditions iterates through each rigid body and collides vortons and tracers with that body by calling CollideVortonsSlice and CollideTracersSlice. As of this article, ColideVortonsSlice is a new routine, extracted from SolveBoundaryConditions from previous articles.

The code snippet below focuses on changes made to facilitate colliding with convex polytopes. Code in purple bold is new.

Notice that this code first checks whether the particle lies within a bounding sphere, regardless of whether the obstacle is a sphere or polytope. That is a broad-phase collision test.

The routines CollideTracersSlice and RemoveEmbeddedParticles have similar changes. See the demonstration code accompanying this article for details.

Parallelization

The routine CollideVortonsSlice was extracted from SolveBoundaryConditions to facilitate parallelizing it with Intel® Threading Building Blocks (Intel® TBB). In addition to extracting that code into its own routine, other changes were made. Previously, the corresponding code directly applied changes to the rigid body’s temperature and momentum. The old code performed operations like this:

1. Read body temperature.
2. Compute heat exchange based on body temperature.
3. Write new body temperature.

But when run in parallel, such updates cause a race condition, as shown in Table 1.

Table 1. Parallel threads cause a race condition.

Both threads update a value at the same address (temperature, in this example). Only one thread can "win."

You could solve this issue by synchronizing the code with mutex locks on the body temperature. But doing so would serialize that critical section of code, which would in turn defeat the purpose of parallelizing it.

Instead, have each thread accumulate changes in a variable local to each thread. When the thread terminates, have the parent thread accumulate those changes and apply them to the body. This might seem to be a perfect use case for Intel TBB’s parallel_reduce operation.

There is one more catch, however: That accumulation operation is not associative. (See Part 12 for details of a similar problem.) Even though addition is associative for real numbers, it is not for floating-point numbers. To ensure that this parallelized routine is deterministic, you have to spawn and join threads manually, because Intel TBB’s parallel_reduce does not split and join deterministically. Instead, use Intel TBB’s parallel_invoke and manually spawn and join threads.

Create a functor to run CollideVortonsReduce with Intel TBB’s parallel_invoke:

For comparison, the demonstration code accompanying this article also includes code for using Intel TBB’s parallel_reduce. It works—in the sense that it generates a usable result—but it is not deterministic, so using it would impede diagnosing issues.

Results

Let’s replace some of the spheres in previous articles with polytopes.

Although the demonstration code uses boxes, the algorithms and data structures support any convex polytope, as depicted later in Figure 8.

Scenarios

Figure 6 shows a flat plate interacting with flames and smoke. Notice that particles move around the plate, and the plate causes vortices to shed from it.

Figure 6. Various views of a plate above flames

Figure 7 shows a flat plate moving horizontally through fluid, leaving a wake with vortices. The code accompanying this article also includes demonstrations with the obstacle rotating about longitudinal and lateral axes, exhibiting the Magnus (curve ball) effect.

Figure 7. Flat plate moving through fluid

Figure 8 shows a polyhedral airfoil moving horizontally through fluid, leaving a wake with vortices. This demonstrates that the technique applies to shapes other than boxes and spheres.

Figure 8. Airfoil moving through fluid. This comes from Gourlay (2010), which used a similar formulation to that presented in this article.

Performance

Table 2 shows how the collision-detection and response routines perform for the scenario with flames and smoke passing by the flat plate. This scenario had, on average, 49,000 tracer particles and 981 vortex particles (per frame), two spheres, and one box. Tracers hit bodies 8876 times per frame, and vortons hit bodies 63 times per frame. The benchmark ran 6000 frames for each run. The processor was a four-core (eight hardware threads with hyperthreading) Intel® Core™ i7-2600 running at 3.4 GHz.

Table 2. Collision-detection and response routines for the smoke and flame scenario

Figure 9 shows a plot of the data in the table.

Figure 9. Run times for the benchmark scenario

Lift

Nonrotating spheres do not generate lift. But lift occurs on asymmetric shapes like flat plates and airfoils.

The algorithm to solve boundary conditions generates lift-like impulses. A flat plate moving horizontally through the fluid at an appropriate angle of attack should encounter lift pushing the plate upward. And indeed, this simulation generates a qualitatively similar result—but it’s from deflecting particles that bounce off the obstacle with partially elastic collisions. In contrast, simulations used in science and engineering calculate the pressure the fluid exerts on bodies, and that calculation can include lift. This simulation does not calculate pressure.

Furthermore, the collision response algorithm does not generate new vortons; it only reassigns values for existing vortons in contact with the object. To be more physically accurate, objects should generate new vortons when necessary. For example, vorticity would be generated on the leeward side of the airfoil, and this would generate a low-pressure region behind and above the airfoil, the vertical component of which would be lift. See the "For Further Study" section for more information about more physically accurate ways to calculate realistic pressure and aerodynamic forces on objects immersed in a fluid.

Summary

Using a simple point-to-plane distance formula, you can make fluid effects interact with obstacles that have shapes commonly used to create models in a video game. The algorithm is easy to parallelize using Intel TBB and runs in less than a millisecond for tens of thousands of particles.

Future Articles

Liquids take the shape of their containers on all but one surface, so modeling liquids also implies modeling containers. Future articles will include extending boundary conditions to include interiors, which will allow for creating containers. That will pave the way for a discussion of free surface tracking and surface tension—properties of liquids.

For Further Study

• Casey Muratori posted a video (https://mollyrocket.com/849) that explains the GJK algorithm using straightforward geometry.
• Lien and Amato ("Approximate Convex Decomposition of Polyhedra," 2006) describe an algorithm to decompose a concave model into nearly convex shapes. Lien’s Ph.D. dissertation (http://cs.gmu.edu/~jmlien/masc/uploads/Main/lien-dissertation.pdf) contains pseudo-code for their algorithms and a comprehensive bibliography on the subject. Also see their technical report (http://cs.gmu.edu/~jmlien/masc/uploads/Main/cd3d_TR_2006.pdf).
• The Wikipedia article on Convex Hull Algorithms (http://en.wikipedia.org/wiki/Convex_hull_algorithms) describes algorithms to obtain the convex hull of a set of points, such as the vertices of a model.
• In chapter 6 of Vortex Methods: Theory and Practice, Cottet and Koumoutsakos describe a vorticity creation algorithm to satisfy boundary conditions. In contrast to the algorithm presented here and in part 4, their algorithm takes into account the entire body at once instead of only a single point at a time.
• I presented a formulation similar to the one described in this article in "Fluid-body simulation using vortex particle operations," an animation poster session at the International Conference on Computer Graphics and Interactive Techniques (SIGGRAPH), Los Angeles in 2010.

About the Author

Dr. Michael J. Gourlay works as a senior software engineer on interactive entertainment. He previously worked at Electronic Arts Inc. (EA Sports) as the software architect for the Football Sports Business Unit, as a senior lead engineer on Madden* NFL, on character physics and the procedural animation system used by EA on Mixed Martial Arts, and as a lead programmer on NASCAR*. He wrote the visual effects system used in EA games worldwide and patented algorithms for interactive, high-bandwidth online applications. He also developed curricula for and taught at the University of Central Florida, Florida Interactive Entertainment Academy, an interdisciplinary graduate program that teaches programmers, producers, and artists how to make video games and training simulations. Prior to joining EA, he performed scientific research using computational fluid dynamics and the world’s largest massively parallel supercomputers. His previous research also includes nonlinear dynamics in quantum mechanical systems and atomic, molecular, and optical physics. Michael received his degrees in physics and philosophy from Georgia Tech and the University of Colorado Boulder.

^*Other names and brands may be claimed as the property of others.

This document will guide you through installing the Intel® Atom™ x86 image for Android* Ice Cream Sandwich, which can be used for development on Intel’s x86 architecture.

Prerequisites

The Android x86 Emulator Image requires the Android SDK to be installed. For instructions on installing and configuring the Android SDK, refer to the Android developer website (http://developer.android.com/sdk/).

Optional: The x86 Emulator Image for Android can be accelerated using Intel Hardware Accelerated Execution Manager (HAXM). For more information, refer to the “Optimization” section of this document.

Installation

Downloading through Android SDK Manager

1. Start the Android SDK Manager.
2. Under Android 4.0.3 (API 15), select “Intel x86 Atom System Image”:
   
   
3. Once selected, click the Install Package button.
4. Review the Intel Corporation license agreement. If you accept the terms, select Accept and click Install.
5. The SDK Manager will download and extract the system image to the appropriate location within the Android SDK directory.

Using the System Image

1. Start the Android AVD Manager and create a new AVD, setting “Target” to “Android 4.0.3 – API Level 15”, and “CPU/ABI” to “Intel Atom (x86):
   
   
   
   
   Note: if the “Intel Atom (x86)” CPU/ABI option is not available, please make sure that the system image is installed correctly.
2. Click the “Create AVD” button.
3. The AVD has been successfully created and is now ready to use:
   
   

Optimization

CPU Acceleration

The performance of Intel Atom x86 Image for Android Ice Cream Sandwich can be improved using hardware-based virtualization using Intel VT-x technology.

If your computer has an Intel processor with VT-x support, it is recommended that Intel Hardware Acceleration Execution Manager (HAXM) be used in conjunction with this system image. For more information about Intel HAXM, visit http://www.intel.com/software/android.

Note: Intel HAXM is for Windows and OS X operating systems only. For Linux hosts, Kernel-based Virtual Machine (KVM) can be used to accelerate emulation performance. For information on installing and configuring KVM on Ubuntu, refer to the following guide: https://help.ubuntu.com/community/KVM/Installation

GPU Acceleration

The Intel Atom x86 Image for Android Ice Cream Sandwich can make use of hardware GPU features to increase the performance of games, graphics-intensive programs, and user interface elements.

Note: The functionality and performance of GPU acceleration is highly dependent on your computer’s graphics card and graphics drivers.

To use hardware GPU acceleration, perform the following steps:

1. Open the Android AVD Manager.
2. Select the AVD, and click the “Edit” button.
3. The AVD editor window will appear. In the Hardware section, click the “New” button:
   
   
4. In the Property drop down box, select “GPU Emulation”.
   
   
5. Click OK.
6. After the GPU Emulation property has been added, change the “value” to “yes”.
   
   
7. Click the “Edit AVD” button to save the AVD.
8. After the AVD has been modified, a dialog will appear confirming the AVD settings:
   
   
   
   
   
   In the confirmation dialog, the “hw.gpu.enabled=yes” line indicates that GPU acceleration is enabled for that particular AVD.
   Note: The GPU acceleration must be enabled on a per-AVD basis.

Copyright (C) 2012 Intel Corporation.  All rights reserved.

Intel, Atom, and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.

All products, computer systems, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

* Other names and brands may be claimed as the property of others.