• # Composition 101: Balance

Visual Arts

In physics, Balance is that point where a specific distribution comes to a standstill. In a balanced composition, all elements are determined in such a way that no change seems possible. The piece must give the feel of steadiness, otherwise, it will just seem off.

Rudolf Arnheim, in his Art and Visual Perception book, stands that there are 3 elements to balance: shape, direction, and location. He also says that in the case of imbalance “the artistic piece becomes incomprehensible […] the stillness of the work becomes a handicap”. And that’s what gives that frustrating sensation of frozen time.

In this simple example, you can see all this. Having the sphere off center gives the sensation of unrest. The sphere seems to be being pulled to the corner almost. It’s if like an invisible force is pulling it from the center. These pulls are what Arnheim calls Perceptual Forces. And with the sphere in the center of the walls, you have the sense of balance, where all the forces pulling from the sides and corners of the square are equal.

Returning to physics, we can say that when talking about Balance the first thing that pops into our heads is Weight. And that’s what it is all about, what we think. Because, as I said before, perception is just the brain processing images. So, if when we talk about balancing something we think of weight it definitely has to have something to do with it in art, right? Exactly.

Arnheim talks about knowledge and weight in balance referring to the fact that anyone who sees a picture of a scale with a hammer on one side and a feather in the other knows that the first one is heavier. If the scales are perfectly balanced it will just seem off. But balance does not always require symmetry, as we might tend to think. Isn’t equilibrium that brings balance. If the scales tilt to the “correct” side (the hammer) perceptual balance would have been achieved.

In Art, as in physics, the weight of an element increases in relation to its distance from the center.

So an object in the center can be balanced by objects to the sides, and objects on one side of the frame must be balanced with objects in the opposite location. But this doesn’t mean that the objects must be the same (symmetry and equilibrium), for there are properties that give objects weight besides their actual apparent weight.

SIZE. The larger the object, the heavier.

COLOR. Red is heavier than blue. Also, bright colors are heavier than dark ones.

ISOLATION. An isolated object seems heavier than the same object accompanied by smaller ones all around it. Arnheim puts the moon and stars as an example here.

SHAPE. Experimentation has shown that different shapes affect the way we perceive weight. Elongated, taller, figures seem heavier than short ones (even though they both have the same area size).

To expand on this matter I recommend you to go back to the books I will reference in the sources down bellow. Even though these are really simple examples, I plan to move on with this theory applied to environment art.

The whole take on Balance gives all the world building process a solid base stone. Embracing these principles will help you understand and better plan object placement in your scene to avoid the feared feel of steadiness Arnheim warned us about.

There is still a bit more to explain about Balance so I will be expanding a bit more on this matter in future posts.

Thumbnail art:  Madame Cezanne in a Yellow Chair, c.1891 - Paul Cezanne

Sources:
Arnheim, Rudolf (ed.) Art and Visual Perception. A psycology of the creative eye. University of California. 1954.
Bang, Molly. (ed) Picture This. (1991)
Baker, David B. (ed.). The Oxford Handbook of the Psychology. Oxford University Press (Oxford Library of Psychology), 2012.

Report Article

## User Feedback

Posted (edited)

This is a great article and what @gdarchive writes is really important. I would like to complement the article because the stated is also true for orchestral music composition. Of course it's always up the to artist to decide how they want their piece to feel like. Imbalance is not by all means a bad thing, although it's usually what you would try to avoid. It's important, however, that the artist is aware of what techniques exist and what set of emotional experience they lead to for the listener.

So, let's image, you got that really strong cello line which starts in the lower registers and then climbs all the way up to where the strings are almost screaming. Now your cellos are located in the front right of your orchestra. As said, we keep the tone but vary the color in our example here. So there're three things we would try to balance here: Texture, tone and direction. I will try to explain what each of them will do. And I will try to show why full balance is best in most cases but is not always what you want.

So let's start with direction, or simply speaking "stereo". Of course, to balance a sound that comes from the right, we need to add one coming from the left. Be sure to not pick an instrument that isn't too much in the rear because this would lead to even more imbalance. A good choice would be a clarinet, maybe a bass clarinet or even the whole section of them. To keep our balance, we would have them play in their lower registers as well.

Now we only have those low notes but maybe want to balance up to the higher octaves. Be sure, though, to keep them very silent as the high cello notes, that will come later, need to remain the strongest voice. As we are going for balance and don't what to set any counter voice right now, we need to carefully pick a matching color, something similar. Horns go very well with clarinets and would also get us some output from the rearer part of the orchestra. But maybe we want to swap the supporting colors to - again - gain more balance. Maybe the middle registers of the trombones would do when played piano in a very soft and fine tone. To accomplish the same sort of balance for the cellos we could use the bassoons but as we decided to swap the supporting parts, we might be going better with the lower registers of the violins. Remember, you can almost always intermix instruments of the same section together.

We should now already have quite some balance in our piece. At least when it comes to color and direction.

So let's go over to the texture. As of now, we only have a melody. The question we need to ask ourselves is: Do we want to support, complement or enforce the melody? Enforcing would mean that all the other instruments we have so far would either play pretty much the same the cellos do, or express a counter melody. This would give us a very powerful melody that is well defined and strong in its expression, no matter what the articulation tells.

Complementing would mean that we try to fill all the pauses and silent notes the cellos play in their main melody. This would take away some rest but still establish some sort of balance in such a way that they would be alternating and taking turns, if you wish.

Supporting the cellos would mean to let the other instruments almost play straight chords, either allowing the cellos to break out of them every now and then, or to re-harmonize everything the cellos do (which is harder to do but creates a softer and more fitting overall experience).

I won't go too much into percussions here but remember that they also consist of very different colors and tonal heights. Use them as such! That is: Having very fast bass drums under very quick double basses will lead to nothing more but audio porridge while placing a few cymbals or triangle hits over the double basses will create interesting rhythmic patterns.

Edited by ptietz

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 0
• 0
• 4
• 3

• 13
• 18
• 15
• 11
• 9
• ### Similar Content

• Hello,
It's my first time posting anything on this forum but I thought it was time to step up my knowledge about gaming theory and game design if I want to get into the industry. I have a lot of ideas of games that would be great. I write everything, draw characters, right stories, design and think about gameplay mechanics etc. A day I had an epiphany about a fighting game with Sekiro's gameplay. I know of course there would be a lot of problems with...camera being wonky, the guard bar must be readjusted, and the major problem would be the deflect spamming. But personally I think that with some adjustments, great character, some risk reward (like you can cancel an attack to throw of your opponent or if you try to deflect and miss your deflect you get punished for 'spamming') mechanics, It would be an engaging experience. It would be intuitive, easy to learn hard to master and mind games.
Of course, I write all of this because I intent to begin digging a bit deeper with that idea. If any of you think this is crap or it is the wrong section of the forum feel free to report me. Sorry if it is the case ^^.
Hope it will interest anybody.

• Concept for Delayed Shots in a Fast Paced Shooter

The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?

• Hi,
I used the 3D shortest distance between two line segments algorithm at this website: http://geomalgorithms.com/a07-_distance.html#dist3D_Segment_to_Segment
This function in Python is checking if two capsules intersect. I checked the algorithm from the website and it seems to work. I tried implementing an epsilon to help with floating point error, but I don't think I did it correctly. Help would be much appreciated.
def check_intersection(particle1,particle2): decimal.getcontext().prec = 100 epsilon = 2**-52 #implement epsilon small_num = 0.00000001 #number to check if they're closely parallel u = particle1.get_s() #s1 v = particle2.get_s() #s2 p0 = particle1.get_p1_position() #P0 q0 = particle2.get_p1_position() #Q0 w = np.array([p0[0]-q0[0], p0[1]-q0[1], p0[2]-q0[2]]) #distance from 2 particles from their p1's a = u[0]**2 + u[1]**2 + u[2]**2 #dot product of u*u. Always >=0 b = u[0]*v[0] + u[1]*v[1] + u[2]*v[2] #dot product of u*v. c = v[0]**2 + v[1]**2 + v[2]**2 #dot product of v*v. Always >=0 d = u[0]*w[0] + u[1]*w[1] + u[2]*w[2] #dot product of u*w e = v[0]*w[0] + v[1]*w[1] + v[2]*w[2] #dot product of v*w D = (a*c)-b**2 #always >=0 #Set all to defaults sc = sN = sD = D #sc = sN / sD, default sD = D >= 0 tc = tN = tD = D #tc = tN / tD, default tD = D >= 0 if D**2 < small_num: # checks if SCs are parallel sN = 0.0 # force using point P0 on segment S1 sD = 1.0 # to prevent possible division by 0.0 later tN = e tD = c else: # get the closest points on the infinite lines sN = (b * e) - (c * d) tN = (a * e) -(b * d) if sN < 0.0: sN = 0.0 tN = e tD = c elif sN > sD: # sc > 1 => the s=1 edge is visible sN = sD tN = (e + b) tD = c if tN < 0.0: # tc < 0 => the t=0 edge is visible tN = 0.0 # recompute sc for this edge if -d < 0.0: sN = 0.0 elif -d > a: sN = sD else: sN = -d sD = a elif tN > tD: # tc > 1 => the t=1 edge is visible tN = tD # recompute sc for this edge if (-d + b) < 0.0: sN = 0.0 elif (-d + b) > a: sN = sD else: sN = (-d + b) sD = a # division to get sc and tc if abs(sN) < small_num: sc = 0.0 else: sc = sN / sD if abs(tN) < small_num: tc = 0.0 else: tc = tN / tD # difference of 2 closest points dP = np.array( [w[0] + (sc * u[0]) - (tc * v[0]), w[1] + (sc * u[1]) - (tc * v[1]), w[2] + (sc * u[2]) - (tc * v[2])] ) # dP = w + np.multiply(sc,u) - np.multiply(tc,v) #S1(sc) - S2(tc) close_d = (math.sqrt(dP[0] ** 2 + dP[1] ** 2 + dP[2] ** 2) ) # closest distance b/w 2 lines # check if distance <= radius * 2, if so, INTERSECTION! diff = abs( close_d - (2*S_RADIUS) ) if(diff <= epsilon): return True else: return False
• By bandages
So, in real life, incoming dot normal at the silhouette is always 0.  With smooth shaded meshes, it never is, not naturally, not outside of contrived situations.  (Not with flat shaded meshes either, I guess.)
And incoming dot normal is one of the bedrocks of CG.  Probably the equal of 4x4 matrix multiplication.  Problems with silhouette normals show up in Fresnel, in diffuse lighting, in environment mapping....  everywhere.  But I can't really find anybody talking about it.  (Maybe I'm not Googling the right terms.)
Obviously, the problem decreases as poly count goes up, eventually reaching a point where it's dwarfed by other silhouette problems (like translucency or micro-occlusion) that CG doesn't handle well either.  But, if I'm reasoning correctly, normal maps don't improve the problem-- they're as likely to exacerbate it as improve it, and the exacerbations are, aesthetically speaking, probably worse than the improvements are better.
I've tried playing with crude fixes-- basically, rotating normals toward incoming by a percentage, or of course clamping incoming dot normal (like we all have to do) to prevent it from bending behind the mesh.  Nothing I've tried looks good.  I suppose the best option might be to rotate normals to perpendicular to incoming at the silhouette and then interpolate to the nearest inflection point  of something like screen space depth to preserve curvature, but the math for how to do that is beyond me, and I'm not sure it would look any better.  Or maybe, instead, somehow, adjust the drawn silhouette to match the silhouette defined by incoming dot normal?  Not even sure how that would work, not if the normal was pointing away from incoming.
I don't know-- is this a solvable problem?  Has anyone tried other stuff and given up, pursued anything that was promising but too expensive, anything like that?  Are there any papers I'm missing?  It's really surprising to me that I can't find anyone else talking about this.
(Apologies if I chose the wrong subforum for this.  I considered art forums, but I felt that people frequenting the programming forums would have more to say on the subject.)
• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?
×