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

Senior Member




Go Go Gadget Arms


« Reply #210 - Posted 2005-12-27 18:12:42 »

Quote
And then you just have to do some magic that gives you the smallest OBB possible.

If  you can do that in real-time with competitive fps, i'l give you all my money.  Smiley

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Amos Wenger

Senior Member




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


« Reply #211 - Posted 2005-12-27 21:15:42 »

Oh..
By "with competitive FPS", you mean, a Quake 3 level running with 60+ characters at 100 FPS ?  Grin
If I had time to lose, I would have tried that, since I'm sure there's a mean to do that. (That mean would probably be to buy a quadri-core workstation with two ATi X800 in parallel, but.. if I succed with that I'll be refunded, heh ?)

"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 #212 - Posted 2006-01-03 20:44:35 »

Quote
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.

Oh yeah. The OBB algorithm is just the first step to determine quickly whether there was a collision or not. Then you have to run another algorithm to get the proper information. The OBB algorithm does provide with some helpful information though. It does give a worthwhile guess to where the proper collision might be, which can be used in a feature walking algorithm as the initial conditions.


Right! Lets implements some joints..........

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
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 #213 - Posted 2006-01-03 23:41:29 »

.... Hmmmmm.  Joints are not going so well......
I have implemented Ball and Hinge joints but neither works. Both seemed very straight forward to port, so I doubt I made two catastopic errors. This makes me think something is broken deeper down .... curses!

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 #214 - Posted 2006-01-04 20:16:55 »

OK. Well to give me something to try the joints out on I am gonna intergrate JAMA with the project so we can use their cholesky code as the alternative intergrator

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 #215 - Posted 2006-01-05 02:09:42 »

see seperate threads for updates....

but I am leaving for a few days now. Back to coding Sat.

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 #216 - Posted 2006-01-29 01:00:54 »

OK I think Joints are essentially working now. I think all fundamental areas of JOODE are working. We just need to fill out the project with more functionality lifted from ODE.

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 #217 - Posted 2006-01-29 16:37:03 »

OK I think Joints are essentially working now. I think all fundamental areas of JOODE are working. We just need to fill out the project with more functionality lifted from ODE.
Nice Smiley

I start to have more time now (holidays Cheesy ), so I think I'm going to take the OctSpace on again. We also should focus on implementing Geoms and Collisions  - do we have there already a good way of dealing with that? I am still thinking on a more general way of dealing with that then implementing all combinations of collision-scenaries.
Box-Box Collisions still don't work, right?

And also Ask_Hjorth_Larsen seemed to be interesting in doing some stuff (he wanted to do some math again)

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #218 - Posted 2006-01-29 20:26:19 »

Oh cool Arne. Yeah getting OctSpace would be great, maybe you should try porting QuadSpace first though as it is a similar problem and at least you have reference code for that. But its entirely up to you.

Quote
I am still thinking on a more general way of dealing with that then implementing all combinations of collision-scenaries.

I agree. Getting convex polyhedra colliding would be the best way. I have decided the route I was persuing last time is not the best way. I have a new idea. I do not have time at the moment though now. I was lucky to have a few hours spare last night. I might have another few again tonight but I have to do an assignment first .. damn uni, it doesn't half get in the way of learning.


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 #219 - Posted 2006-01-29 23:17:01 »

I just remembered the simplex algorithm and I think it could also be used for collision detection - maybe for the trimesh stuff. I believe it could help for the convex polyhedra colliding.

And yes I think I will look into the code of the Quad-Space - but I don't think it's implemented as I want to implement my octtree space, but lets see Smiley

:: 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 #220 - Posted 2006-01-30 00:29:37 »

Here is the webpage from the collision paper I was trying to replicate:-
It features a presentation almost identical to my own! Haha.
http://www.cs.unc.edu/~geom/DEEP/
I have realized a better what though to solve the problem. Um, Instead of projecting the guass representations onto a planar subdivision, represent the guass map as a 3D sphere cut by planes. Use these planes as the deliminators of a BSP tree and assign the guass representation's features within the BSP tree, this can all be done upfront once. Then, when it comes to comparing the two representations you can use the BSP to quickly lookup opposite features by spacial positions. The main bulk of the algorithm remains the same (i.e. walk along the features until you can't get an improvement in your penetration depth) but it cuts out the planar subdivision part which has degeneracies associated (and its also quite hard to implement a fast planar subdivision algorithm as I have found out).   

Thats what I was thinking currently. I have not got time to do it 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 darkprophet

Senior Member




Go Go Gadget Arms


« Reply #221 - Posted 2006-01-30 00:43:36 »

Quote
I just remembered the simplex algorithm and I think it could also be used for collision detection - maybe f....

Im interested, how can the simplex algorithm work for collision detection? Its meant to find the optimum solution to a problem given a set of constraints. If you imagine two lines in a graph, it finds the intersection point, put 3 lines, it will find the point that is the highest, similarly with 4...etc...

Unless theres something im missing ?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #222 - Posted 2006-01-30 15:12:41 »

Have a look at the abstract of this:-
Quote

It kind of estimates the collision point by refining an bounding polyhedra between the objects or something. I have not looked into it all that much becuase I feel all those algorithms are
1) hard to understand (but thats global to all these algorithms Smiley)
2) inprecise
3) can go into infinite loops
4) not that fast ... compared to the latest methods

But if Arne thinks he could implement one of them then cool. It would immediatly be the defact method for JOODE.



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 #223 - Posted 2006-01-30 18:45:43 »

Here is the webpage from the collision paper I was trying to replicate:-
It features a presentation almost identical to my own! Haha.
http://www.cs.unc.edu/~geom/DEEP/
I have realized a better what though to solve the problem. Um, Instead of projecting the guass representations onto a planar subdivision, represent the guass map as a 3D sphere cut by planes. Use these planes as the deliminators of a BSP tree and assign the guass representation's features within the BSP tree, this can all be done upfront once. Then, when it comes to comparing the two representations you can use the BSP to quickly lookup opposite features by spacial positions. The main bulk of the algorithm remains the same (i.e. walk along the features until you can't get an improvement in your penetration depth) but it cuts out the planar subdivision part which has degeneracies associated (and its also quite hard to implement a fast planar subdivision algorithm as I have found out).   

Thats what I was thinking currently. I have not got time to do it though :-(


The article seems to be very promising Smiley They very mentioning a constant complexity, I actually can't think how this should work ... hmm they were mentioning s.th. about a good heuristic for a starting point - hmm if they use the point, that was the deepest last step, it really can work pretty fast.
it seems they are also able to calculate the penetration direction - nice Smiley

My idea with the simplex algorithm was to use it to find the closest point (better: plane going through that point) to the other object (or an optimum if you want it that way Wink ) and then do the same with the other object. And then calculate the distance between the two planes - and voila you would get some kind of penetration distance.
But I've realized, that there are situations, where it would return a penetration distance, where the objects don't even intersect!
So it's probably not so wise to use this approach  Undecided

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #224 - Posted 2006-01-31 14:37:01 »

Yeah the DEEP algorithm is super fly. Its starts with a guess and then tries to improve upon it until it cannot. Really it will only get stuck on a local minimum if the guess is on the wrong side of the polyhedras. So taking the average of their center points or something will yeild pretty good results if the objects have never met, otherwise caching the last calculated penetration direction will also yeaild really good results. Even for stuff like Box Box collisions the algorithm could save on the number of tests. Whether that will translate to faster box box collisions all depends on the algorithms overhead, I suspect it probably won't but not by much.
For the advanced reader I suggest imagining what happens if you only partially represent the gauss representation. This will mean objects will only have a penetration depth for a certain orientation ... This essentailly means you could represent things like planes or terrain using the same system.
the only problem I have with the algiorithm, and what nailed me last time when I tried to implement it was the planar subdivision bit. Projecting the gauss representation onto a plane. There are lots of special cases you need to deal with. Also note that a curved surface does not map onto straight lines when projected (which could cause errors). I have a solution though that I think simplifies the algorithm somewhat. Instead of projection you can deal with the gauss representations directly. Cut the gauss representation (recall a unit sphere with edges on its surface) into spacial divisions using a BSP tree. This will allow fast lookup for features. Then to do the comparison between gauss representations you can take a feature from object A, translate its coords representing the relative orientation between the 2 objects + 180 degrees, then pass it into the BSP tree for B. As it decends the tree you can be testing it with the important features it encounters, most of the BSP functionality will be replicated from the contruction code. So from that you will have a set of features that interest that feature on the opposite side. I really can't see any real computational penalty from doing it this way, and I think it will be more accurate and without special cases to consider.  Anyway this is yet again a rable by me. Although I said I could not afford any time at the moment the gravitaion pull of JOODe has sucked me in again so I am writing the BSP code at the moment :-(

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Pages: 1 ... 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.

CogWheelz (17 views)
2014-07-30 21:08:39

Riven (23 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

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

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

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

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

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
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!