Ahhhhh, sorry to bug y’all again, but I’m having severe difficulty with this crowd sim project of mine!! Coding the backend toolkit is not a problem as its what I’m used to doing, but the interface/GUI is really bugging me!! 
Could anyone give me some pointers to how this type of app would work as a plugin please? For example, how would it be best to create new actor classes, script the brains for the little guys and turn the simulation into animation data? Any ideas?
Cheers
Dan (again!!)
From what I understand of reading your previous posts, you’re aiming to develop this as a C4D plugin.
I don’t know about C4D, but from my own experience of writing Maya plugins I know that trying to conform to someone else’s architecture whilst also trying to develop your own vision is nothing short of a bitch.
I’d think about whether you could restructure your plan to do the main body of your work - the crowd sim - in an outside app of your own creation , i.e. an OpenGL visualisation. Then you could just worry about importing an exporting cached skeleton data to and from C4D (or whatever app you choose), leaving you to concentrate on the hard stuff on your own terms.
The other huge advantage of going that route is that you could (relatively easily) just re-write the importer/exporter for other packages…
Interesting!! I did intend to develop ‘Noodle’ as a standalone app with OpenGL rendering, but decided that a plugin for Cinema4D would be easier and quicker to develop as a lot of the mundane low level stuff was done for me - i.e rendering, scene graph management, IK, etc.
Do you think it would be easier in the longrun to do it the old way rather than conform to the plugin architecture?
Dan
Definitely… How are you planning on doing the movements of the characters? If you’re going to be using motion capture clips–or just baked keyframe animation–then it’s the most senible way of doing things.
Remember the things you mention–rendering, scene graph management and ik–should not really have anything to do with your crowd sim. You just want to concentrate on moving characters over a polyonal landscape by blending motion clips. All you need for that is an opengl preview. All the rendering and other stuff should be handled by your host program.
That helps integration with your host program itself as all you export back to it is a bunch of joint-cached skeletons, keeping it light-weight.
But you might also want to consider later on doing the skinning yourself, and ultimately rendering directly in renderman. After all, I don’t know a piece of software that can easily handle update and display 100,000 fully skinned, hi-res agents in near-realtime. Do you??
I think the thing with a project like this is it’s very easy to start thinking “wouldn’t it be cool if…”. You should just concentrate on doing the bare minimum UI stuff that you can to get the thing working. Concentate on the crowd sim. Churn out stick-figure opengl previews to start with (after all, they’re fun to watch!), then worry about getting it into C4D, Max, Maya, prman, or whatever.
Like Hugh says, if you do it completely outside an app, you can then write translators for any app you like much easier than trying to port application-specific code later on.
Also, for a project of this complexity, I’d advise scripting as much as possible. Do the low-level stuff where you really need the speed in small C++ modules that are tied together by a high-level language. This way you can take a lot of work off your shoulders, have a faster development time, and also allow end users to fiddle a lot more with the way the thing works to get the results they want.
Hmmm. Making the app standalone is sounding a lot better, and easier to create a flexible product.
With ‘Noodle’, the animation will use either keyframed or mocap, just need to find a way to export animation out of C4D, tho not sure if it has same architecture as Softimage (and others) where you can store clips or actions. Any ideas?
Not sure about whether to export back to package as baked anim data or as Renderman RIBs. Probably the latter would be harder as I’m aiming at pro-sumer market, so not sure about availability of Renderman in that market?
In terms of architecture, I’ve got the backend stuff complete, so all services (pathfinding, FuSM, etc) are available to the agents, and am now looking at whether to use Python as my scripting language of choice. But still don’t want to make it all too techie, and would prefer it to be artist-centric.
What else would be useful?
Dan
Out of interest, what’s “FuSM”?
If C4D doens’t support some kind of clip format, then maybe it’d be an idea to generate your own… after all if you’re going to be exporting skeletons, you’ll need some kind of standard skeleton model to work with.
Bringing it back into the package should be as easy as just creating a bunch of skeletons, then reading the cached skeleton data you’ve created off disk frame-by-frame.
Originally posted by playmesumch00ns
Out of interest, what’s “FuSM”?
Fuzzy State Machine (Info here)
Originally posted by djwarder
Not sure about whether to export back to package as baked anim data or as Renderman RIBs. Probably the latter would be harder as I’m aiming at pro-sumer market, so not sure about availability of Renderman in that market?
Personally I would be very interested in seeing RIB output from this sort of tool. I run the Open Source project Aqsis which is a Renderman compliant renderer, so would be very interested in seeing how it would interoperate with your proposed product. (Plus this response sort of answers your question of availability of Renderman in the pro-sumer market).
Cheers
PaulG
While it is available, I suspect a lot of pro/consumers would probably much rather use their packages renderer.
I’m not saying that this is the right attitude, but I think it does reflect the outlook of the majority of people who do not do CG full-time.
At the same time, personally, I’d much rather see a renderman-compliant output…
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.