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 (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 5 6 [7] 8
  ignore  |  Print  
  Pure Java Port of ODE - planning/feasibility  (Read 41079 times)
0 Members and 1 Guest are viewing this topic.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #180 - Posted 2005-11-17 20:48:40 »

Quote
This is what I wanted to introduce when I talked about "GeomGroup", but, err... it's a bit more logic to do "BodyGroup(s)", you're right (or CompositeBody if you want).
Well certainly its possible. There are alot of places it could go wrong though. I have had no sleep for the last 2 days as I have been tearing my hair out getting planar subdivisions calculated properly. I just solved it and I have realised they are not powerful enough. Hmpf! I have a presentation 2morrow as well so I think I am gonna have to present "planar subdivisions".
I am desperatly trying to get convex trimeshes completed for the weekend, so I can then relax for a while  Wink

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #181 - Posted 2005-11-18 00:29:02 »

Yes indeed. I have finished my presentation. It had to be a 5 min presentation on anything I liked and as there is only one thing I know anything about at the moment it had to be something to do with planar subdivisions.
Those of you with open office impress might like to see the presentation becuase it does give a rough thoery of how I am takeling the trimesh problem (very rough as I have to present the talk in 5 mins)
http://homepages.inf.ed.ac.uk/s0570397/planar.sxi
Ii is intended to be amusing, dunno if that will carry over the internet quite so well...  Undecided

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 #182 - Posted 2005-11-18 07:47:28 »

Quote
Ii is intended to be amusing, dunno if that will carry over the internet quite so well...  Undecided

It is Smiley

Nice, you're advertising joode Wink

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Member




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


« Reply #183 - Posted 2005-11-18 19:30:56 »

I traced now loads of errors in BoxBox collisions, but it still doesn't work, because now I get some ArrayOutOfBoundsException, from a part of the code I haven't touched and I don't know how my changes could cause this problem (I propbaly don't know enough). I hope you can help me out there.

Stack-trace:
1  
2  
3  
4  
5  
6  
7  
8  
9  
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 216
   at net.java.dev.joode.util.RealPointer.setValue(RealPointer.java:77)
   at net.java.dev.joode.util.MathUtils.dMultiply2(MathUtils.java:575)
   at net.java.dev.joode.stepper.InternalStepIsland_x1.step(InternalStepIsland_x1.java:234)
   at net.java.dev.joode.stepper.InternalStepIsland.step(InternalStepIsland.java:27)
   at net.java.dev.joode.stepper.StepUtils.dxProcessIslands(StepUtils.java:116)
   at net.java.dev.joode.world.World.step(World.java:159)
   at net.java.dev.joode.test.step.SphereCollisionTest.step(SphereCollisionTest.java:137)
   at net.java.dev.joode.test.step.SphereCollisionTest.main(SphereCollisionTest.java:195)


I've commit my changes (they are only used by BoxBox collisions, so everything else should work still).

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #184 - Posted 2005-11-19 04:22:36 »

It's great to see this project taking off.  I am sorry to have not been of much help, I have been rather busy with my new job.  On the plus side I have had to learn C++ (fast), so I might be able to help (and be more of a help) porting a few classes.

On the topic of formus (raised a few pages back), I suggest using these ones, this is where everyone is.  Post in Game Physics prefix it with [JOODE] or something.

Will.

Offline Amos Wenger

Senior Member




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


« Reply #185 - Posted 2005-11-19 09:56:18 »

It's great to see this project taking off.  I am sorry to have not been of much help, I have been rather busy with my new job.  On the plus side I have had to learn C++ (fast), so I might be able to help (and be more of a help) porting a few classes.

On the topic of formus (raised a few pages back), I suggest using these ones, this is where everyone is.  Post in Game Physics prefix it with [JOODE] or something.

Will.
I think it would be better to make childboards in the "Game Physics" section :
 - General Physics
 - ODEJava
 - JOODE

"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 t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #186 - Posted 2005-11-21 17:48:23 »

Quote
I traced now loads of errors in BoxBox collisions, but it still doesn't work, because now I get some ArrayOutOfBoundsException, from a part of the code I haven't touched and I don't know how my changes could cause this problem (I propbaly don't know enough). I hope you can help me out there.


Yeah. I have supsected those family of math methods are faulty.  dMultiply2 & dMultiply0 & dMultiply1. I think that is what is stopping the step_island_x2 from working as well. I realised one problem with them a while ago, and its a general thing to look out for when using the RealPointer class:-
When pointers are passed in C, they can be incremented and stuff like
foo (Real * A){
  A++
}

The effect of incremeneting them does not show itself out of method scope, however in the way I have implemented them in joode as a class, incrementing them and suchlike will be seen outside the method, so ANY METHODS THAT ALTER THE INDEX OF A RealPointer should clone the RealPointer first. It will still work on the same underlying data but the index will be a fresh copy so it will work more like it does in C. I corrected this once for these methods, but I realise I did not go far enough. So I have fixed what I think will be a problem and maybe it will work for you now arne. I could not find a test case for the BoxBox system so I could not check it.

Hope it did work

Tom

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 #187 - Posted 2005-11-22 20:27:58 »

I was thinking it might be a good idea to gradually replace the calls to the obscure math functions in ODE and use stuff based on vecmath instaed.  Looking back again on the methods I implemented for the Mass class, they seem to calculate things the obscure way.  The equations for intertia would be much more readable if using Matrix4f. 

That said, I know it would not be easy changing some of ODE's fundimental data types.  What does everyone else think?
Offline arne

Senior Member




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


« Reply #188 - Posted 2005-11-22 21:49:20 »

to code functions the clearer way is always good. But we'll probably not be able to code all functions like this, but I think a mixing of obscure code and clear code is still better than only obscure code.

+ If you code such functions put them into a location, where it makes sense for them to be (e.g. Matrix4 in your case), then MathUtils is the class for obscure math.  Wink

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

Senior Member




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


« Reply #189 - Posted 2005-11-22 21:54:10 »

Quote
I traced now loads of errors in BoxBox collisions, but it still doesn't work, because now I get some ArrayOutOfBoundsException, from a part of the code I haven't touched and I don't know how my changes could cause this problem (I propbaly don't know enough). I hope you can help me out there.


Yeah. I have supsected those family of math methods are faulty.  dMultiply2 & dMultiply0 & dMultiply1. I think that is what is stopping the step_island_x2 from working as well. I realised one problem with them a while ago, and its a general thing to look out for when using the RealPointer class:-
When pointers are passed in C, they can be incremented and stuff like
foo (Real * A){
  A++
}

The effect of incremeneting them does not show itself out of method scope, however in the way I have implemented them in joode as a class, incrementing them and suchlike will be seen outside the method, so ANY METHODS THAT ALTER THE INDEX OF A RealPointer should clone the RealPointer first. It will still work on the same underlying data but the index will be a fresh copy so it will work more like it does in C. I corrected this once for these methods, but I realise I did not go far enough. So I have fixed what I think will be a problem and maybe it will work for you now arne. I could not find a test case for the BoxBox system so I could not check it.

Hope it did work

Tom

It doesn't work still. I've modified SphereCollsionTest to do BoxBox Collisions, so this should be the test-case. (Sorry, but I accidently commited it, but if you want the old example back, you'll only have to flip one comment)

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #190 - Posted 2005-11-23 16:09:31 »

Yeah. I would love it if the math stuff was replaced with readable stuff. It is not an easy task though.

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #191 - Posted 2005-11-23 20:59:11 »

Quote
It doesn't work still. I've modified SphereCollsionTest to do BoxBox Collisions, so this should be the test-case. (Sorry, but I accidently commited it, but if you want the old example back, you'll only have to flip one comment)

Hmmmm. I have had a go at it. It still does not work but it seems a bug has been fixed in Multiply2. step_island_x2 partially runs now. It still does nto work but its not crashing now. It seems the A matrix in the step is not setup properly in the BoxBox collisions situation. Its weird that the other collision scenarios work though.

Hmmm.....  Huh

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

Junior Member





« Reply #192 - Posted 2005-11-24 06:04:17 »

Wow I'm impressed this has taken off. Thumbs up guys, hope it goes well!

Vault101 / Mace The Game
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #193 - Posted 2005-11-25 00:35:40 »

I have had another hack at it arne. I find the behaviour that screws up the LCP algorithm is that the boxes seem to hit each other then force themselves closer rather than further away. I tried swaping the direction of the contact normals in the BoxBox Collisions and that seems to make the system semi work. Now the boxes fly away from each other when they hit each other, but at a grossly exagerated spped. This suggests the the penetration depth has been calculated far too high.

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

JGO Ninja


Medals: 38



« Reply #194 - Posted 2005-11-25 00:48:59 »

Maybe the the contact normals were right in the first place but the penetration depth was calculated with the wrong sign for some reason!?

Mathias - I Know What [you] Did Last Summer!
Offline arne

Senior Member




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


« Reply #195 - Posted 2005-11-25 08:39:22 »

good - at least we've found the problem now Smiley

mmh - maybe we should try to create the Boxes on a greater Area? I believe the simulation starts with them intersecting each other - so this might not be very good.

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

Senior Member




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


« Reply #196 - Posted 2005-11-25 16:43:23 »

mmh one thing that came across my mind with that problem - isn't there really a better method for that? Understanding the stuff you code is the best wa to prevent errors. - I'll google for a better method or at least to give me a better idea of what they are doing there.

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

Senior Member




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


« Reply #197 - Posted 2005-12-21 12:05:28 »

Some news ?
Maybe we would have done better to start another physic engine and take ODE as a reference rather than as a basis. Because what I've seen is we take more time to understand how this crappy code works than adding features or fixing bugs (that aren't due to the port).
What's your opinion ?
You may take a look at the "Physic resources" post I've just created and add your favorites docs about physic simulation, so we have a good knowledge basis.

"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 #198 - Posted 2005-12-21 17:40:51 »

Yeah you might be right, It seems as if we've got stuck at the moment Sad

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #199 - Posted 2005-12-22 15:45:58 »

Haha. I am happy with JOODE at the moment. Yes implementaion has ground to a halt at the moment, but I am really busy at uni at the moment. I hope to get some work crammed in Jan before the next round of work comes in.
I have basically been trying to get arbitary collisions working so that all our woes with BoxBox collisions can be skipped. The work is quite tricky to get working properly though so nothing has come of it as yet. In  Jan I shall first do some of the small jobs like joints and things just to make everyone feel comfortable that stuff is being done and then I shall go back to my arbitary collision nightmares.
I want to use the JAMA library. One of the outstanding problems in JOODE is the Cholsky decompositions don't work. The offer an alternative to the LCP algoirthm for actually performing the physics math. I think they are a much simpler way of doing things and would be great for testing. Slow though. Anyway the JAMA library does Cholsky stuff .... and eigenvectors which could come in handy much later on (for OBB trees). The whole package might even be usable for replacing our matrix math with something readable. Though I really suspect we may never have readable math for JOODE  Huh

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

Senior Member




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


« Reply #200 - Posted 2005-12-22 17:09:42 »

Okay, but you may agree it's better if others can actually understand what you're doing and help you, isn't it ? I hope you don't want to be the one and only developer..
So which ways are you going about arbitrary detection collision ?
I never heard about Cholesky decomposition, how useful is it ?

"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 t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #201 - Posted 2005-12-22 20:02:23 »

Yeah agreed. I do not want to be the sole developer.

I do not know exactly what a Cholsky decomposition and factorization is. From what I know the decomposition is a reograganization of matrices into a form that lends them to be solved with a Cholsky factorization. Its a 2 step process basically and the end result is that a set of simulataneous equations is solved.

When you look at MathWorld and things, Cholsky stuff is always said to be useful in engineering applications. They are used in ODE to to the stepping in the world. I think perhaps though that they might blow up to be a NP hard problem or something, becuase by defualt in ODE the LCP algorithm is used instead to do the stepping. The LCP algorithm does not allways succeed, you sometimes get the s < 0.0 error when it fails. This does not necissarily mean the system is broke, just the LCP algorithm can't solve that particular situation. Thus I would like the Cholsky stuff to be working becuase I think it might be more relaiable.

By the way the code reads in ODE I think the cholsky way was the first way that ODE was coded. So it doesn't seem to take enough parameters to implement all the features the LCP algorithm does, like all the joint feeback and things. 

As for arbitary collision detection .... well the OBB tree stuff does not provide enough information for the collision system to work. It just provides a boolean collision or no collision answer. So the first thing to try and do is to develop a system that can return the collision point, collision normal and penetration depth.

So I tried reading up on these things, but the latest algorithms are pretty tough to decipher. I found a nice middle ground though I thought I would try to implement that seemed reasonably effecient. It works for convex-convex geometries.

Basically one of the key concepts in all collision algorithms these days is the Gauss representaion of a convex polyhedra. To build this representation you take the face normals (vectors) and project them onto a sphere. So a face in normal space is an area, but this is represented in the Gauss representation as a point on the surface of a unit sphere. Faces in normal space are bordered with other faces by an edge. So you represent this in the gauss representation by joining the points on the unit shpere with edges. Verteces in normal space are points, but in the gauss representaion the become areas on the unit shpere. What ends up happening, is the gauss representation represents orthoganal planes that can touch the features. (it hard to explain :-( )  Think about a face in normal space. Only one plane or a certain conjugate gradient can be put against it. So on the uni sphere guass representaion the tangetical plane to the vertex representing that face is that same plane. Vertexes in normal space can have a range of planes touching them, and that range is defined by the area they take up on the unit sphere in guass space.
So these planes are really important for collision detection. If two obects are near each other, it is only features that are on opposite sides of the objects need to be compared. You do not  need to compare the right side of the box A with the top part of box B. The seperating distance (or penetration distance) is defined by two planes that touch anti-podal (opposite) features. The planes are the links to the guass representaion.
So to compare opposite feates you take the guass representaion of the two objects, giving you two unit spheres. You cut each sphere into halves. You then need to compare the one half of one object with the other half of the other object (twice for each combination of halves).
In order to compare the halves what you can do is project the details of the semisphere onto a plane. i.e. squash the semisphere flat. This gives you a load of lines drawn on a plane. This is known as a planar subdivision. You need to compare two planar subdivisions. So you overlay one subdivision with another and find all the intersections of details. This is a red green algorithm. An edge may cross with another edge at a point. This point represents a plane. So you need to lookup those two edges on each object in real space and work out how far away they are from each other using the plane as the seperating plane. Evertime a vertex is seen in each planar subdivision you need to lookup what area it lies in on the other plane subdivision. This gives you a vertex and a face to measure the seperation distance in real space using the face normal as the seperating distance. You also need to consider face-face distances (which are vertex-vertex situations on the planar subdivisions).

Anyways. The guass map stuff is pretty easy to implement becuase it basically just involves taking the face normals and joining them up. I have not implemented this yet. The hard bit is the planar subdivision comparisons. A naive approach would take n^2 to run. I decided to use a planar sweep algorithm to do it faster. This involves sweeping a line from left to right over the planar subdivisions. You keep all the details ordered by x and .... it ends up midly faster. I say midly beucase I think worse case it is still n^2. There are heaps of degenerate cases to consider though which have swamped me. Vertical liines are awkward. Working out which area of a division a vertex is in is hard. Really hard for the first vertex encountered becuase no information is present from the other panar division at that point. To help with that kind of degeneracies I had to extend the planar subdivision concept. If you think about what a planar subdivision looks like for a semisphere it ends up as a load of lines within a unit circle. Now what happens to edges that spanned the two hemisheres when you cut it? Really you need some detail to be found right on the edge of the unit circle. So to make sure that all details on the very edge of the cirlce are considered special (including the left most edges) I actually made extra edges start at the edge of the circle and extend to +/- infinity for each coord (cutting the circle into quadrants). This meant all the left hand details would be considered by the sweep algorithm first for both planar subdivisions. As these were considered first I could then extract region information. (Erm, I know this is really hard to follow, I dunno how to say it better.)    Basically it meant that when the sweepline hit the first real vertex I allready had the information about at least two infinite edges from the other planar subdivision available. Its jsut a mannor of working out what face they have in common then to be able to assign a vertex, region. The real point is that this sweep algorithm seemed like a peice of cake to implement but turned out to be really difficult. Its not even that good at performing its job. So I might switch to the naive red green algorithm jsut to get something working reliably. i.e. compare every edge to every other ...

The real hardcore algorithms don't compute the gauss representaions and planar subdivisions upfront. You provide them with an estimate of which plane is likely to be the seperator (the one directly between their centers for example). From this point they measure the distance and lazily and greedy expand the representaions until the find no imrovement on their distance measure. The perform a walk along the features of the two objects (still only comparing opposite features). By giving good estimates you can reduce the time complexity to constant time Shocked. Cachine the results of collisions between time frames is also a very good stratergy. I think it is even optimal still!

So I think I might chuch the sweep algorithm and go for naive algorithm. Then maybe greedy search as am getting into my search algorithms of late. (Orbital library?)

I have not bothered submitting my collision work so far becuase it does not do anything yet. I could do with some advice on a good way of stitching together edge, vertex and face onformation into a datastructure. Everything really needs to be ordered ....

Tom

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #202 - Posted 2005-12-22 20:28:06 »

To continue....

So the current state of JOODE is pretty good. The Sphere demo looks realistic so we have one route of physics working. The fact that box box collisions don't work I don't think is a major problem and should be worried about too much. If we get a good convex convex algorithm working we can forget about box-box special case and run it faster by caching results.

The joint infrastructure is working by the fact Contacts work, they are implemented as joints. Joints themselves are really simple, just entries in a jacobian matrix so porting them is a no brainer but I think doing that next is the best idea becuase they really add value to the package.

The space infrastructure is working, we have simple space. So porting the other types would be a good idea, though it does not add as much value as joints until someone want to do real performance with them.

Testing objects can be destoyed cleanly has not been tested. That needs doing.but fingers crossed it might work  Undecided


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

Senior Member




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


« Reply #203 - Posted 2005-12-23 11:11:33 »

Okay, after having read 10 times what you said, here's some things I believe I've understand, please correct me if I'm wrong :
  - Cholesky decomposition/factorization is just *another* way to solve differential equations needed in kinematics
  - Gauss representation is just a sort of optimizations that avoid to test polygons that aren't opposed
  - Creating a Gauss map is just moving the face's normals to a unit sphere

One thing I didn't understand is : your face is represented only by its normal on the unit sphere, but where are the edges ? You say you just have to "join the points on the unit shpere with edges", but you only would be joining polygons center, heh ?

After that trick I just can't understand the continuation. Where do all these planes come from ? Do you divide your unit sphere in halves or in quarters ?

I would be really glad if I somebody could explain me in a way I can understand, maybe with figures. Thanks.

(Note : I'm not completely lazy, and have googled "Gauss map", but these big equations don't explain anything..  Undecided )

"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 t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #204 - Posted 2005-12-23 13:01:14 »

Quote
(Note : I'm not completely lazy, and have googled "Gauss map", but these big equations don't explain anything..   )
Yeah I know what you mean. Its taken me ages to understand it to this point

Quote
Cholesky decomposition/factorization is just *another* way to solve differential equations needed in kinematics
Yes

Quote
Gauss representation is just a sort of optimizations that avoid to test polygons that aren't opposed
Yes pretty much. Gauss representaions summerize tangital plane information.

Quote
your face is represented only by its normal on the unit sphere, but where are the edges ? You say you just have to "join the points on the unit shpere with edges", but you only would be joining polygons center, heh ?
Yes yes yes! This is the key. Once you get your head round this you enter the matrix....

So imagine you have a convex object infront of you and you need to measure its shortest width. To measure a width, you create two parrallel planes that just graze the object, and measure the distance between them. Now if your object has parrallel faces, like a box, then you can see that to measure the width the parralell planes will be orthoganal to the face normals. i.e. there is only one sensical grazing plane for a face. Now think about edges. Edges are found between two faces. There is a range of sensical "just touching" planes for that type of feature. The exact range is defined by the interpolation of the two face normals. With a vertex, which borders n faces, there is a region of "just touching" planes that are applicable. 
So this is what the gauss representaion summerizes. Face -> points on the surface. Edges ->edges joining up the points (that represent faces), this means edges kind of go in the opposite direction to how you see them in object space (kinda) Vertics -> Regions. 

So if you wanted to find the smallest width of an object you would first create the gauss representaion. Then you would compare opposite features of the gauss sphere.
1. Where there was a point (representing a face) you need to find what region (representing a vertex) it is lies within on the opposite side.
2. To quantify the actual distance between the vertex and face you would need to go back to the original representation. Then you would use the plane orthogonal to that face, and measure the distance to the vertex on the opposite side. That will be the shortest distance possible between those two features.
3n. Repeat for all opposite features (including edge-edge distances, the seperating planes to use are their intersections) until you can say which is the smallest distance.

Finding the width is very strongly related to penetration depth. To find penetration depth between two objects you have to compare features on one guass sphere with features on the opposite side of the other gauss sphere. That is why we chop them into halves. So you can compare one hemisphere with the other himisphere on the opposite side.

The planar subdivision algorithms are the details by which we compare the two gauss representations. see http://www.lupinho.de/gishur/html/Sweeps.html

I do actually have some lush diagrams.... let me go find them...

yes ... the link was on the previous page of this thread ( who says they were not lazy?  Tongue>
(only kidding, it was cryptically advertised)
http://homepages.inf.ed.ac.uk/s0570397/planar.sxi
(oh damn, its an open office doc. Can you read that?)

EDIT: Tada! Dia to the rescue for windows, file size 25kb! (though try to look at the open O presentation, its got proper 3D rendered pictures!)





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 #205 - Posted 2005-12-23 23:37:21 »

Thank you for posting all this valuable information (we actually should save that somewhere in the project, so it doesn't get lost)

I think I've understood most of the stuff, but I'll also look at the links you posted, but not today anymore I think.

When I've some time (probably after christmas) I'm going to try to work on the simpler things (spaces, joints).

Cheers
Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #206 - Posted 2005-12-24 02:36:20 »

Looks like this effort is really going well!  Sorry I havn't been of any help, work has taken pretty much all my time.

Is the intention still to combine JOODE with Odejava - i.e. replace the JNI bindings with the new ones (or more to the point, are the people interested in JOODE interested in using JOODE with Odejava when it's ready?)  I am quite interested in doing this, as the Odejava OO design has suited my projects, and I use the XODE parser extensivly.  I am pretty certain I will be able to dedicate some time when the time comes to adapting Odejava to use JOODE, hopefully that can be my contribution. 

Will.

Offline Amos Wenger

Senior Member




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


« Reply #207 - Posted 2005-12-24 14:05:29 »

Okay cool.
(Hey, thomas, don't you think I'm using Windows, heh.. you may not have looked to my avatar..)
So with the Gaussian representation it's easy to compute an OBB around any convex polyhedra ?
What I didn't understood is the plane story.. What are they used for ? How does it help to compute penetration distance ? Or to detect collisions ? Or are they used only to compute distance between the two polyhedras ?
Is this used when you know that there's a collision and you want to determine penetration depth, or is it used if there's actually a collision ?
The planar subdivision algorithm with all these lines is somewhat obscure too.. I'll read one more time your explanations and try to understand that too.

"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 t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #208 - Posted 2005-12-27 16:32:04 »

hehe. Glad I am being as clear as mud ;-)

So the important thing when calculating penetration distances is that you only need to consider antipodal features (opposite). So the gauss representation summerizes the direction that is important to each feature.

The planar subdivision stuff comes in as the nitty gritty of actually working out which features are opposite at a reasonable speed. You need to consider one half of a sphere against the opposite half on the other (opposite features). To work with the gauss representations it helps to flatten them. So each hemisphere becomes a planar subdivision. The features on the semisphere of the guass representation become lines and vertices on a planar subdivision. No you just need to work out which features on one planar subdivision intact with the features on the other planar subdivision. Doing this quickly is not trivial. The naive approach is jsut go through every item on the planar subdivision and compare it to the other. Quite slow :-(. So there are all these algorithms for doing it quicker. have a look at the applet I posted for an overview of the sweep algorithm.

So all this fiddling around does is tell you which featers on the objects are opposite to save you computations for the penetration distances. It does not tell you the distances between the objects. From the above stuff you get a list of features that then need to have the distance calculated using the original real space representations. For a distance measure you have to decide what you parralell seperating planes to measure distance orthoganal to. This can be extracted from the gauss representation.

Quote
So with the Gaussian representation it's easy to compute an OBB around any convex polyhedra ?
The guass representation will not help with OBB calculations becuase it does not contain any kind of distance measures. A really big box will have the same gauss representation as a really small box (that is alligned exactly)

The OBB stuff in general only helps you to find out if a collision occured very quickly but in JOODE you also need to know the details of the collision. Where it happened, the collision normal and the penetration depth. All the stuff I have described so far is part of the story in calculating these quantities QUICKLY.

Have a look at the paper I put up in my collision resources. It is the main paper I have been working from. It starts by going on about minisky sums.

(right I am on holiday at the moment so I can't really talk too much .. I am in an intenet cafe but I will be working on JOODE again very soon)

Tommo


 

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

Senior Member




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


« Reply #209 - Posted 2005-12-27 17:50:06 »

Oh okay. I think I've understood everything now. My mistake was to consider Gauss representation as "the solution to all our problems" !
About OBB : If I'm right, yes you can compute an OBB around an object, because :
 - Gauss and all that stuff give you opposite features
 - Then you just have to compute the distance between all these features
 - And then you just have to do some magic that gives you the smallest OBB possible.
(I guess it's pretty slow and there are better algorithms around there to do that)

And about OBB trees I think it's really possible to use it in JOODE, why not ? If the algorithm you had just give you if there's a collision or not, then you can test the two geoms and actually find the collision point, the depth, and the normal, heh ? You just need to adjust the algorithm a little bit.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: 1 ... 5 6 [7] 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 (17 views)
2014-07-24 01:59:36

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

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

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

ctomni231 (45 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 (51 views)
2014-07-16 00:42:17

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

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

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

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

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

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

Escape Analysis
by Roquen
2014-04-29 22:16:43

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