Show Posts
|
|
Pages: [1] 2 3 4
|
|
7
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-31 17:21:30
|
OK. Have not moved to Subversion yet. Yeah this is the problem. I can't get any of the instructions to work for migrating the CVS repository in the proper fasion. Have not tried a SVN dump yet. Can you send me one (I think you have my email)
Well, the compressed file still has a size of over 6MB. I will put the file on the shell server, where it has to be for the import anyway.
|
|
|
|
|
9
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-31 11:49:57
|
|
STOP!!! Please try to keep the history, it could be useful if we looking for bugs. If you just delete the history we could have made all changes to CVS as well.
If you have any problems wioth importing the history please tell me and I will try to help you. I can provide an archive containing an SVN dump of JOODE. This should be the prefered way of setting up an Subversion repository.
|
|
|
|
|
11
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-29 20:19:13
|
Most important thing would be, that you migrate the project to Subversion. We need this for repackaging. Otherwise we will not be able to change the visibility of fields. Would be nice if you get this done 
|
|
|
|
|
12
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-29 19:47:43
|
I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.
That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list. Sorry if you find this junk but I agree with t_larkworthy. The Wine project ( http://www.winehq.org) do has a lot of feature and yet they began their X.Y numbering with 0.9. They're actually at 0.9.14 (which I'm actually upgrading to). A 1.0 release is not a small thing, see ODE which is still at 0.5 ! If you read the whole mail you will see that I suggest to start with 0.5 before heading towards a 1.0 release.
|
|
|
|
|
13
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-29 10:41:20
|
I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.
That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list. Make sure all the users methods have javadoc's. Make sure there is methods for everything that is expected to be interacted with, (so no direct interaction with the force accumulator, for instance). Intergrate the properties system with the code flow. i.e. which step method that should be used should be chosen via the properties file etc.
All that is not that important for a release. The only really relevant thing for a first release (let's call it 0.5 before doing a 1.0 release) is that the code is stable und working. The API should not change dramatically anymore and of course everything must be working. And that's where I see the problems for a release right now. The API is not stable and I still have problems getting everything running. As soon as I start implementing more complex applications the physic system is exploding. Write a logging system. I don't like extra dependancies like log4J. I am thinking something very simple. Maybe 3 levels, which all require the C style IO. (to avoid string concatinations)
Why not use the JAVA logging API? I would really discourage from an own logging API. Bigger things that need a bit more discussion are general architecture improvements. I was mentioning this at chrismas. I think it would be good if we could have an interceptor pattern for step events on Bodies and contruction of bodies and geometries etc. This will allow extra simulation behaviours to be snapped in easily. We could even refactor some of our existing ones out like gravity.
Yeah, I've got lots of ideas as well. But let's get the current code clean and running and it should be no problem to make improvements in the future.
|
|
|
|
|
14
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-28 11:03:11
|
|
Could you please make an announcement before you migrate to Subversion. I think it will take some time until the code is moved to Subversion. I do not want to have code changes I have to merge afterwards.
Another thing I'd like to know is what is your idea of how JOODE will go on. You are the project leader and administrator, but I see no directions from your side how JOODE will go on. Since I have joinde JOODE only arne and me are really working on the project. I am afraid JOODE will get stuck, as long as no one will have the ambition and vision in getting JOODE on. We need directions in this project.
|
|
|
|
|
17
|
Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects
|
on: 2006-05-22 11:52:05
|
No, i disagree. A library might contain listener for other implementation to get notified of changes, but it will not provide hooks for direct data manipulation. Especially for a physics library this would almost always result in unpredictable results. If there are improvements they have to be made in the physcis library.
err, either I misunderstood you, or you didn't understand what I meant... what do you mean with "hooks for direct data manipulation"? What I meant: many libraries do something like this: 1 2
| private Vector position; public Vector getPosition() { return position; } |
This is problematic if Vector is not immutable for the public. You can do somePhysicsObject.getPosition().setX( 5 )! And you could even do this while physics is in the middle of some computation etc. That's why my suggestion would be to hand out values only not a reference to a mutable object (or hand out immutable objects). OK, now I understand what you mean  Well, making values immutable requires an interface again. But handing out only values would be fine. Values have to be copied again, if they should be immutable, but if you want to manipulate the returned data again, there is no way around copying values. You also have to be aware that you will be able to manipulate data, if we decide to put there an interface for float arrays. If the reference to the array are kept and data is manipulated outside the physices engine then the physics engine gets corrupted again. But I prefer to put there some best practice adviced over making everything bullet proof.
|
|
|
|
|
18
|
Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects
|
on: 2006-05-19 18:33:03
|
[...] Keeping references means that only the objects that have moved will suffer the virtual call overhead, which is neglectiable these days...
Or is there something im missing ?
Yes, I think so: libraries might not want to give away references - to detect changes to their vectors and avoid recalculation of derived values for each step. No, i disagree. A library might contain listener for other implementation to get notified of changes, but it will not provide hooks for direct data manipulation. Especially for a physics library this would almost always result in unpredictable results. If there are improvements they have to be made in the physcis library. (vectors=float[] and matrices=float[][])
not necessarily! javax.vecmath -> Vector3f -> no float[] This is exactly the problem: the math library would have to use the same interface / data class which is not the case, usually. That's really bad. So sorry for javax.vecmath  Then I see no way for integrating data from javax.vecmath - unless we do not decide to use kavax.vecmath as underlying math library for JOODE. And regarding the interface proposal with functions: you can't unify the different math libraries this way as they may have similar signatures but methods behave differently (e.g. javax.vecmath.Vector3f.add(Vector3f) vs. jme.math.Vector3f.add(Vector3f)). So, yes, hdietrich this would be no benefit. But I don't see how this 'common interface' should work  You must provide implementations for every math library supported, that hide the math libarary's signature. A factory could hide the concrete instantiation. But without gaining any benefit from this we do not have to think about this anymore. What are the most common math libraries we should support? Java3D = javax.vecmath Xith3D = javax.vecmath jME = own math library (does this one use arrays as underlying datastructure?)
|
|
|
|
|
20
|
Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects
|
on: 2006-05-18 17:52:09
|
|
For the internal calculations - especially the lcp solvers - we will need own math implementations.
The frontend requires us to have:
[ul] [li]position vectors[/li] [li]rotation matrices and/or quaternions[/li] [li]force vectors[/li] [li]torque vectors[/li] [li]maybe the moment of inertia matrix[/li] [li]vectors for the definition of geometries[/li] [/ul]
I think that's all. If we have interfaces working with arrays we won't have to show anything at the front - the math library will be hidden from the user.
|
|
|
|
|
23
|
Game Development / Game Mechanics / Re: JOODE Project Structure
|
on: 2006-05-18 14:56:38
|
Ok - I fixed that JointSlider stuff, the testcase now works, there wasn't a bug in the Joint, but in the testcase (sign error) mmh ... sourceforge seems to down again...or do we already have subversion?
I have a very simple test for the JointSlider involving a Box and nothing else. This is nearly the same as SingleBodySliderTest, but it fails. Am I doing something wrong? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
| package net.java.dev.joode.test.joint;
import javax.vecmath.Vector3f;
import net.java.dev.joode.body.Body; import net.java.dev.joode.geom.Box; import net.java.dev.joode.joint.JointSlider; import net.java.dev.joode.test.SimpleWorld;
public class SliderTest extends SimpleWorld {
public SliderTest() { super(true);
Box box1 = new Box(this.space, 2, 2, 2); Body body1 = new Body(this.world); body1.pos.setY(4); body1.pos.setX(-4); body1.mass.setBox(1, box1.getSide().getX(), box1.getSide().getY(), box1.getSide().getZ()); box1.setBody(body1); this.gfxManager.addBinding(box1, this.view.getScene());
JointSlider slider = new JointSlider(this.world); slider.attach(body1, null); slider.setAxis(1, -1, 0); view.getView().getTransform().lookAt(new Vector3f(0, 0, 10), new Vector3f(0, 0, 0), new Vector3f(0, 1, 0)); }
public static void main(String[] args) throws InterruptedException { SliderTest test = new SliderTest(); while(test.fps.runs()) { test.step(); } }
} |
Slowly I hazard a guess that there is something wrong with the moment of inertia created for a box...
|
|
|
|
|
24
|
Game Development / Game Mechanics / Re: JOODE Development Status
|
on: 2006-05-18 14:52:17
|
Uh, you are right. The BoxBoxCollisionTest and BoxCollisionTest show ugly results. The rest of the tests are OK, at least the one's that were working before. I have the suspicion that the BoxBoxCollider still has errors. The Stepper were not influenced by the last changes, so I think it's not realted to the API changes I just commited. I will do some debugging of the BoxBoxCollider again 
|
|
|
|
|
26
|
Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects
|
on: 2006-05-18 14:36:09
|
Let's assume we will have very low impact on performance by putting there an wrapper around the concrete math implementation. What are the concern regarding memory? As far as I see we only need plain vector and matrix operations for JOODE (add, multiply, dot-, and scalar-product). The vector and matrix data will always be a plain array of float or double values. The rest of the code will be methods to manipulate the data. What will a wrapper look like? 1 2 3 4 5 6 7
| public interface Vector { void add(Vector vector); void add(Vector vector, Vector result); void multiply(float a); void multiply(float a, Vector result); ... } |
Isn't this the code implemented by nearly every math library? What are the benefits of putting there a wrapper instead of a concreate math library? If we manage to share the underlying data structures (arrays) from my point of view we will have no benefit. So my suggestion is to put there interfaces, which allows us to share the data structures (arrays), and use whatever math library fits best to the needs of JOODE.
|
|
|
|
|
27
|
Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects
|
on: 2006-05-18 10:59:11
|
For deciding wether to use interfaces or dublicated position/rotation/scale etc. we really should do some performance tests. (my guess is that copying data could be faster than having interfaces)
We have to obey the tradeoff of performance and memory consumption. But some tests would be nice  But I think what really should not be doubled is the memory needed for trimesh geometry as that is a lot of memory. Wouldn't it be most appropriate to use java.io float buffers there? Does JOODE use them?
Right now JOODE does not support trimesh geometry. But I agree that the trimesh definition should be an array of float of a float buffer. It will be interesting how to handle Vertices, Edges, and Faces, because this are informations that might be needed by Renderer and Physics Engine.
|
|
|
|
|
30
|
Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects
|
on: 2006-05-16 13:48:41
|
So I am interested in what are goals of jME Physics 2 if it wants to everything agnostic?
It does not. As stated above it does not make sense to me to be scenegraph agnostic. jME Physics is a physics abstraction/API layer for the jME scenegraph. My fault, I mixed up the response from MagicSpark with the jME Physics goals. Sorry. As stated above I think JOODE can contibute only very few things to this dicussion.
I think the developers on this forum can contribute a lot to this discussion  (and that's not only JOODE developers) That's why I said JOODE  Your suggestion to have wrappers for the math package or to abstract from the actual data holding classes seems problematic to me: first performance would be degraded (polymorphism costs a magnitude in access time). Second it would be very hard to define the semantics of operations on the math data without actually specifying the whole math package.
I think about wrappers, which implement an common interface. By doing this we could have implementations for different libraries. I do not think that the performance impact would be that much. Moreover it is questionable if the impact on memory consumption is nearly the same just as having math structs twice. Thus either using the same math package or converting values on demand seem to be the only choices to me. Why do you use a custom math package in JOODE and which package should be used in favor and why?
The custom math package is a relict from the ODE port. ODE has its own math library and this was ported as well. But this library is very unhandy, since it makes use of pointers a lot. As I already mentioned it will be replaced sooner or later. For me (personal opinion) vecmath from Java3D would be the preferred library. I think it is the most popular library used for game development.
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|