Simulate empty bullet casings, try two!

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

REPLY TO THREAD
 
Thread Tools Search this Thread Display Modes
Old 02 February 2013   #16
Nice hack!
__________________
Vimeo
 
Old 02 February 2013   #17
Originally Posted by stooch: ...Also, can you describe more complex shapes with particle "clumps" etc?


Yeah, you could, I discovered that when playing with constraints to make this - http://vimeo.com/18728698

But its kind of difficult to pull of something big or many shapes without a lot of prep work.
In the end I imagine using nCloth Rigids would be faster...

Off to test something
__________________

.

Reel - 3DInk.com
Filmography -IMDB
R&D - VIMEO

*please read- cyanbsl.blogspot.com/*
 
Old 02 February 2013   #18
Quote: But wouldn't it be cool if we can do what you just did but with a clear nodal workflow ?
When trying to do things with the current parameter driven system one frequently needs to be very creative, and some things are very difficult and require scripting or plugins. I understand the desire for a node based approach, which ultimately is a sort of visual programming language where any construct is possible. Hopefully we will someday support that sort workflow, but for now you will need to be imaginative at times with how you use the software to achieve a particular effect.
 
Old 02 February 2013   #19
...damn after trying a test, realized it will never work well. too much hacking together, nconstraints just arent dynamic enough. :(

Or my initial tests just were not thorough.

So... first I tried making an object, filling it with particles, and using component to component constraint to connect them into a lump the shape of the object. Not thinking through, I then simply instanced the object back onto the particles. Of course then I had 50 instances following the lump (actually a trippy cool effect).

Since that wouldnt work (or can you somehow tell the instancer to just use ONE particle, not all?) I thought about making a 2nd single particle in the center of the lump and then tried constraining it to the original particle lump so it would follow and rotate. Then I instanced the object with the one particle.

It kind of works, but in my quick test couldnt get the single particle to follow the rotation of the lump correctly... Im sure it can be done.

Either way, this is a horrible way to get ONE object to act like a rigid using particles.

Of course if it worked well, it could be scripted, but still a hoaky way to get this working, and I imagine a large number of objects with many constraints would bring Maya to its knees...

Maybe this has inspired some of you to take it further... after a long day at work Im too tired... but Im sure will get to messing with this again. You can do some cool out of the box things with nConstraints and really hope Duncan expands on the tech so we can do more!

Sorry for OT
__________________

.

Reel - 3DInk.com
Filmography -IMDB
R&D - VIMEO

*please read- cyanbsl.blogspot.com/*
 
Old 02 February 2013   #20
Originally Posted by Duncan: When trying to do things with the current parameter driven system one frequently needs to be very creative, and some things are very difficult and require scripting or plugins. I understand the desire for a node based approach, which ultimately is a sort of visual programming language where any construct is possible. Hopefully we will someday support that sort workflow, but for now you will need to be imaginative at times with how you use the software to achieve a particular effect.


Thank you for being so candid Duncan. Your posts are definitely inspiring with their creative problem solving. Thanks a lot for them.
__________________
From Russia, with love @ stooch.tv
 
Old 02 February 2013   #21
I did some rigid body emitting a while back with the dynamica plug-in and a particle system. On the creation expression I created a rigid body and set its position to the particle, gave it the particles velocity and then killed the particle. Wasn't cacheable though and you had to render on the fly, but I'm sure there's ways around that if you're clever. Here it is in action on my old reel http://youtu.be/0p9uP_hzalM?t=57s
__________________
pauljewell.com
 
Old 03 March 2013   #22
It is also possible to use the method I outlined above for more complex objects than bullet casing. I've attached a file that uses 3 particles per object, and instances a torus. Using 3 particles allows the torus to properly settle in a flat orientation. It is not perfect but very fast to compute. One could if desired use more particles than three to better approximate the torus.

The difference with the shell casing( 2 particle ) workflow is that one needs a 3rd particle emitter. In the particle creation and runtime expressions one gets the positions of all 3 particle systems and sets the values of 3 added particle attributes: aim direction, up, and instancer position:

vector $p1 = nParticleShape1.cachedPosition;
vector $p2 = nParticleShape2.cachedPosition;
vector $p3 = nParticleShape3.position;
vector $v1 = $p1-$p3;
vector $v2 = $p2-$p3;
nParticleShape3.aimPP = $v1;
nParticleShape3.upPP = $v2^$v1;
nParticleShape3.instancePos = ($p1 + $p2 +$p3)/3.0;


(something I'm not doing here is normalizing the two vectors... this might be needed in some cases... to do that just do $v1 = $v1/mag($v1))
The up uses a cross product (`^` symbol) between the two vectors, essentially creating a normal for the triangle formed by the 3 particles. The instance position is simply set to the average of the 3 particle positions or the center of the triangle they form, rather than the default which in this case would have centered on the third particle.

Then one sets the instance position to instancePos, aimDirection to aimPP and aimWorldUp to upPP, to rotate and center the instanced object with the triangle of particles.

More particles can be used by adding and positioning more emitters, but one still only needs to reference 3 particles to define the instancer rotation.

The constraint needs to be made between all particles systems with the method set to component order. This will connect all particles in a group to each other, so if one did the setup with 4 particles it would be connected as a tetrahedron.

It would be cool to have a script that would automate this setup somehow. One also could manually create particles in the different systems using the emit command( just make sure to duplicate emission in all systems so that they always contain the same number of particles ).


Duncan
Attached Files
File Type: zip particleEmitConstraint2.zip (9.8 KB, 95 views)
 
Old 03 March 2013   #23
More awesomeness! Cheers!
__________________

.

Reel - 3DInk.com
Filmography -IMDB
R&D - VIMEO

*please read- cyanbsl.blogspot.com/*
 
Old 11 November 2013   #24
Firstly, this setup is really cool and useful! Thank you for posting.

Secondly, I was playing with the shell casing example and I tried adding a second dynamic object "setup" in the same scene created exactly the same way as the first shell casing example (two new offset emitters, constraint, instancer, and new instance object). I'm noticing that when I setup the per particle expression for "lookAtRotate" to the position of the first particle system of my SECOND setup, that first particle system's position stops working correctly - hence ruining the overall system. I'm thinking this has something to do with what you mentioned with the position not properly evaluating ("it messes up the dg attribute dirtying"). Because I've found when I delete the entire FIRST setup (the shell casing), my SECOND setup starts working perfectly.

Is there a limitation to this method only being able to have one SETUP like this per scene using the same solver? I thought about trying to use two different Nucleus solvers, but then my two systems wouldn't interact with each other (and the other rigid bodies in the scene as a whole).
__________________
Check out my reel at www.rossmnewton.com
 
Old 11 November 2013   #25
I've not tried two setups with the same solver, but I would have thought it would work providing the ordering was the same as the first two systems... just as particle1 should not access particle2, particle3 should not access particle4. But I could be wrong... the dependency graph evaluation sequence gets fairly complex in this case due to recursive evaluations.
 
Old 11 November 2013   #26
Try this scene out. When you play it, you'll see my second setup is broken/not working right. But if you delete emitter1, nParticle1, emitter2, nParticle2, and dynamicConstraint1 (the first setup), my second setup will start working fine.

I've looked at the node graph, everything seems to be connected properly - nothing from the second setup is referencing the first setup.

Also, how are you able to get your instances to spin automatically upon creation? Since it's the constraint that's driving the animation I was experimenting with ways to add some initial rotation. Particle rotation doesn't seem the way to go since it's the constraint that's actually rotating and driving the animation. So far I've got some nice results with fields but I was curious how you did it in your test scene and/or what you would recommend. I don't see any initial force/rotation options under the dynamic constraint attributes.
Attached Files
File Type: zip shellCasings_twoSetups.zip (29.6 KB, 14 views)
__________________
Check out my reel at www.rossmnewton.com

Last edited by evolross : 11 November 2013 at 10:56 PM.
 
Old 11 November 2013   #27
It seemed to work for me to instead set the particle4 lookat value inside an expression on particle3... so delete the particle4 expression and create the following runtime on particle3:

vector $p3 = position;
nParticleShape4.lookAtRotate = $p3;

Perhaps doing it this way will avoid the order problem as the position values get pulled when the particle normally evaluates... or it could be that it simply prefers this (reversed) evaluation order.

Duncan
 
Old 12 December 2013   #28
When I try to change the expression according to your last post, I'm getting an error:

Warning: line 0: Connection from nParticleShape3.output[0] ---> nParticleShape4.lookAtRotate was not allowed. You can only connect to a per-particle attribute from another per-particle attribute on the same shape or from an arrayMapper or particleAgeMapper node. This may cause subsequent connections to fail during duplication with the "-ic" flag. //

This seems to be valid since I am trying to set a per-particle value on one shape node from another shape node. Do I have to use the arrayMapper to get this to work?
__________________
Check out my reel at www.rossmnewton.com
 
Old 08 August 2014   #29
Duncan, thanks for sharing this technique. I'm trying to apply this technique but without success. I's very strange case because creating the sim in your scene, I mean, replace your dynamics system with new one works perfectly. In case of doing the same in the new scene I get this :
With instances

Without instances


Playback speed = Play every frame.
Any idea?
 
Old 01 January 2016   #30
Solution?

Hi,
Is there any solution for this problem?
Cheers, D
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 08:19 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.