In the previous three parts of this series, we’d sorted out why B-splines are interesting curves, attempted to sort out B-splines terminology, and decided that it would be really nice to be able to evaluation them with uniform functions. I’d tried some quick and dirty approaches to force it to be, and had gotten little in response. It was time to actually do some algebra and figure out what was going on.

A Note About Tools

That means there are going to be a lot of LaTex-created images in this section. Sorry, but it’s a lot less painful than trying to write out math in raw HTML. (Okay, writing this inspired me to search for LaTex to MathML translators, and of course the W3 itself maintains quite a nice list. Oh well, I promise I’ll look into that for next time.) In the meantime, I’m using the wiki built into Trac to write this post, with the TracMath plugin to take inline LaTeX blocks and render them as PNGs. This means that I just type

#!latex
$$N_{i,k}(v)={{\left(
  T_{k+i} - v\right)\,N_{i+1,k-1}(v)}\over{T_{k+i}-T_{i+1}}} +
  {{\left(v-T_{i}\right)\,N_{i,k-1}(v)}\over{T_{k+i-1}-T_{i} }}$$

and I get

Well, okay, I don’t write that, because I can’t remember LaTeX math syntax to save my life. (I got pretty good at it in college, but it’s been a while.) Anyway, it’s hard to parse by eye, and I’m very prone to swap a u for a v, which can be unfortunate when you’ve just carefully drawn a distinction between them.

Instead, I’m using Maxima, a free Computer Algebra System. It’s stranger to pick up than Mathematica, but the price is right (and it’s quite powerful once you get used to its ways). It seems to be really flaky on recent Ubuntu releases, which is unfortunate, but I’m primarily using 5.17.0 for Windows and it works like a champ. It has a very nice tex function, which will spit out the TeX formatting for any given expression.

So in practice, I work the math in Maxima, have it convert to TeX, then paste that into the post. (Sometimes I tweak it slightly, for example to pull out a leading “1/2″ rather than leaving the whole expression over 2 as Maxima seems to prefer. But for the most part, the expressions in the text are directly out of Maxima.) I have some ideas of writing a Trac plugin to close the loop and directly evaluate and typeset Maxima expressions in the text, but I haven’t got it all worked out yet: the equations in a piece generally build on each other, so you need enough lifecycle awareness to start and maintain a separate Maxima state for each page in flight. Also you probably need some non-displayed helper definitions and intermediate values, so you need a separate bit of syntax to indicate what should be rendered into the page. I think the fact of the existence of the PageOutlineMacro means it’s possible, but the fact that the PageOutlineMacro actually re-parses the whole page means it’s not necessarily easy. (I’d also still have to solve creating and maintaining enough state that the various individual blocks could fetch their expression / formatted results from the initial gather-and-run macro.) Anyway, for the moment I’ll do it the hard way.

Back to the Math

I’m going to run through a concrete k=3 (quadratic) example with 6 control points (so n=5), and claim that this demonstrates a general solution for k=3. I’m pretty sure it does, but it’s a lot easier to keep track of the indexes with a concrete number. Or so I claim.

So, the knot vector T should be the sequence [0, 0, 0, 1, 2, 3, 4, 4, 4]. Recall that indices are zero-based, and that N_i,1 is defined as

Given this, the N_i,1 terms will start being interesting at i=2, where N_2,1= 1 for 0 <= u < 1. From then on, each N_i,1 is non-zero on N_i,1= 1 for i-2 <= u < i-2+1, up through the last value we need at N_5,1. Using Maxima to evaluate the raw B-spline equation

for our knot vector T (again, this is the k=3 case), we get a whomping huge expression in terms of the control points P, the N_i,1 “switches”, and of course v. I won’t reproduce the whole thing here (fully expanded, there are 33 terms, and even my new wider columns can’t handle that), but here’s the coefficient of the second control point P₁ for flavor:

Explicit Equations for Each Segment

The good thing is that we don’t ever really need the whole equation at once. Only one of the N_i,1 terms will be 1 at any given time — this is what produces the curve segments. By setting N_2,1 through N_5,1 to 1 in turn (and the other N_i,1 terms to 0) we can produce the four curve segments. In turn, these are

Maxima Script

For anyone who’s following along at home, here’s the Maxima to get our results so far:

N(N1, T, i, k, v) := if k = 1 then N1[i] else
(if T[i+k-1] = T[i] then 0 else (v- T[i])* N(N1, T, i, k-1, v) / (T[i+k-1] - T[i]))
 +
(if T[i+k] = T[i+1] then 0 else (T[i+k] - v) * N(N1, T, i+1, k-1, v) / (T[i+k] - T[i+1]));

BSpline(P, N1, T, n, k, v) := sum(P[i] * N(N1, T, i, k, v), i, 0, n);
T5Vals : [0, 0, 0, 1, 2, 3, 4, 4, 4];
T5[i] := T5Vals[i+1];

BSpline5_3(v) = BSpline(P, N1, T5, 5, 3, v);

makeN1Helper(curveSeg, n, k) := makelist(if j - k + 3 = curveSeg then 1 else 0, j, 0, n-1);
BSpline5_3_Seg(seg, P, u) := BSpline(P, makeN1Helper(seg, 5, 3), T5, 5, 3, u);
for seg : 1 step 1 thru 4 do disp(
  segment[seg] = facsum(ratsimp(
    BSpline5_3_Seg(seg, P, v)), P[seg-1], P[seg], P[seg+1]));

Note that Maxima lists are one-based, hence the helper function T5 to preserve the zero-based indexing in the original definitions. Since N_i,0 is never referenced, I can get away with a list starting at index 1 (though I admit this is made more confusing by the choice of a zero-based loop variable. Oops.) Also note that BSpline5_3 wasn’t actually defined as a function there — that was just an equality, to make Maxima print it out nicely. Other than that, this is pretty much what it looks like. Oh, and notice that the recursive N definition has to avoid a couple of divide by zero cases to implement the “where 0/0 is defined to be 0″ escape hatch.

Reparamaterization

Okay, those equations work but they look pretty ugly (and they’re different in each segment, but we’ll work on that in a minute). It took me a while to sort this out, but I sort of tipped my hand back in the “Definitions” post where I introduce w and j, so I’ll just repeat the equation from there: v = u (n-k+2) = j+w-1. Remember that j is the segment number ranging from 1 to n-k+2, which is exactly the subscript of segment in the explicit equations above. So we substitute w-1 in the first equation, 1+w-1 in the second and so forth. Using the Maxima definitions above, this is just evaluating the BSpline5_3_Seg function above at seg+w-1 rather than v:

for seg : 1 step 1 thru 4 do disp(
  segment[seg] = facsum(ratsimp(
    BSpline5_3_Seg(seg, P, seg+w-1)), P[seg-1], P[seg], P[seg+1]));

(the facsum bit just rearranges the terms) yielding

Now we’re getting somewhere. The middle two equations are identical except for shifted subscripts on P. The first two and last two are different, but we can work that out in a minute. First let’s generalize the uniform version and check our claim that

works for those middle terms. This will also give us a peek at the what’s going on with the end segments.

B3[uniform](P, j, w) := (-P[j]*(2*w^2-2*w-1)+P[j+1]*w^2+P[j-1]*(w-1)^2)/2;
for seg : 1 step 1 thru 4 do disp(
  difference[seg] = ratsimp(
    BSpline5_3_Seg(seg, P, seg+w-1) - B3[uniform](P, seg, w))
);

yielding

What we’re computing here is the difference between the “real” equation for each of the four segments and what we get from using the uniform equation for all of the segments (ignoring the segment number).

Doesn’t look immediately promising, but there are two good things:

• the two middle segments are as predicted by the uniform function above
• the two end segments’ differences only involve two control points

We know that P₁ and P₄ are used in the middle two segments as well as the end segments, so we can’t do anything to them. However, the two end points (P₀ and P₅) are only used in the end segments. So what it we feed some different value (not the current P₀, but some combination of P₀ and P₁) into the uniform equation? Can we make the result be the same as evaluating the “real” B-spline function on the original control points?

In the uniform version of segment 1, we replace P₀ with a new variable x, then set it equal to the real first segment of the k=3 B-spline:

We then solve for x hoping we can eliminate all the w terms:

rightAnswer : ratsimp(BSpline5_3_Seg(1, P, 1+w-1));
uniformWithFreeP0 : ratsubst(x, P[0], B3[uniform](P, 1, w));
solve(uniformWithFreeP0 = rightAnswer, x);

and we get (drumroll, please)

(Okay, that didn’t really need a LaTeX block, but it really did take me quite a while to figure out, and I was inexplicably happy when I found it (literally: one very really reason for this whole series is to explain to my wife why I was grinning so much that week). If I’d happened to have run into that formula up front I would have spared myself a great deal of frustrating math trying to figure out how to make sense of what I was seeing. Of course, I also wouldn’t have learned a lot about splines, so maybe it was better this way.)

Repeating the process for the last control point (in this case P₅), we get x = 2 P₅-P₄:

rightAnswer2 : ratsimp(BSpline5_3_Seg(4, P, 4+w-1));
uniform2WithFreeP0 : ratsubst(x, P[5], B3[uniform](P, 4, w));
solve(uniform2WithFreeP0 = rightAnswer2, x);

This is a reassuring result — the equations are all symmetric, so it should be possible to reverse the control points and produce the same curve. Therefore, it’s nice to see that this formulation for the end-points is also symmetric.

So the practical upshot of this is that we now have a way to evaluate all the segments of a B-spline, even the “weird” end segments, with the same uniform equation. To do this, we have to massage the control points a little. Given the input sequence

( P₀ , P₁ , … , P_n-1 , P_n )

we need to make a copy, so we can feed the uniform function the sequence

( 2 P₀ – P₁ , P₁ , … , P_n-1 , 2 P_n – P_n-1 )

instead. That doesn’t seem like much of a price to pay for freedom (or at least for being able to evaluate all segments of all k=3 B-splines curves with the same straight-line evaluation code).

The same general approach works for k=4 curves (cubic B-splines). Because the cubic blending functions involve more points in each segment, we have to replace both P0 and P1 with free variables, and solve for them simultaneously (using the known equations for the first two segments, instead of just the first segment), but it’s the same logic and it works quite nicely. I haven’t tried to generalize a formula for any value of k, mostly because quadratic and cubic B-splines are far more common than other types.

This took much longer to post than I’d planned, but I hope it was worth the wait for someone. I can absolutely guarantee that this isn’t an original result, but I haven’t actually seen it in Wikipedia or MathWorld or the usual suspects, so I feel entitled to be slightly smug.

Don’t miss Chyron at Government Video Expo next week at booth 720!  Chyron understands your business models and requirements and will be offering rapid ROI in a truly collaborative environment utilizing centralized graphics distribution & resources.

Did you ever come across a screenshot from flight simulator that made you just stop and gape? One that, at first glance, looked like a photograph instead of a computer-based sim? I had one of those moments this week, and it got me thinking about what makes some simulated objects appear more or less “real” than others. Hint: it’s all in the lighting.

Two add-on previews got me thinking about lighting; Fly Tampa’s new Caribbean airports project, and Classics Hangar’s FW-190. The two products couldn’t be more different in terms of subject matter, execution, or overall feel. What they share is a nuanced and detailed approach in representing how light interacts with objects, and how manipulating shadows and highlights can lend those objects weight and volume.

Modeling Light, Not Just Objects

At right is the shot that first intrigued me. It’s not the fanciest model I’ve ever seen, nor is it a particularly daring composition.  What it does have is an excellent balance between light and shadow. The metal of the roofs is just shiny enough, bright but not overdone, and stands out in stark contrast with the even green of the jungle behind it. Looking below the roof line, you can see the shadows cast by the deep eaves onto the walls below. There’s a bit of reflection in the windows, but it’s subtle.

Then there’s this shot – another terminal at another airport in this package. Again, nothing dramatic, but look at how the shadows under those thatched peaks gives the recessed areas such depth. The thatch work isn’t shiny, so there’s not much contrast between the lights and darks, unlike the red roof nearby. In both shots, the overall contrast is low, which simulates the hazy, moisture-laden air of the tropics. You can almost hear the mosquitos buzzing and the brightly-colored birds twittering.

I’ve seen a lot of technically very proficient models not look half as real and alive as the ones in these two shots. Often times, a modeler will be so obsessed with making sure their textures are tack-sharp that they opt to repeat a small, detailed texture across a broad surface. Inevitably, the effect is less realistic, rather than more, because the human eye is so highly attuned to picking up patterns. All it takes is a whiff of perceived repetition, and all the visual trickery you’re striving for goes up in smoke.

Neither of the two FlyTampa screenshots depict overly sharp textures. Instead, they use their slight softness to good effect, by replacing repetition with natural variation. Look at the corrugated metal roofs in the first shot. Yes, technically, the surface is made up of repeating lines that form a pattern. But look closer… the metal has stains and streaks, random slight shadows and raised spots, none of which follow a pattern. It’s the little things that are barely noticable at first glance that give those buildings that extra presence.

Hand-Drawn or Photos?

In a very different vein, there are these preview pics of Classics Hangar’s upcoming Focke-Wulf FW190 (Late Variants) release. The more I see of this project, the more it blows me away. Nick Churchill has been churning out preview pics, and these shots are from the collection of shots on his forum.

Have a look at the dashboard to the right. If your first instinct is that it uses photographic textures, you could certainly be forgiven. This is a masterful example of a technique called “baking in” the shadows, in which the 3D modeling software analyzes the model’s geometry and factors in how light would bounce around the space. My favorite part of this shot? The ever-so-subtle shadows beneath the gauge bezels. That’s not FS lighting, my friends, that’s pure rendered shadowing, quite possibly heavily tweaked by the devs as well. Look at the shadow under the gyro compass to the right. It’s darker, deeper, and less distinct than those of its counterparts to the left, in keeping with the fact that the gauge itself stands out from the panel more. This is a perfect example of how shadows complement the gauges, increasing the sense of substance.

Here’s a close-up shot of the gauge faces. Notice the way the shadowing on the inner disc of the turn indicator suggests not only the slight backset to that part of the gauge, but that it’s a curved surface as well. Lean in a little closer, and you see something else – the needles in the gauges are casting shadows! Think about it. Not only have they modeled the shadow, but they’ve tied it to the needle movement, which means it’s not part of the gauge face, but a separately-moving item all its own. I’m not sure whether it’s done purely in the textures or with bump mapping, but even the stamped inscriptions on the gauge faces are there.

What these shots prove is that hand-drawn textures can actually trump photos in terms of perceived realism. Yes, it takes a great deal of skill and patience to work at this level, but the results are nothing short of phenomenal.

So the next time you’re thinking to yourself how much a particular add-on appeals to you, stop to consider how much the lighting has to do with it. Reflected light is the way we humans see things, so mimicking the play of that light across a surface is something that 3D modelers have to give a lot of thought to. How they handle it is what makes the difference between a good product and a great one.

Happy flying!

Cody Bergland of Jaggyroad Films just released his latest opus, a preview of Orbx’s upcoming FTX NA Blue: Pacific Northwest scenery. Not only do you get stunning views of this gorgeous part of the world (though I may be biased), but also a couple of peeks at the first two payware airports designed to fit within it – 1S2 Darrington Municipal, and 7S3 Stark’s Twin Oaks (okay, I’m definitely biased). Watch it below, sure, but this is one that’s worth downloading the high res version.

Before getting into a correct treatment of the problem, and deriving a correct way to handle these differing end segments (as part of the B-spline series of posts), I should explain what I mean by “uniform” and why I’m so hung up on it. (That is, other than the fact that the B_uniform function is an easily-understood mixing of three control points, while the recursive definition of the basis functions makes my head hurt.) In particular, why not just accept a solution along the lines of:

function evaluateBSplineWithConditional(u) =
v = u * (n-k+2)
segment = floor(v)
w = fractional_part(v)
if(segment <= 1) then
  do weird thing(segment, w)
else
  do uniform thing(segment, w)

(I may have got the indexing slightly wrong, but I think this works (and is a good illustration of why I was being so pedantic about u, v, and w above — it’s not complex math, but it’s easy to mess up the parameterization).) Also note that I’m only looking at the weirdness at the beginning of the curve; properly the conditional would need to check whether the segment was at either end of the curve. This is a simplified version to support the discussion, not an actual implementation.

Endpoints are often exceptional cases; why not just define the evaluation with that exceptional case and move on? All the more so since my attempted trick of “pre-conditioning the data” (replacing the original sequence of control points with a sequence with repeats at the beginning and end) didn’t work? (An important background assumption to the rest of this discussion is that this function is going to be run many many times, since we need a lot of points on that curve to make it look like a smooth curve when we draw it on-screen, or when we send the points to a CNC router to cut metal, or whatever we’re doing with it. If we only needed to do it once, this would probably be the right solution.)

The Problem with Branching

The answer basically has to do with computer architecture and the way it has evolved over the past couple of decades. Once upon a time, when I was programming on my father’s hand-me-down Heathkit Z-80, this would have been a perfect solution — each time we needed to evaluate a B-spline, we’d simply decide if we were in the normal or weird section of the curve, and calculate accordingly. The problem is that as we poured billions of dollars into CPU fabrication techniques, we got more and more transistors, and needed some way to take advantage of them in order to make things run faster. One major solution is “pipelining”, which essentially can be described as doing many things at once. Rather than waiting for each step to complete before we start on the next step, the CPU will get a lot of things started at once, and pull them all together when needed. (Perhaps I’ve been watching too much Iron Chef, but this seems like partitioning work out to a sous chef.) In the extreme case of the P4 architecture, the pipeline was up to 20 stages long. A much more technical discussion can be found at http://arstechnica.com/old/content/2001/05/p4andg4e.ars but the basic takeaway is that for a modern CPU to run fast, it needs to be able to do many things at once.

A conditional (the “if / then” in the pseudo-code above) wreaks holy hell on this scheme. Before the CPU can get started on “do uniform thing” or “do weird thing”, it has to know which one it needs to do. This is one cause of a “pipeline stall”, since instead of doing 20 things at once, we have to wait for the conditional to be evaluated (through all 20 stages) before doing anything. This is absolutely brutal on performance.

Modern CPUs actually try to work around this problem as well, using “speculative execution” and “branch prediction” — basically, they keep track of what happened last time we ran this code, and assume that the same thing will happen this time. If they guess right, when the conditional is finally evaluated they can just act as if they knew it all along. If they guess wrong, they have to throw away all the speculative work and start over on the correct path. This works, but it’s hugely complex, and it makes performance less predictable and more dynamic (because performance becomes directly tied to the accuracy of the branch prediction). In our case, things would run fast through the first curve segment, when the “weird” path is consistently followed. This would be followed by a period of degraded performance when it kept guessing “weird” but the real answer was “uniform”. At some point, the branch prediction unit would be retrained to guess “uniform” instead, and performance would recover until we hit another “weird” segment. In short, speculative execution and branch prediction are nice things to have, but no substitute for “straight-line”, branch-free code.

This whole preference for a single codepath is even more dramatically true when we talk about “SIMD” (Single Instruction, Multiple Data) parallelism. This approach to performance showed up on CPUs in the MMX and SSE instruction sets, and is one of the ways to really increase performance on modern silicon. Essentially, rather than evaluating points on the spline one at a time, we could stack up a list of points to be evaluated side-by-side, then grind through them four (or however many) at a time. See http://arstechnica.com/old/content/2000/03/simd.ars for a more responsible description. The challenge here is that “Single Instruction” bit — you have to be doing the same thing to your four data points, not looking at each one individually and deciding whether to give it the “uniform” or “weird” treatment. This is true of the SIMD instructions in modern Intel and AMD CPUs, and even more so of “shader programs” running on graphics cards’ GPUs. In fact, early shader programs didn’t even have conditional instructions; everything had to be straight-line code. More recent cards allow you to branch on the GPU, but at a potentially fearsome cost to performance (see http://forums.nvidia.com/index.php?showtopic=107865 for instance).

Separate Batches

So we’re all agreed that branching is Bad. What can we do?

One approach is the “hoist the conditional” out of the inner loop. This somewhat compromises the nice clean interface of the evaluateBSplineWithConditional function, but often be a performance win. To describe this approach, we need to introduce another level of the program, namely the function which was calling the evaluateBSplineWithConditional function. Assume that we’re trying to fill an array with evenly-spaced points on the B-spline, in order to render them or drive a CNC router or whatever. Using the original definition we’d have something like

function naiveFillArrayWithSpline(array, numPoints)
  dU = 1 / (numPoints - 1)
  for(i = 0; i < numPoints; i++)
    u = dU * i
    array[i] = evaluateBSplineWithConditional(u)

The naiveFillArrayWithSpline function would really work on any parametric curve function that expects a u ranging from 0 to 1. Instead, we can give it some knowledge about the end-conditions of B-splines, to produce a version without any conditionals in the main loops:

function batchedFillArrayWithSpline(array, numPoints)
  numSegments = n-k+2
  pointsPerSegment = numPoints / numSegments
  dW = 1 / pointsPerSegment
  for(i = 0; i < pointsPerSegment; i++)
    w = dW * i
    array[i] = do weird thing (1, w)
  for(j = 1; j < numSegments - 1; j++)
    for(i = 0; i < numPoints; i++)
      w = dW * j
      array[j*pointsPerSegment + i] = do uniform thing(j, w)

(Again I’m ignoring the weirdness at the end of the curve, which would require another “do weird thing” loop. I’m also playing fast and loose with the array indexing, assuming that numPoints divides evenly into numSegments, and so forth — this is another strawman, in other words.)

This is a much uglier function than naiveFillArrayWithSpline. It also has a lot of specific knowledge about B-splines embedded in it; you couldn’t reuse this for, say, making an array filled with sin(u). However, it has the huge virtue that there are no conditionals embedded in the inner loops. In fact, there are no conditionals at all — by changing the problem from “evaluate a B-spline at a given value of u” to “fill an array with evenly-spaced values of a B-spline” we’ve been able to significantly improve the performance characteristics.

This version still has flaws, however. One is a software engineering issue: we might need both this version and the evaluateBSplineWithConditional function, if we need to be able to fill arrays efficiently but also need to be able to evaluate arbitrary points (perhaps searching for an intersection). Maintaining two functions with different structure, but supposed to produce the same result, is a good recipe for maintenance pain. (In a prior job, we had exactly this situation — and in fact the single-value version did disagree with the bulk version, which was an on-going source of confusion.)

There’s an argument to be made that software engineering pain is the price of doing business, and perhaps a different language or some code generation approach would let us keep a single version of the source code while still producing these two versions for actual production use. There are two technical flaws (or two aspects of the same flaw), though, that mean this version is sub-optimal even ignoring maintenance considerations.

From the point of view of running this code on a CPU, the issue is code size. Instead of a single, small codepath we now have a rather larger function to evaluate. The on-disk size of a program is pretty much irrelevant in the modern world, but the actual in-use code size still matters because of caching. The CPU has a limited (and often surprisingly small) instruction cache on-die; it’s vastly faster to execute code from that cache than it is to load code from main memory. While it’s unlikely that the method above would actually be larger than the instruction cache, it’s definitely larger than a uniform version, which means it would occupy more of the instruction cache. If, say, the actual rendering loop has to be pushed out of the cache in order to load our spline evaluation method, then we’re paying a definite performance cost for code size (although one that’s very difficult to rigorously detect and characterize).

In the case where this code would run on the GPU, the cost is somewhat easier to see. Rendering commands are transferred from the CPU to the graphics card in “batches”, where everything in a batch is using the same shader programs, the same constants, and so forth (only the vertex data changes between data points). The GPU-based analogue of the method above would be to render the spline in three batches: one for the first “weird” segment, one for the uniform segments, and one for the final “weird” segment. The number of batches is very often a limiting factor in naive rendering approaches; magnifying the batch count by a factor of 3 is a quick way to become batch-limited. In these circumstances it can even be possible for the performance wins of GPU-native evaluation to be completely lost in the face of the communications overhead.

Arithmetic “Conditionals”

If the cost of the computations is low enough, and the penalty for branching is high enough, there can be another answer. Instead of having the program explicitly branch, or separating the different conditions into different loops / different batches, we can simply do both branches. The obvious problem is that we’ll have two output values, but we need to produce exactly one (the right one). To solve this problem, we introduce a “condition variable” which is 1 in one conditional branch and 0 in the other. This is typically a “natural” operation because in C (and C-like languages) boolean variables are internally stored as an integer which is 1 for true and 0 for false. In this idiom, the core of the function becomes something like

function doBoth(segment, w)
isWeird = (segment <= 1)
isNormal = 1 - isWeird

weirdResult = do weird thing(segment, w)
normalResult = do uniform thing(segment, w)

answer = weirdResult * isWeird + normalResult * isNormal

This seems incredibly counter-intuitive as a speed-up, but it can actually be a win if the “weird” and “uniform” paths are both rather cheap to evaluate, and the cost of separate batches is high enough. A nice advantage of this approach is that we’re back to having a single method which can be used as the core of an array-filling loop and also used to evaluate “one-off” points.

In practical terms, I would guess that on the CPU, this approach is likely to be slower than the batchedFill method above, while on the graphics card it would be closer. (This reflects the fact that CPU instruction cache pressure is probably less critical than the communications overhead of sending batches to the GPU, combined with just how fast the GPU is at evaluating math — in the GPU case, the bar for “rather cheap to evaluate” is lower, and the cost of separate batches is higher). I haven’t done any benchmarking at all to test whether the B-spline functions actually fit these assumptions on the hardware I have available.

Tradeoffs and Real Hardware

The last paragraph hints at why all of these approaches are kind of unfortunate. It’s very possible (in fact, likely) for the “right” answer to vary with different graphics cards, different CPUs, and different connections between CPU and GPU. For instance, within a given generation of graphics cards, the cost of evaluating functions tends to drop (as the cards get faster), but the cost of submitting a batch is typically fixed (by the interface between CPU and graphics card, which experiences much slower evolution). However, for on-board graphics (where the GPU is on the motherboard or even integrated into the CPU itself) the cost of batch submission may be almost zero, while these kinds of GPUs are typically computationally weak (so the cost of evaluating the functions would be higher).

One very common solution to this sort of dilemma is to optimize for performance on your hardware, and figure it’s reasonably representative of your customers. If there’s any validity to that assumption, this may be a reasonable approach, but it’s fraught with peril; if nothing else, the optimal solution will change over time (with new generations of hardware), so your program is unlikely to age well. It can also be embarrassing, if customers upgrade their hardware and notice that your program doesn’t take any advantage of their expensive new graphics card.

To really do this kind of thing right, across heterogenous hardware and with an eye toward future-proofing your program, you would need to “do it all”, with dynamic strategy selection. For each performance-critical routine, provide all three variants listed above, then benchmark on the customer hardware to figure out which is fastest in this particular computer. This approach actually can work, and is really used by some very performance-sensitive applications. (For instance, the ATLAS project http://math-atlas.sourceforge.net/ does this for certain key linear algebra computations. Likewise, the “md” RAID system on Linux boxes will test several versions of the XOR routine at runtime to determine which is fastest. In both of these cases, a very small but very performance-critical part of the code is being optimized.) This approach is very expensive in programmer and testing time, and easy to get wrong if you don’t have a wide range of hardware available to validate your performance assumptions.

Sometimes you can instead leverage the work of other projects. For example, many problems can be coerced into problems of linear algebra, and you can then take advantage of the optimally-tuned ATLAS functions to solve them. There is typically overhead in expressing a problem this way, but it can be a win in time-to-market and coding complexity. Unfortunately, this isn’t a mechanical solution, and it isn’t applicable in all cases. In the case of B-splines, it would be possible to express the “do weird thing” and “do uniform thing” sections in terms of matrix multiplication, but it would not be easy to capture the general “do this or do that” problem as I’ve set it up here.

So the long and the short of it (after this very long digression) is that conditionals are a pain no matter how you slice it. Vastly better is to be able to precondition the data — that is, feed a fixed formula something clever to make it do what you want, rather than using two different formulas. (You can tell that I got it to work, or think I did, from my phrasing. If B-splines were inextricably different in their end segments, I’d be writing a very nice summation about how conditionals are hard but sometimes unavoidable, and the next section would be about how the real clever is solution is to have several B-splines to draw, and draw all the middles of all the curves in one batch, and all the end-segments in another batch. Which is actually pretty clever, now that I think of it. But it’s definitely not the way this post is going.)

This is the second part of a so-far three part series. See part one for some context.

For a typical background you can look at MathWorld or Wikipedia. These are pretty representative of the descriptions you’ll find on the internet in casual searching: technically correct, with nicely formatted equations, but not a whole lot of actual help if you’re trying to understand the things. In particular, the recursive definition of the basis functions are very clever but incredibly unintuitive as far as what they mean. (I also notice that the links share my own indecisiveness about how to title-case “B-spline”.)

A much more useful writeup can be found in the “B-spline Curves” section in these excellent class notes. This is a nice treatment with lots of pretty pictures, although I think the author makes things somewhat more complex by staying with the raw 0 to 1 parameterization throughout (so the elements of the knot vector end up as fractions rather than integers). Nothing wrong with it, just a different treatment (and I suspect one motivated by uniform representation across many kinds of curves, rather than my focus on uniform representation for all segments of the B-spline to ease high-volume computation).

(I should say at this point that I’m torn about how to present things. It’s very tempting to start with what I know now, tell a nice clean story, and maybe then offer an amusing anecdote about how even I didn’t quite get it at first… but that’s exactly what the textbook I was working from did (well, except for the amusing anecdote), and it didn’t serve me very well. So instead I’ll let the game tell the story, and just lay it out as it happened to me.)

First I have to explain why I was motivated to take a shortcut, which is a mixture of raw intellectual laziness and premature optimization. Starting with the intellectual laziness, here’s the basic definition of a B-spline. First, some definitions and terminology (Note that wherever I say something condescending like “the casual reader could be confused”, I really mean “I was confused for about a day”):

u

The parametric input variable. In general usage, u definitionally ranges between 0 and 1 — this defines the extent of any parametric curve (one where x=f(u) and y=g(u)). However, spline literature, or at least the text I’m working from, is pretty casual about redefining u to work over various different ranges as convenient. To avoid confusion, I’ll use u in the traditional 0..1 sense, and v and w to track these other ranges.

P_0..n

The list of control points. This is probably the most important input to the B-spline curve. Note that indexing is zero-based, and there are n+1 control points. Note that P is a list of vectors, and their dimensionality wholly determines the dimensionality of the output. In other words, if P is a list of (x,y) points, then the position of a B-spline defined on P at a given u will also be an (x,y) point. Likewise if P is defined in 3-space, that is (x,y,z) then the resulting curve is also defined in 3-space.

n

One less than the number of control points.

k

An input to the B-spline curve, this determines the degree of the polynomials used for each curve segment, as well as various other things. Most of this post considers the case of k=3.

degree

Generally: the highest exponent appearing in a polynomial: the degree of u²+3 u + 1 is 2. Specifically, for the B-spline segments, degree = k-1 (so my working example with k=3 produces a quadratic on u).

v

A variable in the range [ 0 , n-k+2 ]. This range is mapped to the 0 to 1 range of u in the obvious way: v = u (n-k+2)

T_0..n-k+2 T_0..n+k+1

[Edit 11/03/09 - there are n+k+2 total knots (numbered 0 through n+k+1), even though the highest number appearing in the knot vector is n-k+2.] The knot vector. Note that the knot vector’s indexing is zero based. In the case we’re considering (uniform end-interpolating B-splines) it consists of a list of integers between 0 and n-k+2. The first k entries are 0, then the numbers 1 through n-k+1, then k copies of n-k+2. For example, the knot vector for a 6 control point (n=5), second degree (k=3) B-spline would be T = { 0, 0, 0, 1, 2, 3, 4, 4, 4 }. Note that these are not quite indices into the control point array (for one thing, they wouldn’t reference all n+1 control points). These values actually are in the same parameter space as v, above, and basically they serve to knock out terms in the basis functions (when the same value appears repeatedly in the knot vector).

N_i,k(v)

A B-spline basis function, parameterized on i and k. Defined in two parts, as

and

where 0/0 is defined to be 0. This was the intimidating expression that inspired me to take any shortcut presented. In retrospect, I should have noticed that the denominator would be 1 in both terms unless you’re near an end of the curve, in which case one and then both terms will go to 0 (thanks to the slightly odd definition of dividing by zero). The rest of the time, the N_i,1 terms will act as switches, picking a set of terms from each basis function which will be non-zero in the current section of the curve. Also, note that in much of the literature, this function is written as a function of u, but we’ve already made the jump to the v range as described above, so I replaced the u’s with v’s.

B_k(v)

The actual B-spline curve, given a list of control points p and a degree-controlling k. This function is sometimes referred to as p(u), but this is easily confused with the list of control points. Defined as

I looked at all that, winced hard, and skipped ahead to where they’d solved the uniform version, giving the nice-ish equation for a single segment of

or in matrix form,

This was what I wanted anyway, an invariant equation where I could just feed it different parameter values and it would produce an x and y. To prevent completely following the path of my own confusion, I’ll point out here that this function is actually defined in terms of

w

Yet another parameterization. In this case, w ranges from 0 to 1 within each curve segment. This is a reinterpretation of the v parameter as the sum of an integer part (the segment number) and a fractional part (w).

j

The curve segment number, not to be confused with the i which goes from 0 to n in the definition of B above. To tie these various interpretations of parameter together, v=u (n-k+2)=j+w-1. j ranges from 1 to n-k+2. Note that j is one-based, NOT zero-based (hence the -1 offset when mapped from the 0 to n-k+2 range). This is because at the end of the curve, j=n-k+2 and w=1 — effectively, w is adding one to the range of j (so we need a -1 correction to get the ends to line up right). At the beginning of the curve, w=0, so j must be 1 or we’d again go out of range. A more intuitive interpretation of this is that j is the count of intervals, so this is a pretty standard fencepost correction (http://en.wikipedia.org/wiki/Off-by-one_error).

In terms of these renamed variables, the uniform equation would be

So hurray, there was an easy and uniform equation after all; I could either pass in a different window of three control points for each segment, or I could pass in the segment number in addition to the segment-relative parameter (w) and look up the right control points.

The first problem I encountered was that the curve created this way doesn’t actually interpolate the end points. That is to say, when v=0 the curve isn’t at p₀. Here’s where I really took a shortcut. Instead of backing off and trying to figure out what was going on, I noticed two things:

• The knot vector sort of looks like index indirection lookup table. I think this is an especially Computer Science-ish assumption — adding a layer of indirection is a pretty standard way to make non-uniform processes look uniform (see below for a more detailed discussion of what I mean by “uniform”), and a table of integers looks a lot like a list of indices. Particularly because the knot vector repeats its first and last values.
• If you feed the B_uniform function the points [p₀ , p₀ , p₁] (pretending that the control point list had multiple copies of the end-points), and evaluate it at v=0, it does actually evaluate to p₀.

I was actually working with k=4 for these initial experiments; I only dropped back to k=3 in an attempt to simplify things to figure out what was going on. The effect I saw is magnified at higher values of k — in the cubic k=4 case, each B_uniform is mixing together 4 control points instead of 3. To get it to interpolate the end-point required two additional segments to get from the last “normal” segment (on [ p₀ , p₁ , p₂ , p₃ ]) to actually end up at p₀. The last normal segment, evaluated at u=0, gives us 1/6 (P₂+4 P₁ + P₀). When we evaluate on [ p₀ , p₀ , p₁ , p₂ ] as the first “weird” term, at u=0 we get 1/6 (P₁+5 P₀). It’s not until we’re looking at [ p₀ , p₀ , p₀ , p₁ ] that we actually get p₀ at u=0.

In short, I got a little seduced by algebraic numerology — of course if you have a function which mixes 4 points, and you replace enough of those four points with copies of the same point, you’ll end up with a function which returns that point no matter what you give it. (This is the final reductive case, where all four points are actually copies of p₀ .)

The actual problem here is that we’ve wandered pretty far from the original definition of a B-spline. In particular, we have too many curve segments — v is ranging from something like -1 to n-k rather than 1 to n-k+2. (The key difference from the “real” B-spline is that the proper B-spline doesn’t actually have a “normal” segment on [ p₀ , p₁ , p₂ , p₃ ] — instead, it’s already started going into special cases.)

The practical upshot of this is that we’re spending far too much of the parameter space near the end-points of the curve, leaving only a small portion for the whole interior of the curve. This could be disastrous for rendering, where it’s very nice to sample at evenly-spaced intervals of u and assume that this will lead to generally evenly-spaced vertices in 3-space: with this scheme we’d end up with a great many sampling points at the beginning and end of the curve, and a paucity in the interior.

Even this difficulty could be overcome, by introducing yet another reparameterization to redistribute the incoming u values more evenly over the length of the curve. However, there was no getting around the problem that the actual 3-space shape of the curve was different than my reference implementation (a 3D modeling tool). I’m always willing to entertain the possibility that the reference is wrong and I’m right (perhaps too willing), but at least I needed to understand what was going on here.

The B-Spline family of curves are a nice way to make smooth curves from a series of control points. The idea is that the control points give you “handles” to pull the curve around; it won’t actually pass through any of them (except for the first and last ones), but it will be attracted to them while retaining some nice smoothness properties.

That much I knew coming in. For various reasons, I wanted to write a program to evaluate B-splines, with a particular eye to rendering them in 3D. This seemed like it was going to be a very easy task; instead, I learned a lot along the way.

A Motivation for B-Splines

Ignoring the math for a moment, let’s talk about the basic idea of B-splines. There are quite a few ways to fit a smooth (roughly meaning “at least twice differentiable, and with at least the first derivative being continuous across the function) curves to a set of control points. (And in fact there are a lot more if the curve doesn’t even have to pass through the control points!)

The simplest approach is to observe that you can always fit a quadratic (degree = 2) polynomial to any three points, or a cubic (degree = 3) to any four points, and so forth. I don’t think anyone uses this approach in serious modelling or drawing software, but it’s kind of the benchmark against which other approaches can be compared. One key benefit, which I’ll discuss below, is that this approach gives you a single function across the entire length of the curve, making them naturally uniform. There are a few problems, however:

• They get uglier as you have more and more control points, since the degree of the polynomial rises along with the control point count
• More fatally, they wiggle. This is most easily seen in a picture:

Polynomial interpolation demonstrating "wiggle"

A much better family of functions (for geometric modeling purposes) are the Bézier curves. These very useful curves are used in many drawing programs. These curves don’t actually go through the control points, except for the first and last ones, but instead use the control points as “handles” (you can think of them as pulling the curve toward them with springs, rather than having the curve attached to them). Bézier curves exhibit the “convex hull property”, meaning (casually) that if you draw lines connecting the control points, the curve will be contained within those lines. In other words, they don’t have the overshoot problems of simple polynomial interpolation. The fact that they don’t go through the control points is disconcerting at first, but isn’t fundamentally a problem for many design and modeling tasks.

Here’s a Bézier curve through the same control points:

A Bézier curve through the same control points

By now you can probably guess what the nice properties of B-splines are. They act a lot like Bézier curves, having the convex hull property and interpolating only the first and last control points, with the key difference that a change to a control point will only change a limited portion of the curve. To accomplish this trick, B-splines are made up of a number of separate curve segments, rather than a single high-degree polynomial. These segments are cleverly constructed so that when they meet, both segments are curving the same way (their first derivatives are the same). In fact, B-splines have an extra parameter, k, which controls both the polynomial degree of these segments and how continuous they are when they meet (how many derivatives are equal at the intersection point). In common usage, k is 3 or 4, leading to either quadratic or cubic curve segments. (Lower values of k aren’t “curves” in the common sense; k=2 produces straight lines connecting the control points, and k=1 is the disjoint set of control points, not connected at all. Higher k values lead to a “stiffer” spline, as the requirement of equal second and third and fourth derivatives forces the curve closer and closer to a straight line.)

As an example, here’s a k=3 B-spline (each segment is a quadratic curve) through the same control points as the curves above. As before, the control points are shown as blue circles. Additionally, the segments are each drawn in different colors, and the boundaries between segments are marked by red squares:

A k=3 B-spline curve through the same control points

B-spline Curve with segments rendered from u=-0.1 to u=1.1

Notice that we have the nice non-wiggling behavior of the Bézier curve, combined with a much narrower range of influence for each control point. The control points only influence nearby segments, meaning that this curve “flattens out” much more quickly than the Bézier version.

Details… Details they are what make a difference when your trying to illustrate something. The proper use of detail makes a image or illustration into something thats more than just a picture, it enables an image to tell a story. Example; The following image shows the Williamsburg courthouse 1776-1777 if you look in the foreground you will see a muddypath or road. Now the easy way would be to show just a simple dirt path in front of the Courthouse but the wouldn’t tell you very much. I went a step further an added more details. I added things like rocks, wagon wheel tracks and a glossy sheen to create the image of mud. These simple details tell the viewer that road in front of the courthouse seems to be heavily trafficked, used by wheeled carts or wagons and not just a pedestrian path it also implies it must have rained recently. The edge of the path is intermingled with grass which slightly implies to the time period of the scene; it is not a heavily traveled graveled road with a clearly define border put a muddy path that implies that this ‘road ‘ was some what new in its origin.

Details

With today’s economy being more uncertain than ever, companies have to make their decisions count. You know that producing a high quality commercial, company overview, or web video can help give your brand the market momentum it needs.
So then, what’s the next step? Most people ask what’s it going to cost.

Here at Mantis we ask, what rewards will your high quality video bring you? If the video is done right, you will gain exposure on TV, on the Web and anywhere else you can play it (company lobby, in-store displays, airport displays, trade shows, etc…). Once you have completed the video, it can run continuously on all of these mediums for a long time. That’s a lot of exposure with minimal effort and minimal risk.

How much effort and cost is there if you try to get that much exposure without a video? We are willing to estimate that it would be at least 10 times the cost and effort and you will never get the overall market reach that a video can provide.

With that being said, you don’t have to use your entire marketing budget to produce the video. With our virtual business model, we keep our overhead down without sacrificing quality. We offer experienced, high-end, high definition video services for very affordable prices. We are a one stop shop video production agency, so we can help with everything from creative strategy to on set shooting to editing and 3D graphic animation.

You would be amazed at how fast your brand can emerge into the mainstream with a high quality video incorporated with an intelligent marketing strategy.

We would love to answer any questions you have, so feel free to contact us anytime.

On November 3rd and 4th, Chyron is pleased to announce that it will be hosting a two day Open House at the InterContinental Toronto Centre.

Chyron is synonymous with creating the best graphics solutions for “LIVE” TV and is the choice of top broadcasters around the world. Come and experience how you can ‘create’ graphics locally or on the web, ‘manage’ all those assets and finally ‘broadcast’ them to a variety of media outlets.

We will take you through each of the solutions Chyron has to offer and illustrate the complete workflow.

The same presentations will occur in the morning and afternoon on each day.

9:00am or 1:00pm

Chyron for News – the workflow from Creation to Playout.

Explore streamlining News production. Chyron’s order management solution completes the missing link when graphics are not yet available. Comprehensive demonstrations will show you how creating, ordering, fulfilling and distributing graphics in a single location or across multiple locations simplifies your news day.

10:30am or 2:30pm

Chyron for Sports – workflow from Creation to Playout.

Experience why major broadcasters are choosing Chyron for televising the Olympics, Baseball, Football, Hockey, Basketball and Golf. Chyron provides the tools for quickly building and playing back compelling sports graphics.

11:30am or 3:30pm

Chyron for Master Control.

Find out why Channel Box is really “The Next Generation” of channel branding. Chyron’s Channel Box instantly maximizes all revenue opportunities by building a promo template once and using it multiple times LIVE. Channel Box from Chyron is all about providing the tools to do everything you need and more LIVE.

Together with Chyron’s Ontario Dealer, BSE, this is your opportunity to meet, network and discuss your broadcast workflows with the best in the business. Breakfast and lunch will be provided over the two days by BSE.

Chyron’s Toronto native, Greg Lennon, who provided all the in-house video graphics for the Leafs and the Raptors at the Air Canada Centre and for Blue Jays Baseball at SkyDome from 1990-2002, will be there to demonstrate all the latest tools for your News and Channel Branding needs.

Phil Carmichael, with his expertise in Sports including Olympics, will be showing what major Broadcasters are using for their high-end real-time 3D graphics for television Sports.

We want YOU to be a part of this presentation to see for yourself the true benefits of why Chyron is the leader in Creating, Managing and Broadcasting graphics for Television, Web, Phone and Print. So come join us to view the incredible looking graphics solutions from Chyron, the world leader of television graphics creation, management and playback.

To reserve your spot at the Open House, please RSVP to Randy Dickerson. We look forward to seeing you there!

One of the hot topics at the moment is Stereoscopic 3D. At IBC this year, Chyron displayed some of the footage of the 3D graphics from the NBA’s All-Star Weekend which gained a lot of interest from attendees. During the show Chyron was featured on IBC TV News in a segment called “What Caught My Eye?” On the news, product manager Aldo Campisi spoke about the 3D graphics. To view the news segment click here.

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

Features

• Application framework enabling reuse and replacement of components
• Dalvik virtual machine optimized for mobile devices
• Integrated browser based on the open source WebKit engine
• Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
• SQLite for structured data storage
• Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
• GSM Telephony (hardware dependent)
• Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
• Camera, GPS, compass, and accelerometer (hardware dependent)
• Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

Android Architecture

The following diagram shows the major components of the Android operating system. Each section is described in more detail below.

Applications

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.

Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

• A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser
• Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data
• A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files
• A Notification Manager that enables all applications to display custom alerts in the status bar
• An Activity Manager that manages the lifecycle of applications and provides a common navigation backstack

For more details and a walkthrough of an application, see the Notepad Tutorial.

Libraries

Android includes a set of C/C++ libraries used by various components of the Android system. These capabilities are exposed to developers through the Android application framework. Some of the core libraries are listed below:

• System C library – a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices
• Media Libraries – based on PacketVideo’s OpenCORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
• Surface Manager – manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications
• LibWebCore – a modern web browser engine which powers both the Android browser and an embeddable web view
• SGL – the underlying 2D graphics engine
• 3D libraries – an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer
• FreeType – bitmap and vector font rendering
• SQLite – a powerful and lightweight relational database engine available to all applications

Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included “dx” tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

Linux Kernel

Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.

Cheers…

3D graphics has taken over our visual space and it is small wonder that there are so many 3D graphics creating studios out there that are vying
for attention. From advertising companies to website owners, every one wants 3D graphics and interactive solutions to wow their clients and
visitors.

This has created the great demand that enables so many studios to come up in so little time. But the catch in this business is the cost of equipment. Systems for 3D graphic creation are expensive and they require a high amount of initial investment. This includes buying the main computers on which the main creation process will take place. Then come the usual accessories for crating the drawings and the wireframes. There is also the cost of infrastructure and softwares that add to the total sum that needs to be spent.

Till this point, it is still possible for studios to get away with investing in basic equipment to keep it cost effective. However, when it comes to building a rendering system, costs start to skyrocket. As most professionals and even amateurs would immediately, rendering is a processor intensive process and it takes a lot of processing power to crunch the data in at least twice that of real time.

However, the reality is that you need to have a very high amount of processing power to achieve decent speeds and one single CPU is never enough for this purpose. So most professional create smaller clusters of CPUs. This is based on the same principle that multi-core chips are based on – many hands make light work. This called parallel processing and it is how all high-demand computational jobs are carried out.

But these CPU clusters cannot be just chips put together because such a system would need to be custom made and that is super computers are built. Instead, the clusters are actually interconnected machines that are full-fledged systems. They have the full chip, motherboard, RAM, storage and OS setup. Their combined processing power is called upon to make the rendering process faster. After all, no one really wants to wait for days to finish rendering a movie!

But creating such cluster is expensive. Each system needs to be a capable system to be able to contribute properly to the process. This where the costs   really start to escalate. Thankfully, solutions do exists and you do not have to physically go somewhere else either.

There are good renderfarm that operate through the Internet and offer you prices based on how much processing power you will need. The calculation is done on the basis of per Ghz of processing power required by each renderfarm. And you do not have to worry about the types of rendering they support because integration is provided for all major softwares and their rendering types. This includes Maxwell render, mental ray, v ray, final render, and vue, just to name a few. All major softwares like 3D Max, Maya, Blender, etc are fully supported.

Do you want to learn more about hidden forms, how you can see and understand ordinary everyday things around you? Do you want to know more about the history of interior design? What about the 3D graphic space? If your answer is yes, come visit the Library and check read these titles in our Design Collection.

1000 bags, tags & labels : distinctive design for every industry NC1002 L3 E37	American visual culture NX503 R261	Comic book design NC1764 M654	Creature features : draw amazing monsters & aliens NC1764.8 M65 M385
Design meets disability NK1110 P982	Elemental magic : the art of special effects animation NC1765 G475	Figure drawing for dummies NC765 O41	The fundamentals of interior design NK2110 D647
The fundamentals of product design TS171 M877	Goblinoids : how to draw and paint goblins, orcs and other dark creatures NC825 F25 P985	Hidden forms : seeing and understanding things TS171.6 C642	History of interior design NK1710 I65
I miss my pencil : a design exploration NK1510 B712	Limited edition : prototypes, one-offs and design art furniture NK2231 L911	Mass production TS171 M414	Material thoughts TS171.4 B815
Office architecture + design NA6230 M551	Patricia Urquiola NK1452 Z9 P314	Spatial design NA2765 E96	Three D : graphic spaces NC998.4 T531
Thunderbolt illustration NC1001 T535	Tiny houses NA7126 Z46	Virtual typography Z246 H654	Works in progress : graphics for visual presentations NC998.6 J3 A659

This one has been a long time in the making, but the preview pics are finally available. My first project for Orbx is nearing completion: 7S3: Stark’s Twin Oaks Airpark. It’s designed to fit seamlessly into the upcoming FTX NA Blue Pacific Northwest scenery, but it’ll stand alone as well.

If ever there was a small airport that captured the spirit of GA flying in America, this is it. From the official blurb:

Nestled in the rolling farmland of the fertile Willamette Valley near Portland, Oregon, Stark’s Twin Oaks Airpark is ideally located for sightseeing in the Pacific Northwest. The rural location makes for less traffic and a relaxed atmosphere, while providing an easy jumping-off point for flights to either the coast to the west, or the rugged peaks of the Cascade range to the east.

The scenery includes a large area of 30cm/pixel aerial photoreal terrain, featuring the various orchards, Alpaca ranches, and small farms in the area. One special point of interest is the massive Glacier rock quarry, located a few miles to the southeast of the field. It deftly shows the sim possibilities when high-resolution terrain mesh is matched with detailed and meticulously color-corrected aerial photography. The high-quality mesh also makes another appearance, in what is quite possibly a first for an FS airport: multiple elevations. Twin Oaks is carved from the side of a gentle slope, and as a result, the Starks’ house, garage, and two of the hangars are on a hill overlooking the rest of the field. Lead developer Bill Womack has obsessively researched and photographed the airport over the last few years, with the enthusiastic support of owners Bob and Betty Stark. We’re proud to offer the definitive sim rendition of one of Oregon’s aviation jewels.

Check out the preview pics here. And while you’re at it, have a look at the other releases planned for both North America and Australia.

For more Chyron videos, don’t forget to visit out YouTube channel.

This article is about process of creating 3D computer graphics. For information on the study of computer graphics, see Computer graphics.

3D computer graphics (in contrast to 2D computer graphics) are graphics that use a three-dimensional representation of geometric data (Cartesian) that is stored in the computer for the purposes of performing calculations and rendering 2D images. Such images may be for later display or for real-time viewing.

Despite these differences, 3D computer graphics rely on many of the same algorithms as 2D computer vector graphics in the wire-frame model and 2D computer raster graphics in the final rendered display. In computer graphics software, the distinction between 2D and 3D is occasionally blurred; 2D applications may use 3D techniques to achieve effects such as lighting, and primarily 3D may use 2D rendering techniques.

3D computer graphics are often referred to as 3D models. Apart from the rendered graphic, the model is contained within the graphical data file. However, there are differences. A 3D model is the mathematical representation of any three-dimensional object (either inanimate or living). A model is not technically a graphic until it is visually displayed. Due to 3D printing, 3D models are not confined to virtual space. A model can be displayed visually as a two-dimensional image through a process called 3D rendering, or used in non-graphical computer simulations and calculations.
Contents

3D computer graphics
Basic
3D modeling / 3D scanning
3D rendering / 3D printing
3D computer graphics software
Primary Uses
3D models / Computer-aided design
Graphic design / Video games
Visual effects / Visualization
Virtual engineering / Virtual reality
Related concepts
CGI / Animation / 3D display
Wireframe model / Texture mapping
Computer animation / Motion capture
Skeletal animation / Crowd simulation
Global illumination / Volume rendering

Contents

* 1 History
* 2 Overview
o 2.1 Modeling
o 2.2 Layout and animation
o 2.3 Rendering
* 3 Communities
* 4 Distinction from photorealistic 2D graphics
* 5 See also
* 6 References
* 7 External links