Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (532)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4 5 ... 8
  ignore  |  Print  
  Pure Java Port of ODE - planning/feasibility  (Read 41070 times)
0 Members and 1 Guest are viewing this topic.
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #60 - Posted 2005-10-04 19:46:49 »

...single or double precision.  How much will this matter?  Will using doubles make it any more stable?  Will it affect the speed significantly?

Quote
Will it affect the speed significantly
I would preffer to use doubles. Much less problems with bad rounding.

If Java would compile floats, and doubles optimally there would be 2x decrease in speed for doubles,if you don't think about other isues in CPU pipeline. I consider advantage of doubles as worthy to that 2x possible slowdown. Note that 2x difference was measured in a test that attempted to maximalize amount of instructions per second (sciencemark float/double SSE2 matrix multiply on celeron presscott core.). I expect that in real life it would be more like 1.4 difference.
Also I encountered a code that used floats, and was 10x SLOWER than code with doubles (highly likely a bug in JIT, or not.).

Few other notes.

I would be against abreviation in name. Too similar to JOGL, JOAL, and so on. A some more nicely sounding name would be more fitting.

Also isn't one of reasons for this undertaking to avoid mistakes present in ODE? And to have Java standards more abiding interface? Class names needn't be exactly copied from ODE.
Note that a code that believes into some documentation of other code that was ported from, often ends with poor documentation, if any documentation at all.


I don't think a class like.

public class ODEstore {
  public double data
  public double data2
}

Would be against any Java's conventions. Who is spreading that rummor? (This was actually asked by Lina Inverse...) Public variables are confy, and less error prone in a lots of situations. The speed difference between public access and a inline of get(set( is at most 2x on server after considerable running time. It's a quite opposite situation on the client (Or at least was on first JVM in 5.0 series.).

If you really need some implementation of matrix, I have one nearly ready, It could do multiply, inverse, and determinant. It looks like all what is needed. Actually it could do also perpetualization of itself.



YUDITH is a very nicely looking text editor on the Linux, with UTF support on top of that.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #61 - Posted 2005-10-05 00:38:07 »

Quote
I would preffer to use doubles. Much less problems with bad rounding.

Okay, but I think people have been quite happy for some time using floats in odejava. This is a gaming engine and I really don't think you need the precision that a double gives. Especially if it means you physics runs 2x as slow (and physics can often be the bottleneck)
Quote
Who is spreading that rummor?
I was the one spreading the rumour that public attributes are against java conventions. Maybe I should of said good practice. Java is all about good OO principles and data hiding is an important OO principle. I did not really think there was any real difference in speed with public variables these days.  Anyhoo, you don't mind public attributes and I want public attributes for different reasons (easy code comparison to C code) so we are not in disagreement.

The real Java convention I want to break that I know will be contravertial is giving some class names lowercase first letters so they have exactly the same names as their ODE counterparts. Thats still up for discussion at the moment. I think I will probably lose that one :-)

We do not need an implementation of a Matrix. Our discussion was actually whether we should copy ODE's or reuse the much more complete Matrix implementation in the vecmath package distributed with java3D. I think the team is in agreement now that we will reuse the vecmath one.

One of the main annoying bugs in ODE was a stack overflow in the LCP algorithm. Switching to java shoudl solve it. In the event it doesn't I think any of us could fix it. The other main buggy part of ODE is the collision system. I don't think there is really an immediate plan on how to fix that, other than maybe not to port the broken bits so people won't be dissapointed when using the engine. I have a idea on what to do with the collision system but I refuse to commit to implementing it (it involves calculating eigenvectors if your matrix class can do that, the vecmath one can't).


Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #62 - Posted 2005-10-05 01:38:52 »

How much time do you guys someone to devote their time to this effort?

Jeffrey F. Elrod
Complexsive Systems
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #63 - Posted 2005-10-05 02:12:46 »

I was the one spreading the rumour that public attributes are against java conventions. Maybe I should of said good practice. Java is all about good OO principles and data hiding is an important OO principle.
Yes.. but Ithink that is in the conext of hiding the data structures used for a particular implementation of an algorithm.  I think the type of structs that would be simpler with public member data are things similar in concept to what Java already does this with, like Point, Dimension, Insets, etc.  They are still 'simple' types in a sense.  Usually manipulated by other classes, not member methods of their own class.

I think JOODE ("Judy") is a cool name for the project too Smiley

Offline Niwak

Senior Member


Medals: 1
Projects: 1



« Reply #64 - Posted 2005-10-05 11:55:32 »

I think data hiding is really an important OO design principles. You are right stating that in some very special cases public attributes fit well but I think that this is for very special cases like Point, Vector, Color,... i.e. classes that are so stable that they are highly unlikely to see these attributes ever change. This is not the case for most classes and one of the major problem with not hiding data is that, if you want to abstract your class later in the development process, you won't be able to replace it with an interface. From my experience getter / setter have a near 0 footprint.

On the subject of float versus double, I have no idea of what is the best but there have been a couple of posts in the forum stating that doubles are actually faster than floats. This has to be checked since we could benefit of using doubles both in speed and in precision.

                Vincent
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #65 - Posted 2005-10-05 13:10:21 »

Quote
I would preffer to use doubles. Much less problems with bad rounding.
The real Java convention I want to break that I know will be contravertial is giving some class names lowercase first letters so they have exactly the same names as their ODE counterparts. Thats still up for discussion at the moment. I think I will probably lose that one :-)

Hey, when we simply remove the first Letter (that's always a 'd', if not prove me wrong), we get upper letter class names. So what's the problem there, we could simply write then:
 For documentation see 'd'+ClassName in the ODE specification

About float/double:
I only know that Xith3D is using floats, because the graphic cards use floats. But we don't use the hardware of the graphics card here. But because Xith uses floats it would be much easier for the user, when we use floats, because else Vector3d would have to be transformed into Vector3f and this could get time expensive. So we would have to put another layer around or ODE port and then we could also use our own Matrix and Tuple classes. Another drawback for javax.vecmath just occured to me: For the Math stuff it'll probably pretty bad, if we'll always have to convert between e.g. Point3x and Vector3x, because we need methods from Point as from Vector (This happens pretty often if you do crude, fast math). On the other hand Java3D uses also Vector3d.

So I think we have two options here:
1. use doubles, which have more prcision andmight be faster, and add a layer around the ODE port, which could cost some performance.
2. use floats, which have not that much precision, and have direct acess to the ODE port, which makes it faster.

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #66 - Posted 2005-10-06 16:55:40 »

Quote
So I think we have two options here:
1. use doubles, which have more prcision andmight be faster, and add a layer around the ODE port, which could cost some performance.
2. use floats, which have not that much precision, and have direct acess to the ODE port, which makes it faster.
I don't understand these two options. A double warapper around a float based port will not work. There will be no benifits. We could design the system so that both are supported but this is not preferable as it means design changes. Really a hard decision has to be made upfront. ODE is preprocessed to either use floats of doubles (effectively).
Double do require slightly less effort to code becuase you do not need to suffix f to everything. I spose it does not really matter, it is not a big deal to transform the system from one to the other with skilled use of replaceAll function.

I think this thread (with a sun engineer invloved) does resolve the issue
http://192.18.37.44/forums/index.php?topic=8234.0

Floats are now faster, becuase they are used properly.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #67 - Posted 2005-10-06 19:01:38 »

Quote
So I think we have two options here:
1. use doubles, which have more prcision andmight be faster, and add a layer around the ODE port, which could cost some performance.
2. use floats, which have not that much precision, and have direct acess to the ODE port, which makes it faster.
I don't understand these two options. A double warapper around a float based port will not work.

I meant it the other way round- using doubles inside and floats on the outside (cos maybe in the internal stuff has to be more exact)

Quote
I think this thread (with a sun engineer invloved) does resolve the issue
http://192.18.37.44/forums/index.php?topic=8234.0

Floats are now faster, becuase they are used properly.

Ok floats then. Cos this will be faster than doubles and we won't have to make another layer for 3D-API.

:: JOODE :: Xith3d :: OdeJava ::
Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #68 - Posted 2005-10-06 22:09:54 »

This may be too soon to answer, but will the transition for applications that are now using OdeJava be smooth transition to JOODE?

Jeffrey F. Elrod
Complexsive Systems
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #69 - Posted 2005-10-07 03:18:53 »

This may be too soon to answer, but will the transition for applications that are now using OdeJava be smooth transition to JOODE?

Yes.  Unless you are using the unsupported functions of Odejava (which are documented as such) you won't have to change a thing.

Will.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #70 - Posted 2005-10-08 22:27:09 »

So how are you continuing? Did team assembled? Did you looked into ODE internals and properly analised pipeline? Like: pointer A, B....    A++ = (something++) *(*B)

ODE has a lot of code where assembly syntax like mov eax, [eax] rules over C one.

I tried a little benchmark of floats and doubles I used 4MB + arrays to prevent any locality. Floats were faster only if you didn't use  ((float) Math.sqrt(float)) * ... If there was any need of retyping into a float, speed was worse than 6 multiplications and one division tried with double data type.

Of course there is also question if ODE problems are not caused by low precision. Did anyone tested ODE recompiled into doubles, and compared it with float based ODE?


As for data hiding. Don't overdo it, game library needs to be able to work in close cooperation with itself. If people abstract every layer inside library, library could be slower, and possibly harder to maintain.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #71 - Posted 2005-10-08 23:26:17 »

Quote
As for data hiding. Don't overdo it, game library needs to be able to work in close cooperation with itself. If people abstract every layer inside library, library could be slower, and possibly harder to maintain.

There won't be any datahiding. Almost everything will be public attributes.

The project request has been sent off now. It was delayed unfortunatly becuase the system was closed for maintanece when I tried to do it Thurs. I am suprised they did not put up the project up though in the forums anyway though, becuase I did send an email to the dev people. Oh well. I hope this does not delay us too long.

So floats are decided. I am gonna gonna preprocess the C and see if I can build a more complete UML diagram (it was ignoring PP instructions so was probably losing information).  Woo!

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #72 - Posted 2005-10-09 11:31:07 »

I think JOODE ("Judy") is a cool name for the project too Smiley

For what it's worth, I don't see JOODE as "Judy". After all, the English name Cooke is not pronounced Cooky", nor is the word code pronounced "cody". I can't think of any words ending with 'e' off the top of my head where the e is promounced 'y'. I read JOODE as in "Hey, Jude".
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #73 - Posted 2005-10-09 21:07:50 »

Quote
I read JOODE as in "Hey, Jude"
Hmmm. Yeah. You might be right. Either is cool though. We will swap pronounciations to whatever is most unpopular at the current time to keep people on their toes.

I have managed to construct a fairly comprehensive set of Java classes based on the ODE source using bouml. There are 304 classes in total, though most of these need to be deleted and alot are just typedefs. In doing this I had to alter the ODE source to give the enums names, becuase currently they are anonymous. Hence I will be including a copy of the ODE project so that we have a project copy that we can keep in sync. I will also put in the latest verion of the ODE in the javaode project, and the required .dll and .so so tests can be written to compare functionality and check things are working.   

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #74 - Posted 2005-10-10 18:58:10 »

Only a side thingi, but you said, that we first should only allow Boxes and Sphere's as collideable objects. But we also should keep in mind to be able to extend the number of objects.
We e.g. should be able to have something like a GeomTerrain, that's not implemented over a GeomTriMesh (because as we know GeomTriMesh sucks). GeomCylinder and in the end GeomTriMesh (even if it sucks - it's needed) should be added later on, too.

I don't know how collisions are implemented in ODE, but we sure should try to have a working solution, where we don't have to code extra stuff for all different pairs of Geoms. (I believe this is the case in ODE, if not, the rest of this post is garbage, because it deals with generalizing collisions between two objects)

I've got an idea of how do get the collision point between two objects (independent of the type of the objects), but as an idea it's pretty good I think, but it's close to impossible to implement (without a huge performance reduction). I'll post it anyways:

I explain it with a 2D example, because I think then it's eaier to understand.
We always probably start with a situation like in collision1.jpg (attachment) To find the closest intersection point we can transform it into collision2.jpg (simply rotate) Now we can represent the Objects as mathematically functions, so we can solve the problem with analysis. We got an equation like this:

    a(x) = d-b(x)
=> a(x)+b(x) = d

To find the first collision point, we have to find the absolute maximum of a(x)+b(x).
To do this we have to calculate:
        (a(x)+b(x))' = 0
<=> a'(x)+b'(x) = 0
From all the x that we get as a result, we have to use the one with maximum distance.

Problem's with this algorithm:
- The algorithm would automatically have to be able to solve a'(x)+b'(x), in 3D this would be even more complicated, so we would need a Math API that can solve equations and for 3D also derivate.
- For rotating Body's ( which pretty often happens) it would also get more complicated.

It's crap right? Some self critics has to be  Roll Eyes

Nah, If such a Math API exists (than can solve this stuff pretty fast) I could imagine this to be an option. Ode specifies collision cases between all different Geoms (I am right here, right?), so we could do like wise (faster) and only use this method, if no such collision got specified.

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #75 - Posted 2005-10-10 23:47:21 »

Bounding box? It works on any geometry. Sphere test works as well. Even plane ray test needs just 12? multiplication and one division in 3D space.
Offline kitfox

Junior Member




Java games rock!


« Reply #76 - Posted 2005-10-10 23:55:12 »

JOODE sounds like a great initative.  Please post a link to the project when you get the website set up.  I'd like to sign on as an observer, or maybe even contribute code (although there's now way I could commit to giving time to the project).

If it's going to be a straight port of the ODE code, hopefully that will mean few surprises.  I've implemented my own physics engine in Java, and did not find it an easy task.  (Although is did get a ball to roll down a corkscrew spiral and then bounce on the ground, which was fun).

Mark McKay
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #77 - Posted 2005-10-11 14:12:03 »

Arne. The problem with collision detection is not detecting a collision, but quickly detecting that there hasn't been a collision. The reason why I suggested we only implement boxes and shperes at first is just for simplicity. We can't port the ODE trimesh code so we need a fresh approach to arbitary geometries. This may mean a whole rethink of how the collision systema ctually works, so I don't think we should faithfully port all the collision code we can think of (like CCylinders and rays etc). Anyway I really don't want to think about the next step yet. So just spheres and boxes for now.

Kitfox. We are jsut waiting for the project to wind its way through the admin. Should be going soon.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #78 - Posted 2005-10-11 14:22:43 »

Yeah, but we should keep in mind, that it should be able to get extended later on.

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #79 - Posted 2005-10-11 14:28:50 »

Arne. The problem with collision detection is not detecting a collision, but quickly detecting that there hasn't been a collision.
In the end it's just the same.

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #80 - Posted 2005-10-11 17:43:55 »

Arne. The problem with collision detection is not detecting a collision, but quickly detecting that there hasn't been a collision.
In the end it's just the same.
Yeah, because if the simulation slows down when there are several collisions, it's bad too...
Someone posted a link to a paper (http://www.peroxide.dk/papers/collision/collision.pdf) which is very interesting.
They do collisions between ellipsoids and tri meshes. To simplify the process, they create a specific ellipsoid vector space (where the ellipsoid is an unit sphere) and they transform the trimeshes coordinates to this space. It simplify a lot the computations and it's much faster. We could combinate this with AABB auto-generated trees (with adjustable depth) and it would be a very good starting point.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #81 - Posted 2005-10-11 19:18:03 »

Yes we should use a tree to split up regions.
I did this once for a 2D application, where circles were flying onto a mass of other circles. I was able to create 1 000 000 circles in this way in 1 minute using a quadtree, where other contestants (it was for a contest) only were able to do 100 000 in some hours, not using a quadtree, but c++. The tree ofcourse had some other advantages (because I didn't really simulate)

For a tree I'd suggest an octree with variable depth, a simple 3-dimensional array would probably also an alternative, but I think it'll take too much memory.

Hmm.. what about a 3-dimensional linked list? Objects normally only move from one field to another (done in constant time in linked list) - But then we also have to think about: should the fields in the linked list of the same size, or should they have dynamic changing sizes, or - do we even want to link the objects directly?

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #82 - Posted 2005-10-12 23:54:56 »

Sparsely populated arrays can be effeciently replaced with HashMaps, which I beleive is exactly what HashSpace does. HashSpace is also multi resolution in the ODE implementation.
As for Oct Trees I think I have mentioned this. ODE has QuadTrees which don't really make sense for a 3D environment, although I spose are applicable to landscape shaped worlds like battlefeilds. However I have never been able to work out from the ODE docs what way round the QuadTrees are orientated so using them is not immediatly obvious.
I would not worry too much about Spaces yet. We will have enough on our plate getting a basic system using a SimpleSpace going.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline kitfox

Junior Member




Java games rock!


« Reply #83 - Posted 2005-10-13 08:25:43 »

I'd think that if this project goes ahead, that putting off triangular mesh collision to later is likely a bad idea.  Namely because colliding with triangular meshes is the main thing anyone will want to use a collision engine for.  While spheres and boxes would be faster to implement and get the engine working early, putting meshes off too long might paint the project into a corner where adding triangular mesh support is difficult.  If this happens, JOODE won't have much use beyond simple demo programs.

Mark McKay
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #84 - Posted 2005-10-13 18:45:34 »

I think kitfox is just right.

About octrees, spaces and all that stuff, here's my ideas :
 - Why doing different kind of spaces ? One is suffisant. The distinction between simple shapes and trees could be done at the Geom level. It's each Geom that is responsible to check if it collides with each other.
- For trees, imagine a tri-mesh object. We first check if the object we handle collide with an AABB of the tri-mesh object. If not, there's no collision. If yes, then we subdivide the AABB into 2, 4 or 8 AABB more precise. Then we check collision again. And so on, we stop at a defined step were we check triangles individually.

- How do we do about the relationship between BodyS and GeomS ? Can have a Body multiple GeomS ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 742
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #85 - Posted 2005-10-13 19:29:43 »

- Why doing different kind of spaces ? One is suffisant. The distinction between simple shapes and trees could be done at the Geom level. It's each Geom that is responsible to check if it collides with each other.

That's true... but then you just discarded one of the best ways to optimize calculations.

You have to subdivide your space, to prevent checking everything against everything else.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #86 - Posted 2005-10-13 20:33:50 »

It's standard algorithm (a - 1) *(a/2)

so for 5 objects you have 4 + 3 + 2 + 1 tests. It completely kills performance for 10000 objects.

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #87 - Posted 2005-10-13 21:34:22 »

I think kitfox is just right.

About octrees, spaces and all that stuff, here's my ideas :
 - Why doing different kind of spaces ? One is suffisant. The distinction between simple shapes and trees could be done at the Geom level. It's each Geom that is responsible to check if it collides with each other.
Yeah, but the Geom has to find the Geoms it could collide with. The geom could do this over a space. A always good thing is to use an interface for space, and simply implement the space, we think fit's best. This way we're still open to use other spaces.
Quote
- For trees, imagine a tri-mesh object. We first check if the object we handle collide with an AABB of the tri-mesh object. If not, there's no collision. If yes, then we subdivide the AABB into 2, 4 or 8 AABB more precise. Then we check collision again. And so on, we stop at a defined step were we check triangles individually.
Yes. This is a very nice and probably also efficient way of doing collisions. As example, if we first specify a bounding sphere that contains the terrain as a whole. Only if another Object collides with the Sphere, it can collide with terrain, so we split up to get more detail. If it still can collide with one (or several) of the subspheres, we have to check there also until we're at triangle level. If in one step we don't find any Sphere's it could collide with, we're finished and no collision happened.
Quote

- How do we do about the relationship between BodyS and GeomS ? Can have a Body multiple GeomS ?
This is a hard one. If it could gain us some performance we should implement it. (Static joints didn't seem to work that well for Odejava)
So with that you start onto a new crutial section of ODE: Joints. I'd say we should keep with how it's done in ode (answering the question above  Tongue ) But we tried to do that with the collisions also and now we've got a full scaled discussion going of how to do collisions Cheesy - so this can change.

Quote
It's standard algorithm (a - 1) *(a/2)

so for 5 objects you have 4 + 3 + 2 + 1 tests. It completely kills performance for 10000 objects.

yep it's O(n²) vs O(n log n), but is there a faster way? That's Question, are we able to get O(n) ?

I already mentioned a LinkedSpace, where every Object knows it's neighbors (with whom it might collide). If implemented correctly it could get O(n).

But thats Space discussion - if we do a good interface, we should also afterwards be able to implement such stuff.

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #88 - Posted 2005-10-14 00:31:06 »

ODE allready has spaces kind of hidden like interfaces. I think in the convertion we will end up with abstract classes for the geom supertype and the space supertype. Space division is important, thats allready handled well in ODE with HashSpace. An OctTree space would be really handy in addition.

I dunno what is best for trimeshes. I am not going to worry about it until the other parts of the system are done. Like the LCP solver.

BTW, I have got my development platform setup now. I have translated the skeletal structure of ODE into Java, however the process has lost many attributes. I have put the reverse engineered model in its own package. I do not beleive working off that directly is a good idea, but its nice to have it there for reference and cutting and pasting the bits that are correct. I would say as we implement bits we build up code in other packages. That way we know which bits really are implemented.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #89 - Posted 2005-10-14 00:34:43 »

The hanging moss algorithm can be extended to 3D to greatly reduce the amount of geometry you have to search through for a collision. Similar to a progressive refinement on an octree collision detection method.

Quote
An OctTree space would be really handy in addition.
Im sure there is already on in ODE too...But you have to give it the extents of the quadtree, which makes things hard for free flow environments...

Quote
Can have a Body multiple GeomS ?
Doesn't ODE/Odejava already have that? Compound objects? IIRC, its even covered in the ode docs...

Quote
I already mentioned a LinkedSpace, where every Object knows it's neighbors (with whom it might collide). If implemented correctly it could get O(n).
Dont think that would work arne. Imagine a high speed moving thing over lots of little boxes (the boxes being the terrain). The moving thing would have to recalculate its list everytime it updates because its moving. Which again boils down to an O(n*n) solution (or the 3d hanging moss). Unless I understood you wrong?

BlueSky, you still haven't told me the difference between the integrators. I can't find it anywhere on the internet...

D{

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Pages: 1 2 [3] 4 5 ... 8
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (14 views)
2014-07-24 01:59:36

Riven (14 views)
2014-07-23 21:16:32

Riven (13 views)
2014-07-23 21:07:15

Riven (15 views)
2014-07-23 20:56:16

ctomni231 (43 views)
2014-07-18 06:55:21

Zero Volt (40 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (36 views)
2014-07-16 23:30:00

Cero (50 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 08:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 05:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 05:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 16:13:37

HotSpot Options
by Roquen
2014-05-15 14:59:54

HotSpot Options
by Roquen
2014-05-06 20:03:10

Escape Analysis
by Roquen
2014-04-30 03:16:43

Experimental Toys
by Roquen
2014-04-28 18:24:22
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!