Discussion.Modelling Guidelines

[piratepad link]

Pad Archive as of 26 Oct 2011 00:53 UTC

Pioneer modelling guidelines:

• Models must/should be comprised of 4 seperate LOD levels
  • LOD1 - Collision mesh - less faces the better, 500 iis the recommended limit.
    • It is the lowest quality mesh and collision mesh. Not just collision.
  • LOD2 - Low quality model viewed from far away
  • LOD3 - Higher quality model viewed quite close
  • LOD4 - High detail, you can go a little crazy here...
• Ideally all LODs except for LOD1 will share textures
• It is preferable to use as few textures as possible, try to include engines and other smaller components on the main texture
• Ship's assets total size should be no greater than 10MB, although most would generally be much lower. This includes all variations of a single ship model (alternate textures etc).
• Texture variations are also possible however simple colour changes can be taken care of with materials in the lua file
• Sub-models like scanners, weapons, radar, ecm, missiles ect can be added to the model based on whether the ship has them equiped or not, we have a selection of sub-models but we always welcome new ones
  • I would recommend some additional lua helper functions to reduce the if-else mess. DrawMissile(pos, rot) style. No API changes necessary.
  • That would be good, we also discussed having blender do this for you, although we are unsure on the best approach for this.
    • For example Blender could place submodels itself and output that file which is read by Pioneer and translated into something useful.
  • Similarly the call_model(pos_light... stuff is icky - should wrap it in another function
• Its recommended that models be created in a 3D modelling package like Blender or 3DSMax and then exported. This generally makes the scripting requirments fairly simple. Models can be built scripted primitives but this is difficult and error-prone, and so not recommended.
• Modellers shouldn't concern themselves on micro-optimizations (trying to control texture switching or vertex sharing for example).
• Organizing the models:
  • Buildings should be organized by set name (preferred) or artist name. Models shouldn't use content outside their own set.
  • Ships can remain organized by name, one folder can contain variants of the same ship as before. They can be grouped by set ("fleet") if there are many similar/from one artist. Ships shouldn't use content outside their own set.
    • Exception to content sharing: very few sub_models. Equiment. Chairs, pilots, decals - not generic enough. We might have a duplicate .obj or .png here and there, but the point is to avoid dependency problems.
• We need excellent sample/template models with line comments.

stuff about static/dynamic and lods. should be put together into a "where to put things" kind of section. could probably even make a stub script with all the bits you have to fill in

• sub models like lights should be put in static and in lod > 1

• missiles should be in dynamic - depending on size of ship in lod > 2

• thrusters should be in static and in lod > 1

• make use of xref_thruster()

• This is just a modeller convenience thing

• prefer ship with no overlapping meshes - multiple objects - to avoid z-depth issues.

• Try to put as much in static as possible. Only use dynamic if you absolutely have to.

  • Things that SHOULD go in dynamic:
    • Submodel calls for equipment types
    • set_material() for parts of ship that change look put them in lod > 2
    • get_label() aka, registration id lod > 2
    • gear and animations
    • gear should not be part of collision mesh instead use primitives with smallest number of divisions/poly count to define collision mesh for gear so that ship does not have gear completly covered in ground once landed.
  • Things that SHOULD NOT go in dynamic (try to explain each - why not?)
    • load_obj

• What about huge ships, huge stations?

  • These are guidelines only. Unusual situations may call for exceptions.

lod_pixels is meant to represent percent of screen that model takes - not pixels because bigger displays have more pixels and pioneer use some dark magic hardcoded internal 800x600 display

• Once we have Rocket it'll all be real pixels - no more virtual display ;) Doesn't have to affect lod_pixels, whatever it ends up being called.
• That 800px thing seems like a bug - I don't see LmrNotifyScreenWidth being called anywhere
• Pixels is the sensible unit here. You see more detail at 10% of 1024 than 10% of 800.
• I think 800x600 is only for the gui..the 3d view works at what ever resolution?
  • Nah, this 800px thing is actually in LmrModel.cpp. See issue #700 but reality is something else and lod_pixels is this:

    float pixrad = 0.5f * s_scrWidth * rstate->combinedScale * m_drawClipRadius / cameraPos.Length();
    // pixel radians/radius????
    

the cameraPos.Length() arg is currently broken for sub_models

well whole LmrModel.cpp is broken and need fixing.

So we could say LOD pixels is a rough scale of how many pixels are on-screen, although a big emphasis on the rough part ;) That thing need to be carefully chosen and probably all lod_pixels stuff rewritten. It simple should be percent of screen ~0 - not on screen or very small, 60 percent and you have full detail. Yeah percent on-screen, or perhaps zoom level. I suppose for zoom level it could just be a multiple of bounding radius, if its <2 its LOD4 <5LOD3 ect ect, that is the distance from center. so: Lod_zoom/distance (50, 20, 5, 2) You guys know the model setup, you'd have the best idea. Write up what you'd like and put up an issue and we'll make it happen. It'd be really nice if lod switches could be calculated from bounding radius - less magic numbers for the modeler to deal with. Model radius is something that we could calculate automatically from collision radius and then make it possible to override They already are sort of, "bounding radius" is/should be named clipping radius because it is really used for clipping radius. Where is it used for "clipping"? m_drawClipRadius ? That is what it's called but it is not used for culling. Consistent eh? It IS used for culling. All right, all right :) :)

How about this? : float pixrad = rstate->combinedScale * ( cameraPos.Length() / m_drawClipRadius ); In theory that would give 1.0 up to some large number depending on how far away the camera was from the ship. lod picking depends on lod_pixels being given in increasing order: 1, 10, 50, 100 you would need to change that. Give it some testing, but first this camera position thing need fixing, so when pixrad is calculated that length between centre of sub_model and camera is used and not length between main model and camera. This actually seems to work :) so its: lod_pixels = {80,20,3,1}, which is a multiple of camera distance to ship, or bounding radius

Pixel size equation, it should work ok for what ever this 800x600 thing is, as long as it respected fov..otherwise you'd need what ever fov the scheme used.

object size in pixels on screen = (object bounding radius / dist from eye to object) * (0.5 * screen width in pixels/ (tan fov/2))