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)
- 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. 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)
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)
- 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)
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)