[Bf-committers] Dimensioning for GSOC suggestion

[Jean-Michel Smith]

Regarding imperial vs. metric vs. whatever.

Why not break the problem into two parts.

1. definiton of units in terms of base unit with label, e.g.
metric-system with meter as base unit and other values derived
therefrom, definition of imperial as foot as base unit and other units
derived therefrom, etc.  This would allow flexibility to use pretty
much anything (even "metric-60 plank units" such as
http://autonomyseries.com/Canon/Metric-60/ , particularly if unit
definitions are in a simple-to-understand XML format.

2. map blender units to the system referenced, and to some unit within
that system (one person might be working in km, another in mm, another
in inches, someone twisted like myself, in zaratocks).  The .blend
could contain a pointer to the XML definition of the system of units
in question (metric and imperial definition XML files could be
included with blender by default) and a specification of what unit in
that system of units a blender unit maps to.

regards,

Jean.

On 4/19/06, Campbell Barton <cbarton at metavr.com> wrote:
> Hi Hos, dimensions arnt as simple as you hinted :) - Heres my plans for
> implimenting, but would be a fine GSOC project.
>
> Dimensions are not that simple esp if you want imperial (ft/inches)
>
> Heres a list of teh stuff that needs to be added.
> Store the Dimension data in the Scene (not prefs)
> Add 2 new values to the Scene DNA
>  - int unit_type:   0-none, 1-metric, 2-imperial, 3-Japanese
> (http://en.wikipedia.org/wiki/Japanese_units_of_measurement) -
> apparently its worth having.
>  - unsigned double unit_scale:   this is the real world size of the
> blender unit, how many blender units to make a meter. so 1.0 means 1
> blender unit is 1 meter.  100.0 means 100 blender units is a metre.
>
> Now we need 2 utility functions, convert a blender distance to a string,
> and a string to a blender unit.
> so somebody can type in 2mm, or 4.9km and it will be converted.
> Unit conversion will be hard coded here. though there should be defines
> for unit scales and sub divisions.
>
> This can easerly be applied to edge length display and header grab length...
>
> Once this is done numbuts will need to be have an arg for being a
> measurement button.
> This well make the numbet display using the num2string utility function
> described above. as well as evaluate user input with the util function.
>
> Now we can talk to blender in units, the 3d view grid needs to follow
> the units.
> firstly the grid just needs to change size for the units. this is a no
> brainer.
> The more complex area is to have measurements like imperial where there
> is a different grid subdivisions for miles/feet/inches.
> So at different zoom levels you will neet to impose different sub
> divisions. (not all that hard,just define an array of sub divisions foir
> each dimension type)
> Once the grid is drawn correctly snapping follows. (did some tests with
> modifying grid sub division)
>
> It will be trickier to have transform numeric input work, but probably
> just evaluate the input string on input and update when a valid results
> returned.
> This one could be posponed.. theeth probably needs to look into it.
>
> This is just for dimensions, for weight volume etc you could go crazy,
> but I think dimensions alone are fine for blender.
> - Cam
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>