www.jpct.net
jPCT - a 3d engine for Java => Projects => Topic started by: Raven on November 01, 2005, 11:15:34 pm
-
Hello everyone.
For the past week I've been experimenting with jPCT (very happy with it, actually, I'm very amazed that there aren't more people using it! Why is that??). I wanted to share with you some of my concerns regarding a system architecture for an FP(S) platform (I'd like it to be more than just a shooter (hence the parenthesis).
My end-goal is to create a first-person game, but since I haven't quite decided the game's nature/theme I'd like to begin with creating a general platform for it (that I could perhapse release under GPL for others to experiment with).
Currently I'm wondering about the following things:
1. Levels
My current architecture introduces levels as classes, for each level there is a class with the same name. The level class would store vital information like the players starting position in that level, lighting positions, etc... However, the problem is that that's a lot of information to hand sort, object positions, decorations, etc..
A partial solution to this problem would be having a certain type of signal in the level designs as pointers for a "LevelManager" which would place objects.
For example: a sphere with the texture named "PlayerPos" is actually a pointer for where the Player Starting Position should be. Levelmanager would read these pointers, and use their position to automatically instantiate and place the right types of objects, etc.. (then delete them from the world)
Theoretically, this would be possible with jPCT, yes?
2. Segmented character/player bodies
Multi-part humanoids. For an FPS game, it'd be really nice to have arms, torso, head and feet all separate objects capable of being damaged independently. However that would pose many problems: Animations for each part would have to be animated seperately and initiated at the same time when something happens to the humanoid. So it would be very hard to animate these parts independantly from eachother while the end result is supposed to act as a whole.
Can anyone think of a good way to implement a segmented-body ? There's also the question of computation, will segmented humanoids be too much for jPCT to handle?
I also noticed in another thread that Egon/Helge has been questioned before about skeletal-character physics like Half-Life uses. At the time there was no plan to implement that kind of feature. That hasn't by any chance changed, has it? :)
3. Saving
My current thoughts on saving are by simply making the Level class, Stats class (Contains historical info about the gameplay) and Player class serializable. When continued you would simply load the classes.
Sounds a bit brute to me, but that's all I can think of.
---
Thanks for reading.
Hope you're having as much fun as I am.
Cheers,
- Raven
-
A partial solution to this problem would be having a certain type of signal in the level designs as pointers for a "LevelManager" which would place objects....
Theoretically, this would be possible with jPCT, yes?
Yes. But i would use the name of the object, not it's texture. jPCT creates names for objects loaded from 3ds that start with the name the object has in 3ds. You may check for this name and don't merge the placeholder object to the level but replace it with the item instead.
Can anyone think of a good way to implement a segmented-body ? There's also the question of computation, will segmented humanoids be too much for jPCT to handle?
Not too much to handle, but difficult to implement. It should be possible to code such a thing using IVertexControllers....but it sounds quite hard to do to me.
I also noticed in another thread that Egon/Helge has been questioned before about skeletal-character physics like Half-Life uses. At the time there was no plan to implement that kind of feature. That hasn't by any chance changed, has it? :)
The point is, that i can only do so much. Doing a good skeletal animation system is a little project of its own. To be honest, i hoped for somebody to write one on top of jPCT, releasing it to the public and letting me integrate it into the engine's core to squeeze out some additional performance...but that didn''t happen until now :wink:
To be honest, i don't recommend starting with a goal as high as this animation system because chances are that you'll never finish it. But that's just me.
My current thoughts on saving are by simply making the Level class, Stats class (Contains historical info about the gameplay) and Player class serializable. When continued you would simply load the classes.
Sounds a bit brute to me, but that's all I can think of.
Don't know, should work well enough if space and/or loading times aren't important.
-
Yes. But i would use the name of the object, not it's texture. jPCT creates names for objects loaded from 3ds that start with the name the object has in 3ds. You may check for this name and don't merge the placeholder object to the level but replace it with the item instead.
Ah, I didn't know that. That's great! It'll make mapmaking a lot easier. Yeah, replacing the object is what I had envisioned.
Not too much to handle, but difficult to implement. It should be possible to code such a thing using IVertexControllers....but it sounds quite hard to do to me.
Ach, that's too bad. At this point I don't think I dare venture into IVertexControllers. I'd rather get a working demo first. But thanks for clarifying this for me.
The point is, that i can only do so much. Doing a good skeletal animation system is a little project of its own. To be honest, i hoped for somebody to write one on top of jPCT, releasing it to the public and letting me integrate it into the engine's core to squeeze out some additional performance...but that didn''t happen until now :wink:
To be honest, i don't recommend starting with a goal as high as this animation system because chances are that you'll never finish it. But that's just me.
I usually try and set my goals high to begin with and then tone them down as time progresses. Thanks for being honest - I was hoping someone would have a "magic solution" for accomplishing this, but given the options I won't attempt create it (Well, not yet at least :wink: ).
I have an idea though of how to accomplish "damage" to different bodyparts; simply creating invisible 3x3x3 cube around the characters. When a character would receive damage, the cubes register where the "inflictor" came from. For example, if a projectile hits a character in the chest, it must have passed through the middle cube -- this way we know a bit more than just that the character was hit. However, I'm unsure what kind of invisibility would be required, since I gather that invisible objects aren't processed? Maybe a dummy object cube?
EDIT: Actually, just a simple row of invisible cubes would be an improvement. One cube around the legs, one in the middle and one for the head. At least a lot simpler to implement.
Thanks for the feedback.
-Raven
-
It should be possible to get what you want easier IMHO. I think that you can use polygon IDs for this. For each model in question, you may determine which polygons belong to which body part. Using the PolygonManager on an untransformed/-translated object you can get the vertex coordinates in object space...and it may be possible to say that (for example) everything below y=-10 is the head, between 10 and -10 is the chest etc...that may work on most models well enough. Store this list and use a CollisionListener to get the ID of the polygon that has been hit by the collision, search your list for it and voila, you have your body part. Just an idea...
If you follow the "boxes"-approach, they don't have to be invisible all the time, just during rendering. That's what Paradroidz does to calculate collisions against a sphere even if the droids are usually none. When rendering, the droids are visible and the spheres are invisible. When doing the collision check, the spheres will become visible and invisible again after collision detection has finished. But i would head for the polygon ID way instead...should be easier and works better if you manage to assign polygons to body parts in some way.
-
The polygon ID plan sounds better. Thanks for the advice. This could also prove a very useful discussion for future jPCT-FPS gamemakers.
-Hrafn "Raven"
-
Hello again. I'm back with more pondering.
I've been developing Operatable objects -- so far so good. Objects can now perform various operations when clicked.
But I'm wondering about objects connected to eachother. For example, if a "ButtonObject" is connected to a "DoorObject" -- does anyone have a good idea as to how to assign these objects to eachother?
Better yet; Let's say I have a level with 10 doors and 10 ButtonObjects, how would be the best way to assign each ButtonObject to it's specific door?
All ideas are appreciated.
Cheers,
-Raven
-
object3d.addChild() ?
but i think it is good idea to create some wrapper for your game objects to separate from 3D, lets say something like this
public class GameObject {
protected Object3D object3D;
...
}
public class Door extends GameObject{
public Door();
}
public class DoorTrigger extends GameObject{
private Door myDoor;
public DoorTrigger(Door door){
this.myDoor = door;
}
}
...
-
Or write yourself a GameEvent and a GameEventListener. Make the door a GameEventListener, register it on each button in question and let the button fire a GameEvent(<pressed>) to all its listeners when pressed.
-
Thanks for the advice guys.
I'd created a wrap for objects, but the objects extended Object3D ... I hadn't thought of the other option :oops:
Both your ideas help a lot. Thanks. I'm going to read up on how I could implement a GameEventListener, not quite sure how that'd work yet.
Keep you posted.
Thanks again.
-Hrafn
-
Thanks. I'm going to read up on how I could implement a GameEventListener, not quite sure how that'd work yet.
Somehow like this:
GameEvent:
package framework;
public class GameEvent {
public final static GameEvent BUTTON_PRESSED=new GameEvent(0);
public final static GameEvent BUTTON_RELEASED=new GameEvent(1);
public final static GameEvent ANOTHER_EVENT=new GameEvent(3);
public final static GameEvent WHATEVER=new GameEvent(4);
private int i=0;
private GameEvent(int i) {
this.i=i;
}
public int getID() {
return i;
}
}
GameEventListener:
package framework;
public interface GameEventListener {
void eventFired(GameEvent ge);
}
Your door object:
package framework;
public class MyDoor implements GameEventListener {
public void eventFired(GameEvent ge) {
if (ge==GameEvent.BUTTON_PRESSED) {
System.out.println("Wooosssshhh!");
}
if (ge==GameEvent.BUTTON_RELEASED) {
System.out.println("SSSSHHHTTTT");
}
}
}
Your button:
package framework;
import java.util.*;
public class MyButton {
private Set listeners=new HashSet();
public void addGameEventListener(GameEventListener ge) {
listeners.add(ge);
}
public void removeGameEventListener(GameEventListener ge) {
listeners.remove(ge);
}
public void press() {
fireEvent(GameEvent.BUTTON_PRESSED);
}
public void release() {
fireEvent(GameEvent.BUTTON_RELEASED);
}
private void fireEvent(GameEvent ge) {
for (Iterator itty=listeners.iterator(); itty.hasNext();) {
((GameEventListener) itty.next()).eventFired(ge);
}
}
}
How to use it:
package framework;
public class Test {
public static void main(String[] args) {
MyDoor door=new MyDoor();
MyButton button=new MyButton();
button.addGameEventListener(door);
button.press();
button.release();
}
}
But that's just an idea. You don't have to do it that way. In fact, i'm not doing that myself in Paradroidz but using a tighter coupling. Depends on your needs...
-
:shock:
Holy s***, whether or not I will use this method this tutorial definately teaches me a thing or two about Java! :D
I haven't had a lot of experience with interfaces and listeners, so you just saved me about half a weeks worth of reading Helge. Awesome.
I'll be testing this asap.
Cheers,
-Raven
-
Thank you both, Helge and rolz -- I combined both of your ideas keeping the object3D seperate in a GameObject class wich emplements a GameEventListener. It worked like a charm, and gave me much clearer view of how to puzzle all my smaller bits together that I've been experimenting with since I starting working with jPCT.
I have another question though that is perhapse not justifyable on these forums due to the fact that it derives from my inexperience working with full scale applications and especially 3d rendering.
But well, here it goes: I'm trying to get a grip on how I'll manage the animations that follow triggering, for example, a door object. I implemented the door triggering event where the Door(Object3D) was an md2 file with an "Opening" animation. Of course, the opening animation itself was carried out in the Door object and was therefore not in consistency with the frames in the main game. To explain: initiating the door opening animation caused the animation itself too be drawn too fast for the player to see.
In the official jPCT examples, this is solved by calling doMovement() once every loop in the main gameloop, hence the animations are always consisent with the main thread.
So what I'm currently thinking is to have a GameEventManager, which would keep a listing of all GameObjects as well as an AnimationQueue: a Hashlist that contains all the objects that require animating in the next iteration of the main game loop.
The main gameloop would therefore look something like this, with the addition of soundManager:
gameloop {
while (!quit) {
player.doMovement();
GameEventManager.animationQueue(); // If there is something that requires animation
SoundManager.playSounds(GameEventManager.soundQueue()); // Play any sounds that the gameEvents emit
}
}
So, to sum up, my question basically is: is this the way to go? Or is there some other method that's better when making 3D games? For example, should I be looking into threading each type of manager so it runs independantly?
Thanks for reading and helping :)
-Raven
-
For example, should I be looking into threading each type of manager so it runs independantly?
I'm quite busy ATM, so the short answer to this is: NOOOOO! :wink:
Don't let another thread than your main thread manipulate your game entities (at least not as long as it affects jPCT related stuff). It may happen at any time, even when jPCT is rendering them and that will cause all kinds of wierdness which are a pain to debug. Trust me...been there, done that...
Don't manipulate the Camera, the World, an Object3D etc. from inside another thread. Don't do it. Never! jPCT has a kind of locking implemented (has to be enable explicitly) to make it pseudo-threadsave, but that dates back to the times where i thought that i might be a good idea. It isn't...
Edit: Here's a short code snippet from Paradroidz' main loop. Looks similar to your approach. That doesn't mean that it's the only way to go, but it works for me.
if (!gameState.showsSomeOverlay()) {
if (data.isAlive()) {
player.checkInvincible(storeTicks);
player.reEnergize(level, storeTicks);
}
level.updateShadowVolume();
eManager.enterCollisionMode();
player.enterCollisionMode();
level.processDoors(storeTicks);
level.processEnergyPads(storeTicks);
level.processDisruptors(storeTicks);
SimpleVector playerPos=player.getTranslation();
player.processProjectiles(storeTicks);
map.disableCollisionListeners();
if (data.isAlive() && !gameState.hasState(GameState.FINISHED)) {
move(storeTicks);
}
eManager.setPlayerPosition(playerPos);
eManager.calculateVisiblity(storeTicks);
eManager.moveEnemies(storeTicks);
map.enableCollisionListeners();
if (data.isAlive() && !gameState.hasState(GameState.FINISHED)) {
eManager.fireAtWill(storeTicks);
fire(storeTicks);
transfer();
level.setArrow(eManager.getClosestEnemyPosition(playerPos, false), storeTicks);
} else {
eManager.moveBulletsOnly(storeTicks);
}
eManager.leaveCollisionMode();
player.leaveCollisionMode();
player.processClouds(storeTicks);
player.synchronize();
level.processExplosions(storeTicks);
level.processBlastRings(storeTicks);
level.processParticles(storeTicks);
processCamera(storeTicks);
}
-
hello raven,
So, to sum up, my question basically is: is this the way to go? Or is there some other method that's better when making 3D games? For example, should I be looking into threading each type of manager so it runs independantly?
as a rule of thumb, you should avoid threading whenever you can. it only complicates things and cost some performance (due to syncronization and context switching overhead). use threading where you have to do so (for example when use blocking i/o)
in karga, to simplify things, i targeted a constant fps. even collision detection and other non-render stuff doesnt cost much compared to rendering, so if i cannot reach targeted fps, i simply skip rendering for some frames and update the game state only. this method depends on measuring render time, something like this:
while (running) {
long startTime = System.nanoTime();
gameUpdate();
gameRender();
long elapsedTime = System.nanoTime() - startTime;
if (elapsedTime < expectedElapsedTime) {
// sleep here for some time
} else {
// do some gameUpdate without render
}
}
with this approach, even on a slow machine updates stay closer to high targeted fps (50 for instance) so you can decide animation indexes etc depending on targeted fps
instead of controling animations and other things (movements etc) from a central location i've also defined a FrameListener interface which lots of my 3d objects implement. so they can 'take care of themselves'
public interface FrameListener {
public void timeForNewFrame(/* pass here whatever you want like frame no, world etc*/);
public void timeForRender(/* same as above */);
}
so what i do in gameUpdate and gameRender is:
private void gameUpdate() {
for (FrameListener l : frameListeners) {
l.timeForNewFrame(/* some parameters */ );
}
}
private void gameRender() {
for (FrameListener l : frameListeners) {
l.timeForRender(/* some parameters */ );
}
}
hope this helps :wink:
r a f t
-
instead of controling animations and other things (movements etc) from a central location i've also defined a FrameListener interface which lots of my 3d objects implement. so they can 'take care of themselves'
Yep, i'm doing it in a similar way. It's just that i have no common listener interface for that but "managers" on top of each entity-class that hold the references to all entities of a type and forces them to update/move/hide...whatever is needed. My timing works different. I'm measuring the time that has passed since the last frame in "ticks". A "tick" in Paradroidz is a 200th of a second IIRC. All my methods take these ticks as a parameter and act accordingly. For example: If i move an entity x units forward for one tick, i move it 8*x units forward if 8 ticks has passed since the last call. This has two drawbacks you have to be aware of:
1. all your algorithms have to be "tick"-able, which causes some extra work from time to time.
2. time taken in collision detection correlates with the length of the translation vector. This can cause the following: Game needs 2 ticks to update all entities, collision detection is called with 2 ticks, needs 1 tick itself due to that. So, you have 3 ticks for the next frame, call collision detection with 3 ticks, which now needs 2 ticks to complete and so on...that will result in a seconds per frame display over time. To avoid that, i'm limiting ticks to a max amount. If it superceeds this value, the game will simply slow down (i theory...it never happened for Paradroidz because collision detection is too fast)
-
in theory...it never happened for Paradroidz because collision detection is too fast
certainly it is. in fact everything, even those you mark as expensive in javadocs, is quite fast compared to render time. dont get me wrong, i dont mean rendering is slow :wink:
i choosed this way since i couldnt find effective solutions for some questions, especially in a multi-user enviroment. for instance, if some user moves from point A to B, basicly only these two points are broadcasted to other clients. assuming constant fps it is trivial to decide where that user will be in each frame. with un-constrained fps it's somewhat more complicated
r a f t
-
assuming constant fps it is trivial to decide where that user will be in each frame. with un-constrained fps it's somewhat more complicated
himm, i'm re-thinking now about the subject and, assuming constant fps even in an un-constrained enviroment may be a good assumption. normally fps doesnt change that much if something doesnt change radically (such as world size doubles or user opens another cpu eater application).
so, measuring fps every -say- 5 seconds and assuming it constant may also simplify things. i guess this way fps increases slightly since number of updates decrease. a drawback is, if one moves with key strokes every frame, fps/ups results in a smoother feeling
sorry raven, filling your forum with self thoughts :oops:
r a f t
-
Thanks a lot for your reply guys.
Helge, your mainloop made me breathe easier.. means I know what I need to to actually implement what I'm thinking of without reading up on a lot of stuff ;)
EDIT: Also, after your posts I promise not to thread my app at all ;)
Due to my state of newbieness to the matter of fps' and ticks, I'm still digesting what you were talking about regarding it. But if I understand correctly, you're basically normalizing game animations and events by checking how fast the application is running?
So for example, this would keep gameplay basically the same for everyone regardless of their CPU speed provided that their CPU's aren't slower than X?
raft: Feel free to fill my thread thoughts, it helps :)
-Hrafn "Raven"
-
Due to my state of newbieness to the matter..
nevermind, i'm also a newbie for this kind of projects, or at least i was before karga :wink:
if I understand correctly, you're basically normalizing game animations and events by checking how fast the application is running?
yes, exactly. the idea is to increment the game state (animation indices, positions of moving objects etc) as much as the time elapsed since last update
say you have an opening door animation which you want to last for 2 seconds, and your fps is 50 (= 1/50 seconds elapsed) you increase animation index of door by 1 / (50 * 2) each frame
r a f t
-
I just found this thread about game timing. Maybe it helps: http://forums.indiegamer.com/showthread.php?t=5192
-
Great, thanks guys.
Man, java interfaces can be confusing. Just "finished" working out the framework for operable objects, animated objects and trigger objects -- while multiple inheritance is a necessity, it sure is quite messy sometimes.
Next I'll try out the game timing.
-
Phew. Just finished my finals at the university for last semester, had some time to come up and breathe (i.e. make a small applet).
After spending so much time programming a heavy-duty fps framework, I decided to try something less demanding out. But as always, things take more work than you expect.
The plot: Show MRI (magnetic resonance images) scans of my brain (yes, my brain) in a 3D applet.
I pulled it off quite nicely I think, however there are some problems I was hoping you guys could give me some advice on.
1) The scans are placed on a thin slice as a texture, the slices (object3D's) are then made transparent(0), however -- it's still very hard to see "inside" the brain without moving the slices further apart.
Can anyone think of a way to make this look better?
In the actual applet you can swirl the scans around using the arrow buttons, but unfortunately my service provider doesn't allow applets to read files (textures) from the server itself. So I only have images to show.
Here are the screenshots:
(http://www.vortex.is/raven/brain/images/brain1.png)
(http://www.vortex.is/raven/brain/images/brain2.png)
(http://www.vortex.is/raven/brain/images/brain3.png)
(http://www.vortex.is/raven/brain/images/brain4.png)
What do you think?
-
1) The scans are placed on a thin slice as a texture, the slices (object3D's) are then made transparent(0), however -- it's still very hard to see "inside" the brain without moving the slices further apart.
0 is the lowest possible setting for transparency in the software renderer, so there's no way to make them more transparent when not using hardware. Maybe picking a slice with the mouse is an option. If it's picked, you could temporary remove all slices above or make the picked slice slide out somehow.
In the actual applet you can swirl the scans around using the arrow buttons, but unfortunately my service provider doesn't allow applets to read files (textures) from the server itself. So I only have images to show.
How it that done and why? It should be quite transparent for the server if a browser is reading the files or an applet is. However, how about putting the files in the applet's jar and load them from there.
Oh, and...nice brain... :wink:
-
Oh, and...nice brain...
Thank you :lol:
How it that done and why? It should be quite transparent for the server if a browser is reading the files or an applet is. However, how about putting the files in the applet's jar and load them from there.
Thanks for the hint. I tried that, no luck -- same error.
I have no idea why it happens, but my best guess is my providers security issues, here's the error I get:
Loading Texture...slices/0.png
java.security.AccessControlException: access denied (java.io.FilePermission slices/0.png read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkRead(SecurityManager.java:863)
at sun.awt.SunToolkit.getImageFromHash(SunToolkit.java:472)
at sun.awt.SunToolkit.getImage(SunToolkit.java:486)
at com.threed.jpct.Texture.loadTexture(Unknown Source)
at com.threed.jpct.Texture.<init>(Unknown Source)
at BrainVision3.loadSlices(BrainVision3.java:226)
at BrainVision3.init(BrainVision3.java:69)
at sun.applet.AppletPanel.run(AppletPanel.java:354)
at java.lang.Thread.run(Thread.java:552)
-
Looks like you are not using the correct method to load them. To load them from a server, use the URL-version of the loading methods, to load them from a jar-file, use the InputStream variants. You can get the InputStream like so:
this.getClass().getClassLoader().getResourceAsStream(<your file>);
-
It's been a really long time since I messed with applets, so I don't have any trouble believing the error is on my side :cry:
But anyway, I tried both accessing the image from a .jar file and by using:
try {
URL imageURL = new URL("http://www.vortex.is/raven/Brain/slices/"+i+".png");
img = Toolkit.getDefaultToolkit().getImage(imageURL);
texMan.addTexture(i + ".png", new Texture(img));
} catch (java.net.MalformedURLException MURLE) {}
But no luck. Same error.
Any ideas?
-Raven
-
Loading them from the jar should definitely work. Can you provide me with a simple test case that doesn't work for you? I could upload it to my webspace and see if that works.
-
If you're using an un-signed applet you need to make sure that the location you specify is *exactly* the same as the codebase of the applet. (Easiest way to do this is to use Applet.getCodeBase() and then append the filename on the end of it.)
-
Hey everybody.
Been busy months and haven't really gotten anything done since the last day I posted.... a few months back, so unfortunately no cool screenshots.
Going to try and get started again.
To review what my problem was: I was trying to get an applet that loads images (see screenshots above) to work online (it works on my computer, but gives access error when online).
Can you provide me with a simple test case that doesn't work for you? I could upload it to my webspace and see if that works.
Thanks a bunch for the offer Helge! I'd really appreciate that if things don't start working soon.
If you're using an un-signed applet you need to make sure that the location you specify is *exactly* the same as the codebase of the applet. (Easiest way to do this is to use Applet.getCodeBase() and then append the filename on the end of it.)
Thanks for the tip. I'm going to look up a few examples online, but I have a couple of questions:
(1) What is the 'codebase' exactly? Is it not just the URL of the applet?
(2) I'm storing the images in a separate folder, might this be the problem?
Thanks again everyone.
-Raven
-
The codebase is where your applet is located on the server. It's usefull to store the applet on another location on the server than the calling html-page.
For example, if your page is at "/hurz/gurz/myapplet.html" but applet is at "plopp/glopp/applets/myapplet/", the latter would be the codebase.
-
Ugh...
Helge, if you offer still stands on taking a look at this for me, that would be really really great, it's driving me insane. Tried a whole bunch of stuff... but still the error when I don't view it in appletviewer.
-Th
-
Helge, if you offer still stands on taking a look at this for me, that would be really really great, it's driving me insane.
Sure, just send it to me. I'll have a look at it.
-
Thanks a lot. Really appreciate it.
EDIT: If anyone has been following this thread, thanks to EgonOlsen the applet finally works online and can be viewed on my webpage (http://www.vortex.is/raven/brain).
Thanks for the help Helge.
-Hrafn Th.
-
Well. Another project just hit the beta stage. A Hexapod simulation based on the CarDemo that comes with jPCT.
The project was developed as a teaching aid for an Artificial Intelligence class at Reykjavik University. Basically, it's a hexapod (six legged creature) where the user has control over it's legs. If the legs move while touching the ground it propells the hexapod -- in simple lingo: you can make it walk.
The project uses the Constructionist A.I. approach in which the hexapod acts as a module communicating through a publish-subscribe mechanism -- a program called Psyclone that acts as a medium for messages. So you can create a seperate program (a brain) to control the hexapod through messages to the legs (on the same computer, or somewhere else in the world).
The project can be downloaded from http://www.mindmakers.org (under "Projects", called CADIAHexapod, direct link here (http://www.mindmakers.org/projects/CADIAHexapod)). It requires Psyclone to run, but Psyclone is very easy to use and I included a simple step-by-step run guide.
Although it's mainly intended as an "A.I. operating system", I recommend Psyclone for anyone doing large scale systems in which it would be easier to maintain if broken down into seperate modules that interact. Currently, modules can be implemented in Java, C# or C++, giving the option of writing your project in many different languages at the same time.
- Hrafn Thorri
-
yeap, i've seen it walking ;) interesting project..
r a f t
-
Hello Hrfan, i just registered to this mindmaker website. The idea is interesting to me because i m also studying in the AI field ( multi agents systems and stuff like that). I will have a closer look at your project once i will have some time . Thanks for the link. :P
-
Thanks for the comments, raft and manumoi.
The demo gait/walking pattern provided with the sim is not a very pretty one ;-) I didn't include or write perfect gaits, but if anyone does, I'd like to see them if you want to share.
manumoi: Yeah, the Constructionist A.I. approach upheld at Mindmakers is very interesting and definately promising. I've tried out Psyclone and OpenAIR in a couple of other projects, mainly for integrating speech recognition and synthesis, but now in jPCT too -- it has worked very well so far.