Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I updated the first post in this thread with links to Python and PyCarrara that are guaranteed to work (assuming you get them installed correctly). That might make it easier.
Update:
Earlier today, I released a version of PySwarm that fixes a defect PhilW discovered. You will find the latest links for the full (but ever so small) package of everything or just the PySwarm script itself.
Great - thanks for doing this so quickly.
Yes... both of you... Thank you very much.
Say Fractal, when you're talking about the walk cycle thing for the future... what do you mean. It will have a walk developer function? Would that work to have like a 'catch and release' thing that works on the feet as the hip moves forward, along the specified velocity? Never mind... I don't need to know how... lol
Have you given thought about what you can do along with the power of PyCloid in addition to PySwarm? Just a thought in passing on that idea makes me sort of... quiver.
Dartan, all good thoughts and questions. Thanks!
At the moment, I am thinking of applying something like what Frederic demo'ed with PyCarrara here:
http://www.youtube.com/watch?v=nNr7y61VLy0
But I am thinking of a "walk" as really any cycling motion of the boids - swimming motion for fish, beating wings for birds, etc. And yes, that PySwarm would inject keyframes to drive the motion. The real question is how to create an interface that is relatively easy to use, but is capable of handling complex "walk" cycles. I recently acquired ERC, and am thinking of ways to integrate PySwarm walk animation with that plug-in. It may make PySwarm's work easier, but would require having that plug-in. It might work for the first phase.... I'm always open for suggestions and thoughts on this topic.
I should mention that my initial testing seems to indicate that embedding lots of keyframes to an animation does not consume a lot of memory (which is a bit of surprise since some aspects of Carrara does not seem to be memory efficient). So injecting repetitive keyframes is an option to pursue (at least for now and address memory problems if they arise later).
I have watched the PyCloid animation sequences, but have not had a chance to dig into it yet. I suspect (at first blush) that it has at least the potential of PyCarrara.
Sorry, just a dump of thoughts at this time. I'm still on a major learning curve with Carrara, PyCarrara, and Python. :)
Not at all... please... dump those thoughts. Saying stuff out loud always helps.
First of all... yeah. I like what PyCarrara (and Frederick) did with that walk cycle. That's beautiful.
Next, for the power of being able to drive a walk cycle, how about the interface being nothing more than an explanation of what parameters to look for, like the excel - like format in the current manual. Just tell us where to look and we take it from there. Your manual makes this script really easy to use, I think. Too bust to try it atm.
Next, Leave memory consumption up to us as well. I'm glad that you're taking that into consideration, so that you have the ability to exclaim: "Don't crank this too high or..." sort of thing. But when we start talking about animating masses, we should expect to use caution or else!
Here are some thoughts on that front:
Animations are laid out by PySwarm by creating Keyframes.
Carrara has the ability to convert all or some keyframes into NLA clips.
NLA Clips can have all manner of things happen to them.
Using the combination of PySwarm and Carrara's NLA features gives us a good method of "saving" our PySwarm results for later use. The PySwarm setup already does all of the work to get the animation to take place. Imagine how reusable just a few objects worth of BOIDs can be to create a city full of people or a battlefield full of fighters! I'll often take a longer animation clip and have different people use different parts of the same clip over shorter render times to be stitched later. Alternatively, we could use a bunch of people and control them all with PySwarm for shorter periods of time. But if memory is less of an issue, we could PySwarm longer animations, and just use several cameras to film shorter periods along the same scene. This make for some really efficient Batch Queue rendering. I normally have no less than four filming cameras on busy scenes set up to catch different points of view. That gives me at least four batch renders off the same scene file - which gives me more choice during the mastering stage.
Oh, geeze... I'm babbling again. I just did that in another thread - and said I was going to bed... I better do that!
I've been spending a lot of time and thoughts on how to inject a walk cycle.
My conclusions is that it's better done on two stages. First, move the character (it's what PySwarm does), and then apply the walk cycles when you know speed and heading.
If you have poser and Fenric exporter (and a lot of time for a crowd), you could even use poser walk room :-).
I've tried algorithmic walking See Boulic works and the mathematica demo, but it was not so easy to implement variations that looked natural enough and, furthermore, it was limited to human walking.
Right now, I'm heading on a BVH retargeter (I have a demo working) which allow to extract walk cycles quite efficiently. I was planning to mix it with some of Boulic works to add a realistic variation in speed.
For birds, it's somehow easier (mainly, I think, because most of the people won't notice discrepancies), so it may be a good start.
Dartan, all good thoughts and questions. Thanks!
At the moment, I am thinking of applying something like what Frederic demo'ed with PyCarrara here:
http://www.youtube.com/watch?v=nNr7y61VLy0
But I am thinking of a "walk" as really any cycling motion of the boids - swimming motion for fish, beating wings for birds, etc. And yes, that PySwarm would inject keyframes to drive the motion. The real question is how to create an interface that is relatively easy to use, but is capable of handling complex "walk" cycles. I recently acquired ERC, and am thinking of ways to integrate PySwarm walk animation with that plug-in. It may make PySwarm's work easier, but would require having that plug-in. It might work for the first phase.... I'm always open for suggestions and thoughts on this topic.
I should mention that my initial testing seems to indicate that embedding lots of keyframes to an animation does not consume a lot of memory (which is a bit of surprise since some aspects of Carrara does not seem to be memory efficient). So injecting repetitive keyframes is an option to pursue (at least for now and address memory problems if they arise later).
I have watched the PyCloid animation sequences, but have not had a chance to dig into it yet. I suspect (at first blush) that it has at least the potential of PyCarrara.
Sorry, just a dump of thoughts at this time. I'm still on a major learning curve with Carrara, PyCarrara, and Python. :)
All good thoughts, but NLA clips are currently at the boundary of my Carrara knowledge. I've not pursued much in that area because until the past month, I've not done much in animations. I'll be looking to you and other experts on this to offer guidance and help build a script that works best. (This might be one of those areas to enhance PyCarrara - manipulating (creating, inserting, moving, etc.) NLA clips.)
All of this is still a few weeks down the road, but I can sense you and others are building a vision of where this might go. That is awesome and I'll look to you all to drive me in focusing on this. (I get easily distracted, so I need an occasional pep-talk! :) )
For now, I am hoping to have V0.4 ready for release at the end of this week (to coincide with Halloween ... Hmmmm....). I may hold back on inserting any "walk cycle" animation until the dust settles on V0.4. Then V0.5 would be specifically targeted at how to animate the objects (not just move them).
Okay, now, it's time to get my nose down to the grindstone and run some more animation tests....
I like the idea of retargeting BVH files, and am looking forward to seeing what you've put together! A Python module that reads BVH files might be an awesome addition to PySwarm. ;)
I am definitely looking forward to shifting into exploring the various options to animate "boids." This is really exciting! Thank you! :)
Oh, right.
You - don't worry at all about NLA. PySwarm creating Keyframes is absolutely it. Perfect.
End User - may use NLA to remove animation data from the timeline to run another script - is what I was getting at - somewhat.
What I was meaning is that, with Carrara's NLA features, individuals can really be recycled in other areas of the scene - especially in the background - to add even more motion to the scene - making PySwarm an ideal approach the way it already works.
This is some excellent stuff.
LOL! Many innocent blunders in history have been recorded as "excellent stuff." ;)
I am not sure I understand what you're getting at.
One interpretation - You can create multiple "groups" in a single scene. You just have to make sure they are named differently, so PySwarm doesn't confuse them. To complete an animation sequence, you would import multiple PySwarm scripts - one for each group. The script doesn't really care what else is going on in the scene. A few simple examples of this: two groups of fighter aircraft in a dogfight; or a flock of birds getting flushed from a field where a group of hunters and their dogs are walking (that's 3 different groups).
Of course, the downside of this is that (yet) PySwarm doesn't allow different groups to interact while generating the keyframes. I do have a "Predator-Prey" rule I will work on later where a single script will manipulate two separate groups. That is the first step in adding greater integrated animation.
An afterthought: The above statement is really only HALF true. You can create some limited interaction between groups by using the ATTRACTOR rule. This is how it would work - First, run PySwarm on one of the groups. Then, when you run the PySwarm for the second group, you can select either the "Camera_Focus" object in the first group (which is the center of mass for that group) OR one of the individuals in the first group as the Attractor object. This would work, for example, to animate dogs flushing quail from brush. The first group would be the quail, and then have the dogs (as a group) be attracted to the center point of the quail. Some tweaking would be needed, but I hope you get the idea....
Another interpretation - After running the PySwarm script, you can manually change any of the keyframes inserted - in essence rescripting the behavior. Adding NLAs is one thing you can do. Also, since PySwarm doesn't insert keyframes for all aspects of an object (i.e., right now, it only does (x,y,z) translations, and later, rotations), you have all of the other animate-able aspects to work with. And PySwarm won't mess with what you do there, so only translation keyframes get erased if you rerun the PySwarm script.
Are either of these on point? I want to make sure I understand as this can influence my priority of work.
What I'm talking about isn't adding anything to the script beyond what you already have in mind. You just keep on a workin', where I said nothing at all! lol
So then I come along, as an end user. I open the script and set my parameters. Bam! PySwarm sets all of these wonderful keyframes. They were a product of my preparation as the end user. I am being less thrifty that some - as far as resources go - so I have a huge number of BOIDs involved. Well that gives me a lot of keys! I also set it to run for forty seconds, but I only plan to render three or four seconds at a time. Now I'm getting ahead of myself...
Okay, so I ran the script. I already had each individual set up to have it's own NLA track. So I can save all of the script generated keys into an NLA clip. Upon doing so, by default, all of my keys get deleted.
So I save my NLA Clips to my browser. One for each of my BOIDs that I had in the scene. Now I can use this motion on anything I want! So if I use the script to make BOIDs busily moving through a four way intersection. Some going straight, though avoiding other passers by, some rounding to the left and others to the right. I can use that single scene (with the keyframes intact) for multitudes of shots. But I can also save the NLA Clips to reuse the motions individually as well - as an end user sort of thing.
Basically - I was thinking out loud of some amazing possibilities that I will try with this script. And I do tend to babble.
Sort of like my mentioning using this along with PyCloid. Not asking for any new features... just daydreaming aloud! ;)
What I'm talking about isn't adding anything to the script beyond what you already have in mind. You just keep on a workin', where I said nothing at all! lol
So then I come along, as an end user. I open the script and set my parameters. Bam! PySwarm sets all of these wonderful keyframes. They were a product of my preparation as the end user. I am being less thrifty that some - as far as resources go - so I have a huge number of BOIDs involved. Well that gives me a lot of keys! I also set it to run for forty seconds, but I only plan to render three or four seconds at a time. Now I'm getting ahead of myself...
Okay, so I ran the script. I already had each individual set up to have it's own NLA track. So I can save all of the script generated keys into an NLA clip. Upon doing so, by default, all of my keys get deleted.
So I save my NLA Clips to my browser. One for each of my BOIDs that I had in the scene. Now I can use this motion on anything I want! So if I use the script to make BOIDs busily moving through a four way intersection. Some going straight, though avoiding other passers by, some rounding to the left and others to the right. I can use that single scene (with the keyframes intact) for multitudes of shots. But I can also save the NLA Clips to reuse the motions individually as well - as an end user sort of thing.
Basically - I was thinking out loud of some amazing possibilities that I will try with this script. And I do tend to babble.
Sort of like my mentioning using this along with PyCloid. Not asking for any new features... just daydreaming aloud! ;)
Okay, got it! I understand. I think you leaped a mile ahead of my horizon for PySwarm! The farthest I'd gone down that stream of thought was in using simple boid objects (like the ones in my test scene) to work out the knots for how it would play out in a real scene. And when all kinks and problems were tweaked out, then simply rerun the resulting script on the REAL scene with my more complex objects. You've taken that idea further. Thanks for sharing!
And your thoughts of PySwarm's potential application does help, so no worries about stream of consciousness!
Well it's just that I like to save animations if I think that they're cool - and that they're reusable. I get a feeling that this script has the potential to create many, many reusable animations!
PyCloid can add even more attraction/repulsion to these animations using particles! I think PySwarm is going to be really cool - and I look forward to seeing it in action. PyCloid is another plugin I have from Frederick Ribble that I need to get my head around to using. So just the thought of both together sounds like a lot of power... and fun!
The way I can envisage using it is as follows. Develop a walk cycle / flapping cycle etc for your actor and save that as an NLA clip. Loop the clip so that you have an object (just one at this stage) walking / flying on the spot. Duplicate that object and the rename each instance using the suggested number scheme that PySwarm uses, and at this stage you can also stagger the NLA loops so that they are at different phases and not walking / flapping in sync (unless that is what you want, eg. for a marching band?).
Now apply the PySwarm script to produce the movement that you need, this should not interfere with the NLA clips which are producing the character articulation. You may need to adjust the maximum speed for walks so that this matches (more or less) the step size in the NLA clip. You should now have a group of people / flock of birds etc, all articulated and all moving according to the rules that you have set.
Particularly for walks, this would not stand up to close scrutiny of the feet, but for many purposes this may not be an issue anyway.
I hope this gives food for thought.
Still. FD may take his time working on that walk designer. Like you've said, one might have to adjust velocity... I was thinking along the other path... stretch or contract the NLA clip to match the velocity prior to placing that check mark into the 'loop' box. Either way... his conversion of BOIDs to Carrara via PyCarrara is a true blessing to the Carrara Animation society as a whole. Hmmm... that has a nice ring to it... Carrara Animation Society! Phil, you wanna start a club?
Speaking of which, I wonder if this script is copping any buzz down at Carrarators. I'm so far behind in what I mean to do here, and at the Cafe, that I'm having a hard time making it to 0oseven's cool new site. I guess he has some bugs to work out, though... so maybe I have time.
Back to PySwarm, I have been getting all sorts of imaginative ideas for uses with this script. Follow me on this, Phil... you know how you made those shaders for your particles bit on the rocket in the Advanced Training? What if we used similar techniques (without using the Particles Shader, but similar techniques) to use these BOIDs as special effects, natural effects, other scene elements? With this sort of power, we could even use this along with the powers of PyCloid to create some real, running water, I'm thinking! Flocking and Predator swarming behaviors can have all sorts of benefits to animation - even if (perhaps, especially if...) you can barely see the driven objects, due to them being nothing more than fantastical air or (with the use of PyCloid) swarms of bugs or other type of effect...
The problem is two-fold:
My imagination won't let me sleep and
My project won't allow me the few minutes to try the script for myself, right now
Soon, though. I've watch the video and would love to see it again, but I've finally got that song out of my head. Hmmm... dilemmas.
Oh... about matching the feet:
Also, like you've said (PhilW), much of the time this shouldn't really be an issue. We can always hide the feet-to-surface view in some way.
I was just watching Star Wars (AGAIN, says Rosie! lol) Episode I and noticed a lot of places where CG characters feet are often hidden from view where they must meet the surface. It's amazing how such a small detail can totally blow a video. I was playing a game and saw, in some of the cinematic scenes, that the feet were sliding. It's funny because, if the feet weren't sliding, I'd never have even noticed the feet at all. I'm not the sort of person that watches something with my judge-scoring pen and pad (like evilproducer and his actor/director brothers!) looking for places that suck. You can get away with a lot of errors and still collect me as a fan - or so I might think. But Star Wars doesn't even really try to hide the fact that they're masking the foot-to-surface contact! They just plunk a piece of scenery just in front of it - like a 2d plane of plant life, like grass or something. When I finally do get round to scrutinizing, I see this billboard placed in such a way as to mask the fact that feet are sliding! lol
The moral to that story is that it's far better to have someone notice that you've placed a billboard, that to have everyone notice that feet are sliding! ;)
I'll often just give the scene a good reason to keep the camera elevated enough to not shot foot-to-surface contact, unless the feet are not sliding - where I happy show them off! :)
Um... before I get into trouble on the above post:
There are many other reasons to mask the feet besides them sliding. Perhaps they weren't sliding at all and there was another reason. So be it. The point remains the same. Getting great mass movement - especially in such a natural way - is far more important than worrying about foot slide! lol
Gosh, there's a lot there! Just to pick up on your thoughts about running water, I think you'd need to use a particle-based system rather than anything that PySwarm offers. Keep in mind that PySwarm requires separate named instances of an object, I'd hate to have to do thousands of those! (But then again, maybe there is a way to script that!).
Interesting about finding sliding feet in Star Wars and using props to obscure that for a lot of shots - goes to show that we all have the same issues! There are a few ways to do this
- place the camera low and shoot upwards so that the feet are not in frame;
- use an object or scenary (or even dust) to obscure the view of the feet;
- have so many "actors" that the feet aren't visibly as they are obscured by other actors;
- or simply film from the waist up!
PyCloid is a particles plugin by the same author as PyCarrara.
Using the same attractor that uses PyCloid as your BOID in PySwarm!
For many things you'll be allowing the particles to do the visual work so the object itself has no other needs - just to be the attractor for PyCloid and the BOID in PySwarm, and you can flock these particles. And particles can really be anything! Just a few spurts here and there... or a massive cloud. They could even drop particles that go nowhere, too. But with the power of PyCloid... it gets me thinking all kinds of thinks. :)
So how about this:
Make a model of the river bed or a water slide... etc., and run the boids through it. The BOIDS are using PyCloid enhanced emitters.
Go to thePyCloidsite and check out the videos in the Gallery menu. Otherwise, here's a Playlist of all of Frederic's Demo Videos for PyCloid to help show off it's amazing abilities with a single link. I also want to model a low-flowing current mesh and make an animated texture map for current changes around rocks and such. Hey, it's my dream, right? Dogwaffle Rocks for these sorts of things. I wanna try it. But I've also been kicking around the idea of using particles with special shader settings that make them fade from visibility further away from center, where there's a nice water shader. With multiple BOIDs, you can drastically change the size, shape, everything, about the particles. All PySwarm cares about are the names and the hot points. Am I even awake? I better go and check.
I read slowly through the dialogue from yesterday, and probably need another day to digest it all. But so far, I've taken away several things of immediate value:
1. PySwarm V0.3 was released to mostly test the water. It was not really intended to offer enough functional control to do anything meaningful, but allow others to experiment with it. With that in mind, it seems to be serving its purpose of creating and gelling some wonderful ideas in ways I had not thought of. My intent with V0.4 is to expand on the basics of V0.3 to make it usable to animate BOIDs in real (though somewhat basic) animations. Thus, I am attempting to adapt the improvements I am making to handle the "winds of change" in its potential use. Later today, I will post a list of the changes/additions I am working on for V0.4, and ask for feedback to see if that set of changes work.
- To illustrate the value of these discussions, one change I am making after reading the above description is I need to have a "minimum speed" setting in addition to a "max speed" setting. I was planning that for V0.5, but a minimum speed would be useful to reduce the "sliding" effect of slow moving BOIDs on a surface. So I am adding that to the V0.4 changes.
2. While I had originally intended to add "cycling" (I guess we've not quite settled on the right term to use) to V0.4, I may hold off until V0.5 and let others test integrating NLA loops into PySwarm motion. I suspect, as mentioned in the above posts, it is possible to create animations that would pass the litmus test of the average viewer, though maybe not under technical scrutiny.
3. After releasing V0.4, I will sink my teeth into PyCloid and see how this might be integrated into PySwarm capabilities. I have been meaning to do this, and it would probably be fruitful to do that sooner than later. It is still not clear if and how individual particles can be manipulated. It would be so much easier to drop a particle emitter into a scene and let it "pump out" the BOIDs. With the ideas formulated so far, I now have a better lens through which to view the PyCloud plug-in. :)
4. After looking at PyCloid, I need to contact Frederic. There are a number of changes I'd like to suggest for PyCarrara, now that I have a specific application for it. One of them is whether it is possible to have PyCarrara actually duplicate BOIDs for the scene. That would simplify a lot of upfront work! I have other needs.
Thanks Dartan and PhilW for sharing your thoughts and energy!
Here are the current modifications I am working on for V0.4. Most of these have already been scripted, and I just need to finish testing them.
1. Add MAX_TURN rule:
This rule limits the angle an individual can turn (e.g., bank) during a given time period.
2. Add LANDING rule
Individuals will land briefly if their path takes them to the ground.
3. Start and End times
Modify the current “sim_time” variable to set specific start and end times in the simulation for PySwarm to run.
4. Initial positioning
Allow the following positioning options to start the simulation:
(1) with the current placement of individuals
(2) inside a circle with a predefined center and radius (flat surface)
(3) randomly placed inside the bounding 3D space
5. Initial velocity
Allow the following initial velocity options to start the simulation:
(1) Set velocity vector based on the direction the individuals are facing (heading) and initial speed value (speed)
(2) Set velocity vector using a predefined vector for all individuals
(3) Set velocity vector randomly
6. 2D/3D Space rules
Allow conditions to limit movement on a surface (2D) or in a 3D space. Phase 1 2D (V0.4release) is for flat surfaces; phase 2 (in a later release of PySwarm) 2D is for terrain following. This goes with mods to setting the initial positioning and velocity vectors.
7. Pitch and roll
Adding banking and pitching adjustments when individuals are in a turn, climb, or dive.
8. CONTAINMENT modification
Containment structure can be a box, cylinder, or a sphere
9. Rule adjustment parameters
Change rule adjustment parameters to be on a scale where a value of 1 is for normal operations, values near 0 being "weak," and values over 1 being "strong."
10. Minimum speed
Some objects must maintain a minimum speed (they can't stop). Add the parameter "min_speed" to the SPEED_LIMIT rule calculations.
If there are any other suggestions you can think of that you believe would be useful in starting to create some basic (i.e., pre-cycling) swarming animations, please let me know!
That looks to be a terrific list and should be able to produce some very varied animations! You appear to be making very fast progress on this, great work.
Yeah, kudo, FD... Kudos!
@FD: I am so happy to see PyCarrara coming back to life !
Integration with PyCloid may pave the road towards crowd animations with more than 100.000 objects.
I am looking forward PySwarm project next steps !
Frederic.
The master himself!
Yeah... I think FD was reading me that I wanted him to integrate PyCloid functions into his PySwarm script. I mean... if he can and wants to... sure! But I was actually dreaming of using BOID bots that already have PyCloid applied to them. I have many other dreams for this thing. But I wanted to release those thoughts to the public before I drove myself mad! That's a lot of awesome to keep trapped up inside!
Now I have to dig up that great video that McGuyver made, using PyCloid to make running water. Study it a bit... get lost (again)... and then ask him how in the world he made that look so freaking real.
Update
I will be releasing PySwarm V0.4 for public use after a few more days of testing. I will update the title and first posting in this thread when it is released.
You can watch a 5 minute demo reel for this version showing some of the new features and capabilities:
http://www.youtube.com/watch?v=gJje10XVy-Q
My hope is that, with this version, there are now enough features and capabilities that people can start creating real animation sequences.
Here is a brief summary of the improvements in V0.4:
1. New MAX_TURN rule
2. New LANDING rule
3. Now set start and end simulation times
4. New initial positioning options
5. New initial velocity options
6. New 2D/3D space rules
7. Pitch and bank added
8. New CONTAINMENT shapes
9. Improved rule adjustment parameters
10. New minimum speed
11. Improved algorithm and bug fixes
12. Input error checks and warnings
You can find more information on these changes on this post within this thread:
http://www.daz3d.com/forums/viewreply/466706/
Looking forward to it - some great examples in your video too.
Wow! This is amazing! Quick someone render the next Ender's Game!
Just a suggestion on your sample render videos FD, to either turn shadow strength down or render with a shadow buffer light…. The stingray's shadows are dark and sharp, and it makes their motion sometimes difficult to understand.
Incredible stuff!
Good point, Holly. Will do. Thanks!