Jump to content
  • Advertisement

Danathus

Member
  • Content count

    26
  • Joined

  • Last visited

Community Reputation

224 Neutral

About Danathus

  • Rank
    Member
  1. Hey everybody, I'm resurrecting this thing. The reason why nothing has happened so far is because I was more or less waiting until I went back to school full time, so I could dedicate myself to this project. A lot of time passed and I didn't manage to successfully pull myself away from work. In today's economy, it might be a good idea for me to wait while I do have a steady job. That said, I think I can manage to work on this part time, and I do have something to start this project with. So, it's in its infancy, but here it is: http://code.google.com/p/react3d/ ^ There is some code in there, which I am still working on. Anyone interested, please check it out and let me know what you think. If you want to help collaborate, let me know, and I'll see about figuring out the required permissions.
  2. Hey everybody, I'm an experienced C++ programmer who is relatively new to CMake and very new to developing on OSX (traditionally exclusively a Windows developer). I've got a project I'm working on written in C++ using SDL and OSG, and so far I've been developing exclusively in Windows, though the whole time I've been trying to keep my code theoretically cross-platform. I switched over to the CMake build system as a step towards building on multiple platforms, and now I'm trying to get my CMake scripts working for OSX (on my recently purchased MacBook) -- and I'm having some difficulty. I finally got everything compiling and the static linking apparently sorted out, but now when I run my application, I get some odd behavior. I seem to not ever see anything but a blue screen, and when I query for some things (like the viewport and lights and such) I get NULLs back when I'm expecting valid pointers. Note this is all code that works fine on Windows, and (as far as I can tell) my code isn't making any assumptions about building under Windows. As an experiment, I tried creating an xcode project from the osg application template. I then took the code generated from that, and wrote a cmake script that would create a new cmake-generated xcode project for this example osg code. Now, this code is Osfield-blessed, and very short, and makes no assumptions about platforms -- it even built, and ran correctly on this very Mac -- when configured with the right build settings. However, I cannot manage to find a way to come up with the correct magical cmake incantations to generate an xcode project that will correctly build a running executable that looks like the example is supposed to. Again I get blue screens, nothing but blue screens... I know that people have gotten cmake-based OSG projects building on the Mac, so I must just be missing something -- but I have no idea what, and what to search for. I noticed that the template-generated xcode project has a big "Link Binary With Libraries" section for the application target, and my cmake-generated xcode project does not...I tried modifying the cmake-generated xcode project to attempt to manually recreate this, but it doesn't seem to change my results at all. Other clues I have stumbled upon when browsing cmake scripts that supposedly build for the mac but are for projects more massive than mine (and as such the scripts aren't directly transferrable) but don't really understand involve the install() cmake command...Is this a required step, that might be used to somehow correctly associate dependent libraries with my app in a way that they might run correctly? Or is that just for preparing my app for distribution, something I don't need to think about yet until my app is running correctly on my own machine? As you can see, I am very confused and am grasping at straws at this point. The holy grail would be an extremely short but effective CMakeLists.txt file that will generate an xcode project that can successfully build a runnable and correctly working one-cpp-file OSG application -- from there I have faith that I can study its essentials and extract the wisdom I need to get my application running...but short of that, even just some clues for what to search for or what caveats I should be aware of will be immensely helpful. Has anyone out there tackled this problem before? Please help! {: ) Thank you for your time.
  3. Hm. Well, alright -- thanks for the reply. That being the case (that no open-source solutions seemed well-suited), do you have any recommendations for what to build on top of for crafting one's own solution? From looking at the website you linked, our target applications appear to be very similar. Also fwiw we will be open-sourcing anything we come up with, as part of the Delta3D game engine.
  4. Hey everybody, I'm trying, with a group of like-minded people, to start a software development worker's co-op (to make games and other things). We're distributed across the US, so really we have a number of states where we might base the organization. My question is, to those in the know, what are the pluses and minuses of starting a software development company based in one state as opposed to another? FWIW I think we are leaning towards formally establishing it as a corporation, though that is not set in stone for sure yet either.
  5. Hey all, I'm not sure whether this should go in Multiplayer and Network Programming or in Alternative Game Libraries, so my apologies if it's miscategorized. I'm helping to develop a serious (non-entertainment) game, a training application that involves modeling contacting other players via phone and radio. We're hoping to find some nice straightforward open-source Voice over IP library that we can drop in for easy use. I've been tasked with getting the VoIP functionality working. I've done a little bit of poking around, and I've found this nice list here: http://en.wikipedia.org/wiki/Comparison_of_VoIP_software ...and the only section that seems applicable is the "Frameworks and libraries" section, so naturally I'm looking at Tapioca and Telepathy/Farsight...but I'm not totally sure what I'm looking at, and whether it's directly applicable for the kind of purposes I have. I don't really need 3D positional audio (at this time, anyway); I just need to be able to fetch audio from a microphone, send it over a network, and play it on the other side, and to be able to control when and to whom this is done. My development and test platform is a Windows PC, though staying cross-platform is ideal. Has anyone here ever incorporated VoIP into a game, not merely on the end-user side, but integrating it as part of the application proper? Do you have any recommendations for someone in my position? (BTW, someone on the official GameDev.net IRC channel mentioned I should come here and ask the moderator of this forum, hplus0603. They indicated you're some sort of expert or something. :) Hear my cries, oh mod!)
  6. Danathus

    ODE Installing problem

    The Windows binary distribution of ODE 0.10.0 can be found here: http://sourceforge.net/project/showfiles.php?group_id=24884 If you're a novice user of ODE, you probably don't want or need to be building it yourself -- it's an unnecessary complication at this stage. Getting the distribution that has .h and .cpp files is a bad sign -- you want a distribution that has .h and .lib and perhaps some .dll files. These are pre-built, so you can just link ODE into your app easily enough. If I recall correctly, this ODE distribution gives you several linking options. They all share a common set of header files, so you should be able to get past the compiling stage fine as long as you point MSVC (or whatever you're using) to the right header directory. Then when it comes to linking, you need to decide what exactly you want to do. Do you want to statically link all of ODE into your application? This might be easiest, though keep in mind that this will make your final exe file fatter than it needs to be. You might instead choose to go with dynamic linking, where at the link stage of building your app you link with a small .lib that just gives your exe enough information to know how to connect to the dll. Then, when you run your program, you need a copy of the .dll handy so that the operating system can hook it up to the code at program load time, as it starts to execute. Make your choice, and make sure that you're linking with the right lib! There's a fat lib for static linking, and a skinny lib, paired with a dll, for dynamic linking. Note that there will be one pair of each, for debug and for release. You'll have to tell MSVC (or whatever) how to find the lib directories so that it can link things up, and then you'll have to add the names of the lib files to the list to link with on the link tab of the project properties. Then, if you went for dynamic linking, the dll files will need to be somewhere in your execution path (the current directory (same as the exe) will work fine if you're lazy) when you try to run in order for it to work. I'm sorry if I went over some things you already know, but I had the impression from what you were saying that you were a little confused from having so many options, and were just trying things, rather than really understanding what they all are. I hope that this helps you make more informed decisions. Also, it would help to know at what stage you're getting these errors, and pasting some of them wouldn't hurt either.
  7. Danathus

    ODE Installing problem

    You're really going to need to be a lot more specific. What exactly are you trying to do -- compile an application that links with the libraries? Using what language/environment? What exactly are your errors, and at which point in the process do they occur? We don't really have much to go off yet, and the more you can provide, the more likely it is that someone here can help.
  8. I think you guys are basically arguing for the same thing really -- to have an internally C++ library with a C API trimming. I've seen this done before, as in ODE for example, and I definitely see why a C API would be a lot easier for other languages to bind to than a C++ API would be. However, I don't see the harm in exposing the C++ API as well as the C API, so that C++ programmers would have the option of using the C++ API directly. So I think the way to go is to essentially go ahead and write it as a C++ library (making extensive use of the modern engineering practices we know and love like the various design patterns), but continually maintain a C wrapper API that other languages can more easily bind to. In the end I don't expect the kernel to be very big -- it's mainly just a housing for the various bridges and the central pump for data flow -- so maintaining this C wrapper won't be so daunting a challenge as, say, wrapping up a massive scene graph library. While C#/Mono support hasn't explicitly been set as a priority, I certainly wouldn't want to stand in the way of improving the accessibility of this library. To that end, I will definitely add the instating of a C API wrapper (not replacing but in addition to the directly exposed C++ interface) and the option of building custom containers instead of using the STL to the list of priorities for this project. In response to your other points CoreyWhite, Horde3D and Bullet would indeed be great libraries to bridge to. Once the framework is in place and published, I hope the community at large will assist in developing all the bridges we could ever need. (: They'll be standardized and maintained within the same repository as the core. I see inverse kinematics as a control problem, so it's beyond the scope of the kernel, but possibly not the core at large. It might be most appropriate to handle problems like IK in a higher level control library that the kernel would bridge to, and since the exact scope of the control aspect of this project hasn't been fully fleshed out, I can't really say how it would best fit in for now -- certainly getting the infrastructure in place and working is the more immediate priority...But I'm sure it will find its place, and it's likely that it will be in the same repository. Going backwards to wodinoneeye, you bring up some interesting points about standards. As far as I know, this is entirely new territory, and much work has yet to be done to arrive at such standards. Perhaps here is a good place -- what ideas do people have? My first thought, for standardizing an animation format, is to have keyframe animation, where each keyframe is a list of torques/forces applied to joints. This would probably best be coupled with some sort of judgement thresholds that deem whether we're remaining successful or if something has gone awry and we should abort. With regard to physics and terrain, it seems to be common for physics engines to each have their own standard way of creating collision meshes for heightmaps (and other irregular 3d geometry). I'm confident that this problem is already taken care of and does not need to fall within the scope of this library. Finally, I've some good news -- I may be able to get funded for this project! I work as a programmer in the Serious Games industry, which means I write training and simulation software comprised of 3D real-time environments (basically non-entertainment video games). I've been discussing this project with my employer, who definitely sees the use of ragdolls in our applications, and who's been gaining interest in being able to have characters dynamically perform some agile maneuvers. So, they might potentially be willing to let me work on this project on company time, essentially funding its development. It's not at that point yet, as they would prefer that I write something tailored specifically to the engine we use, Delta3D (which internally uses CAL3D and ODE). However, my intention is to whip this up and then massage it into a more general purpose library, and then have it publicly published. [Edited by - Danathus on July 17, 2008 3:49:29 PM]
  9. That's my intention -- that the core library (the piece including the kernel) would only define interfaces for the bridges, and make no further assumptions about them other than that they implement the bridge interface. At the moment the plan is for three types of bridges, which I'm sure would require separate interface designs (though there may be some elements they share in common) -- those to skeletal character animation libraries, to physics engines, and to controllers. About the Controller Bindings, these basically serve as the link between the kernel and the controllers. The controllers are bodies of code that drive dynamic animation, and really could take any of a number of conceivable forms, though I had been assuming that they would quite frequently be scripts -- hence the use of the term "bindings." I realize now that it's probably better to just follow the more generic term and file this as just the third type of bridge, since you might want your controllers to be compiled code or in any previously conceived format. The design of this interface is definitely still in the research phase, a lot of which being wading through research papers to see how other people do things and to try to assess what sort of standards are already out there. I'd definitely appreciate any help in this area (thanks already for those links, l0calh05t!). I know DANCE has their own format, which seem to be arbitrary hand-coded controllers or simple descriptions of static poses that straight-forward PD controllers (feedback loops that take derivatives into account) are used to drive between, with python scripts to compose the various aspects of the simulation together (models, collision data, actuators, etc). What NaturalMotion uses for Euphoria is a mystery to me, though I understand one thing they do is run many generations of genetic algorithms to "grow" effective animations. One thing that the DANCE people write about is requiring that the controllers have full read access to the current model state, and that they implement an interface for assessing if pre-conditions are met, and for determining whether the controller is succeeding or failing (so that a higher-level controller, if you wish to arrange a controller hierarchy of some sort, could assess whether to switch behaviors). My first thought is that they be simple agents that in the abstract just reflect on the current status of the model at large (and any other data they are privy to) and issue commands to the kernel that call to apply torques at joints as desired. Thoughts?
  10. Danathus

    Modular Growing Character

    Your idea reminds me a lot of Katamari Damacy, in which you form an ever growing ball of random junk that starts out being just inches in radius that grows to being miles in radius. General principles you can glean from Katamari Damacy's design include allowing the connecting of larger classes of parts only once you have already reached a sufficient size, and allowing navigation of new areas of play when you reach larger sizes. Larger models don't necessarily have to be complicated, just larger -- in this fashion as the size scales, the complexity doesn't have to; you simply think in terms of the size bracket you're currently at, and worry less about smaller size brackets. To handle the processing requirements of becoming larger and larger, I am pretty sure that they have distinct LOD models for objects in Katamari. There's a noticeable "weird" effect when you grow between certain sizes, and I think that's meant to hide the LOD change. Applying a similar technique, with some sort of snazzy "power up" effect to hide the LOD change would, I'm sure, be plenty acceptable by the players.
  11. I'm happy to see the growing interest in this project. For licenses, I have reread the BSD license again and I must say it is growing on me. Just to be clear though, is the only real difference between the (current) BSD and MIT licenses the "don't use our names to endorse your product" clause in BSD? Because I've seen MIT with a similar clause appended...Are there any other real differences that I may not have realized? My curiosity is piqued since multiple people here have expressed a preference for BSD over MIT, so I want to be sure I understand why. As far as names go, it may be worth explaining that the name REACT was proposed as referring to a character responding dynamically to a situation, and mentioning that I've been revising the acronym a bit on recommendations -- the current iteration was Robust Extensible Animation Control Technology. (The Control is in there referring to control theory, as I realized the "Animated Character Technology" didn't in any way suggest that anything dynamic was actually going on.) I must say l0calh05t, I do like how Toolkit fits in well describing this library (as there still is some assembly required, but it'll give you what you need to do a lot), so I'd then further adapt the name to be Robust Extensible Animation Control Toolkit. CAST is good too -- I like the stage reference. What do other folks think? As for hosting, I'm starting to lean towards google code projects now. It sounds much easier to deal with and faster to get moving than source forge, and I kinda like the idea of encouraging competition by trying out the new competitor. The only thing I'm potentially concerned about is the lack of support for some advanced features, such as being able to do server-side build steps on commit...It would be nice to automate some unit testing and to auto-generate and host documentation and the like. It's possible that google may yet unveil this support sometime soon though, and the project could always switch hosts later on if deemed appropriate. Before I move on for the day, here's a simple diagram I whipped up that maps out some of the (high-level) design I had in mind so far for the library: The crux of the dynamic animation library (the one being proposed here) is the kernel, which manages the internal state of information and acts as a central intermediary between all other bodies of code that seek to manipulate or request that information. I realized that much like how the library does not need to be dependent on any particular physics engine, it likewise does not have to be dependent on any particular character animation library -- thus enter the bridges. Implementations following the design pattern of the same name, these would be bodies of code that connect two distinct libraries, responsible for directing information between them, so that the two libraries need not depend on each other. With the exception of the controller bindings (although, if there do perchance happen to already exist a few standards for defining controllers, as may be the case amongst researchers, it would be quite cool to have a bridge for each...) these bridges would be add-on libraries that are not part of the core but that are still essential for functionality (like, say, drivers in an operating system). I expect that they would still be part of the repository code base, but would be built as separate libraries to be optionally linked in as needed. Some application would then depend on the core (consisting of the kernel and core drivers) and any other necessary non-conflicting drivers, and whatever other libraries those drivers connect to. Note that we could just as easily have a bridge to PAL as to any specific physics library, so we wouldn't require folks to depend on PAL if they don't like it (and prefer to go straight with Havok, for example). Thoughts?
  12. Here's a news update for anybody still following. Currently I am favoring the name REACT (Robust Extensible Animated Character Technology), a variation of one of the afore-mentioned name possibilities. I am also leaning towards the MIT license. Though I might perhaps like a license that explicitly encourages people to contribute back to the project, there's really no way to force people to do so, and I have beef with some aspects of the LGPL (largely that the dynamic-linking aspect won't hold up well for most embedded systems such as many game console platforms). The MIT license is simple, and imho a bit more clearly worded than the BSD license. Now, the only remaining issue before beginning the project proper is determining the most favorable site to host the project at. Right now I'm looking between sourceforge and google code projects. They each have their strengths and weaknesses...I'm just not yet sure. Suggestions/commentary?
  13. Hey again all, my apologies for the delayed response. I'm ready to start getting moving on this project. My thoughts are that it be hosted on SourceForge. If anyone has a better idea, please shout it out. The license should be unrestrictive except, I think, for encouraging collaboration on developing the library. This area is admittedly under-researched on my part, but unless anyone provides a good argument for a different license (if you have one, PLEASE do speak up), my thoughts are that the project be started under the LGPL license. Otherwise I fear indefinite procrastination due to not knowing what license to use, and that would be a shame! Again, my current thought is to base the library on the well-established open-source library CAL3D. It's too early to be sure that this will go smoothly, or if we'll find a need to make considerable changes to CAL3D, or even a need to define a separate character animation system if it turns out that CAL3D simply won't work...though I don't expect that will be the case (and indeed I hope not). Since I personally only have direct experience with ODE, if I'm to start the project myself, that would be where I would begin...though I would plan soon to switch code over to be based on PAL, since it seems to be the most extensible move. If anyone thinks there's a better way to do things regarding dependencies, do please speak up. As for what exactly would be included in the project, my thoughts are that it at its core would be an intermediary interface between the character animation library and the physics library, with data structures reflecting the bones and model found in the character animation library and the joints and geometry found in the physics library. Without all of the design details worked out exactly, the idea I have is to have this layer act as a kernel through which all information relating to animation can flow, and which can act as a filter. For example, it should be feasible to set up a system where canned animations are played, but filtered through the kernel before being visualized by being written back to the CAL3D structures. What the kernel would do with this information is communicate with the physics library as appropriate to establish that the animations can be performed as requested -- you can think of this process as redirecting the movement through the physical world before executing it proper. If bone geometry collides with a wall while attempting to perform the animation, the final animation presented would be altered accordingly, while still attempting to continue to play to its completion (unless the application, upon learning of the change, chooses to discontinue the animation). The end result would be, for example, trying to punch through a wall but instead being stopped by it. Pumping animations through this kernel, when properly tuned, should similarly allow one to easily enough play any number of standing animations that will automatically adjust to standing on arbitrarily shaped terrain under a model's feet, bending knees and ankles as needed in order to continue to maintain balance. (In practice though I'm sure this will also require some sort of feedback AI generating animations to be blended in). This filtering should of course be adjustable, as there may be times when you want to use completely physically-based animation, times when you want completely canned animation, and times when you want them to interplay, in yet unanticipated very specific ways I'm sure. In addition to that, we'll need some means for specifying exactly how one wants to build the physical representation of the body. Though it's easy enough to generate, I'm sure in most cases we do NOT want a one-to-one correspondence between CAL3D bones and physical bones, and going with a default assumption that every joint is a ball-and-socket joint won't do either! So we'll need some way to build a physical bone/joint hierarchy, probably stored in an easy-to-edit and easy-to-merge text format (xml I expect). Once this file format is well-established I expect it will be appropriate to build a nice wysiwyg tool for taking a CAL3D model, examining its bone structure, and building a physical bone structure from that -- and exporting in our established file format. Finally, the top-most level of the library (and arguably the funnest part) will be the artificial intelligence interface -- logical patterns for generating animations procedurally. We'll have PID controllers and the like for controlling characters to maintain constraints via feedback loops, and I imagine that probably the first example in this department (once the rest of it has all been sufficiently implemented) will be a little dude standing that you can push on, but who will react in order to simply maintain his balance. Here we can have fun also mixing in some randomness for more lifelike animations...and indeed, at this level writing character animation logic may be analogous to writing short shaders to flavor animation. More sophisticated environment interaction will be an interesting research problem, and will probably best be handled at yet a higher level of AI processing, perhaps to be tackled in a separate library all of its own. Now all that being said, before we get this thing a proper home, I'd prefer to have its name squared away...so I'd like to begin a discussion to that end. I personally am big on acronyms, and two potential names that I've come up so far are REACT (Robust Emergent Animated Character Technology) and DASH (Dynamic Animation Simulation Hierarchy). If we choose to play directly off of DANCE (a good name, but alas already taken by those maddeningly-selfish researchers! Prohibiting commercial use? Damn them and their selfish altruism!) my first thought is PRANCE (*PRocedural* Animation aNd Control Environment). Thoughts?
  14. Hey everybody, I've done some work lately with ODE (the Open Dynamics Engine, a physics library) and CAL3D (Character Animation Library 3D, a graphics engine-independent skeletal animation library) to create some ragdolls for an application using the Delta3D game engine. It occurred to me that this could be pushed further to realize a dream I've had for some time of creating a dynamic physically-based character animation system. I started wondering what might be out there already in this direction, and having done some research, all I came across was something called "ODECAL" that was purportedly a ragdoll library based on top of ODE and CAL3D, except that it was apparently ONLY mentioned in some book that I can't find the text for online (so there's no website, it's not hosted anywhere, etc)...and something called DANCE, which looks really cool and can be found here http://www.magix.ucla.edu/dance/. The problem with DANCE is that its creators absolutely PROHIBIT commercial use, as it's meant to be exclusively for academic research. Well, that won't do for my purposes at all -- what I want to see is something both open-source and free for either commercial or non-commercial use. I'm admittedly still probably under-read on my open-source licenses, but I think I like the sound of LGPL, since the philosophy of "if you improve it, give back" resonates well with my philosophy. Basically what I want to see is (until I am convinced otherwise -- I happily encourage anyone to tell me things I don't know) an open-source LGPL'ed library based on top of CAL3D (unless there's a better graphics engine independent character animation lib out there?) and...probably PAL for physics? Has PAL been well-accepted as a standard intermediary for physics engines? If anyone has seen any sort of library like what I'm looking for, please LET ME KNOW! Otherwise, I am looking to start such a thing -- probably hosted at source forge. I don't have a good name for the thing yet (DANCE is a fantastic name, but it's sadly already taken) but am totally open to suggestions. Mainly, right here I'm looking to find like-minded souls, gauge / drum-up interest in this sort of library, inquire as to the common pool of knowledge about what's already out there, see who else might be interested in such a project, and maybe bounce back and forth some design ideas. Whaddayasay?
  15. Quote:Original post by nahid569 Hey guys THANKS alot! Those are gread ideas lord and I will use that but first I need to get a way to make a function that runs always. I do not have an idea how to do that. I was thinking of putting the entire movement thing in MAIN function because that is always running but I do not know how to do the keyboard thing outside of Keyboard function. Is there a better way? Let me know There is. Do a google search for "glut main loop" and you'll find a few pages describing things to try. You just need to register some sort of idle function or main loop, and that should be enough. You can still have a distinct Keyboard function that works the way it does -- and you can just communicate messages from Keyboard to your main loop function by way of...heck, even a global variable just to get things working (but at some point that should become some sort of formalized message loop). Really, I'm sure GLUT has some framework for this in place already...it's just a matter of searching through documentation to find exactly what it is, and then get that working.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!