First, we need to establish outlining goals of what OpenPL aims to provide to the end [user|developer]. Here are a few to start the discussion:
-Both continuous and discrete methods should be supported. They require somewhat different primitives.
-We don't want to compete with Novodex or Havok. We really should aim at low-level to provide an open standard so these groups and others can work with either PPU, GPU, or CPU.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What do physics programmers or physics engine developers use/want in terms of base structures, algorithms, and methods that could be hardware accelerated?
Then we have to balance this against what can be accelerated efficiently on both GPU and CPU.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The most important thing to have (and accelerate) in the core level would be large matrix solving and optimization. This can ultimately be done in hardware with great advantage.
Populating these matrixes for specific algorithms would be a more high level task, probably done in a software level.
What I may want (in a user perspective):
-The ability to cleanly choose between several algorithms for a speed/precision tradeoff. The underlying differences between algorithms should not be visible to me (I.E. the api would be algorithm-independant).
-The ability to have different "dynamic worlds" being simulated at the same time, and the ability to move object groups from one to another.
-The ability to use relative coordinates whenever needed (I.E. a way to change the coordinate system base, much like in opengl)
(etc?)
What shouldn't be done:
-The use of primitives like spheres or cubes. This belongs to a higher level api (PLUT?). Only use point masses.
-Tying up collision handling stuff with dynamics simulation stuff. These two, if both get included, should be made as separate as possible. We may just want to use one of them, or use both separately.
(etc?)
BTW, is there a mailing list for this project? I'm in a planning phase of writing a physics simulator, so this project may be interesting for me.
Cheers
Renato
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, we need to establish outlining goals of what OpenPL aims to provide to the end [user|developer]. Here are a few to start the discussion:
-Both continuous and discrete methods should be supported. They require somewhat different primitives.
-We don't want to compete with Novodex or Havok. We really should aim at low-level to provide an open standard so these groups and others can work with either PPU, GPU, or CPU.
What we hope to illicit now is:
What do physics programmers or physics engine developers use/want in terms of base structures, algorithms, and methods that could be hardware accelerated?
Then we have to balance this against what can be accelerated efficiently on both GPU and CPU.
The most important thing to have (and accelerate) in the core level would be large matrix solving and optimization. This can ultimately be done in hardware with great advantage.
Populating these matrixes for specific algorithms would be a more high level task, probably done in a software level.
What I may want (in a user perspective):
-The ability to cleanly choose between several algorithms for a speed/precision tradeoff. The underlying differences between algorithms should not be visible to me (I.E. the api would be algorithm-independant).
-The ability to have different "dynamic worlds" being simulated at the same time, and the ability to move object groups from one to another.
-The ability to use relative coordinates whenever needed (I.E. a way to change the coordinate system base, much like in opengl)
(etc?)
What shouldn't be done:
-The use of primitives like spheres or cubes. This belongs to a higher level api (PLUT?). Only use point masses.
-Tying up collision handling stuff with dynamics simulation stuff. These two, if both get included, should be made as separate as possible. We may just want to use one of them, or use both separately.
(etc?)
BTW, is there a mailing list for this project? I'm in a planning phase of writing a physics simulator, so this project may be interesting for me.
Cheers
Renato
<quote>
Both continuous and discrete methods should be supported. They require somewhat different primitives.
</quote>
What do you mean by "continuous methods"?