Talk:Reference mesh

Moved

A "mesh" can also be collision, and this page doesn't seem to be talking about the term itself. --TomEdwards 08:53, 2 May 2008 (PDT)

No. In this context a mesh has deformable geometry whereas Collision models are made from rigid hulls. Unlike Meshes, Hulls do not include weightmaps, UV maps or Skins.- see Mesh#Disambiguation --Beeswax 14:53, 2 May 2008 (PDT)

A mesh is a collection of polygons that gets compiled to whatever it needs to be by studiomdl. The term 'Hull' is only used when the meshes start to be handled with C++ code in a certain way - it's the same data, a polygon mesh, just treated differently. This might not make sense because I am editing VDC at nearly midnight and I do not know why. --TomEdwards 15:51, 2 May 2008 (PDT)

No. In this context a mesh has deformable geometry whereas Collision models are made from rigid hulls. Unlike Meshes, Hulls do not include weightmaps, UV maps or Skins.- see Mesh#Disambiguation --Beeswax 14:53, 2 May 2008 (PDT)

Was that a server glitch? I'm trying to explain how hull is a term that only becomes meaningful when programming with C++. --TomEdwards 05:07, 3 May 2008 (PDT)

No. You are missing the point. Collision Hulls become meaningful when they affect collision events in game. Hulls are part of the game's collision system, whether they're modified in C++ or banana boxes is of no significance to their role in game. Remember: "meaning = use". --Beeswax 06:18, 3 May 2008 (PDT)

Please stop trying to use "mesh" and "SMD file" interchangeably. You are only confusing yourself. An SMD file contains mesh data as well as other data - see reference model (updated WIP). --Beeswax 06:18, 3 May 2008 (PDT)

This is the distinction I'm trying to make. It seems pretty fundamental. "Hull" and "Mesh" seem to be the best terms available; ie causing the least inconsistency with current documentation.

I'm basically asserting that a Hull is a single convex collision object, a single piece of collision geometry, as opposed to a concave or jointed collision model which is an assembly of Hulls ... this usage is also fairly consistent with:

• the (original) naval use of the word. (Talk:NPC_Hulls even appear to have Double Hulls]!)
• Convex Hull seems to be a specific concept in geometry, whereas there is no comparable "concave hull" concept.
• in Source I'm aware that this is extending the common use of the word from a Qphysics concept (NPC Hull, etc) to a Vphysics concept which AFAIK has no distinctive name. The properties of both Vphysics and Qphysics Hulls are virtually identical at a high level, even though they hail from 2 different codebases. --Beeswax 09:08, 3 May 2008 (PDT)

Vertex Geometry Type: design & function

Type:	Mesh	Vphysics Hull	Qphysics Hull
Surface:	continuous	continuous	continuous
Convexity:	any	convex	convex
CollisionProp:	NotSolid	Solid (by default)	Solid (by default)
Visibility:	texturemapped	not rendered	not rendered
Elasticity:	weightmapped	rigid	rigid
SMD defined:	reference.smd, submesh.smd, lod.smd	physics.smd	no
QC specified:	$body, $model, $bodygroup	$collisionmodel, $collisionjoints	($bbox $hbox ... kind of ?)
Model defined:	VVD & VTX	PHY	no
Entity defined:	no	no	NPC_Hull, Player Hull, etc.
Engine/Pipeline:	Rendering	Physics	Physics

Hulls do exist, and I'm not sure why you seem to think I'm arguing they don't. But they are still meshes. You are writing documentation for modellers that makes distinctions only a programmer needs to think about. (OK, except for concavity.) --TomEdwards 08:43, 3 May 2008 (PDT)

Default mesh / Sub-mesh

I've run some experiments and I don't see the distinction between a "default" reference mesh and a "sub" reference mesh. It's simply a case of what QC command you use when compiling them into a model - not any kind of property of the meshes themselves.

The QC configuration allows the mesh data to have/become properties of the model. StudioMDL is a compiler. AFAIK The body-mesh (;-)) is always used as the chassis for every bodygroup, whereas sub-meshes can be switched on and off for different bodygroups. Each mesh is designed for a different purpose and exported separately. A Sub-mesh.smd cannot be part of the Reference.smd. --Beeswax 16:07, 2 May 2008 (PDT)

They are designed differently and exported separately, but they are still the same at a technical level. There is no difference except in how a developer chooses to use them: you can use your 'sub-mesh' as your 'reference' and vice versa. --TomEdwards 05:07, 3 May 2008 (PDT)

Significant similarities are (1) they are both render meshes (2) they are both enveloped to the same Skeleton. --Beeswax 07:07, 3 May 2008 (PDT)

Why are you telling me this? --TomEdwards 08:43, 3 May 2008 (PDT)

In the same area, "sub-models" are actually entirely different entities, which have naught at all to do with the reference mesh. --TomEdwards 09:19, 2 May 2008 (PDT)

Yes that is correct, they are enveloped to different skeletons - see distinction in Mesh#Optional mesh.

PS: Actually yes, the point about "entities" is a good one - thanks. --Beeswax 16:12, 2 May 2008 (PDT)

definition

• In Source, a Reference mesh (sometimes body, envelope or skin) defines some or all of a model's rendered geometry and its skeleton. A model needs at least one reference mesh or it will not be visible in the world and will not be able to animate properly.

The Skeleton is not part of the Mesh. The mesh is enveloped to the skeleton so the skeleton can deform the mesh. If you could even get an un-meshed skeleton into the game, yes it would be invisible but it would probably animate perfectly! AFAIK the skeleton derives no data whatsoever from the Mesh. The skin is "parented" to the mesh and the mesh is "parented" to the skeleton. I think you are confusing the "reference mesh" with the "reference.smd". --Beeswax 21:01, 2 May 2008 (PDT)

Yes, I am. I think it would be much, much easier if a reference mesh and a reference SMD were treated as the same thing, since they are bound together 100% of the time. --TomEdwards 05:07, 3 May 2008 (PDT)

It might be easier but it is neither correct of helpful ;-). The "reference.smd" happens to contain a block of triangles/mesh data which you choose to call the "reference mesh" because it is defined in the reference.smd ? But the reference.smd also contains the much more important Reference Skeleton ... all of a model's 3d geometry is "parented" (or referenced) to the Skeleton, whereas only the Skin/texture is "parented" to the Mesh. Only the Skeleton (rootbone) is "parented" to the $origin, ie the Entity's position and orientation in the world. The Skeleton (and I mean both ref.SMD|nodes and ref.SMD|skeleton blocks) is the key!! --Beeswax 06:39, 3 May 2008 (PDT)

I was confused about your intentions here, but I think I understand them now. --TomEdwards 08:43, 3 May 2008 (PDT)