Place TP on MoGraph

#1

This is simple example to place Thinking Particles on MoGraph object.

Sample 1 (only place TP on MoGraph)
http://www2.11moon.com/sample_files/20110626/MoGraph_TP2.zip

Sample 2 (Added cut off function with user data)
http://www2.11moon.com/sample_files/20110626/MoGraph_TP3.mp4
http://www2.11moon.com/sample_files/20110626/MoGraph_TP3.zip

Sample 3 (Added fall off and random function with user data)
http://www2.11moon.com/sample_files/20110626/MoGraph_TP4.mp4
http://www2.11moon.com/sample_files/20110626/MoGraph_TP4.zip

It is not so difficult to make sample 1 and 2. Some MoGraph nodes are new, but not so different from usual XPresso nodes.

About sample 3, I added a data channel “ID” to the Thinking Particles. The “data channel” is similar idea to “user data”. This is because “re-arrangement” is happen after the particles are cut off from arm, without this.

For example, normally “particle” port of PPass node put integer number regularly like “0,1,2,3,4,5,6,7,8,9…”, and each particle fits to arm with corresponding number.

Then, assume that a particle number “2” is moved to different group, and cut off from the arm. Here, total number of particles decreases 1, and particle number “3” is now put as particle number “2”.
As a result, it can be seen like the particle number 2 jumps from arm “3” to arm “2”, This is problem.

To solve this problem, I uses “ID” port substitute for usual “particle” port, to get position of arms. The ID port stores number which the particle had when it was generated. So they should be same, until total number of particles is decreased.

#2

It’s great that you’re sharing these experiments with the community, tofuji.

There’s still only very few good practical examples of TP Data Channels around,
so this is really welcome.

I’m picking up a few good bits of knowledge from every experiment you post.
Thanks.

d

#3

The same goes for me, thanks very much tofuji.
The last example you posted is very sophisticated
and nicely commented, learning a lot here.

I hope you don’t mind if I post here a non xpresso
solution to your setup. The new correction deformer
allows you to have a polygonal instance of your generated
extrude object, you can even define polygon selections on it!

I reduced the extrusion steps down to 0, selected all the
polygons on the correction defomer, set a polygon selection, set the
extrusion steps back to 4, the polygon selection grew with the
extrusion (which is awesome), so now you can use the correction
deformer with the polygon selection set in a cloner, to clone the
spheres onto and with a wind effector and some dynamics you have
nearly the same behaviour as in your last example.

Scenefile:
http://dl.dropbox.com/u/28253825/MoGraph_TP4_yader.c4d

#4

You are wellcom, Yader.

The correction deformer is actually great. I knew it, but did not know the usage, you explained. Basically R12 can not deform primitive or NURBS objects by bone (skin), but it enables it (see below).

http://www2.11moon.com/sample_files/20110627/primitive_skin.zip

About your example, it is not enough because your example does not have “switch” from “fix to arm” state to “flow by wind” state about end balls. So the end balls start to fall down before wind effector approaching.

I have tried some way in MoGraph, but could not get answer without XPresso. How can we switch them with native MoGraph functions?

note. R12 can deform primitive or NURBS objects by bone, with “Weight Effector”.

#5

You could set your clones to be triggered by an collision event and add a deformed sphere as a collision object which goes from right to left trough your tentacle object. Then you only have to play around with the friction/damping/collision settings in order to get a smooth transition between “fix to arm” and “flow by wind”.

#6

OK, I have got it.

The key was “ghost” mode in dynamics tag.

http://www2.11moon.com/sample_files/20110626/MoGraph_TP4_yader2.zip

#7

Nice, very nice. Never used the ghost mode to be honest

I like how this thread evolved from a TP/Coffee/Xpresso
solution to a “normal” mograph solution. Good work tofuji!

#8

I have got another one, which is closer to sample 3 in my first post.

http://www2.11moon.com/sample_files/20110626/MoGraph_TP4_yader3.mp4
http://www2.11moon.com/sample_files/20110626/MoGraph_TP4_yader3.zip

In this example, I update “MoGraph Selection” by XPresso, to cut off the balls randomly from arms.

There are really “many ways” to go to top of the mountain. The best way is changed case by case, and one by one. But generally speaking, the TP is bit old. I like the TP, but it may be better for new users to learn MoGraph first, and XPresso in next.

#9

I absolutely agree, I hope that Maxon either updates TP or gives his Standard Particle System more brain. Maybe we will see a mograph dynamics based particle system in the next updates to come? Pyrocluster is also an old grandpa and deserves a much needed update.

#10

Dont wanna hijack, just throw in:
No. TP is great. It is only a bit slow (compared to other Particle Systems, but this is also due to Cebas, not only Maxon).
But nevertheless, i agree in you with saying it should be updated, yes. There are some essential things (like ParticleIDs), which are there, but still kind of hidden and not so easy to deal with especially in the beginning.
But, again, TP ist great when one knows how to handle them.

#11

Yes mark. Speed is the most weak point of TP compare to MoGraph.

One reason of the slowness of TP is that it is working in XPresso which is processed by interpreter. It is a trade off between speed and flexbility, and can not speed up without changing basic design.

So I think best way is that to make “many supporting particles” by MoGraph, and “few leading particles” by TP.

#12

no, wrong. even MoGraph is a very nice module with a lot of great possibilities and features, it is the slowest thing ever found on this earth. really, MoGraph is much much much slower than TP.
no comparison.
TP starts to get slow when you deal with many many particles.
ever tried to simulate 30.000 particles? get a cup of tea.
ever cloned 30.000 cubes? shut down your computer.

#13

OK, now I tried 30000+ cubes (323232).

This was still possible in even my small MacBook Air with 2GB RAM, but much slower than my estimation, and close to TP.

So I will change my word to “there is no difference between TP and MoGraph in their speed”.

#14

With MoGraph the speed is mainly depended on the number of objects. The calculations only make up a small part of the needed CPU time if you use many objects.
TP speed is in gneral equaly dependent on the numbe rof objects, but since TP setups can include much more calculation intensive functions (multiple PPass iterations etc.) it can be a lot slower.
One way to keep TP as fast as possible is to use as few PPass operations as possible.

#15

I tried that, needed 1min to setup and another 1min to render.
http://dl.dropbox.com/u/28253825/32768_cubes.jpg
(macbook dualcore, 2,26ghz, 4gb ram)
As Srek stated it’s the geometry that bogs the performance down,
not the calculations. This is one of the reasons why there is a matrix object,
I generated the 32768 clones with the matrix object, took a cloner with
a real cube and referenced it to the matrix object as I went to render, done.

TP Particles = Matrix Object
TP Particle Geometry = Cloner Object
No wonder the Matrix Object can generate Thinking Particles
as the underlying concepts are the same.

Maybe Maxon could expand the particlewise capabilites of MoGraph,
as this would make TP somewhat obsolete.

#16

I fear that the two concepts are basicaly mutualy exclusive. You can connect the two, but unifying them will either produce a nearly unusably complex system or will cripple it.

#17

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.