Programming experience changes the sense of beauty

I had a chat with a guy today who hates things that have no intrinsic meaning.
Say we have a directory structure like

episode - sequence - shot

and shot dependent files are under the 'shot' directory.
(I'm sure this structure is familiar with you if you are working in a vfx studio)

When we want a directory to put data that are common to all the shots in an episode. We can think of two directory structures for the purpose.

episode - sequence - shot
               - common

episode - sequence - shot
               - common   - common

The latter has two directories named "common". Outer "common" always has only one directory: inner "common". So essentially it's enough if we have only one common directory like the former example. Having two commons are redundant and it can make people feel intuitively ugly. But in real life creating two directory has a good meaning - if we have two commons, we can always assume there are three directories, one for episode, one for sequence, and one for shot. This assumption simplifies making tools a lot. It slows down directory access a little bit, slightly increases disk usage and traffic, but in most cases you can ignore them. It will also make you irritated if you access to common files manually, e.g. with windows explorer, but it is usually wrapped up by tools and it should be, so there's no drawback in that sense as well.

In general, it is better if there are smaller number of rules while making things well defined (i.e. not like, "we have everything in 'any data' direcotry".  In the above example "common" direcotry should have well defined sub-directory). As you start getting used to programming, you become finding simplicity more beautiful, and you starts understanding that removing simplicity just for removing redundancy has no sense because it means sacrificing functional beauty just for visual appearance.


Jun 30 added:

Good generalization and bad generalization. Good generalization makes you extend functionality easily,  bad generalization puzzles you with lack of information on what data it is about. If you have a fully generalized structure (directory structure, framework structure,  work flow structure etc.) and well defined layer on top of it based on your demand, you can prevent having 'any data' stuffs that all you know about is creation date, and the structure still has room for future extensibility.

Hand editing pouring water

Again from my friends project.
It shows how the tool lets you hand edit water pouring into a wine glass.
He says it was a 5 minutes work. Nice usage example.

http://www.facebook.com/sparta.project

You can see the result first, and the tool being used at 0:55.
The number of particles are still low and it looks blobby but you can imagine how the tool can be used and be evolved.

Wine Video from lyouta on Vimeo.


1) Simulate liquid by nParticle
2) Exports BIN files
3) Edit BIN files by Sparta
4) Import BIN files as Maya Particle
5) Connect Maya Particle to nParticle
6) Polygonize liquid
7) Render liquid


 By the way it succeeded in cloud funding today. Congrats.

Espresso Machine!

Finally I bought  one for myself. I'd been telling my friends to buy one since it's kind of big and expensive and it was best to have one at my friends apartment, but recent ones are smaller and cheaper than before.

Buy the way I started working at a CG production again. It's good to be in the CG world.

Espresso machine and cow tit cup