Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (767)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (854)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: 1 [2]
31  Game Development / Game Mechanics / Re: [Odejava] OO Issues Reloaded (4) on: 2004-04-11 23:07:47
Will,

As a new user to Odejava with little code to covert, I have no problem with this.

-Tab
32  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-04-06 15:35:48
So basically, it's all relative. With a possibly non-linear relationship between any 2 masses.

That's kind of what I figured, just not what I hoped. Oh well, more tweaking.

-Tab
33  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-06 01:31:25
I see some of them now with the update I did earlier. But I don't see these (in Body.java):

1  
2  
3  
4  
5  
6  
public Vector3f getAngularVel(Vector3f result);
public Vector3f getFiniteRotationAxis(Vector3f result);
public Vector3f getForce(Vector3f result);
public Vector3f getLinearVel(Vector3f result);
public Matrix3f getRotation(Matrix3f result);
public Vector3f getTorque(Vector3f result);


And in Geom.java:

1  
public Matrix3f getRotation(Matrix3f result);


Sorry to be so anal; I was raised an engineer. Thanks for the work so far.

-Tab
34  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-04-05 20:11:02
Jani, any luck with my code?

I asked this before, but I never got an answer. Why does ODE want masses to be specified in such a narrow range (e.g., 0.5 to 1.5)? Isn't this unrealistic? How am I supposed to model the interactions between a North African swallow and and an M1 tank (for instance)? If I could specify the correct masses, I would expect the bird to bounce off the tank without the tank moving (perceptively). Or am I missing something?

-Tab
35  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-05 20:06:27
This has been brought up before, but I'd thought I'd add it to this post as well:

5) "getter" methods in Body (and possibly elsewhere) should accept vecmath objects as arguments and fill them in.

If I recall a previous post, the argument against this is that it violates the java conventions. On the other hand, it greatly reduces the number of transient objects (and related garbage collection).

I also believe it was proposed to use a different method name for the additional methods (e.g., fillVelocity(Vector3f v)). That's fine by me as long as the functionality is there and the extra objects are kept to a minimum (or never created at all).

-Tab
36  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-05 20:00:44
Will,

I removed my changes from the code, did an update and compile, and there are no problems. In fact, my project compiled without changes, so I guess we think alike as far as method signatures.

Concerning 4) my only intent was to mirror the kind of interface used elsewhere in the Java API. For instance the TableCellRenderer interface specifies the JTable the renderer is being called for, allowing multiple tables to use the same renderer and the renderer having the ability to customize itself for the table. Perhaps your interface isn't quite the same thing, but I'd thought I'd mention it anyway. Like I said, I don't require the additional functionality.

-Tab
37  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-05 16:04:56
No, I haven't done a cvs update for a couple of days. I'll do that tonight if I get a chance, and incorporate your changes.

I'm using WinXP Pro.

I'll request Observer role. Thanks.

-Tab
38  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-05 02:40:53
Will,

I took a look at 2) and 3) myself and slapped some code into my copy of the source to get things working.

As I looked at the code, I also realized the problem with removing bodies from a world, but I decided for my purposes, I could just disable/enable the body, I think. As I understand it, a disabled body isn't "processed" by ODE, so it doesn't take up any CPU. As long as I also remove the associated geometry from the space, then ODE won't auto-enable the body during a collision, since there's no geometry to collide with. If my understanding of this is flawed, please correct me.

Related to 3): when I implemented my own version of the removeGeom method and tried to use it, I got an JNI exception at line 335 of Geom.java. I had to comment out the call to Ode.dSpaceAdd to get it to work:

1  
2  
3  
4  
5  
public void removeFromSpace () {
   Ode.dSpaceRemove(spaceId, geomId);
   spaceId = Space.SPACEID_ZERO;
   //Ode.dSpaceAdd(spaceId, geomId);
}


Evidently, ODE doesn't understand a space with an ID of zero? If that fix is correct, please incorporate it.

I'd submit it as an issue, but I'm not sure how to. I think I need to be a member in the project in order to submit an issue (according to https://odejava.dev.java.net/servlets/ProjectIssues). Should I request membership?

-Tab
39  Game Development / Game Mechanics / odejava missing functionality on: 2004-04-04 17:22:50
This post isn't meant to pressure Will and Jani, but meant as a place to document obvious missing functionality in the odejava binding. On a personal note, these items are holding me up, but hey, no pressure  Smiley

1) Multi-geom support within a body. Need the ability to add mulitple geometries to a body, each with their own translation/rotation relative to the body's reference point.

2) Ability to remove a Body from a World. There is, of course, a way to add a body, but no way to remove one.

3) Ability to remove a Geom from a Space. Like bodies in a world, I need to way to remove geometries from collision space.

4) DisplayTransformable.setTransform method should probably have an additional parameter: the OdeTransformable the DisplayTransformable is associated with in the DisplayBin. This would allow a single class implementing the DisplayTransformable interface to handle multiple objects. This isn't important for me now, but more a matter of Java form.

Those are the obvious ones for me.

On a related note, I'd be happy to contribute to the odejava project (instead of just whining). Should I get CVS write access or should I just post diffs to this forum?

-Tab
40  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-31 18:47:11
I'm still stuck. Here's some code you can try:

http://www.bennedum.org/files/ODETest.zip

It includes a simple ant script, a single source file, and a batch file to run the test. Run ant with no arguments to build the test. The build script assumes a "lib" directory at the same level as the entire archive file. It assumes Java3D is installed into the Java SDK.

When you run the test, it will open a 1024x768 frame with a simple scene. The "terrain" is a single triangle (GeomPlane for odejava. The "traveler" (the thing you can control) is a simple box (GeomBox). The controls are:

Escape - quits
Up arrow - forward
Down arrow - reverse
Left arrow - turn left
Right arrow - turn right
V - change view (above and behind, left side, 1st person)

I'd like you to observe the behavior without touching the controls. For me, the box falls to the "ground", then bounces much more than I'd expect. If you let it run, within a few seconds, the box will out of control, spinning wildly.

What I want is: the box should fall to the ground, bounce a little and settle down.

Any idea what I'm doing wrong here? Is this behavior "normal" and I'm just expecting too much? I can't seem to tweak things to get decent behavior.

-Tab
41  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-31 16:31:01
Will,

I'm back up and running now. I download and installed xith and got your car terrain test working. I don't see any box/trimesh issues at all, especially the one in your issue. Again, for reference, I'm on Windows XP Pro, SP1+, Java 1.4.2_04, latest odejava source from CVS as of the time of this post (actually about 30 minutes before). I was using Xith3D from the 2004-02-29_cvs snapshot.

As it relates to my project, the car terrain test is amazing. My code behaves nothing like that test, leading me to believe I'm doing something significantly wrong. I'll have a close look at the test code and see if I can get better behavior.

-Tab
42  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-30 13:32:27
But I don't use JOGL. I'm been using Java3D for DirectX exclusively. But I'll probably need JOGL for your test.

-Tab
43  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-30 01:38:01
Yes. I basically need the ability to create multiple geoms, each with its own transform to specify its position/orientation with respect to the body's reference point.

I suppose ideally, if you could create a scene-graph like tree with nested transform groups and geoms, that would great. But I'd understand if that's beyond the scope of your implementation. And I don't have have a need for that complexity (at least not yet  Smiley ).

My poor dev box is taking a bit more time than expected to come back. When it does, I'll give your issue test a try.

Oh, as I'm rebuilding my box, I've remembered I've been running Java 1.4.1_01. I'll be installing 1.4.2 on the new box. I'm not sure if that makes a difference in any of this, but I'd thought I'd throw it out there.

-Tab
44  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-29 15:43:41
I can work around trimesh/trimesh collisions for now, but it could be a big issue later on. It seems that having a method to take a soup of triangles and convert it into a bunch of boxes would be a good thing for this purpose. That might sidestep the problem, but it depends on...

Multi geom per body: are there plans to get this done? I mean, are there some tricky issues, or is it just a matter of having enough time to code it?

It's good to hear I'm not the only one having box/trimesh problems. I may be able to keep my sanity.

I did some reading on the ODE mailing list archives and discovered that ODE doesn't handle dynamic friction, which I assumed it did. I found the methods for inducing drag and that may help some of my problems too.

I won't be able to test anything for a liitle while though. It seems it's time to reformat my drive and reinstall Windows so I can reliably use my network again. Long, painful story.

BTW, I'm using a version of odejava from CVS about 7 days old now. When my dev box is back up, I'll update and recompile to make sure I have the latest stuff.

-Tab
45  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-27 22:23:34
Will, that might explain some of the behavior I'm seeing.

I'm working on reducing the complecity of my simulation in an attempt to better understand some of the settings, but I'm running into some fundamental questions (that I seemed to have made assumptions about in my original testing, which may be causing me my headaches).

My main problem at the moment: what's the correct way to position/orient multiple geoms with respect to each other and the body's reference point, in the same body? Specifically, I want a box with 4 spheres, 1 at each of the "bottom" corners of the box. I've been doing that like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
body = new Body(world);
Geom g;

g = new GeomBox(WIDTH, HEIGHT, DEPTH);
g.setPosition(0, 0, 0); // I suppose this isn't really necessary
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(-HALFWIDTH, -(RADIUS + HALFHEIGHT), -HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(HALFWIDTH, -(RADIUS + HALFHEIGHT), -HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(-HALFWIDTH, -(RADIUS + HALFHEIGHT), HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(HALFWIDTH, -(RADIUS + HALFHEIGHT), HALFDEPTH);
body.addGeom(g);


Is that the correct way to do it? The ODE docs talk about adding the extra geoms under a transform (sort of like a scene-graph maybe?), but there's no transform object that I can find.

And as long as I'm asking questions, here's some more:

1) The ODE docs talk about the ability to have nested spaces to optomize collision detection. That seems like it might be useful, especially when using a large TriMesh for terrain. In a similar fashion, my Java3D terrain scene-graph uses a hierchical structure (with some 1024 Shape3D leafs) to achieve better rendering speed. Does odejava support nested Spaces?

2) The ODE docs say:

Quote
Triangle meshes can interact with spheres, boxes and rays.


This implies you can't collide a TriMesh with a TriMesh. Is that really true? That could be a huge problem.

3) I don't get the idea of setting my body's mass to 1. Why can't I set it to the "real" mass of the body (e.g., 2000 kg). I tried, and bad things happened. Doesn't this mean all my bodies will have the same mass? Doesn't this screw up collisions? Mass is directly related to inertia, so how can ODE accurately model the reactions when bodies collide, if all the bodies have the same mass (when they're not supposed to)?

Those are the questions bugging me right now. Unless my understanding of physics or how ODE works is completely wrong, I'm beginning to think ODE may not be a suitable basis for modeling physics. But I'm willing to be enlightened.

-Tab
46  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-26 12:22:27
Jani,

First of all, I really appreciate your help with this.

I don't import my terrain, but rather generate it during app startup. I'm sure the triangles are created in correct vertex order, because I do get collisions, they just seem to be out of control.

My traingles are 4 units on a side, and the box is 2 units square (xz) and 0.5 units high (y). The terrain is laid out in the xz plane in a regular grid and it's height points (y) are based on a height map.

I'm running all this on Windows XP Pro.

I haven't tried any of the non-console tests since I don't have Xith installed. Maybe I can try those out today.

I'll take another poke at my code today and take a look at the ODE docs again (a good night's sleep sometimes helps). If I still can't get satisfactory behavior, I'll try to get the code in some shape for you look at. My code uses Java3D and the j3d library. Would any of that be a problem for you?

-Tab
47  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-25 22:00:11
Jani,

Thanks for the info. I hadn't explored the JavaCollision class; I just grabbed it's use from one of the simple tests.

My step size is based on the frame rate, so it's typically around 0.0125 (and I believe small is good?), but is set on a per frame basis.

I bumped the interactions up to 10 (I don't understand exactly what this number implies, or how it relates to anything in the simulation), and I set the collision defaults as you posted, but the simulation is even worse. When the box initially falls, it hits the terrain and bounces uncontrollably into the air.

I added a bunch of leading zeros in to the collision's bounce and bounceVel settings (hoping to imply less bounce?) and it's just as bad.

That surfaceMu of 1000 seems very high to me, but what do I know? The ODE docs talk about Mu and the two modes ODE can use with it, but it's not clear how you set either mode. Is that one of the bit values you set in the surfaceMode property? If so, how do I know which mode I'm selecting (there's nothing in the docs for odejava or ODE)?

I'm pulling my hair out with this. I wouldn't think it's this hard to get something that resembles reality. Isn't there some set of recommended nominal values for all these things that result in something useful?

-Tab
48  Game Development / Game Mechanics / Need odejava tweaking help on: 2004-03-25 17:29:34
I've successfully integrated odejava into my project, but I'm having a hell of a time tuning the physics to get what I consider to be believable behavior. Here's what I have:

I've created a GeomTriMesh from a fractal terrain mesh to represent terrain. I've also created a simple box geometry to represent the user. The tri-mesh is added to the Space, the box is added to a body, which is added to the world. (BTW, the odejava API is pretty good, but it needs a ton more docs).

I've also, of course, created visual representations of all this using Java3D. The visual geometries exactly match the geometries I'm feeding odejava.

When I turn everything on (after setting the box's body position to be a couple of meters above the terrain), the box falls as expected and contacts the terrain. Then the box jitters a little (as I would expect) as things settle down. If I wait long enough, the box will start to slide down one of the tilted triangles it's landed on. That's cool too. But as the simulation continues, the box doesn't seem to behave very realistically, and eventually will flip completely over for no apparent reason. I've read the ODE docs and understand the issues concerning precision and instability, but I can't seem to get the system to behave nicely.

I think I need some guidelines on what setting values to feed to ODE. For instance, here's how I set up the world:

1  
2  
3  
4  
5  
odeWorld = new World();
odeWorld.setGravity(0, -9, 0);
odeWorld.setStepInteractions(2);
Ode.setSurfaceMu(4);
Ode.dWorldSetCFM(odeWorld.getId(), 1);


On each frame of rendering, I do this:

1  
2  
3  
4  
5  
odeWorld.setStepSize(frameTimeSeconds);
odeCollision.collide(odeSpace);
odeCollision.applyContacts();
odeWorld.stepFast();
odeConnection.updateAll();


Notice I'm using the DisplayBin class for the odeConnection variable (that whole API works quite nicely, BTW). Notice also that I'm not changing any of the contact collisions.

Am I doing anying fundamentally wrong here? Can anyone suggest better values or other settings for the world? Should I be doing something with the contact collisions?

-Tab
49  Java Game APIs & Engines / Java 3D / Re: Newbie needs some help on: 2004-03-20 16:41:36
I solved the problem. If I had the author of the tutorial in front of me now, I'd strangle him. It will always be a mystery to me why some authors don't test the code they publish.

The problem was the geometry all along. The 4 coords used to define the square were defined in the wrong order so the geometry was being backface culled. Reverse the order and the square appears.

What irks me most is that the author made a point of mentioning the order of the points to prevent just this problem. In a later section of the tutorial, he reveals that j3d uses the right-hand-rule for culling. His orginal example was based on the lef-hand-rule.

I'll try to drop the author a note so he can correct the tutorial.

-Tab
50  Java Game APIs & Engines / Java 3D / Re: Newbie needs some help on: 2004-03-19 15:23:56
After getting some sleep and calming down a bit, I realized I left out some pertinent info from my previous post.

First of all, there's only 4 source files in the download: Plasma3d.java implements main, Universe.java implements the VirtualUniverse, Camera.java implements the view, and World.java implements the geometry. Together, the files implement a minimal 3d setup without using any of the utility classes in java3d. When I use the SimpleUniverse class from the utilities in other apps, I can get things working, but I don't want to use SimpleUniverse because I need more control over the view (when I get a bit further with my app).

I can run various demos from the java3d package successfully, so I know java3d is essentially working on my setup (which is java 1.4.1_01 and java3d 1.3.1 on WinXP Pro SP1).

Given the info here, I'm led to believe the problem is in the view related class (Camera.java) and not the geometry class (World.java). However, since I don't know what's wrong, who am I to judge?

I've tried fiddling with the camera location and geometry location, thinking maybe I wasn't seeing anything because it wasn't in view. I've also tried adding some ambient lighting, thinking I didn't have enough light. None of these things worked, which again leads me to believe there's something wrong in Camera.java.

I'm still stuck on this. Any help would be appreciated. Please? I can post the code directly to the forum if requested.

-Tab
51  Java Game APIs & Engines / Java 3D / Newbie needs some help on: 2004-03-19 02:22:30
I'm tearing my hair out with this one. I've been programming Java for about 7 years, and before that I was doing low level 3D stuff (hand-coding line drawing, polygon filling, and transforms in assembly), so I have something of a background in 3D, just not Java3D.

I've done various searches here and on Google, but I can't find any remedy.

I've been working on the a tutorial (http://www.j3d.org/tutorials/raw_j3d/index.html) and I've gotten to the end of chapter one where, supposedly, my program should produce a display with a square. I can't for the life of me figure out why it isn't displaying. All I get is a black window, no square.

I hate posting a pile of code and asking other people to help me, but I fear I have no choice this time. I'm totally stumped.

I've zipped up my code, complete with ant build script and batch file to start to app. I've posted it on my server: http://www.bennedum.org/files/Plasma3D.zip

Could someone please take a look and tell me what I'm missing? Please?

-Tab
Pages: 1 [2]
 
EgonOlsen (1254 views)
2018-06-10 19:43:48

EgonOlsen (1124 views)
2018-06-10 19:43:44

EgonOlsen (862 views)
2018-06-10 19:43:20

DesertCoockie (1270 views)
2018-05-13 18:23:11

nelsongames (1104 views)
2018-04-24 18:15:36

nelsongames (1334 views)
2018-04-24 18:14:32

ivj94 (2073 views)
2018-03-24 14:47:39

ivj94 (1226 views)
2018-03-24 14:46:31

ivj94 (2169 views)
2018-03-24 14:43:53

Solater (792 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!