@varkenvarken
Can you elaborate on these parameters please >> Tropism, Top bias and Surface bias
Tropism: 0.9~ creates
Is it a feature? ;D
Is it a feature? ;D
@light bwk: I am not sure what is happening in your scene. what supposed to happen is that after the direction of a new internode has been calculated due to endpoints Tropism is then added as an offset in the z-direction and based on the actual position of the new internode is determined. Í will try to reproduce it and see what happens . (You did use version 0.0.7?)
Top bias and surface bias only work with the default, non-grouped way of defining the crown shape. That top bias isn’t working when defining groups is a bug. Both parameters influence the distribution of the endpoints, a positive top bias should placd relatively more endpoints near the top of the crown which will result in a tree with less side branches near groundlevel.
Yes, version 0.0.7.
I think I know the cause already, my kill distance is too short.
So the culprit are
- short kill distance and
- high tropism
Also found another problem…
the branch bends back to itself.
Can’t quite pin point the cause yet.
and thanks for the explanation for Top/surface bias and tropism, I think I got them figured out already.
@light bwk: if you add extra endpoints during the growth a branch might theoretically bend back on itself. I can even think of some egde cases where this might happen anyway but I then would expect this to be a single branch or so. Do you have an example (img)?
BTW, nice examples!
2 examples, always tropism closing to 1.0 creates it.
Number of End Point isn’t the main culprit.
Edit: Crown Shape > 1.0 and Tropism ~.9 will create the folding back branches
Mmm, I can even reproduce the effect w.o. changing the crown shape. The problem seems to be that if there are relatively few endpoints and a large tropism the new branch section might end outside the kill distance after the tropism is applied. The next branch section will then be pointing to those same endpoints, causing a sharp bend. I am not sure how to fix this in an elegant way. one option is to simply forbid new branch sections that are at a ‘weird’ angle (> 120 degrees or so) but that doesn’t feel quite right.
Is it possible to store the last point and forbid it to point at that?
@ejnaren: that is already done but doesn’t help I’m afraid: when a new branch segment is generated there is a check that it isn’t close to any other branch segment. I could make the range that is considered close bigger, but it would have be a lot bigger to prevent this kind of behaviour and that would probably influence the shape of the tree.
[edit] maybe it would be a better idea to apply tropism after the skeleton of branches is generated. That would mimic the influence of gravity better (and for light tropism there already plenty of control because you can distribute the endpoints with groups of meshes)
Version 0.0.8 is available. It implements a substantial speedup in the branch generation for complex trees. More info in this article.
Most people call me Michel or varkenvarken. 
the number of branches cannot be set explicitly but if you raise the number of endpoints and lower the internode distance and/or kill distance you get a more complex tree. small branches (twigs) might also be added by setting a suitable value in the number of new endpoints per thousand iterations. The geometry of the leaf is always a single quad. The idea is to apply an alpha mapped image of a leaf to these quads.
@220696: Sorry for late replay.
I only modified three parameters
number of end points:750
Internode length:0.21(It reduces the scale of branches-this is what i understand)
Kill distance:0.1(this is the main thing we need to play with- more than scale option this one influence the over all scale of the tree)
sorry if i am wrong in something but this work for me very well.
thanks for nice words and thanks again thanks for the scripter
It looks different to the Sapling Tree Generator. I may have to try this.
Hi, Michel! Where are you from? Hmm, okay… I will try to understand more about this script… Oh! I have tried to change the value of everything there, but all I get is the leaves don’t spread equally along the branch. They gathered in a point, and make a form like a flower. How to spread them like in your thumbnail preview?
It’s okay, I almost forget to check this tread You set the crown shape by defining the mesh group (You added the monkey into a group called group, that’s my conclusion). I’ve tried that, but my mesh is a hemi-icosphere. I’ve set it like yours, but nothing comes out. So curious.
I’ve been using this addon for an actual scene recently, will this addon be updated anymore or is it done? (because I have some comments on where it could be improved.)
1). I found that when I used the skin modifier method and compared it to the native one, I noticed that the native one was markedly inferior to the skin modifier on branches that go out on a right angle. Basically, what I found is that some of those branches actually end up looking flat at the base instead of round and I’ve already mentioned the subsurf issues in a previous post. The skin modifier is also superior because any overlaps or folds in the geometry can be easily corrected.
2). It would be nice if it was able to generate the fine twig details that sapling does, I know this script does twigs but you sometimes have to subdivide the ends of the finished results (using the skin modifier) to get some of those twigs to go all the way to the leaves.
3). The default UVmapping on the leaves, to my knowledge will map a leaf image 90 degrees off alignment with the branch, this is easily corrected fortunately.
4). It wouldn’t hurt to space the leaf planes a little further out from the branch so as to prevent it from overlapping the image when you create the leaf texture, at least try to tweak the spacing so the bottom pixels of the image is perfectly flush with the branch.
5). Perhaps use simple distance checks to make sure that no leaf cards are placed where there is no room, I’ve seen some small twigs generated near the trunk and a few cards end up almost all the way inside the mesh.