I added a small piece of extra functionality to the tree add-on: now instead of just growing a single tree from the 3D cursor you can specify a group of objects (empties) whose locations are all simultaneous starting points. Handy for hedgerows and such.
Details in this article, including a pointer to the latest version on github.
Without a full error message it is impossible to help you out. Any python errors will show up in the console. The console can be toggled from The main menu at the top on Windows (I think from the window or view menu, I am not sure and not behind my machine right now) and on unix like systems i think you have to start blender from a commandline to view these messages.
Traceback (most recent call last):
File “C:\Users\dank0\AppData\Roaming\Blender Foundation\Blender\2.66\scripts\addons\add_mesh_space_tree_init_.py”, line 459, in execute
File “D:\Applications\Blender\2.66\scripts\modules\bpy\ops.py”, line 188, in call
ret = op_call(self.idname_py(), None, kw)
TypeError: Converting py args to operator properties: enum “EDIT” not found in (‘OBJECT’)
I had the same problem, if you are using Empties as starting points then you’ll have this error since Empties are not Objects , you need to use meshes Cubes or Cones in a group as starting points. That worked for me
Empties are objects all right but they cannot Enter edit mode. For some reason if I want to intersect a ray with an object I do have to toggle edit mode. This is strange but it don’t have a solution yet… just select any mesh object now before you add a tree and you don’t have this problem.
A new release (0.0.6) is available and instructions are in this article.
I fixed a few bugs and added the possibility to duplicate an extra object alongside the leaves, which might prove useful if you want to add fruits or something.
Version 0.0.7 is available on GitHub. This version sports a completely new way of skinning the trunk skeleton. It’s a native implementation (i.e. it doesn’t use Blenders Skin Modifier) and speeds up things by a factor of ten or more. Details in this article.
PS> the next release will focus on bug fixes and code cleanup and will hopefully result in a 1.0.0 release, so feature requests are still welcome but bug reports even more!
A very common feature request would be interactive slider updates. I was previewing version 0.7 from github. I thought the script was just broken when I moved a slider and nothing happened. Then I noticed the update button.
You can add a hook to a function for each property then when the slider changes, that function gets called.
An example of a single property extended with the update function.
maxIterations = IntProperty(name="Maximum Iterations",
description="The maximum number of iterations allowed for tree generation",
@atom: thanks for reviewing. About interactive updates: the script isn’t fast enough to provide a smooth experience when there is interactive feedback so I copied this scenario from the Sapling add-on.The problem is that while execute() is running, none of button or slider events is processed so there isn’t even a way to abort the execute() function. Maybe it’s possible to let execute spawn a separate thread but that would require some serious research
@varkenvarken: Great work. It is really nice that you keep improving this addon! It is already the best way to add foliage to a scene in my opp. The way you can shape trees is just great. Eksample: I do an architectural project and would like to include a specific tree that is near the project I am doing. I can now quickly specify the size and shape of the tree and get a rough approx of it!
When we hit around summer I planned like to work on a new project to create some different real life tree types and put them on Blendswap. I am thinking now though (with your permission) it would be nicer to create a package consisting of textures and settings to get a tree that looks like some specific tree type. then people could tweak it themselves. Maybe these could be hosted along with the addon as presets or on the webpage?
PS: feature idea: Maybe you already do this or have it planned (I have not tried the new version yet) but is it possible to take the vertex radius into account to define the thickness of the tree? You can do this with the skin modefier which is really cool! Maybe a blend function that interpolates the radius from the “root vertex” by some factor all the way to each branch?
I tried the new version of the addon, and the skinning routine is indeed now a lot faster.
Theres’s only one issue though, and that is the custom skinning function currently does not have anything that would prevent geometry from intersecting and overlapping each other (especially when you have a combination of a wider trunk and a lot of branches originating over a short distance). This gives the impression that the implementation right now is just to emulate the skin modifier, what might be needed is the need to do distance checks from the center of the tree skeleton and forbid the creation of any branch verticies below a certain distance, in which the branch geometry is connected afterwards to a hole cut in the geometry of the parent branch.
@ejnaren: if you create something nice and want to share it, please do, you don’t need my permission, in fact I love it when people give back stuff they make
ABout the radius: there are scale and power sliders that you can use to control the overall thickness of the trunk/branches and how fast this radius decreases at each fork. These radii are stored as vertex radii and used by blender skin modifier and in the new version also used by the native skinning method. I admit that some documentation would be useful
@ace dragon: you are right, when a branch forks with a small angle between the new branches there will be some overlapping geometry. It’s not the vertices that overlap but most likely the connecting edges. either way, I will certainly try to improve on that, also because I want to generate uv-coordinates as well. I will try to illustrate the way the algorithm is implemented so that sharp eyed people like yourself can comment on it, but that will take some time. Anyway, thanks for testing and commenting!
@ramboblender: yes the algorithm cuts some corners. If you apply a subsurface modifier the branches not only will look nicer but will follow the skeleton better. (Note by the way that the branch skeleton is not removed from the final result but will not be rendered because it consists solely of edges. If you like you could delete the native skin and add a regular skin modifier even after you have finished modelling the tree) .
As a first step to a full release I made some documentation. The text is fairly complete but I still need some extra illustrations. But because it is already quite useful as a reference it is published in its current state. Comments are welcome of course.