Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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 3 ... 32
1  Game Development / Game Mechanics / Re: how would u conect joode 2 a java3d screen graph over the net? on: 2007-07-28 09:43:25
joode doesn't know anything about the renderer you use.

It has a bunch of Geoms, which represent you're Shapes (or TransformGroups etc. ) in Java3D. The positions of those Geoms get updated every time you call step() in joode. After you've called step, you can fetch those positions (and rotations) and send them to your client computer, who then updates the shapes' positions according to the data you've send.
How you do this sending exactly, and if you filter the positions you send (because the Client wouldn't be able to see them and you want to save network traffic) is up to you. Joode doesn't have any functionality yet for something like that.

I hope this helps a bit.

2  Game Development / Game Mechanics / Re: Compilation bug in JOODE on: 2007-07-17 21:29:45
ok - don't bother overwriting files I already migrated to joode, because I think we will do that again, when we know on which things we have to pay attention to. I already found some really nasty differences, I probably didn't pay any attentions at, when migrating the previous code.

The current list of differences can be found in doc/openmali-migration.txt.

Non the less, I will try to keep on doing the test migration, because there still will be nasty stuff with all that pointer thingies.

hmm - Tom, I think the next big thing in joode will be the migration to openmali. Marvin proposed to make a release before that, I think that's a good idea, because then we can redirect everybody to the release, while we're have time to modify the complete code, which will definitely make the code uncompileable for some weeks. Another idea would be to have an universal wrapper, so the code doesn't brake and we can test all the changes we make, or which allows parallel execution of the old and new part, so errors get auto-detected.
3  Game Development / Game Mechanics / Re: Compilation bug in JOODE on: 2007-07-16 17:58:16

you changed exactly the correct files Wink Marvin suggested to port joode code to the OpenMali vecmath lib (which also has MatrixNxMf and so on). So I started rewriting joode to that math-lib. But you exactly didn't change the files I already changed Wink very neat Wink

about that ported joode code, should we put it in a seperate branch first? It's simply loads of methods have different parameter orderings, so there might be bugs after the port. (Even while I'm trying to be extremely careful) + I could upload my changes too...even if it doesn't compile yet.

4  Game Development / Game Mechanics / Re: joode capabilities on: 2007-07-15 19:49:25
I used odejava before and found in unsatisfactory because many of its methods were broken and caused crashes.
that was one of the main reasons, why we created joode Smiley
I plan on using capsules mostly and maybe sphere's or boxes.  Eventually I would like to also implement a heighmap collider, so if anything ever comes of it I'll let you guys know.
With boxes, Spheres and Boxes you'll be fine indeed.
You're welcome to contribute your heightmap collider, when you're finished Smiley

5  Game Development / Game Mechanics / Re: joode capabilities on: 2007-07-15 11:48:21

I'm not quite sure how many bodies Tom was able to have in joode, he once mentioned something like that though (even in this forum, so do a search). But non the less I think joode will be able to do 1000.

But also the kind of Geoms in the Bodies is important, what are you trying to collide? TriMeshes for example are extremely costly, while spheres really go fast. But that shouldn't be the main issue, more important: There aren't yet all types off Collisions implemented yet!

You'll be able to collide all types of Basic Geoms with each other, those are:
- Box
- Plane
- Capsule
- Sphere
- Ray

also 2D is possible:
- Circle
- Rectangle
- Ray

If you need TriMeshes, joode might not be an option for you, because TriMeshes can only collide with Box, Sphere and other TriMeshes yet.

I also don't know how well the GeomTransform works ( so you'll be able to create complex geoms out of simpler ones ). And Cylinder doesn't collide yet with anything.

Bevore you try implementing your own physics engine (that'll be damn hard) , it's probably much easier to code the needed Colliders (that's not very easy either, but non the easier than coding the whole thing, I think Wink )

I hope joode is still useable for you Smiley
cheers, Arne

PS: I don't know what broumbroum is talking about, physics has nothing to do with applying textures to bodies and so on. Joode is completely seperated to any 3D engine. It will be easiest to use joode with Xith3D, because there already exist many helper classes for that.

PPS: As an alternative physics engine, there is also ODEJava, which uses ODE via JNI. In joode we "simply" ported ode to java to get rid of that jni and make it pure java.
6  Game Development / Game Mechanics / Re: XithConverter fixed and pimped on: 2007-07-05 21:48:31
With the new Event system all of these steps can be automatically done by listeneing to worldStep events and Geometry events. Thats what XithManager does, so
connecting the graphics engine to the physics is now a one line creation of the XithManager. Its much like how I altered the way the collision system to work.

very neat Cheesy
7  Game Development / Game Mechanics / Re: Multiple Geoms for the Same Body [JOODE] on: 2007-06-17 00:07:21
right, so GeomTransform should be fairly understandable (and fixable, if it doesn't run Wink ) - ohh and we should add a test in Space, that Geoms belonging to the same Body cannot collide.
8  Game Development / Game Mechanics / Re: [joode] TriMesh on: 2007-06-17 00:04:22
it was simply easier then resetting the vertices of the box (which isn't that difficult easier), and I simply was to lazy, to test, if that improves the results.
9  Game Development / Game Mechanics / Re: Multiple Geoms for the Same Body [JOODE] on: 2007-06-15 18:33:07
- By having a list of Geoms referred in Body instead of just one. But that would require that the Geom have two position/rotation : one position/rotation relative to the body (which doesn't change with stepping), and another absolute (world coordinate, is updated each step with the Body's own position/rotation)
that sounds like GeomTransform. But I don't know, if it works already.

By simply using a Space, but that would also require that the Geom have two position/rotation (relative to Space pos/rot, and world coord).
I don't follow you. The class Space groups geoms, that can collide with each other, so how do you want to force fixed positions into there?

I think using GeomTransform is the easiest way, because it's not as trivial as it first looks to have several geoms in one body, because the problem the solver has to solve gets modified.
10  Game Development / Game Mechanics / Re: [joode] TriMesh on: 2007-06-15 18:18:31
TriMeshBox is implemented now, too. I just convert the Box into a TriMesh in the Collider. There may be some bugs in it though (espacially with not 2x2x2 boxes), because I use some crude trick (I misuse the rotation matrix to also contain scaling) to set the size of the box, so I don't have to set the vertices all the time.
11  Game Development / Game Mechanics / Re: [joode] TriMesh on: 2007-06-14 20:00:54
trimesh-sphere works now Smiley At least I haven't found testcases speaking against that Smiley
12  Game Development / Game Mechanics / Re: [joode] TriMesh on: 2007-06-14 15:45:15
collision works, when the sphere hits a plane of the trimesh, but it behaves oddly, when it hits an edge. The response is way to high, and in collisions with that triangle-ball thingi it even gets the solver to hang (or something).
13  Game Development / Game Mechanics / Re: [joode] TriMesh on: 2007-06-14 09:52:13
Art answered me, seems the bug already existed before *puh* (or not, so it's now much harder to fix Sad )
14  Game Development / Game Mechanics / [joode] TriMesh on: 2007-06-13 22:19:59

I'm currently trying to implement TriMesh colliders for Sphere and so on, but I just happend to have found a bug, I produced into the TriMesh code, when transforming it away from javax.vecmath to the Joode vector classes. That bug is corrected, but it's still not correct (but a lot better).
To get the buggy test-case, you'll have to change the lines in TriMeshTriMeshTest specifying, what TriMeshes to collide, to make it collide two Pyramids.

Could someone please tell me, if that bug already existed before my changes removing the javax.vecmath dependency?

15  Game Development / Game Mechanics / Re: Initial Rotations for the geoms in the collision tests on: 2007-06-10 18:10:40
you were changing the position of the geom, but then you attached a body to the geom. But by that the position of the geom got replaced by the position of the body.

I just corrected that.
16  Game Development / Game Mechanics / Re: Motors on: 2007-06-10 18:01:39
ok, because you needed it, I just added to the svn. It contains an Motor. (And the Capsules)
17  Game Development / Game Mechanics / Re: XithConverter fixed and pimped on: 2007-06-10 16:55:30
Now the Geoms have Textures. Looks again much better.

No, the Capsule is not wrong. It's just, that you should not apply an inhomogenous scale to it. the radius and length of the sphere must be known at creation time (well, at least their proportion). After creation only a scalar scale can be applied (because it is a single geometry now). Where do you see the wrong Capsule?
i only applied a rotation, and it was correct before.
The example is shown in the image, I posted in the post above.

The reason, why I'm sure the Xith-representation of the Capsule is, because the rendered geometry of the capsule intersects with the other geometry and doesn't cause a collision.
It is no shadowing (unfortunately) it's just simple lighting. And it is quite simple to be configured. Just add a DirectionalLight to the main scene BranchGroup (see XithConnection line #60). Then add lighting enabled Materials with correct color settings to the shapes' Appearances. This can be seen in XithConverter. Oh, and the shapes need to have normals. Just do it like in XithConverter (or simply use it Wink).
nah - I was using XithConverter, but I didn't add that light source. So no surprise there actually Wink

18  Game Development / Game Mechanics / Re: XithConverter fixed and pimped on: 2007-06-10 10:34:23
mmh I think capsule is wromg, because, at the ends of capsule there are supposed to be sphere-halves and not streched sphere-halves (because collision with spheres is easier than wit other stuff).

+ how do I configure that shadow stuff? It somehow does no look even worse...


Edit: Have you made the floor transparent or something? The walls below it seem to shine through..
19  Game Development / Game Mechanics / Re: [JOODE] Joint(Angular)Motor on: 2007-05-22 20:19:33

I've got a box attached by a hinge Joint to the static world. The Box hinges fine. Now I want to make it rotating loopings  and being able to lift stuff up by adding a motor (or something like that).

There is JointLimitMotor, but I have no clue of how to use it. (Never did that with Ode either)

how do I do this?


solved - will add javadoc description, so others won't have to read the sourcecode...
20  Game Development / Game Mechanics / Re: JOODE: documentation on: 2007-05-22 17:19:14
public Example ( ) {
    super ( 128 f ) ;
    // first we’ll setup Xith (we want to show our results somehow , right ?)
    Tuple3f eyePosition = new Vector3f( 10.0f, 10.0f, 5.0f );
    Tuple3f viewFocus = new Vector3f( 0.0f, 0.0f, 0.0f );
    Tuple3f vecUp = new Vector3f( 0.0f, 1.0f, 0.0f );
    Xith3DEnvironment env = new Xith3DEnvironment( eyePosition, viewFocus, vecUp, this );
    this. getInputManager().registerKeyboardAndMouse(canvas);
    BranchGroup bg = new BranchGroup();
    env.addPerspectiveBranch( bg );
    canvas = Canvas3DFactory.createWindowed( 800, 600, ”My empty scene” );
    env.addCanvas( canvas );

this won't work, because
this. getInputManager().registerKeyboardAndMouse(canvas);

needs the canvas to be created already. But at that point it is still null. Or is that canvas argument not needed? Wink

Just another thing to mention:

    * The overridden onFPSCountIntervalHit() method should get a super call, since otherwise some other things won't work.

might also be the same in XIN Wink

21  Game Development / Game Mechanics / Re: [JOODE] Joint(Angular)Motor on: 2007-05-22 15:31:05
While I'm asking noob questions... does GeomTransform work - and if yes - how? I wasn't able to get it work.
22  Game Development / Game Mechanics / [JOODE] Joint(Angular)Motor on: 2007-05-22 10:58:10

I've got a box attached by a hinge Joint to the static world. The Box hinges fine. Now I want to make it rotating loopings  and being able to lift stuff up by adding a motor (or something like that).

There is JointLimitMotor, but I have no clue of how to use it. (Never did that with Ode either)

how do I do this?

23  Game Development / Game Mechanics / Re: JOODE: documentation on: 2007-05-22 10:38:35
OK, I'm currently reading your document. And I will write about my floating impressions...

Doesn't JOODE mean "Java Object-Oriented ODE" .> "Java Object-Oriented Open Dynamics Engine"?
nope, then it would have been JOOODE Wink
Weren't ODEJava's problems with native libs solved recently?
dunno - it's ugly anyways Wink
Gravitation -> Gravity Smiley
Triangle Mesh (list entry) should be annotated with the postfix "(TriMesh)", since this Word will be found in most documentations (and should be used in this doc).
you've got a point - done
I would not write, that ODEJava should be faster than JOODE, because it uses native libs. Java can be faster than C(++) even for number cruncher code (Java isn't that bad Wink). So ODEJava might be slower just because it has to handle the JNI overhead. But, yes, benchmarks are to do Smiley.
changed the should to might Wink
In the very first example you should move line #32 between lines #38 and #38 (and #43 after it), since the canvas is needed first there and if errors occurr while scene setup, OpenGL would not yet have been initialized and would not be hard-destroyed. This is not the best thing for finished games, but the best for testing.
I don't understand you here. How can I move something between one line. And what am I supposed to do with line 43 Huh
The step() method should be called like this:
protected void prepareNextFrame(long gameTime, long frameTime)
    super.prepareNextFrame( gameTime, frameTime );
    w.step( frameTime * 1000L );

Well, maybe we should provide the frameTime in nano seconds in xith.
I didn't made those frameTime dependent step sizes, because for now I prefer a stable simulation - jumps can have strange effects in physics simulation
I guess, your addGeom() method should take a NodeGroup instead of a BranchGroup. A BranchGroup is solely for the root of the scene (a RenderPass). And I guess, you want to add the Geom to any place in the scenegraph.
mmh - yeah, but I won't change that now, because than I would also have to change that XithBinding stuff.
You should use a Monospace Font for the code examples. I think, it would be good to use a background color for the code blocks like in XIN.
no - When latex gives me Java syntax highlighting, why not use it?
EDIT: The RenderLoop method prepareNextFrame() is meant to be used aith the super call as the first one. The renderNextFrame() method should have the super call as the last one. Thsi should be used like this in the documentation. It is not always used in the JOODE test in SVN. Maybe this should also be changed, if it wasn't made by intent, was it?

thanks for the feedback Smiley

new version is in the svn now.

24  Game Development / Game Mechanics / Re: [Odejava] Box won't tip over on: 2007-05-14 19:37:14
hmm - could it be, that you've set the mass incorrectly?

This error could happen, if you create your geom, set the position of the geom and then attach a body. The mass of the geom is centered at the origin of the Body's coordinate system. To solve the problem, change your Box' position by modifing the position of the body and not of the geom itself.
25  Game Development / Game Mechanics / Re: JOODE: documentation on: 2007-05-06 17:51:14
I think it's time to get this thread "on topic" again Wink

I've committed the first version of the documentation into the svn. You can find it in doc/joode-intro. How can we also put it on our Joode-webpage, so newbies won't have to hassle with svn?

btw. I don't like the title of the document I've created very much yet. So I'm open for renamings Wink Actually I'm not yet quite sure, what we want to put inside it, too.

I'll be away till next thursday, so don't expect me to answer till then Wink


PS: And yes - Joints are yet missing in the document.
26  Game Development / Game Mechanics / Re: JOODE: documentation on: 2007-05-04 11:16:24
yeah - Eulerstepper seems to run very well with it Smiley

great work Smiley - I think Joode is now finally in a state, which we could really call useable Smiley - It's damn time for me to create a first version of the Joode tutorial Wink

About this mu-thingi: I think for most simulation it is ok to have non mu-friction, but It'll be a nice thing to have.

27  Game Development / Game Mechanics / Re: JOODE: documentation on: 2007-05-03 15:56:17
somehow friction now got totally lost...
28  Game Development / Game Mechanics / Re: JOODE: documentation on: 2007-05-03 08:51:59
Hey, good work, Tom !!!

Euler now seems to run very stable. I wasn't able to find any explosion like behavior yet.  Cheesy

I can't really test RK4, because it's so damn slow somehow, I get an fps of about 8 fps, while Euler gives me 60. (so it should not entirely be my crappy pc).

29  Game Development / Game Mechanics / Re: Bounciness of rigid body? on: 2007-05-03 08:47:16
no, physics are supposed to be discussed here in general.

But Odejava is a very commonly used physics simulator, so there are many posts about odejava here.

But you can also find discussions about other physics simulators (e.g. JOODE) here, too.
JOODE btw. is a pure Java implementation of Ode, which Odejava uses.
30  Game Development / Game Mechanics / Re: More than one solution possible on: 2007-05-01 13:36:32
yes it does - maybe also a xith update fixed it? - I'm using the latest xith svn - or at least the one, that was the latest yesterday Wink
Pages: [1] 2 3 ... 32
EgonOlsen (76 views)
2018-06-10 19:43:48

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

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

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

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

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

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

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

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

Solater (173 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!