Tracking the development of the BlenderPeople script suite.
Thursday, June 05, 2008
Train leaves the station...
I'd say that I'm not veering back into BlenderPeople development, but I know how I am. It's already in my head, so that means that within a few weeks I'll be fooling around with it again.
Also, I've started coding solid animation baking and conversion into Blender, which it needs anyway. Basically, it boils down to A) Bake motion from constraints and parenting relationships to Ipos; and B) Convert bone level to object level animation and vice versa.
I have the object-level baking engine working, but it needs lots of interface work, both internal and external.
Monday, January 14, 2008
Some thoughts on the road ahead...
A commenter on the BlenderPeople page brought up some issues that have been addressed before, and some that haven't, and I thought I'd respond on the main page, so that anyone interested will most likely see it.
I would like to remind everyone that while I have tried to make BlenderPeople as easy to use as is possible at this, and also to provide comprehensive documentation, it is still a 0.8 release, and, for that matter, a personal project. Yes, it's one that a lot of people are interested in, as evinced by the fact that the BP page and XML feed gets more traffic monthly than the rest of my websites combined by an order of magnitude. But I decided a long time ago that "public interest" was not going to rule the development process, and, in turn, my personal life.
I think that anyone who has read and worked through the Quick Start in the (IMHO) really great documentation would have a hard time saying that I've simply said "Here it is and good luck."
As for making money from it... well, the software isn't ready. And neither is Blender. My footstep generation solution is interesting but hacky, and Blender itself doesn't have one yet that creates real footsteps. It's still just cycled motion. As I have source commit "powers" and have done some work as one of the minor developers with Blender, I see it as up to me to put such things (baking tools and a good footstep system) into Blender as would be generally useful for all character animators, as well as for BlenderPeople. There are no "Blender Gods" that I need to bring an offering to for this: it'll hinge on me bringing a great proposal and solid working code implementation to Ton and Josh.
And now, a reminder about where I see BlenderPeople going by the time it hits 1.0:
- The controls and UI integrated into main Blender panels, via the current tools API and event refactor, or, if that doesn't become possible, using one the other Python scripter's interface layers for a much better control system.
- Significant increases in speed. Right now, speed is prohibitive for anything over 1,000 actors due mostly to search times during the first phase and a lack of dupligroup pose caching in the second phase. I have a couple of ideas for drastically cutting search times (near linear scaling, instead of n^2!) that I've worked on paper, but have yet to put into code. Ton and Josh tell me that pose caching for duplis is not that big of a deal to implement, so I'm sure I can expect some help on that when it becomes the big bottleneck.
- Automating the use of Level of Detail -- it's in there right now, but hidden. You can do it "by hand", but I want it to be automagic.
- Better animation blending and a real footstep system. If I go "100% pose space", it will avoid the crazy "swoops" you see in the demo animation., which is what's going to happen.
- A couple of different demo setups, including a hand-to-hand combat one, a "city streets" one and a stadium/crowd rally.
- Making the behavior tree nodal. Right now, it's hard coded, and works pretty well for a default, but if Python coders can get access to Blender's node interface, this could easily and usefully converted to a nodal system. Such a change would give BP an enormous boost.
- Support for multiple materials and variable character types for assisted/automated generation of diverse crowd meshes.
On the prospect of eventually making money, it could certainly happen. The software will remain Open Source (it's GPLv2 right now), but people who have a commercial need to implement it will always be free to obtain real support directly from me for a fee. Likewise, libraries of commercial quality characters and actions, including motion capture, could be sold.
Personally, I think that's the biggest barrier to using the software in a production environment, both now and in the future: creating the actors and animation. The motion engine itself actually works well enough and could produce usable results right now if the modeling and animation library were good enough.
So, that's where BlenderPeople stands, and where it's probably headed, in case you were wondering. (Cross-posted at harkyman.com)
Tuesday, December 18, 2007
Just Letting You Know the Score
BlenderPeople development is on hiatus while I am writing my book. Development will resume in the Summer of 2008. I’ve had a number of requests for step-by-steps about getting BP running, and requests for personal service. Due to my writing schedule, I can’t give personal service right now. Also, the documentation is complete as of the latest version and contains a step-by-step simple startup. If you can’t get it working from that, I just don’t have time to help you get it going. Sorry for the inconvenience, but 1) 0.8 release and 2) free.
Wednesday, August 15, 2007
Just to clear and on the record, BlenderPeople is still on hiatus. While I can carve time to work on BP itself, maintaining a separate build of Blender that has the features that allow it to function in line with BP's needs is really "out of scope" for me. When Blender catches up, I'll be there.
Two little tidbits, though:
1. I actually got to show it at SIGGRAPH this year, at least in the Blender booth. I was fiddling with it and someone came up to say "How are you getting MASSIVE to run inside Blender?" which is funny because of how totally much BP is not MASSIVE.
2. I think I have a new way to find nearest neighbors that will be significantly faster than the previous one. It's a diagramming method. I'm not really into the theory of that sort of thing, but I know how it works from a functional standpoint. Of course, after my last try at something like this was a bust, my confidence is a little lower.
Tuesday, February 27, 2007
Demo in Boston Next Week
I'll be speaking/giving a presentation/doing a Q&A about BlenderPeople and group AI in Boston at the Asgard on Monday, March 5th. The organization that's hosting is called Grey Thumb. From their website:
"Grey Thumb Boston is a group of scientists, engineers, hackers, artists, and hobbyists in the Boston metro area with a strong interest in artificial life, artificial intelligence, biology, complex systems, and other related topics."
The release they're sending around:
"When: 7:00pm March 5, 2007
Where: The Asgard (350 Mass. Ave, Central Square, Cambridge)
Who: All are welcome
BlenderPeople is a free, open source crowd and combat simulation
project. The system uses a combination of Blender 3D, Python programming
and a MySQL database to generate and track the motion and interaction of
Actors within a simulated environment. Although there have been other
partial implementations of free crowd simulation software, BlenderPeople
is the only one currently in development that offers a complete
solution, from initial visualization through final rendering with high
resolution character models. The project is not intended to be a
realistic crowd simulation in the sense that one could use it to model
emergency escape routes for architectural design, but focuses on
producing animation that will be believable from an entertainment
perspective. Technical issues that are addressed in BlenderPeople are
different path finding algorithms for different time constraints,
avoidance and self-structuring behavior of Actors from short rule sets,
programming of Actors through simple distance thresholds, and a novel
approach to footstep based character animation. Currently, the project's
focus is on slashing search times for nearest neighbors from the field
So, if you're in the Boston area and want to say Hi and see me demo BlenderPeople, you're welcome to stop by. If you want to come, leave a comment so I know who to look for!
Wednesday, November 01, 2006
With the ground height and color tree searching moved into Python, that leaves the nearest-actor calculation as the single biggest time sucker in BlenderPeople. I know I'm not supposed to be working on this right now, but I think I've come up with a way to do this significantly more efficiently than I have in the past.
The way it works now is that every time an Actor needs to know who is closest to him in the simulation, a distance calculation is done against every other current Actor. An Actor may ask for nearest person up to four different times in a single round. This means that the average number of distance calculations (followed by a non-indexed proximity sort) is (Actors^2)*2 (two times the square of the number of Actors). The "squared" part means that as the number of Actors goes up, efficiency declines not linearly, but as a square. That's bad.
Here's my brainstorm, and what I'm working on (it may turn out to be crap, and not work, but my ideas like this usually pan out): When it moves, an Actor gives itself a three-numeral score, based on the distances from three constant, strategically chosen points within the ground area. These three values locate the actor discretely within the field of play. Then, a sort is done against the whole Actor set three times, using each of the current Actor's values in turn as the zero point for the sort, the difference from the main sort value is cached. The Actor with the lowest cumulative cache after the third round should be the closest, if my mental model is correct. With this model, Actors are required to make three distance checks (Actors*3), then four indexed sorts. On queries, no new distance calculations need to happen -- just the triple-sort.
My guess is that the difference will not be noticable on requests with smaller actor pools (100 actors with old method = 10,000 distance calcs + 200 sorts; new method = 300 distance calcs + 400 sorts), but on larger pools (2,000 actors old = 2,000,000 distance calcs + 4,000 sorts; new = 6,000 distance calcs + 800 sorts).
If this works it will dramatically increase the speed of BlenderPeople, and in turn making it a viable tool for larger and larger numbers of Actors.
Tuesday, October 31, 2006
Well, now that the old house is sold(!), I'm not living in mortgage-induced poverty any longer. That being the case, I finally found a nice price on a new computer. Our old kitchen computer had been on the fritz for a long time, and I finally replaced it last night with my main workstation.
Being delivered tomorrow to my house is an AMD 64 X2 (dual core) machine with 2GB of dual channel RAM, into which will be placed the very tasty nVidia Quadro FX video card gifted to me by the Blender Foundation (thanks guys!). Although I'm neck-deep in other projects right now, I feel quite certain that I'm going to have to take an evening off to see how the dual cores and generous RAM allocation treat the parallel processing task that BlenderPeople presents.
I'll let you know how it turns out.
02/01/2004 - 03/01/2004
04/01/2004 - 05/01/2004
05/01/2004 - 06/01/2004
06/01/2004 - 07/01/2004
07/01/2004 - 08/01/2004
08/01/2004 - 09/01/2004
09/01/2004 - 10/01/2004
11/01/2004 - 12/01/2004
12/01/2004 - 01/01/2005
01/01/2005 - 02/01/2005
02/01/2005 - 03/01/2005
06/01/2005 - 07/01/2005
09/01/2005 - 10/01/2005
10/01/2005 - 11/01/2005
11/01/2005 - 12/01/2005
12/01/2005 - 01/01/2006
01/01/2006 - 02/01/2006
03/01/2006 - 04/01/2006
04/01/2006 - 05/01/2006
05/01/2006 - 06/01/2006
06/01/2006 - 07/01/2006
07/01/2006 - 08/01/2006
08/01/2006 - 09/01/2006
09/01/2006 - 10/01/2006
10/01/2006 - 11/01/2006
11/01/2006 - 12/01/2006
02/01/2007 - 03/01/2007
08/01/2007 - 09/01/2007
12/01/2007 - 01/01/2008
01/01/2008 - 02/01/2008
06/01/2008 - 07/01/2008