next »

[horati]

Maybe I don't understand the design of the collision/1p movement/avatar APIs, but wouldn't it be easier to connect all this together if FirstPersonInputHandler.MovementListener extended java.beans.VetoableChangeListener?  That way, the listeners could tell the FPIH that it wasn't allowed to go somewhere based on factors it doesn't know or care about.

Maybe I'm missing something because this might be a case where I'm thinking of an ivory tower design that won't perform well.  What do you think?

[Marvin Fröhlich]

Maybe I don't understand the design of the collision/1p movement/avatar APIs, but wouldn't it be easier to connect all this together if FirstPersonInputHandler.MovementListener extended java.beans.VetoableChangeListener?  That way, the listeners could tell the FPIH that it wasn't allowed to go somewhere based on factors it doesn't know or care about.

Maybe I'm missing something because this might be a case where I'm thinking of an ivory tower design that won't perform well.  What do you think?

Yes, the FirstPersonInputHandler should definitely provide a way to be connected to the collision system. When the new (JOODE) collision abstraction is realy, I will do that.

OK?

Marvin

['n ddrylliog]

In my vision of things, here is how a correct movement in BSPLoaderTest would perform

(XAPL refers to the Xith3D Abstract Physics Layer)

--- INIT ---
- Load the BSP level
- Create a new XAPL CollideableGroup
- Create a XAPL TriMesh for the BSP Level
- Create a XAPL Capsule for the Player
- Add a FPIH to.. what ? (I don't know FPIH internals, will take a look at it..)

--- LOOP ---
- Update FPIH (done via RenderLoop)
- Resolve collisions (done via XAPL SimulationEnvironment)

-------------------

So the changes are not *cancelled*, but *corrected*. Following the "cancelling" scheme, you cannot slide, you cannot glide, you cannot roll, and so on..

But I have 3 tons of ideas about Physic and two weeks of holidays to implement that.. So just wait and see

[Marvin Fröhlich]

In my vision of things, here is how a correct movement in BSPLoaderTest would perform

(XAPL refers to the Xith3D Abstract Physics Layer)

--- INIT ---
- Load the BSP level
- Create a new XAPL CollideableGroup
- Create a XAPL TriMesh for the BSP Level
- Create a XAPL Capsule for the Player
- Add a FPIH to.. what ? (I don't know FPIH internals, will take a look at it..)

--- LOOP ---
- Update FPIH (done via RenderLoop)
- Resolve collisions (done via XAPL SimulationEnvironment)

-------------------

So the changes are not *cancelled*, but *corrected*. Following the "cancelling" scheme, you cannot slide, you cannot glide, you cannot roll, and so on..

But I have 3 tons of ideas about Physic and two weeks of holidays to implement that.. So just wait and see

Sounds really cool. But I think, the FPIH should provide a createPhysics() method or so to create all necessary physics internally (like the capsule). And there should be a getCollideableGroup() method, where all things should be placed in, that the Avatar needs to be tested for collision with).

Marvin

['n ddrylliog]

I disagree.
The beautiful thing with that architecture is that the FPIH and the Physic system just don't have anything to do with each other. They just use common data structures, that is : Placeable (actually it's an interface, but it works just the same). Use a MemberLink between the FPIH and a Capsule and it'll work !!
And I don't think the Capsule nor the CollideableGroup should be handled in the FPIH. Remember the FPIH independant from physics. And you could also add other objects to that Group and you could want to specify the type of that group (Simple, Hash, OctTree), so I think it's definitely not a job for the FPIH.

[Marvin Fröhlich]

I disagree.
The beautiful thing with that architecture is that the FPIH and the Physic system just don't have anything to do with each other. They just use common data structures, that is : Placeable (actually it's an interface, but it works just the same). Use a MemberLink between the FPIH and a Capsule and it'll work !!
And I don't think the Capsule nor the CollideableGroup should be handled in the FPIH. Remember the FPIH independant from physics. And you could also add other objects to that Group and you could want to specify the type of that group (Simple, Hash, OctTree), so I think it's definitely not a job for the FPIH.

Agreed.

[horati]

Why would my suggestion prevent sideways movement, rolling, etc.?  I can see how the character might stop moving altogether if they were moving diagonally and bumped into a wall instead of moving forward which is what one would expect.

So change the interface so that it can throw VetoException as well as CorrectionException where CorrectionException carries along the corrected location.  Then the FPIH could updated all callers back to the start location and attempt to get to the newly corrected location.  There are some ways to add details to the interface to optimize performance a little bit, but all these suggestions are essentially the Observer Pattern which seems ideally suited to anonymous interaction between 1 input source and multiple, simultaneous, pluggable physics/collision systems.

Regarding my ivory tower statement... I am assumping the operations are only a few dozen times per second which makes this approach viable.  Obviously, this much overhead could not be tolerated in a section of code related to individual polygon calculation or some other high intensity calculation loop.

['n ddrylliog]

@horati : I think it wouldn't be "manageable" to mix several physics engines. The whole thing is abstract, true, but you only use one at a time.

Do you know how collisions are handled in JOODE ?

First collisions are detected, and Collision Info is created. Then contact joints are created for all the collisions you want to react to, then collision joints are "solved" (forces are applied to the colliding bodies to satisfy the contact joints).
But ! these objects aren't just "Geoms", they are "Bodies" so for (JO)ODE to solve collisions correctly, it also needs Velocity, Acceleration, every force applied on the Body, the Mass of these bodies, and a whole lot of other parameters.

No, really mixing several physic engines seems overwhelming to me..

[Mathias 'cylab' Henze]

So change the interface so that it can throw VetoException as well as CorrectionException where CorrectionException carries along the corrected location.  Then the FPIH could updated all callers back to the start location and attempt to get to the newly corrected location.  There are some ways to add details to the interface to optimize performance a little bit, but all these suggestions are essentially the Observer Pattern which seems ideally suited to anonymous interaction between 1 input source and multiple, simultaneous, pluggable physics/collision systems.

I would avoid exception handling for movement, there might be a lot of restricted movements in a game and creating exception objects and throwing them is not a lightweight task for the vm. Rather return the new location from a movement method or implement a callback with a boolean (movementVeto [true/false], correctedLocation [vecor]).

['n ddrylliog]

I would avoid exception handling for movement, there might be a lot of restricted movements in a game and creating exception objects and throwing them is not a lightweight task for the vm. Rather return the new location from a movement method or implement a callback with a boolean (movementVeto [true/false], correctedLocation [vecor]).

Yeah but on which criterium the Correcter does compute the Corrected position ??

[Mathias 'cylab' Henze]

Yeah but on which criterium the Correcter does compute the Corrected position ??

This corrected location has to be based on the physical properties of the capsule and the wall it hits.

[horati]

Absolutely, a return value would be cheaper than an exception.  I wasn't really think about implementation optimization yet.

As far as mutliple physics engines, I guess I was considering the case where you have a cheap physics engine for calculating collision with static planes (i.e., walls) and a real engine to calculate collisions with everything else.  Admittedly, I haven't looked into JOODE yet; however, I guess I assumed that "never cross this line" could be calculated cheaply before even engaging the physics engine *shrug*

['n ddrylliog]

So, to be clear, I don't like at all the idea of "Vetoable Movement", it's rather a "Collision Solver", in my vision of things.

Collision detection and Physic simulation are two separated things in implementation, they are only connected by the "Collision" class (see it in org.xith3d.physics.collision package).

With the help of a Collision detection package (not necessarily JOODE), you get a list of the "Collision"s you're interested in.

Then, you can use a "real physic engine", like JOODE, to solve them. For that, I think a "CollisionSolver" class will be added to the JOODE XPAL implementation.

But don't worry, I'm working on it, and critics will be easier when something's actually done. For now I'm working on the Connection API, which is nearly finished (and will permit me to achieve the Xith3D logo video), then I can implement JOODE-XPAL simulation part (the collision part is almost finished, only the Plane, Ray, and Trimesh collideable types are missing, and this is easy to add).

I'll put the JOODE-XPAL work on the JOODE SVN as soon as I can.. but I'm waiting on JOODE guys to switch to the latest Xith3D.

Is that enough infos for a few days  ? I'll notice you when JOODE-XPAL is on (a) SVN server, so that you can see the work and help/contribute to it.

[horati]

Sounds good.  Just to let you know, I'm working on an X3D-based product that I intend to launch at JavaOne this year.  For version 1, I only need collisions which are a whole lot easier than physics so I guess I was trying to lobby for my own needs without compromising the design

['n ddrylliog]

Sounds good.  Just to let you know, I'm working on an X3D-based product that I intend to launch at JavaOne this year.  For version 1, I only need collisions which are a whole lot easier than physics so I guess I was trying to lobby for my own needs without compromising the design

Don't worry, collisions are already fully working.. It could be smoother but heh...

I'd advise you to use JOODE-XPAL collision impl + a basic collision solver (basically, foreach collision, just moves the body along the normal of "collision depth" units). It *works* but not really well when you have more than one collision. I'll search if I can implement a more realistic collision solver which can work with several collisions. (JOODE-XPAL simulation impl will contain one, but if you don't want to use JOODE-XPAL simulation..)

Anyway, don't worry the JOODE guys (thomas larkworthy, principally) are working on switching to OpenMali so I can then put the JOODE-XPAL impl into JOODE svn.