steve at stevestreeting.com wrote:
>
>
>>I agree with you generally, but dont really see the value of seperate
>>StandardModel/SkeletalModel types. If a mesh is not boned, then simply
>>don't include the bone id/bone weight chunks in the file. So your submesh
>>block becomes:
>>
>>
>
>I totally agree with Alan here. There is no difference between a skeletally
>animated and on-animated mesh apart from this optional information.
>
>
Then how about putting the skeleton binding in the submesh (where the
bone weights are) instead of in the main model/mesh. This would allow a
mesh to be assignable to more than one skeleton type, but mainly it
keeps the optional skeleton section together so its one section or none,
not two sections or none.
>
>
>
>> Submesh
>> - Texture/Material (per texture-unit)
>>
>>
>
>I disagree with this. Your mesh should not care about how many texture units
>there are, or how many layers there are in the material you choose to use with
>it. The link should be just to a single material, and the material defines the
>number of texture layers and the source of the texture coord data (from one or
>more of the texture coord sets, from auto generated texture coords, from
>vertex shaders etc. Meshes should IMHO know nothing about shading parameters,
>they should just provide texture coord data which the material can choose to
>use however it sees fit.
>
yeah it makes more sense that way
>> - Face data
>>
>>
>
>Just a quick point - a submesh could use geometry that is indexed or
>unindexed. If unindexed, then the vertex data IS the face list. I think this
>should be renamed to 'index data' and is optional.
>
>
Agreed, so we'll also need a way to describe the indexing type if theres
no 'face list' chunk trilist/tristrip/trifan etc.
>
>
>> - Texcoord data (per texture-unit)
>>
>>
>
>Again just a clarification - it's not per texture unit, this is just input
>data which a material may choose to use. Nothing ties the material to use it,
>nor does it follow that texture coord set #0 is used for texture layer #0, you
>can mix and match.
>
>
Thats pretty much what i mean, texture-layer would've been a better word
to use then texture-unit, the main requirement i was specifiyin ghere is
more then one set of texcoords, since in my initial proposal the linking
to the material/texture was done before the texcoord data.
>
>
>> - Bone ID's (optional)
>> - Bone Weights (optional)
>>
>>
>
>Bone weights are pairs of <boneID, weight>, they're tied together therefore
>should be one entry.
>
>
So then (imho) i think it shoudl be
- Skeleton Binding (optional)
-Skeleton name
- boneID-weight pairs
>
>
>>-Precomputed mesh lod's. I prefer my lod done offline by an artist, rather
>>than in realtime for both speed and apperance.
>>
>>
>
>In OGRE we support 2 types of LOD - manually assigned and automatically
>calculated, because both are useful. In my experience when you're making a
>manual LOD, you want control over everything so you might change the vertex
>data, the material (to eliminate expensive multitexture blends, shaders etc),
>switch to a lower detail skeleton too etc. This actually means that you're
>switching the whole _mesh_ out when using artist-defined LOD.
>
This is the primary type used in OSG
>
>When using pregenerated LOD however, there is a linkage between the top-level
>LOD and the lower detail lods, because they are procedurally generated. This
>means you can reuse some data between levels. In OGRE we use the same source
>vertex dta but change the indexes; this is more memory-efficient and the use
>of the same vertex buffer with more sparse indexes has little or no
>performance penalty when using hardware vertex buffers, which is our target.
>
OSG would support this type too, so I think these two LOD types is a must
>So we have 2 sets of information about LOD in the Mesh, a list of LOD metadata
>which states the type of LOD to use at each level (calculated or manual);
>the 'manual' type just causes this mesh to act as a proxy for another mesh
>object at different LODs (so the file format just names the alternative mesh,
>and at runtime it binds this to an actual Mesh instance) whilst a 'calculated'
>entry indicatesthat each SubMesh actually includes alternative triangle index
>data. At the moment we only support calculated LOD on indexed data.
>
>
I'm no Cal3d guru, but from what i can understand, cal3d's LOD system
works by collapsing vertices into other verticies. Each vertex is
assigned two numbers: an ID of the vertex the vertex collapses to, and
the number of faces that are removed during the collapsing. Vertices are
pre-sorted in order of collapsing, the first to collapse at the end of
the vertex array. Then given a floating point LOD value, the mesh can be
collapsed. Is this a common technique? or is it something only Cal3d
does (ie. should we include support for this type of LOD data or not?)
Wallaba
--
http://wallaba.sytes.net/~wallaba/
"Gross stupidity, falsehood, and muddled
thinking are not dream; and form no escape
from life to a mind trained above their
own level."
-H. P. Lovecraft