This is a program that Alfred Differ and myself are working on
This is not a true simulation, just a simple sequence without physics simulation yet.
Long Term
Objectives
- Simulate physics of solid bodies of any shape with, forces, torques, collision detection and response.
- Uses Newtonian mechanics (not relativity or quantum mechanics).
- Force types: constant (gravity), inverse square, collision (impulse), and contact (static, sliding friction, rolling).
- Allow different renderers. Simple 2D in applet or full 3D in application.
- Able to model multiple solid bodies and jointed structures.
- Ability to model elasticity (work as a finite element analysis tool).
Design decisions
- Uses Clados to hold physical quantities where appropriate. http://sourceforge.net/projects/clados/
- Shape (Node) types: cube, box, sphere and group (tree)
Phase 1
Objectives
- Simulate physics of solid bodies which are boxes or spheres, including forces, collision detection and response.
- real time.
- no optimisation for performance
- 2D rendering in applet.
Design decisions
- Written in Java
- Uses Clados to hold physical quantities where appropriate. http://sourceforge.net/projects/clados/
- Force types: gravity and collision.
- Shape (Node) types: box and sphere.
Renderer Issues
Types of renderer:
| pros | cons | |
| real time, OpenGL or DirectX |
|
|
| photorealistic, raytracing | high quality | too slow for realtime |
| draw in 2d window to represent a view in x,y or z direction (orthographic parallel projection) | Can put directly in java applet without plugin | non realistic line representation. |
| script VRML or game builder program | would allow programming at a higher level. | tied to the program or standard concerned, not sure if its flexible enough? |
I think OpenGL might be the best option, but it can't be called directly from Java, therefore it would be good to have a general interface which would allow different types of renderers:
The boxes in the above diagram represent the following:
Physical Model
This holds full information about the world in a way that allows objects motion and interaction to be calculated. It has information about the whole volume occupied by each object, so it can calculate when the boundaries of objects are in contact and also the internal mass distribution which effects the way objects move.
Surface generator and smoother
If the physical model in made up of cubes then additional smoothing will be required to stop the output looking like its made from Lego bricks. We may also want mesh reduction to reduce the size of the data.
Texture or colour generator
Converts the material information into data about what the surface looks like. We may have a JPEG image of what the surface looks like or just colour information. Also information about how the material reflects, refracts, absorbs, scatters, or generates light.
Physical model to render converter
The renderer requires only surface information about the objects and this information needs to be in a form that can be used by renderers. Most renderers require surfaces to be made up of flat faces (polygons) usually triangle or quads, defined by 3 or 4 vertexes. Normals are used to smooth out the appearance of these flat faces and there is also optional texture and colour information. Some renderes also support an option of using NURBS which allow shapes to be defined by mathematical functions which are driven by control points.
This also converts from Monad to vector and matrix representation of vertexes, normals and transforms.
Java3D or other wrapper for OpenGL
Java3D is a Sun extension to their Java software. It is an additional free download (it does not come with the Java SDK or runtime) it also requires the latest java 2 version of the runtime. Therefore it wont work in most browsers until both of these have been downloaded and installed, I think most web browsers would not be willing to do 2 big downloads just to see a webpage with a Java applet. Some people would be willing to do this for our full application but it can be a messey process.
Java3D has a much higher level interface than OpenGL, it stores its information in a scenegraph which makes it very good for our application. However Sun seem to be loosing interest in developing this and so they may not be doing many enhancements to this in the future.
There seems to be a move to lighter weight wrappers for OpenGL such as the JOGL project on JavaGaming.
Sun
announced an agreement with SGI to cooperate on developing Java bindings
to the OpenGL API (spec
here), I think this is about putting 3D on mobiles?
Raytracer
Such as POVRay, not sure if Java is supported or suitable for this type of application?
Implementation Issues
If we don't need to interact with the program then we can divide up into 3 separate programs.
If we need to interact with the simulation as it is happening then, we need to put this all in one program.
This looks a lot more messy as we either have to:
- generate the full render tree seperately for every frame in the animation, (very slow).
- or, keep both trees and cross link them so they are kept uptodate.
The second case is much faster as we only have to change the transform at each frame.
