Hi guys!
Just wanna show you what I'm working on. It's an effect for a personal
project. C&C are welcome!

seb.

http://www.vimeo.com/19427894 [vimeo.com]

i like it, maybe a bit more dense

not bad for a start, perhaps add some noise to your trigger pattern so it looks less like an expanding sphere or add a slight per point trigger offset so they don't trigger all at the same time.
You are getting a bit of stepping.

Also consider different plants growing at different speeds. The grass might grow faster than the other plant. Again, implement a per point triggeroffset.

Also the animation feels as if it pops at the end of the growth cycle. It would be nice If your grass/plants grow from 0->1 and “sway softly in the wind” from 1->2 and that the blend from growth to swaying is seamless. If it doesn't need to interact, consider making a few animation loops.

Also, just to make the picture complete (even if it is a test) add a ground object so your grass doesn't just float in mid-blackness. This may also lead you to using your growth points to procedurally displace the terrain a little if you wanted to.

thank you both for your advices!

pclaes, your are right. one of the next steps is to implement individual
groth-speed to the different kinds of plants. Its only grass and clover so
far, but I plan to add daisys as well.

I tried to make this setup so controlable as possible, so I built an
interface to have almost all parameters in one node (screenshot)

I really like the swaying grass idea, I will definitely implement this.
The grass is already controled by a bend deformer for the overall curvature.
Maybe I can introduce some wind-like movement to it.

There are no dynamics involed yet, cause its all done with copy-sops and
a sop solver (which doesn't really act dynamicly). I'm sure there are a couple
of different possible approches to achieve this effect.

You are talking about animation-loops. how and where would you build in these loops (maybe you have something different in your mind)?

I hope you are not doing your copy sop inside your sop solver.
But instead just solving your template points, caching those to disk and loading them back in and then applying your copy sop.

Anyway, in regards to the animation loops:
*) you have a set of template points that you are solving. It would be nice if these points could go through different stages. Like “grow”, “sway” and “die”.
Rather than using a pscale to just scale up your plants you can make anything happen in the growth cycle and cache that geometry to disk.
*) on your template points you accumulate an animation value or a start frame when the points are triggered. From the moment they are triggered the animvalue starts running and is fed into the lookup for the geometry cache on disk: my_plant_01.$ANIMVAL.bgeo or something similar.
*) When the growth animation ends, you make sure it blends seamlessly with the start of the “sway” clip. When the sway clip ends, you make sure it blends with the “die” clip or with the start of the “sway” clip. So it's a loop. You can make different cycles of different lengths as long as they blend. That way you quickly get a lot of variation.

*) the advantage of that setup is that you cache things to disk, you can use instancing and delayed loads and go with massive amounts of geometry rather than the limiting copy sop. It effectively becomes a crowd system.
*) the disadvantage of that setup – and that is why I asked in the other post. Is that you lose a bit of that dynamic interactivity. You can do it, it just becomes harder to control.
*) you could also do a blend of the two techniques and identify the points that will need dynamic interaction (say if they are within the bounding box of a collision object). Those points you can treat separately with a wire solver/springs/bend/…


–) if you like sopsolvers and triggering things, you could also implement a “cooldown” period after the plants have died, after that cooldown they can be triggered again and all the cycles start again. I've done a fire&fuel simulation in the past where you regenerate the fuel, then trigger it with temperature. If you allow for enough variation you can get bits burning long enough to reignite the regenerating fuel. You get beautiful feedback loop patterns. Really cool stuff and you can still control it a bit by overriding or triggering it yourself with your own triggerobjects.

you are a source of inspiration! thank you for you detailed explanation.
I think I will re-structure my network to work with instances.

to your question:
no, the copy sop is outside the sop solver, cause its only for the calculation
of my groth attribute.

I never worked with delayed instances yet, so I HAVE TO TRY IT

I control all my stamp values with the grow value (0->1) and vary the incomming curves, transforms etc. it works fine, but doesn't seem to
be a very fast solution.

I will post my next steps!

Hi pclaes!
I've studied your example files for delayed instancing and was able to
recreate everything. Its really fast, once the setups is done.

But one thing iI don't like with this approach is that I kind of loose my
'interactivity'. now I have to time the groth speed before, cache differnt
variants out and test it.

I just imaging clients sitting beside me and always asking for differnt versions
of the effect (and ending up with the first version of it (of course!)

Glad you like it.
The copy sop is good for prototyping your instancer and getting some of that interactivity.

Once that look and feel is achieved and you want to scale things up for a bigger scene, there is no way around delayed load.