princeton-vl / infinigen

Infinite Photorealistic Worlds using Procedural Generation
https://infinigen.org
BSD 3-Clause "New" or "Revised" License
5.39k stars 467 forks source link

Logging parameters for tree generation #277

Open Ala1s opened 4 months ago

Ala1s commented 4 months ago

Hi! Thanks for developing such a good tool! I am using it for my research project and tried to find answers myself, but with some of the questions I am at the end of my wits :( 1) what is the attribute "level" influences during the generation of the tree, in https://github.com/princeton-vl/infinigen/blob/main/infinigen/assets/objects/trees/README.md its mentioned that its used to avoid placing twigs with leaves on the trunk. Do I understand correctly then that the twigs with leaves are attached only to points with the maximum "level" value in the whole tree? Does the "level" influence anything else besides that, like geometry or textures? 2) I can't find in the code the place where the twigs are being instantiated and attached to the tree, can you point me to the right file and maybe line? Is it possible to somehow access the position and rotation of each individual twig in the code so that I can log them? 3) Is it planned to fix this bug #214 anytime soon? Is it known what was the latest release that doesn't have this bug?

araistrick commented 4 months ago
  1. If I remember correctly (its been a while + I didnt write the tree code - that student has graduated), I believe 'level' just records, for each node, 'how many steps away am I from the base of the tree?`. This is used for anything that needs to know how far along the growth each part of the tree is - I think it might factor into the width of each part of the tree, aswell as leaf placement as you mention. We may also use it for moss placement iirc.

  2. Twigs are placed via geometrynodes it is unfortunately a little hard to access, since the forloop that actually spawns them is inside of blender's compute graph executor.

However, there is python code that sets up this compute graph. In the function add_tree_children we call coll_distribute, which then creates an instance on points node here that actually places the twigs.

Another way to access the specific positions of the twigs is to use our ground truth code. Each twig is treated as a separate instanced object, so will appear in our Objects.json with a unique pose and bounding box. You can read our ground truth docs for details. You could also consider directly calling save_meshes from execute_tasks.py, which saves numpy arrays that include these poses, but this is not well documented or officially supported.

Note this add_tree_children code is used on two levels of children, both for placing leaves onto twigs and for placing twigs onto trees. Both trees and twigs are considered "trees", but a big tree is a tree containing twigs (little trees) as its children.

  1. Sorry for letting #214 slip, I do intend to fix it, please ping me here if it is not fixed in a week. I believe v1.1.1 should be free of errors (and the trees havent changed since then), but I am not positive.