Thanks for all the positive feedback we’re had on the demo video! Due to the interest shown I’ve started a documentation wiki and written a substantial amount of info about the less-than-obvious features that are included.  Its more of a technical reference so everyone working on our project knows how to use the generator than a straightforward tutorial.  If anyone is interested in writing/screencasting a tutorial I’d be happy to offer help when I can!  We’ve also released an example blend file with a simple setup.

Documentation Wiki

Example Blend File

In addition another RNA update broke the script just hours after we released it, so I’ve published an update here! Note its still a script which needs loading in the text editor rather than an add-on.  Tested with r31726.

So Bassam’s been away in Bulgaria for a couple of weeks and Henri and I mostly had the studio to ourselves.  I’ve been working on a mushroom generator for a couple of timelapses – not that tube will be filled with glowing mushrooms, more that we wanted something half way between the ivy generator and a fully fledged particle system.  Henri modeled some funky mushrooms and together we spun together a quick demo video just to show off some of the effects that are possible, and to exercise our fetish for indirect lighting and luminous pink.

Mushroom Generator Blender 2.5 from Henri Hebeisen and Josh Wedlake on Vimeo.

The script is still heavily in development but if you like alpha stuff and you’re happy to do your own debugging, then feel free to download and run.

Download – UPDATE Fixed for r31726 and up

Essentially you need to model a couple of mushrooms (just a generic term – you can model flowers or trees or robotic arms) with some shapes for their animation which will be blended sequentially, some shapes for random variation, some shapes in which they bend up the y axis, a painted vertex group for shrinkwrapping the base of the mushroom, all scaling and rotation applied and the origin at the base of the mesh.

above: creating the shapes for auto animation

above: adding manual animation to a mushroom

You also need a target mesh which has nice topo (ideally no elongated tris or nasty convex quads), optionally painted vertex groups named OBmymushroomname… and MAmymushroommaterial… to control the distribution of your various materials and different object types, optionally a limit vertex group (ie only faces within this will receive mushrooms), and a lot of patience.  Select the mushrooms then make the target active and tab into edit mode, select the start face(s) then hit spacebar>Mushroomer (remembered to run the script first).

above: mission control, godspeed

Adjust the settings and hit go.  I suggest you run blender from the terminal so you can watch for progress and any hangups.  You might well want to abort if it starts slowing right down from too many mushrooms.

above: when its done

Development on this script has been a bit of a nightmare.  Currently it is not possible to create multiple linked objects and have different shape key and material animation blocks on them without having to duplicate the mesh and/or material blocks (thus unnecessarily eating up huge amount of memory and removing the possibility to edit the mesh for one mushroom and have all of the update).  This is in the blender bug tracker as #23546 and #23547.  If they get fixed you can uncomment the deep data path keyframe adding and enable all the code for migrating actions to object level.  Another limitation which slowed development is that it is currently not possible to merge two actions into one.  This is necessary if you are moving mesh level and material level animation data back to object level.  Essentially you need to combine two actions into one.  Not only is this not possible, but its also not possible to copy an fcurve in its entirity, but rather python has to iterate through very slowly copying every handle one by one, and even this is susceptible to some bugs (not yet reported).  This is because the collection of fcurves is read only even though each fcurve itself if read/write.  I was also held up by bug #23532 which prevented me from doing the action block combining in the NLA editor, and for a short while by bug #23548 which caused blender to crash when creating new fcurves.  Finally the script can’t currently support animation data on the mushrooms’ materials due to bugs #23593 and #23594 – I’ve chosen to block this feature rather than risk an inescapable hang and data loss – uncomment those lines at your own risk!  Fingers crossed the devs will iron these out sooner or later and the mushroom generator will be running faster, with lower memory requirements, smaller file sizes and more stability!

Its also been a sad day today as we waved goodbye to Henri who is on his way back to France as I write.  Its been great fun working together for the last 2 months.  Luckily we’ll only be a stones throw apart when we’re back at our separate homes in Toulouse and London.  If all goes well we’ll be at the Blender conference this October as well.  Rest assured, the world hasn’t seen the end of the glowing mushrooms saga – I’m hope we’ll have another chance to work together soon!

Been meaning to post these for ages… from 4 or 5 weeks ago…

I’ve been modeling the train on and off when I’ve not been pythoning – don’t want to give too much away now, just to say that the model is going to be very high poly.  Most of the details are now complete but I still have all the big panels to go.  I’ve built a low(ish) poly base mesh which all of the details will be deformed to (using shrinkwrapped 2D lattices).  All of the side panels are modular so we can swap around the order for variations etc.  Thoughts gladly received.

Version française en dessous.

hi,

For the last few week, I’ve mainly done some modeling trying to add as much detail as I could so we can use the models in the various close-up shots we have on the tracks. I had to model various little objects to “populate” the scene. I also started the first texturing tests for all our various models. Until now, we’ve mainly modeled objects but we only have a few textures and materials because we were waiting to see how blender internal is going to evolve with project Durian. We were especially expecting to use the ‘material refactor’ which would allow us to have better shading. Unfortunately, with Brecht’s departure and all the other work on 2.5, the project seems to be stopped for the moment…

In this post, I’ll try to explain how I textured the concrete support of the tracks using material nodes.

The basic idea for this model is to have old and damaged concrete blocks, covered in oil. I started sculpting some cracks, details and broken parts. Here is the model before starting texturing :

The next step was creating two basic materials, one for the damaged parts and one for the regular concrete. i tried to use procedural textures as much as possible to avoid resolution problems. Then I painted a texture to tell blender which part of the model receives each material. Finally I mix everything in the node editor :

So far my concrete block looks like this :

It’s not bad but it’s not really realist. The next step consists of adding all the oil splatters. As I have two different materials, it’s easier to add these splatters using nodes. I’ve used an overlay mix to composite my generic oil map over my base material. By using the ‘mapping’ node, I could use the same map several times and play with scaling and rotation values to add variation.

Here is the final node setup for the concrete material :

And voila! this is a quick method for adding dirt to a material without having to paint a texture in gimp!

French version :

Ces dernières semaines, j’ai principalement fait du modeling pour le projet en essayant de détailler un maximum pour pouvoir utiliser les modèles dans les nombreux plans où l’action se situe sur les rails du métro. Il m’a fallu modéliser pas mal de petits objets divers pour ‘peupler’ la scène. Mais j’ai surtout commencé à faire les premiers tests de textures pour les différents modèles. En effet jusqu’ici nous avons surtout des objets modélisés mais très peu de textures ou de matériaux car nous attendions de voir comment le moteur de rendu de blender allait évoluer avec le projet Durian et notamment nous attendions de voir si nous pourrions utiliser le fameux “material refactor” qui nous permettrait d’avoir un shading bien plus réaliste que ce que nous avons actuellement dans blender. Malheureusement, avec le départ de Bretch et la sortie de la 2.5, le projet semble être remis aux calendes grecques…

Dans ce post je vais détailler comment j’ai texturé la base des rails en utilisant et en abusant des nodes !

L’ idée pour ce modèle est d’avoir du vieux béton abimé et couvert d’huile. J’ai donc commencé par sculpter les détails, par ajouter des craquelures et par ‘casser’ un peu le modèle. Voici à quoi il ressemble avant de commencer le texturing :

La première étape a été de créer deux matériaux assez basiques, un pour les parties abimées et un autre pour les parties en meilleur état. J’ai essayé d’utiliser au maximum des textures procédurales, histoire de ne pas avoir de problèmes de résolution. Ensuite j’ai peint une texture pour déterminer quelle partie du modèle recevra quel matériau. Et enfin grâce aux nodes j’ai mixé le tout.

Et voici à quoi ressemble mon bloc de béton à cet instant :

C’est pas mal, mais pas franchement réaliste. L’étape suivante consiste donc à ajouter de nombreuses taches d’huiles qui vont salir un peu tout ça.  comme j’utilise deux matériaux différents, le plus simple est de rajouter ces taches d’huiles via les nodes. J’ai donc utilisé une map générique avec des taches d’huile que j’ai superposées à mon matériau de base. En utilisant le nœud “mapping”, on peut utiliser la même map plusieurs fois en changeant sa rotation ou son échelle…De cette façon on ne voit pas la map se répéter et le résultat est bien plus réaliste :

Et voila le setup nodal final, vous pouvez voir dans la zone légèrement sur-éclairée toutes les couches nécessaires pour ajouter les taches d’huiles  :

Et voila, grâce à cette méthode, on peut très facilement salir ou vieillir un objet sans avoir a passer par Gimp!

Happy blending !

Hi folks,

Tube will be on slight slowdown the next couple of weeks, as the local team goes on various hiatus(es? ii? hmmm) . I’ll be in Sofia Bulgaria, teaching with some standup talented Blenderheads at TOSMI (Training in Open Source Multimedia Instruments – in a word: Blender) sponsered/ ran by interspace.

Becky is taking a week break from drawing- right now we’re four shots short of our summer goal of finishing a draft of the new animatic- and visiting friends in NYC. Fateh, Josh and Henri are vacationing in Boston, Block Island, and NYC for a few days, then back to the studio.

I’ll be still working on Tube part time, via IRC , email and Helga. Expect some rigging goodies soon!

Blender only has one choice of smooth algorithm which can be a bit frustrating at times.  Blender’s smooth can limited by the world X,Y and Z axes which is great, but it would be better if you could also constrain smoothing by object local axes or transform orientations.  What about if you could also mask smoothing by vertex groups, or stop the shrinkage effect by using algorithms which don’t shrink objects or automatically shrink/flatten each vertex to retain the object’s volume, or even if you could change the way smoothing handles non-manifold edges and get smooth to leave them be or ignore them completely?  How about the edges of the selection – blender currently pretends that anything which isn’t selected doesn’t exist, but what if you wanted to take account for the unselected vertices but not actually change their position?  All of these were things which were bugging me last week when I was modeling the smooth curved body panels of the train in ‘tube’.  I put my mind to it and coded a new add-on for blender which provides much more advanced options for all you smooth operators out there.  Introducing the “Full Fat Smoothie Maker”!

DOWNLOAD v0.1

The Full Fat Smoothie Maker

All these options might be a bit confusing to the first time user, and a lot of getting to grips with the tool is just experimenting.  There are well over 1000 ways to combine the basic choices!  I produced a quick reference chart which shows how the different algorithms handle some difficult test objects which I created.  A high-res version of this is in the zip download.

As always let me know if you find any bugs in the comments and happy blending!

Time to Rig
Our character concept art has been finaled for a while (expect a post with pretty pictures soon). All I really need to know is where the joints and outlines are, which I can get from the concepts, so it is at least a good time to begin rigging.
My last production character rigs have all been in Blender 2.4x, examples can be seen online in the Mancandy rig and the rigs I did for CNIPA ( Suzanne Award winning entry by Spark Digital Entertainment). These rigs are ‘old’- there’s been progress/new ideas in the world of rigging, and Blender 2.5 is designed to enable (some) of these techniques.
Research
For research I studied two great blender rigs: Sintel by Nathan Vegdahl and Blenrig by Juan Pablo Bouza. I also looked at the features of Anzovin Setup machine rig for Maya, and had a great time looking at rigging PDFs, books, and demoreels. The basics are all the same it seems, but some features I had considered ‘optional’ are now ‘required’, and I found some awesome hints for more realism/detail in rigging, such as proceduralism, skin sliding and more. As I implement some of these I’ll blog the techniques.
Jarred and I conducted some rigging and python experiments, such as Pivot Switching, space Switching, twisting Spline IK, Mouth rigging, and more. I also made the copy menu addon for Blender because copying visual transformations was a good step in automating rigs, and taught me about the various available transformation matrixes for Blender bones.
Dan Finnegan, a previous Maya user, learned enough Blender to do cloth simulation tests in controlled situations. As a result we are quite nervous about using Blender’s cloth in production! We’ll opt probably for a rigged solution, or a cloth solution that only does part of the work and requires rigging for the rest. Our cloth requirements are quite extensive based on the concept, but not as bad as some of our early clothing designs. Thanks to work done by the team at project durian, we can at least use cloth sims in linked characters.
Results

I had great help from JPBouza, who customized a Blenrig model and rig to Gilgamesh proportions from the Zepam mesh – after deliberation, I will do a from scratch rig for our main character, while borrowing some features from this rig, the most important in my opinion is the awesome mesh deformation cage he has made that gets excellent results, which he adapted to Gilga’s proportions, so I’ll probably use that with no modification. I’ve got a list of ‘must have’ features, a good idea of how the overall rig should look like, and a list of ‘nice to have’ features. Some ‘advanced’ techniques are surprisingly easy to do, while some (ahem, skin sliding) will take more work to find workable.
Requirements
We need to start animation in September, so the first thing is deadlines: we need the main body controls locked down by then. No time to wait for a final character model, so I work on a proxy I made for rigging.
A small list of needed features on the very basic proxy:

• IK/FK Blending on the arms and legs
• Locked Elbows for the arms
• Locked Knees for the legs
• Adjustable automatic shoulder rotation
• Adjustable rotation isolation for arms in FK
• Seamless IK/FK blending for legs and arms
• FK control chain for Torso
• Adjustable rotation isolation for torso controls in FK
• IK controls for Torso
• FK/IK switch for Torso
• Seamless Pivot Switching for Torso
• Toe-Midfoot-Heel Pivot for Feet
• Neck controls that allow nice motion/deformation of Gilgamesh’s very unique neck and shoulders
• Eye direction and tracking controls
• Rule tagged bones for easy adjustment and robustness of the rig (with rigamarule)
• Optional stretch for arms, legs and torso

This is not the final list, is enough to get animation started, but not finaled. More features will happen, some on the proxy, some after we get the final character model done, such as:

• Facial animation
• Hand and finger animation
• Deformation tweaks
• Bend tweaks
• Cloth and hair
• Procedural shakes and vibration
• Direct knee and elbow control

Progress

We’ve got the basic FK controls for the Torso, IK and FK for the arms and legs, Auto shoulder rotation tweakable, IK FK blending working on arms and legs, seamless (no jump) blending working 90% on the arms (both ways) and working on the legs going from IK to FK. An initial control UI exists, ready for tweaks, and we have rigamarule ported to 2.5, lacking only nice UI so we can start tagging bones (Thanks Daf and Josh)

Just a quickie post; the copy menu script is now in bf_extensions SVN on blender.org. Some updates: It can now copy Vertex weights by index and it can also copy mass ( a request on this log) thanks to Fabian Fricke. I’ve also updated it to work with current SVN, which means… yes, it won’t work with Blender 2.53 beta anymore. It’s a fast paced Blender we live in! I’ll try to make it work in both soon, but no promises.

Yet another python add-on for today!  I hope this is one that will be useful to a great many of you, even though its pretty hard to explain how it works… bear with me as I expect it will speed up your modelling work flow.

I’ve long been frustrated by the limitations of ‘Remove Doubles’ in blender.  Remove doubles searches for verts which are close together (in all axes) and merges them, which is great.  However sometimes its nice to be able to constrain this action to a single (or pair of) axes.  For instance if I have a row of vertices running along the X axis and I want all of them to have the same Y and Z coordinates I could select the entire row then press “s” (to scale), “shift-x” (to constrain to Y and Z), then “0″ (to snap all of them together) .  This is fine if you only have one row of vertices.  Say now that you have 100 such rows of vertices, all running roughly in the X axis direction, and you want each row to run exactly in the x-axis, so for every single one of those 100 rows you have to select each row, and press “s, shift-x, 0, enter”.  Does it get a bit boring?  Would you prefer if it was automated?

Have a look at the quick tutorial image below to see what I mean, and then if you want, download the add-on and install it.  As always let me know if you find any bugs in the comments below and I’ll try to fix them ASAP.  Happy (faster) blending!

DOWNLOAD: http://tube.freefac.org/wp/wp-content/uploads/2010/08/snap_with_axis_constraints.zip

Tutorial:

On another note we’ve been out to the pictures a few times recently.  We saw a double feature of “I am Love” and “Winter’s Bone” on Sunday.  Personally I thought that the cinematography in Winter’s Bone was a refreshing break from the all-to-common extreme-DOF-fatigue that we got to see in the europudding (see Truffaut) of a movie that was “I am Love”, a film laced with religious salvation metaphor and comic (decency induced) visual-analogy-as-substitute-for-the-explicit.  Conversely the portrayal of value-less material items as symbolic of ‘our’ personal hollow ambitions for wealth (in the form of tacky debris spread around the dwelling; toy horses, kitsch garden ornaments displaying cherubic qualities), set against the wholesome immaterial but valuable actions of the film’s main character provided an interesting subtext for what would otherwise have been a straightforward plot.  Sadly some of our friends didn’t see it the same way and criticized the ‘off’ direction and cinematography.  One way to look at it is that they were only judging according to their own personal objective perceptions of how films ‘should’ be directed and shot, rather than to how an audience subjectively perceives a film.  Fire off in the comments; lets hear your own views!

Just a quick one to say that I’ve expanded the functionality of the bevel_weights add-on to now include the following functions:

• Ctrl+E Set Edge Bevel Weights (for use with bevel weight modifier)
• Ctrl+E Average Selected Bevel Weights
• Select Menu > Select Same Bevel Weights (adds to the selection any edges which have an equal bevel weight to the active edge)
• Select Menu > Select Same Creases (ditto but for edge crease values for use with subsurfs)
• Select Menu > Select All Creased Edges
• Select Menu > Select All Beveled Edges
• Select Menu > Select All Marked-Sharp Edges (as opposed to the built in select sharp which works on edge angles)
• W-key > Bevel – bringing the functionality of the old 2.49 style ‘destructive’ beveling is back.

The add-on is now called edge_tools and is available here:

http://tube.freefac.org/wp/wp-content/uploads/2010/08/edge_tools.zip

Note that due to some recent Python API changes this will only work with recent svn builds of blender.  Anything from r30984 onwards should be fine.  Let me know in the comments if you have any problems or spot bugs and I’ll try to fix them ASAP.

I had a terrible time trying to make sure that the ‘destructive’ style beveling didn’t affect any other edges’ bevel weights.  Basically it works by setting bevel weights for any selected edges then it adds a bevel modifier and applies it.  Of course the user only wants the selected edges to be ‘destructively’ beveled, and not any edges which already have bevel weights so the script needs to preserve the pre-existing bevel weights.  I tried various methods: first I created a custom “FloatProperty” for each edge to store the existing bevel weight in (these seemed to survive the modifier but got their values deleted).   Then I tried creating edge custom properties whose names included the bevel weight’s numerical value which I could get as a string by parsing the properties with dir() (I then discovered that properties from one edge got propagated to all edges by the modifier stack).  Then I noticed that edge crease values seemed to be stored to floating point accuracy.  I thought that by shuffling bits around I would be able to store two numeric values (the edge crease and the bevel weight) in the edge crease’s value temporarily, which would have worked fine, except for the fact that by a quirk of the python API the edge creases get rounded up to 2 decimal places when setting them.  Finally with all other plans foiled I wrote a function to generate identifier strings based on edges’ vertex locations which I could then store as dictionary keys with the old bevel weights as the values!  So you can see how several hours of experimentation and head-scratching later I finally managed to implement a very simple feature… hope you find it useful! Josh