Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/xxinagvm/public_html/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 77

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/xxinagvm/public_html/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 87
October 2013 – daveleack.com

Month: October 2013

Stress Maps – Continued

If you read my previous post about stress maps, you’ll find I’ve put a link to a blend file in there.

Well, if you download that, then use the “Animated Bake” addon (http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Object/Animated_Render_Baker) to bake out the first hundred frames of the texture on the “wormy” object, then load the blend file linked below and plug the first one of those baked textures into the image texture node on the material on the “wormy” object, then take a look at the render output, you should see that the diffuse shader with the wrinkly normal map is only being mixed in where the bends occur and this is being driven by a shape key.

Basically (heh), there’s a driver attached to the “offset” value of the image sequence texture node in the material such that when the value of the shape key changes it does the maths: frameOffsetToUse = valueOfShapeKey * numberOfFramesIHave which means that given that the shape key goes from 0 to 1, you should get a frame range of 0 to numFramesIHave. This means that when the shape key is fully “on” you get the fully bent texture from the baked sequence, and when it’s fully “off” you get the fully relaxed texture from the baked sequence (plus you get all the gradiation inbetween).

Video Demo: http://youtu.be/69_aZf2fjgM

Link to second Blend File: https://docs.google.com/file/d/0BworKSfkE1_AaV9GbUtOUHU5M3c

Stress Maps – Interesting Stuff

I’ve been playing with Stress Maps in Blender.
Basically, what I’ve been trying to do is set up a texture such that faces which are squished are one colour, and faces that are stretched are another colour.
I just got this working quite neatly.
Now, I can’t explain why the blend stops have to be where they are on my gradient to make it go from black to (nearly) white on this level of squish and stretch, but I toyed with it for a while and it looks pretty good.

The next thing to do would be to unwrap the object to a nice UV layout, bake out each of the frames to a sequence, then load that sequence in as a texture in cycles, but use the colour value to blend between two different shaders/shader noodles.

Might be useful for wrinkles and suchlike.

Video Demo: http://youtu.be/YfXxZjw6djc

Link to Blend File: https://docs.google.com/file/d/0BworKSfkE1_AOHgwVUdmOWJ3Mjg

More bake sound to f-curves!



I love the “Bake Sound to F-Curve feature” in blender. Whenever I’m playing with shape keys or armatures I always end up doing something with sound.

I suppose then it’s a bit shameful that I’ve not yet figured out the frequency bands to create a good visualisation from. No matter, it’s funny enough with my hamfisted frequency selection.

I have been wondering though if the bake sound to f-curve function is still being worked on. I have no idea how much work has gone into it up to now, but I don’t remember seeing much happening over the past few releases on that front.

It’d be really nice to see it have some default values for attempting to pull out drums/melody/vocals which I’d have though would be pretty similar frequencies across tracks although I could be totally and unforgivably wrong on that.

I might take a look at some visualisation code. There must be some online that I could look at and see what bands they use…

Anyhoo, enjoy.

Music: “Interlude(Total Tea Time)” by Anamanaguchi
Textures: 3D Reference Face Loops by Athey on Deviantart (http://athey.deviantart.com/art/3d-reference-face-loops-141698442) and something else that I munged together from other sources.
Models: Me (but obviously the one on the left was heavily influenced by the loop layout in the original picture by Athey)


On Me, Blender’s Interface, Andrew’s Podcast, and Naming Things

On Me

I call myself a programmer, mainly because I often find myself writing software and enjoying it.
I also attended university to study software engineering, but I needn’t have done so in order to call myself a programmer.

With that out of the way, anyone reading this will know all they need to know about whether to trust my opinion on which terms are common knowledge and which are known only to programmers and computer scientists.
The answer of course is not to trust my opinion on that matter at all.

On the other hand, having been actively involved in programming, software development and other nerdy pursuits for many many years, I’ve seen lots and lots of User Interfaces.
I’ve seen UIs that start out looking crappy and hard to work with and never get any better.
I’ve seen UIs that immediately look useable but soon show themselves to be limited, finicky and annoying.
The block, I has been round it.

On Blender’s Interface

So it is with all of the above stated plainly that I declare that I do indeed, for the most part, love Blender’s UI (post 2.49).
Take from that what you will. A programmer overlooking flaws in a UI for very geeky reasons is certainly nothing new, but I also have other reasons that I don’t think are so geeky and are actually mostly based on usability. I shan’t go into them unless pressed but if you’re interested, they align neatly with those expressed by Sebastian König in this video: https://plus.google.com/110725366823695093673/posts/QhypqEYnZh6

On Andrew Price’s Podcast

I appreciate the frankness with which Andrew Price (http://www.blenderguru.com/) is approaching his issues with the UI in his podcast, I really really do. Believe me when I say that the frankness, is thoroughly appreciated.
What I don’t appreciate however, is the apparent lack of research into the problems that he finds, that leads him to conclusions that I would say are flawed, such as “I don’t know this word therefore it must be the wrong word or some archaic and obscure word that nobody’s heard before”.
So if I’m being honest, I’d take the criticism of the UI more seriously if the people doing the criticising would just hop over that first hurdle, look it up, understand it, decide *at that point* whether it’s the UI that’s wrong, or the user in that case, then take a more humble approach if required. It’s not surprising, given how I started the very first paragraph of this post that I absolutely don’t subscribe to the theory that the user is always right. It’s simply not true. Sometimes the user is wrong, and listening to them is fine, but acting upon their requests would also be wrong.

On Naming Things, Propaganda and Other Stuff

Now, indulge me for a moment while I enumerate the list of things that I *would* like to mention with respect to user interfaces, the idea of uniformity across packages and a few other things.

1. In my opinion, just because best selling package A does a UI element one way, doesn’t mean that’s the best way to do it and anyone who says that it does is peddling propaganda and should stop it right now.
“Best” is also a totally subjective term. It depends what you’re after. Which leads me on to…

2. Being the kind of guy that I am, I want the UI to be optimal with respect to speed, while retaining any elegance possible after that optimisation. Furthermore, and this is probably my nerdyness showing through, I hate using the mouse when it technically isn’t necessary. Compared to the keyboard I find it to be slow, inaccurate and basically overkill when I’ve got hundreds of key combinations at my fingertips that don’t require me to navigate to a point on the screen with an analog (roughly, you know what I mean) pointing device. Give me keyboard shortcuts. They’re fast, and work well for a lot of tasks.

3. If you have difficulty remembering what something does, the name should tell you, *but* and this is a big *but*, it should be the proper name. It should be a word that even if you don’t know exactly what it means at the time, that should you look it up in a dictionary, it would be so accurate and so close to the actual function that the button enables that there’s no ambiguity at that point as to what that button achieves.
If you take this standpoint and run with it, then yes your users may have to look something up once in a while, but probably only once, then they’ll know a new word, one they should probably already have known anyhow, they’ll know *precisely* what it means in that context, they’ll remember what it means I suspect, and they’ll perhaps appreciate the opportunity to learn more about the field in which they’re working by using your software.

4. If your software is built for working in a technically dense field i.e. there’s a depth to the knowledge required to fully understand the field that you wouldn’t expect a novice to intuitively grasp, don’t try to dumb it down too much unless you are *absolutely sure* that you won’t cut off access to advanced options and features.
It’s not a good enough argument to say that you shouldn’t, for instance, label a slider “normal” and place it within the “velocity” pane of the “particle” settings because a user wouldn’t immediately guess that that slider controls the “velocity” of a “particle” along the “normal” axis. That’s not good enough in my opinion, because the user WILL WANT TO KNOW THIS if they plan on using the feature. In this example, if the slider in question was simply called “velocity” or worse yet “speed”, how on earth would you define in which direction you expect the particle to travel?

5. As a user, have some respect for the options that have been given to you. The default settings may not be optimal for you. It’s highly unlikely that *any* set of default options would be optimal for everyone.
You are given choices however.
Look at the options.
Change them, try them out, save them if you like them.
If you don’t learn how to customise a piece of software in a very basic way like this, then you will be forever at the mercy of the software that you choose to use, and the way it presents itself by default.

6. Keep an open mind. If it takes a long time to get used to something, that doesn’t mean that it isn’t worth getting used to. I’ve often thought that cars would be easier to control with a joystick and buttons, rather than a wheel and pedals, but if I ever do learn to drive, I won’t say the wheel and pedals are dumb because I don’t know how to use them right away. It takes time to learn things, but if they’re worth learning, you’ll be glad you spent the time.

In summary

I’m a fan of the Blender UI. I find that it allows me to work really, really quickly on most tasks and doesn’t often slow me down on anything that I can personally think of a better way of doing off the top of my head. I’ll accept that it’s tough to get into, but you know what? CG is a pretty technically complex topic.
I didn’t expect it to be super easy to do straight off the bat with no prior knowledge at all.

*Goes off to mumble grumpily about this sort of thing*