0 registered members (),
1,209
guests, and 0
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Additional primitive collision shapes for c_move/c_trace
[Re: Damocles_]
#362697
03/09/11 12:25
03/09/11 12:25
|
Joined: May 2002
Posts: 7,441
ventilator
Senior Expert
|
Senior Expert
Joined: May 2002
Posts: 7,441
|
is it really necessary to show the physx logo if you use physx? i didn't know that... jcl, you wouldn't have to implement it yourself from scratch. at the moment the ellipsoid system uses the open source OPCODE library as far as i know? that's outdated... the new state of the art open source collision libraries are newton and bullet. you could use one of them instead. their convex hull systems are even better than what physx has to offer. they both use the very liberal zlib license now and their collision systems can be used independently from their physics systems. (but if you are at it you could implement their physics aswell since it makes a lot of sense if only one collision system gets used for everything.)
|
|
|
Re: Additional primitive collision shapes for c_move/c_trace
[Re: ventilator]
#362723
03/09/11 14:12
03/09/11 14:12
|
Joined: Sep 2003
Posts: 6,861 Kiel (Germany)
Superku
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
|
If you look at the platformer games, they work better with a flat collision Hull on the floor. So the units dont fall off the cliff unexpectitly, but exactly when the Cliff-Hull and Entity-Hull dont match anymore. With elipsoid Hulls, the entity probably slide down when getting close to the edge. I've tried to describe that problem in the AABB-thread: "The first screen uses a faked box-trace that achieves the desired effect/ movement, the second horizontal line demonstrates the problem with OBB-USE_BOX-(gravity) trace: (Ignore the bright blue box, the dark blue box is the bounding box.)" A box-trace would help here.
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual Check out my new game: Pogostuck: Rage With Your Friends
|
|
|
Re: Additional primitive collision shapes for c_move/c_trace
[Re: Superku]
#362769
03/09/11 16:16
03/09/11 16:16
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
OP
Expert
|
OP
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
Every new collision shape requires a lengthy implementation and test. Thus we can't implement an arbitrary number of collision shapes, but only one, if at all. That's interesting. I would've thought you'd use the Gilbert-Johnson-Keerthi algorithm for collision detection, in which case supporting a new type of convex hull that's compatible with all other collision shapes would simply be a matter of writing a new support function for that type of hull. As others have said, I think a cylindrical hull (as well as support by c_trace with USE_BOX) would by the most advantageous addition for us programmers if you can really only do one. Jibb
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Re: Additional primitive collision shapes for c_move/c_trace
[Re: jcl]
#362834
03/09/11 19:10
03/09/11 19:10
|
Joined: Dec 2008
Posts: 1,660 North America
Redeemer
Serious User
|
Serious User
Joined: Dec 2008
Posts: 1,660
North America
|
A flat bottom hull trace is often required, not only for platformers. A flat hull is just a special case of an ellipsoid. You can easily make the hull a flat disk by setting min_z and max_z tight together. Yes, but then the collision hull has no vertical depth (and still isn't perfectly flat on the bottom). We need the collision hull to have a flat bottom/top and perfectly vertical sides that match the vertical size of the model.
|
|
|
Re: Additional primitive collision shapes for c_move/c_trace
[Re: jcl]
#362945
03/10/11 10:58
03/10/11 10:58
|
Joined: Oct 2007
Posts: 5,210 İstanbul, Turkey
Quad
Senior Expert
|
Senior Expert
Joined: Oct 2007
Posts: 5,210
İstanbul, Turkey
|
i thought all problems would go away when c_trace/c_move stuff started using physx for collision dedection?
3333333333
|
|
|
|