User:Enetheru/Map Features: Difference between revisions

From Spring
Jump to navigationJump to search
m →Scale: added more of my observations about scale.
m cleaned up a little. added texture section.
Line 35: Line 35:
== Scale ==
== Scale ==
there is a 1:1 ratio for the obj model values to the pixel values of the ground texture.
there is a 1:1 ratio for the obj model values to the pixel values of the ground texture.
in other words, a 2x2 map that has a texture resolution of 1024x1024 can contain a model that is 1024x1024 dimensions
in other words, a 2x2 map that has a texture resolution of 1024x1024 can contain a model that is 1024x1024 dimensions. From my experience, objects need to have dimensions of at least 8^3 otherwise they are too small to be noticed and not worth the trouble.
 
* the arm commander has a height of 64
From my experience, objects need to have dimensions of at least 8^3 otherwise they are too small to be noticed and not worth the trouble.
* trees are between 32 and 96 in height with the average height at 64.
 
* rocks and boulders have good sizes at between 16 and 48
trees are between 32 and 96 in height with the average height at 64.
* if you take that a house with roof has a good height at 32, then 16 per story, and you get the rough dimensions of 5 units equals 1m. and is a good rule of thumb for making units.
 
the arm commander has a height of 64
 
rocks and boulders have good sizes at between 16 and 48
 
if you take that a house with roof has a good height at 32, then 16 per story, and you get the rough dimensions of 5 units equals 1m. and is a good rule of thumb for making units.
 
sometimes however it is useful to exaggerate the size of an object, such as grass. to provide a more interesting look.
sometimes however it is useful to exaggerate the size of an object, such as grass. to provide a more interesting look.


Line 55: Line 48:
* see also [[Trouble-shooting_s3o_units]]
* see also [[Trouble-shooting_s3o_units]]
* not animatable/scriptable. features are designed to be static. if more complexity is required perhaps units or buildings are a better fit.
* not animatable/scriptable. features are designed to be static. if more complexity is required perhaps units or buildings are a better fit.
== textures ==
* the more objects in a map that have the same texture atlas the better, it reduces texture context switches and helps performance.
* compiling the dds textures use <code>nvcompress -bc2 imagename</code>


== basic defaults ==
== basic defaults ==
I want to create a table of defaults, for energy/metal/reclaimtime/mass/etc so that new features can be copy pasta'd etc. and i can put presets in my script.
I want to create a table of defaults, for energy/metal/reclaimtime/mass/etc so that new features can be copy pasta'd etc. and i can put presets in my script.
things like:
things like:
dimensions of feature(x,y,z)
: dimensions of feature(x,y,z)
type of feature(grass/shrub/tree/rock
: type of feature(grass/shrub/tree/rock

Revision as of 06:57, 2 August 2013

seriously dammit I cant seem to categorise/organise the various models/animations etc inmy mind so that I can start on docs for them..

afaik, and this is arbitrary, there are CEG's, Features, Units, Buildings, but they are all basically the same thing, some have more detail than others..

so if we lump them under one heading like maps, whats the simplest, and then how can we extend that simple idea?

  • Static Model multiple pieces
  • textures
  • Corpses
  • animation scripts
  • particles
  • Shaders

And in what capacity can they be used in game?

  • map feature
  • effect
  • unit
  • building

Static Map Feature

mapcontainer.sdd/
   features/
      feature.lua
   objects3d/
      model.obj
      model_heirarchy.lua
   unittextures/
      textures.png

Scale

there is a 1:1 ratio for the obj model values to the pixel values of the ground texture. in other words, a 2x2 map that has a texture resolution of 1024x1024 can contain a model that is 1024x1024 dimensions. From my experience, objects need to have dimensions of at least 8^3 otherwise they are too small to be noticed and not worth the trouble.

  • the arm commander has a height of 64
  • trees are between 32 and 96 in height with the average height at 64.
  • rocks and boulders have good sizes at between 16 and 48
  • if you take that a house with roof has a good height at 32, then 16 per story, and you get the rough dimensions of 5 units equals 1m. and is a good rule of thumb for making units.

sometimes however it is useful to exaggerate the size of an object, such as grass. to provide a more interesting look.

caveats

  • the tex1 image needs to have a completely black alpha channel so that team colours do not override the diffuse values.
  • the UV coordinates need to be mirrored on the V axis(y)(only when not using dds textures)
  • rotations clockwise (positive integer only) [0-65536] = [0-360] degrees
  • see also Trouble-shooting_s3o_units
  • not animatable/scriptable. features are designed to be static. if more complexity is required perhaps units or buildings are a better fit.

textures

  • the more objects in a map that have the same texture atlas the better, it reduces texture context switches and helps performance.
  • compiling the dds textures use nvcompress -bc2 imagename

basic defaults

I want to create a table of defaults, for energy/metal/reclaimtime/mass/etc so that new features can be copy pasta'd etc. and i can put presets in my script.

things like:

dimensions of feature(x,y,z)
type of feature(grass/shrub/tree/rock