I’m suspecting this has to do with graphic memory allocations.

Found a great article about VM tracker here:

• http://liam.flookes.com/wp/2012/05/03/finding-ios-memory/

And a no-less-informative article from Ray Wenderlich, here:

• http://www.raywenderlich.com/23704/demystifying-ios-application-crash-logs

As in the Ray Wenderlich article I see process/type as unknown/unknown (how elegant). However I don’t get jettisoned.

Instead I get [vm] under ‘reason’ and the statuses of my app are:

(audio) (frontmost) (resume)

So, given that texture allocations are a likely reason for memory shortage, I think I’m on the right track. Reading a stack overflow item, I also find that the number of pages used by my app at the time of crash looks dangerously similar to what I get, so if you feel worried you may be gobbling too much memory, have a look here for comparison: http://stackoverflow.com/questions/13152502/my-app-crashes-and-closes-down-and-there-is-very-little-information-as-to-why

Yea that’s it for me so much for the exciting stuff.

The shadow volume generated by the casting triangle consists in four planes. The first plane contains the casting triangle. The remaining planes include one edge each, and are parallel to light rays.

So, a method to determine which part of the target is shadowed consists in performing a CSG operation between the target and the four planes.

So the problem can be reduced to plane / segment intersections.

Intersecting a segment and a plane:

Intersecting a segment A,B with a plane P,n, where n is the plane’s normal and P is any point on the plane

def xSegmentPlane(A,B,P,n):

AB = vector(A,B)
AP = vector(A,P)

k = dot(n,AP) / dot(n,AB)

if k < 0 or k > 1: return None

u = mul(AB,k)
X = add(A,u)

return X

Of course, ‘vector’ evaluates the corresponding vector given two points, ‘dot’ is the dot product, ‘add’ is the sum of two vectors, ‘mul’ multiplies a vector by a number.

So, the intersection test per se isn’t difficult. Annoyances will arise, however:

• If dot(n,AB) is zero, an error will be generated. Additionally, imprecision may arise when dot(n,AB) is near-zero. At first it appears that such imprecisions are not important, but later we will see that these imprecisions can result in ‘holes’ in the generated geometry.
• Likewise, imprecisions may arise when k is almost zero or one.
• We’d like to know which side of the plane A and B are. This is given by the sign of dot(n,AP) and dot(n,BP). Theoretically, if A and B are both on the same side of the plane there will be no intersection. However, we can verify that, given the above imprecisions, the method may return an intersection with A and B (evaluating to being) on the same side, or may return no intersection even though A and B evaluate to being each on either side of the plane.

So, if you read somewhere that performing CSGs is difficult, that would be one of the reasons: while the above test looks neat and simple, it does not take into account numerical inaccuracies, nor does it provide all the information we need. A better intersection test should return the following:

• Nothing. If the plane does not intersect the segment.
• An intersection. If there is one. Plus, it will tell us whether the intersection is ‘special’ (the plane touches A or B) or ‘ordinary’ (a point along AB, different from A and B )
• The segment itself, if the plane contains it.

If we don’t take these into account, a trivial triangle/plane intersection test will result in missing or degenerate triangles.

[to be continued...]

A common problem between all these is the overhead involved in processing triangle/triangle (t/t) pairs. For example, to perform self shadowing over 1,000 triangles, you might process 1 million pairs.

Let’s not process 1 million pairs.

In context: using python; the balance is towards clarity and concision since we are not aiming at realtime (yet).

There isn’t a super-abundance of zero-nonsense explanations about how to do geometry on the computer so I’ll probably open an A to Z with useful recipes.

The original shadow casting spike should be a pre-requisite to this article, maybe I’ll find a moment to introduce this later.

Previously I was working on a ‘shadow gun’ casting shadow particles. I used a grid (in light view) to optimise processing. It works quite well. To cast a shadow particle, identify the grid slot you’re casting to, recover the list of candidate triangles. Before shooting rays, move the triangles to light view then, for each grid slot, list all triangles intersecting the slot (I have not verified whether using triangle bounds or actual geometry to intersect the slots would be faster).

Now writing a ‘shadow cutter’. Compared to shadow particles there may be less work (no more shooting rays) but a grid may not perform well. What bothers us here? With the grid based method each triangle may cover several slots. But, rather than asking “would a ray intersect triangles T0, T1, … ” we are now asking, “would T0 intersect T1, T2, …”.

Choosing an optimisation strategy

Quadtree

I tried using a quadtree to sort the input. The advantage compared to a grid would be that, we can retrieve candidates without having to search for duplicates. Each node is instantiated as follows:

• If MAX_DEPTH is reached, add all triangles as leaves.
• Otherwise, consider the bottom-left, bottom-right, top-left, top-right quadrants implied by the current node and sort triangles accordingly to get the branches.
• Triangles that do not fit into any quadrant are added to leaves. This disposition may be imperfect in some ways; the advantage, however, is that each triangle is represented once in the tree (no duplicates)

Add a new material

scene.objects.active = myObject
bpy.ops.object.material_slot_add() # add a material slot to active object
material = bpy.data.materials.new(“gold”)
# assuming the object previously had no material slots, otherwise search for empty slot
myObject.materials[0] = silver

Create an object

foo = bpy.data.objects.new(name=”foo”, object_data = data)
scene.objects.link( foo)

Create a mesh

mesh = bpy.data.meshes.new(“mesh”)

Populate using from_pydata(vertices,edges,faces). For example:

verts = [ ( 0,0,0), (1,0,0), (1,1,0), (0,1,0) ] # a square
edges = [] # usually not needed, but, e.g. [ (0,1), (1,2), (2,3), (3,0) ]
faces = [ (0,1,2,3) ] # connecting the square corners; can use 3, 4 points or more!
mesh.from_pydata(verts, edges, faces)

Duplicate an object

Method 1: bpy.ops.object.duplicate()

• bpy.ops.object.duplicate() – duplicate currently selected objects (deep copy)
• bpy.ops.object.duplicate( linked = True ) – duplicate currently selected objects (shallow copy – mesh and other properties should be shared).

@see make an object the only active, selected object

Method 2: create a new object and duplicate properties

The disadvantage of this is that duplicating all properties can be hard.

@see create an object

Get the current scene

bpy.context.scene

Get the scale (‘unit’) of the current scene

scene.unit_settings.scale_length

Make an object the active, selected object

Assume an object named X

for k in bpy.data.objects:
    k.select = False
X.select = True
scene.objects.active =  X

Set an object’s location

object.location = (x ,y ,z )

You’ve been toying around with the python console and/or adding quick scripts as text nodes in blender files, you wish to reuse your scripts, but add-on creation feels intricate? Read on.

However, if you’ve created a great script that you’d like to share with the community, you need to create an add-on instead (checking existing add-ons in the blender scripts folder is the way to go).

Move your script to py files

The idea here is to bypass time consuming integration steps, while retaining basic flexibility:

• Don’t create an add-on.
• Don’t create a button oriented UI
• Keep scripts in *.py files (not in a *.blend file)

So, let’s say we have a script under /Users/Dick/foo.py, how can we call this from blender? The (quick and dirty) solution is to create a text node in the blender file, and add the following code:

# import sys and foo modules; append our script dir to the python path
import sys, imp
sys.path.append(“/Users/Dick”)

# import our py file as a module; reload to make sure recent changes
# to the script are considered
import foo
imp.reload(foo)

# call a function in the script file
foo.myFunction()

Then, we can invoke our script by hitting ‘run script’ in the text window.

We don’t want to type these lines over and over again. So we can add them as part of the default startup file. Just do File > Save User Settings.

Keep in mind that this will overwrite the startup file with whatever’s in your workspace (so, adding the quick and dirty ‘script runner’ right after opening blender is a good idea).

One of the most basic choices in game design is camera management. Choosing to create a game in first, third person view, deciding wether cameras will be fixed or not, these are choices directly impacting processing cost (GPU time, if you want).

Put bluntly:

*** It takes very powerful hardware driving well optimised rendering engines to correctly display large amounts of painstakingly detailed artwork with a great depth of field. ***

In a typical scenario not all these are available;  I orient my review towards “optimisation strategies” which directly encompass artwork and level design. The key idea is that good game art is a lot easier when designers, artists and programmers are willing to designate an area of interest. And as we’ll see, focus needn’t be constant throughout the gaming experience. So we can have everything (detailed characters, pretty environments, atmospheric scenes etc…) and do everything just right, but in most cases we can’t have everything at the same time.

First person games

The problem with first person cameras is that they easily develop perspectives which are deep and wide at the same time. Typically this drives savvy designers in either of two directions:

• Dungeons and Corridors. It is no coincidence that the first FPS games had so many dank corridors. In a best case scenario all that’s left two draw is walls, ceiling and a few NPCs.
  (Doom, image found on gt4v.com)
  .
  What’s more, dungeons and corridors can be mapped on a grid, so you don’t really need a level editor. Heck, you could map your levels in notepad using a fixed size font.

• Foggy settings. Using fog to limit depth of field is a trick that never grows old (honest). While serious 3D programmers will look down on it, fog rarely makes a scene look bad and efficiently limits depth of field; within limits, it also produces visuals that scale down well over less hardware.
  This time honoured trick predates graphic cards.
  
  (Ishar: legend of the Fortress on Atari ST – image found @ mobygames.com)

Isometric views, with or without perspective

With first person games, we start with a problem to which we need to find solutions. In contrast, isometric views (forcing the camera to look 30 to 60 degrees down), are less demanding:

Diablo – image found on rampantgames.com

The obvious reasons being:
(1) the distance from the camera to each object is constant (or mostly constant if perspective is added).
(2) here we don’t need walls everywhere (!) since the camera angle naturally restricts the view to a very small part of the map.

So, this is inherently a savvy approach and there is hardly an excuse for messing up (displaying low definition artwork) – since isometric views are nowhere near as lively, dynamic and complex as first person views.

Platforms versus continuous terrain

Platforms are an awesome device, both for game artists and level designers. In short, platforms are a game convention allowing a very idiosyncratic (meaning, specific to games) form of ellipsis: using platforms relieves everybody from the need to consider ‘intermediate space’ that is either non playable or non interactive.

• Less load on the GPU
• Easier design. Often the junior artists I work with (and myself) find it difficult to design models which aren’t self-contained. It seems that there is an implicit requirement to (mentally) break down continuous environments into separate elements, then later reverse the process and design continuities. Good platforms need visual framing yes, but that is, apparently, more straightforward.

Walls may also be used to delimit playable areas. But walls increase fill (more GPU time) and create design issues – with a fixed camera for instance, the player can’t see behind walls which creates (tractable yet time consuming) problems with either first or third person views.

Platforms seem to work with any kind of view – isometric, first person, third person – the effect is the same. All you need (if anything) is a nice background to act as filler.

 Super Mario War – image found on hartwork.org

Platforms are no worse than fog. They are a device which at times may seem cheap. In the meantime, platforms create wonderlands. Floating islands and castles (lost in the fog).

Freeze!

The obvious (lame) solution to warrant awesome game art is to freeze the camera. Two advantages:

• Everything is under control. You get the best shots and you can pre-render artwork for *hours*.
• Your GPU programmer will resign so you can hire another artist instead (yay!)

Okay, this is extreme. Still, many games take significant steps in this direction:

• Fixed angles. Even with an isometric view, using fixed cameras (instead of a turntable style approach) will yield a significant increase in performance (and/or art quality). Also (and although some players readily dislike it) using fixed cameras affords increased usability (at the cost of additional design).
• Games on rails. They’ve been doing it since game arcades, and they’re still doing it. Putting players on a rail pushes the idea of linearity to the extreme.
  Non linear gameplay is a deep concept, but when it comes to media production, it is a thorny road as you’re practically scattering resources and incurring the risk of producing a lot of artwork that no single player will fully experience.
  Providing a linear story line and defining artwork along a clear path, to the contrary, ensures that all resources converge towards a designed gaming experience. That rail games (however shallow) still encounter concrete success is no surprise ( not convinced? lookup Rage – ID software! – or Temple Run).

Arenas 

Arenas offer a choice that is (in appearance) even more limiting than putting games on rails – with an arena based approach, the camera needn’t be fixed; since gameplay is confined to very little space, it is no longer a problem.

Unreal’s mobile flagship, Infinity Blade, is a well disguised arena game: between fights ‘gameplay’ is on a rail – actually there’s no interaction but since the scenes aren’t pre-rendered the transition is seamless (‘we’re still playing but we’re not!’). During fights the opponents do not move (oh wait, the second half of every fight takes place 3 meters forward, right?).

I attended a post-mortem which leaves very little doubt as to how they fit the pretty artwork into a mobile format:

• Use cards (somewhat-elaborate-yet-to-cut-a-long-story-short-pre-rendered-backgrounds).
• No more than 2 characters on-screen.
• 2048 x 2048 textures, one for each character, including the complete UV unwrap (body, head, armour and weapons).

Multimodal interaction

If we look at the approaches I described so far, all but arena oriented games share a common problem: how can we express characterisation when we don’t get a chance to display detailed characters in closeup?

So, one answer may be ‘using cut-scenes’; but (maybe my own bias), this tends to frame dramatisation ‘outside gameplay’. There is an approach, typical of JRPGs, which can give you the best of both worlds.

Yes! Regular navigation (isometric, FPS style or other) affords developing scope – the sense of being immersed in a large world – while arena based interaction (combat or conversation) allows maxing poly count and texture detail (isn’t it obvious? :D ) to reinforce characterisation.

(images found on epicagames.com)

Conclusion

From a technical point of view, methods are definitely available to help display (and fit into memory) beautiful vistas with a great depth of field:

• Mip-mapped textures
• LoD (level of detail) nodes
• JIT (just in time) pre-rendered backgrounds
• (and more…)

The Elder Scrolls: Skyrim – personal screenshot found on j-u-i-c-e.hubpages.com

Technical optimisations can be applied regardless of target hardware. What’s happening is that you keep more GPU time for drawing the foreground and I think it’s obvious even in the pretty screenshot above.

In the meantime, I think the approaches I described above are here to stay. Only the most ambitious projects running the latest hardware can deploy the production muscle needed to do everything perfectly at the same time. So I guess the main idea behind my article is that any project can achieve a balance between production cost, visual quality and rendering complexity.

Copyright notice: none of the images in this article were produced by me. These images belong to their respective owners.

For games, exporting bone transforms is often more efficient than exporting animation curves.

Most animation data is modeled using Actions; however, data related to the current pose (for an Object using an Armature) is exposed via Object :

x = D.objects['armature']

bone = x.pose.bones['root']

bone.matrix # transform
bone.location # just the location.

(‘D’ is a shortcut for bpy.data).

Actions

In Blender 2.63, retrieve actions using:

anAction = D.actions[name]

Action.fcurves contains animation data per channel. The grouping of fcurves (in the blender UI) is cosmetic.

• FCurve.data_path refers the data being animated using a given animation curve. This could be something like ‘pose.bones["neck"].scale’. Several curves may use the same name (e.g. scale has 3 components so there may be 3 curves with the same data-path)
• FCurve.keyframe_points refers keyframes for a given curve. The main property of a Keyframe is co, which includes the time offset co.x (the frame) and property value co.y

References (Blender API docs)

• bpy.types.Object
• bpy.types.Pose
• bpy.types.PoseBone
• bpy.types.Action
• bpy.types.FCurve
• bpy.types.Keyframe

Python

# get a reference to the 1st marker in action 0
m = bpy.data.actions[0].pose_markers[0]
m.name # marker name
m.frame # frame for this marker 

References

• Action
• TimeLineMarker

Fundamentally, the solution is the same (see here). I added a new build rule with the described parameters:

Matching rule

*2.5x/assets/*.blend

So, all 2.5x / 2.6x files go under a ###/2.5x/### folder (depending on the file version, I run either Blender 2.49b or Blender 2.6x ). This rule matches a fragment of the path, so it will still work with multiple projects, e.g. :

• …/foobar/2.5x/assets/foo.blend,
• …/superfungame/2.5x/assets/funasset.blend
• (…)

Script invocation

/Applications/blender-2.6x/blender.app/Contents/MacOS/blender -b “${INPUT_FILE_PATH}” -P /Users/xxx/svn/blender-scripts/ox3ich/ox3ich_main.py — “$INPUT_FILE_DIR/../../build/$INPUT_FILE_BASE.blz”

ox3ich_main.py is the script used to export assets, so maybe you’ll invoke a COLLADA export script or such.

Output:

${INPUT_FILE_DIR}/../../build/${INPUT_FILE_BASE}.blz

This just matches the output (in script invocation, specified after “–”, note this is a custom script rule, Blender lets you pass custom parameters after “–” )

Caveats

While testing remember XCode may not re-run the script unless the input file has changed (even if the previous invocation failed).

Blender 2.5x/2.6x has a somewhat complex script registration mechanism. When integrating with XCode, however, what tends to happen is… …nothing. So typically you have a script FOO.py, which is designed to run as a registered blender script; then you should pass a bootstrap script BAR.py to drive FOO when running Blender from cd. This is more or less what I did.

One more thought on this is that, all considered, if the main use of your script is exporting via cd, you don’t need to learn about script registration, you just write your export script and feed it to Blender via the command line.

Note: With a little trickery you can write scripts that will run on both blender 2.5x and 2.63 and later; I’ll cover the changes later. Or you can read the NGons and tesselated faces gotcha (from blender.org).

Maybe it’s the weather; or maybe I’m bored. I was just thinking – why am I still doing all my Objective C coding with XCode? Is it that good? Meeehh.

Seriously, I used to type less code. In fact I was annoyed enough with your average off the shelf IDE that I used to write all my code using my own tools. While it’s gonna take more than a rain check for me to pick up ee-ide and integrate with ObjC, there’s something left from this bygone era – the urge to meta-program.

Sidekick wanted

So putting aside the more interesting question (what do I want to analyze? What would I use meta-programming for?) I found myself wondering once again: if not java, what am I supposed to write my utilities in?

I’m pretty used to Objective C by now, but it’s not the kind of language that I want to use to write rough and ready utilities. Python comes to mind. I have this unqualified connection with Python: using it to write our blender scripts, suffering from the lack of straight OO semantics, irked by the lack of typing and compile time checking, amused by the syntactic sugar (e.g. sequences), encouraged by the no-nonsense, generous approach to standard libraries.

I prepared a bunch of references to skim through. I think I’ll be going old school, approaching utilities with the command line before (hopefully) integrating with XCode.

Yea that’s it for today. My refs are below. Just basic stuff.

References

Varied tutorials for working with files

• Working with files in Python (dream.in.code)
• Working with file objects (diveintopython.net)
• Top 4 ways to work with files in python (python.about.com)
• Working with files (marakana.com)
• The pathutils module  (voidspace.org.uk)

And some n00b references to run our py scripts:

• Run a python script in Mac OS X terminal (beckism.com)
• Running python scripts on Mac OS X (theatre of noise)