Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


Activate last won the day on June 11

Activate had the most liked content!

Community Reputation

33 Excellent

About Activate

  • Rank

Contact Methods

  • Website URL

Personal Information

  • Name
    Niels Provos
  • Location
    Mountain View, CA

Recent Profile Visitors

253 profile views
  1. Here is a link to the paper: http://www.andylomas.com/extra/andylomas_paper_cellular_forms_aisb50.pdf Enjoy.
  2. That looks great. Thanks for sharing. When you look at the paper from Lomas, he also experimented with reaction-diffusion as well as photosensitivity, e.g. nutrients get produced where sunlight reaches.
  3. I finally got around to cleaning up the hip file and have attached it. If you end up using this, please let me know how it's going and share a pointer to your work. The major challenge with writing this in VEX was that VEX does not offer any of the canonical data structures one would use to efficiently implement this. For me, the simulation ends up running out of memory around a 1000 frames. As I am novice to Houdini, I would also appreciate any feedback and comments you might have if you end up taking a look. Enjoy? :-) MorphogensisInVex.hiplc
  4. I found the largest challenge to be cell splitting for which I needed to implement in-order neighbor traversal: https://gist.github.com/provos/4e88a9f13fb7354fa680c7b1d4c907b2 (this may not be the latest code) Let me think about sharing the HIP file. It was a fair bit of work but ultimately nothing particularly special.
  5. Thank you all for confirming this. I will stop banging my head against the wall. For my particular experiments, there are likely memory optimizations I might be able to do, e.g. for the forest cull leaves that are facing away from the camera, etc, but the lack of scalability of packed primitives is certainly disappointing.
  6. Ignoring the packed disked fragments and going much simpler, here is another test: Box -> Points from Volume - Copy SOP packed primitive ~10k points -> 0.35GB Mantra usage ~100k points -> 0.6GB Mantra usage (2900 bytes per packed primitive - by delta) ~1M points -> 2.45GB Mantra usage (2100 bytes per packed primitive - by delta) ~10M points -> ~21GB Mantra usage (2060 bytes per packed primitive - by delta) That seems to be 5 times larger than what the SideFX documentation claims: 400 bytes per packed primitive (http://www.sidefx.com/docs/houdini/model/packed)
  7. I have a large ground (grid 120x120) on which I grew a meadow, e.g. 6 packed primitives copied to 8 million points. To make this more? efficient, I fractured the ground into 20 fragments and read each fragment as a packed disk primitive - to avoid loading when the camera does not see it. When I render an individual fragment, mantra takes about 1.4GB of memory. When I render all of them together, it's around 30GB. According to SideFX, each instance of a packed primitive should take only 400 bytes. That would translate to 150M or 3GB respectively. Can somebody here help me understand what's going on? If you are interested, here is the scene file: https://drive.google.com/file/d/0B3SRWSd2MwvPVWNqNlZxazlPN0U/view?usp=sharing (Warning, that's about 600MB) Ps: The grass code comes from: http://blog.schdbr.de/houdini-grass/
  8. Andy Lomas' work on cellular growth has been really inspiring. He implemented all his code to run on GPUs. I was wondering how hard it would be to do this natively in Houdini. After some contortions, this is what I ended up with:
  9. Thank you. renderstate(packed:attribute) on point attributes works great.
  10. So, far the only solution I have been able to get to work is to assign different materials (based on some thresholds on the parameters) rather than doing full parameterized materials, e.g. make leaves look more wilted if they have less vigor, etc.
  11. It works but it causes unpacking of primitives in mantra, so that the geometry is no longer shared. It significantly increases render times and memory. That's a problem with material stylesheets. I believe they work effectively only for light-weight geometry, e.g. crowds.
  12. I am struggling with getting material variations with packed primitives when using a Copy SOP. The example is a forest, e.g. a fairly complex tree with 100ks of leaves. With the Instance object, it was possible to assign a shop_materialpath and material_override to points, e.g. to change BaseColor. With packed primitives and the Copy SOP, adding a material_override causes mantra to completely ignore the assigned material. A way to get around this is to assign a material_stylesheet. Unfortunately, material_stylesheet causes mantra to unpack all the packed primitives which quickly exhausts all available memory. Here is an example file: https://drive.google.com/file/d/0B3SRWSd2MwvPQndFcWhOTUlrcVE/view?usp=sharing (25M) Any ideas would be appreciated.
  13. The tree growth sim I wrote keeps track of axillary and terminal buds for the branches. That's the groups you are seeing. The fix I ended up with was to separate the branches by degree and polywire them separately and then combine them back into a polygon via volumes. That allows polywire to compute joint scales, e.g. between the main trunk which is degree 0 and the lateral degree 1 branches. It's just heavy and expensive. I filed a bug report with SideFX. Polywire should not behave like that :-) Anyway, here is an example with some leaves on it and the volume conversion for the trunk.
  14. The tree.bgeo.sc is in the zip file.
  15. I am having trouble with polywire creating proper joints especially when the width of the joints is disparate. See attached examples. Any suggestions on how to rectify this? My work around has been to chop the tree up and convert it into vdbs and then convert that back into a polygon soup but that's pretty slow and creates much heavier geometry. unhappy_tree.zip