Proposed changes to A3DL (though currently being partly implemented by Pete in the new S5 UserInterface):
(TODO what are these things?)
- Render layer...
A3dlView (click for more info)
- Nodes...
- Scene...
- Clock...
More stuff that we'd like to add to A3DL, in no particular order :
- World options that affect how the user can move through the world, i.e. in what dimensions.
- Option on objects to always face the user. Maybe change billboard to be a co-type that basically overrides the object's orientation to always face the user, or indicates that the orientation property is in the view coordinate frame rather than world (even though position is in the world frame). Could have a similar type that affects position in this way too.
- heightmap terrain, with splatting
better support for portals (which presently do sort of exist in A3DL but arn't supported in the csvosa3dl plugin, which makes them pretty useless) -- see WorldPortals
- native keyframe animation (as opposed to loading MD2)
- native ["Skeletal Animation"] (should be based closely on Cal3D so we can take advantage of that library)
- more sophisticated material model with diffuse/specular/highlight parameters
- alternate geometry representations: constructive solid geometry, NURBS, fractal splines (not sure exactly what this is, is it extrusion based?), subdivison surfaces
- physics parameters: mass, density, center of gravity, moment of inertia, elasticity
- cached lightmaps, so they don't have to be computed on the client side
- metaballs etc.
- subdivision surfaces - rename "polygonmesh" to "mesh" and add optional properties that specify subdivision parameters (with default as no subdivision)
- specially mark objects/surfaces to help avatars align; be gravitationally attracted to (fall
- towards... mario galaxies), or to help avatars walk/climb on otherwise complicated geometry (stairs, ladders, etc.)... or should we let servers do this, and instead have flags in the world/sector to disable the client's default controls/physics?
Of course, much of this depends on 3D engine support. The first UserInterface prototype is using LightFeather instead of CrystalSpace (see discussion in vos-d mailing list archives for why). It would be nice to have another 3D engine supporting VOS though, as it would give us some perspective on what the right "middle ground" is between various 3D engines.
[PeterAmstutz] I'm also thinking about changing the A3DL coordinate system definition to be a geocentric coordinate system instead of a screen-centric coordinate system. Currently A3DL defines the neutral orientation as looking down the Z+ axis, with the X+ axis to your right and the Y+ axis going up. This is a left-handed coordinate system, I believe, and is the coordinate system used by Crystal Space (which is where we got it from). It is derived from computer graphics where one is thinking in terms of screen space being an XY plane of pixels, and then Z axis depth going into the screen.
My proposal is to go to a right-handed coordinate system. The neutral orientation would be looking down the X+ axis, with the Y+ axis going to your left and the Z+ axis going up. This makes a lot of sense when you think in terms of a more earth-based coordinate system, where if you are looking down on your world (such as looking at a map) the earth's surface is expressed in terms of an XY plane, and the Z axis is the elevation from that plane.
I believe blender uses the latter coordinate system (which has the current COD mesh exporter tied into knots doing the coordinate system conversion). Of course, the Crystal Space plugin would have to be modified to do coordinate system conversion on the fly instead. (Note this isn't an expensive operation, just mapping the axes differently and negating one to flip it).
[ReedHedges] Well, whichever coordinate system you use, any program using the *other* coordinate system will have to do the transformations. If we can determine that a majority of modelling programs etc. that people will want to use to create content uses right handed, then maybe switch. Or, even, have a3dl allow either with a tag indicating which is being used (with the transformation being done in TerAngreal). This makes exporting from other programs a no brainer, at the expense of making A3DL more complicated and harder to implement. That expense might outweigh the convenience, but I'm not sure yet.
Random small things
- Cone and cylinder primitives (and others) implementations for CS could divide very long dimensions into parts so that offscreen polygons can more easily be skipped by the renderer. Neccesary?
Future Features
- a mode to support assembling objects like legos. (objects have "snap points"
- that connect.