abpy / improved-sapling-tree-generator

A new version of Blenders sapling tree generator addon with improvements, new features, and bug fixes
GNU General Public License v2.0
140 stars 24 forks source link

Small enhancements #2

Closed Garfield96 closed 8 years ago

Garfield96 commented 9 years ago

Small enhancements in GUI and update process

abpy commented 9 years ago

1, negative leaf number is actually a feature from the original version, it makes palmate compound leaves 2, update_leaves seems like a good idea

Garfield96 commented 9 years ago

Thanks for the quick reply. To avoid further issues with the negative leaf number it would be useful to add a comment on the effect in the description of the IntProperty field.

abpy commented 8 years ago

Ok, these changes look good, I'll merge them soon. Thank you for your contributions.

Garfield96 commented 8 years ago

Here some future ideas I want to discuss with you:

  1. add option to create multiple leaf objects, which would be useful for texturing
  2. add option to assign an exising texture to the leaves, so that the user can examine if number or size of the leaves is suitable for his texture
  3. add in 4 or 5 presets with textures, which could be used by architects or others who don't want to bother with the long process of generating and texturing a tree but want a quick way to establish a nice looking environment and background for their model
  4. add more options for the root, for example an option to determine where the rootflare starts
  5. format the source code to conform pep-8, which is recommended by the Blender Foundation
  6. change the internal architecture:
    1. Possibility: split the source code into 3 big classes:
      • Tree
      • Leaves
      • Armature This classes would contain all methods to generate themselves and they hold the information needed for following update levels, for example Leaves would store LeafMesh and LeafObj, which is needed to generate the armature The objects of these classes would be created by the init process and would stay for the whole execution time of the addon
    2. Possibility: Instead of moving all methods into own classes, it is also possible to create one big data class holding the information to generate the tree, the leaves and the armature. In addition, change the update system to use different levels of update: For example: Level 0: no update needed Level 1: rebuild whole tree with leaves and armature Level 2: rebuild only leaves and armature Level 3: rebuild only the armature Therefore replace the BoolProperty do_update with an IntProperty. In addition the idea of the last pull request to use a method like update_leaves could be extended to also use an own method for the armature and pruning. On the one hand this avoids unnecessary updating if the particular option is disabled, on the other hand it is possible to define the update level needed to apply the changes made by the user to the model. Advantages of the new architecture:
      • allows to rebuild the leaf object and the armature without rebuilding the whole tree
      • better code structure
      • long term advantages: it's easier to implement the generation of a whole forest Disadvantages:
      • more memory consumption
abpy commented 8 years ago

I'm not really interested in doing a major restructure right now. I may sometime consider splitting the add_tree() function so that things can be generated without rebuilding everything.