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, $lod	$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)

I agree that XSI, etc (probably) make no distinction between completely convex and partially convex "polygonal models", however, if you are designing a collision model in XSI, you do need to know how Source will handle your model so you can design it to perform properly. --Beeswax 09:16, 3 May 2008 (PDT)

For example a Mesh which does not include UVmap or Weightmap data will not function as a Source Mesh. But a Hull does not require these tedious things. --Beeswax 09:21, 3 May 2008 (PDT)

That isn't enough reason to lay on all of the confounding detail you're trying to. Saying "a collision mesh must be concave" and "a reference mesh needs a UV map and weightmap" does the same job with a fraction of the words. --TomEdwards 10:09, 3 May 2008 (PDT)

The detailed explanation is entirely for your benefit. Please try reading it again, it certainly does not say "a collision mesh must be concave" because that is obviously incorrect. --Beeswax 10:50, 3 May 2008 (PDT)

I just used the wrong word, geez. Anyway, I'm talking about what's on the Mesh article page, not what's on this one. --TomEdwards 08:07, 4 May 2008 (PDT)

(though, incidentally, the weightmap is automatically generated by the exporter if absent)--TomEdwards 10:09, 3 May 2008 (PDT)

I would expect all SMD exporters to "generate" Skeleton, Weightmap, and UVmap data if none was user-specified (have a look in a physmodel.smd). The SMD file format requires those "fields" to be filled. StudioMDL does not necessarily use the "default" weightmap and uv data. This behaviour could conceivably vary between SMD exporters (it would be annoying - and noteworthy - if it did!). But this info would be better placed in an Export SMD checklist ? --Beeswax 10:50, 3 May 2008 (PDT)

Not if it's automatically generated, since that removes it from the list of things that have to be done. It should definitely go in the weightmap article though. --TomEdwards 08:07, 4 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)

"no difference except in how a developer chooses to use them" which is surely what the documentation is for. Meaning = Use. What "technical level" are you on ? --Beeswax 11:45, 3 May 2008 (PDT)

The documentation is already present in $model, $body, and $bodygroup. There is no point in inventing multiple names for the identical data that is fed into them. Let's put it this way:

"A reference mesh can be used in three ways"

Not:

"There are three types of reference mesh"

--TomEdwards 08:17, 4 May 2008 (PDT)

OK, you can't use any mesh as a sub-mesh: it needs to be enveloped to the "body" mesh's skeleton (before export) so it will align properly on the model. The envelope is part of the mesh (triangles) data, so a sub-mesh is a special type of mesh. It's the same thing with sub-models (see Creating worldmodels from viewmodels) - w_weapons are not just any phys-prop. --Beeswax 15:18, 4 May 2008 (PDT)

Hang on. I think the problem here is this word "reference". Your using it where I would use "render", eg "render_model" as opposed to "collision_ model". I'm thinking of "reference_model" in terms the "default_model" which can be modified by additional skins, additional meshes and/or LOD (not to mention animations, vphysics, etc). The additional renderables come in additional SMD (or VMT) files and need to be "spliced" into the model with optional QC commands ($texturegroup, $bodygroup, $lod), whereas $body/$model is not an optional extra ... so to me, the "reference.smd" contains all the SMD data you need for a basic prop_detail or skybox model in one SMD file ... throw in a physbox.smd and some propdata and you have a simple prop_physics ... see what I mean ? --Beeswax 15:51, 4 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)

Almost ;-) My contention is that the $body QC command specifies the "reference.smd" - the file where StudioMDL will find the data intended to be used as this model's Mesh and Skeleton. It does not define the "reference mesh". The "reference.SMD#triangles data" defines this Mesh - but that's not what the QC asks for. It just wants the name of the "reference".smd. ("KISS" ...) --Beeswax 10:12, 3 May 2008 (PDT)

OK, looks like you're in the right here. I still don't like the idea of the phrase "reference.SMD" though - there's no harm adjoining the separate terms with "reference mesh SMD". So long as the files are always mesh+skeleton+UV, which they are, it's the most immediately-understandable way of putting it. --TomEdwards 10:38, 3 May 2008 (PDT)

I sympathise with your desire to make it "look right" on the page, however I think it is more important that the information is specific and uncluttered. I know you hate redundant "quotes" and file extensions but I think they help make the code readable at a glance. The more that the syntax/example looks like the real thing, the easier it will be to use. I think the links for a concept that might be referenced from another doc (eg $model or $bodygroup) are potentially invaluable, as long as the article they link to gives all the relevant info ... ? Here's a few format examples that make sense to me :

$body "<name>" "<reference>.smd"
$body "<name>" "<referenceSMD>.smd"
$body "<body_mesh>" "reference.smd"
$body "<mesh_name>" "<reference.smd>"
$body <mesh_name> <reference.smd>    

$lod <threshhold> {                           // ie: anchor link to "$lod#threshold"
replacemodel <original.smd> <lod1.smd>        // ie: anchor links to "$lod#notes"
replacematerial "original.vmt" "lod1.vmt"     // See notes #3 and #6 below. (ie: just a simple comment pointer)
}

--Beeswax 11:37, 3 May 2008 (PDT)

This is getting minor now, but is there really a huge difference between 'reference.smd' and 'reference SMD', except the lack of a direct link to SMD? --TomEdwards 08:22, 4 May 2008 (PDT)

Well I don't see any reason to link to SMD (file format) when we're specifying a specific file that happens to use a format called SMD. We don't need to know about the file structure, we only need to know the filename. "Reference" is the significant bit, but by itself would be too general; it doesn't obviously say "I'm a filename". Using "ref.smd" rather than "ref_SMD" makes it clear that this is the filename.file extension. Also it makes sense to use a presentation format that works for all similar situations: eg a physbox is not the same thing as a physbox.smd ... At the end of the day it's known as the "reference.smd" or "modelname_ref.smd", not the "reference file" or "reference data" or "reference_SMD.smd" or anything else. I really see no reason to deviate from that. --Beeswax 14:34, 4 May 2008 (PDT)

I think "modelname_reference.smd" is just too long! How about :

$body <mesh_name> <ref.smd>
$body <mesh_name> <#_ref.smd>    
$body <mesh_name> <modelname_ref.smd> 
$body <mesh_name> <model_ref.smd>
$body <mesh_name> <name_ref.smd>
$body <mesh_name> <#_reference.smd>

They don't seem to be as easily recognisable somehow ... ? --Beeswax 16:08, 4 May 2008 (PDT)