I should probably reference this at a given code site where I have been developing, but generally I like discussing this and its to add to my blog collection. Ideas are developed in Python at the moment. Basically working on abstracting existing process.
Thresholding how it works:
Thresholding (TH) are housed in a list nested dictionary called TH are read and unpacked and accordingly applied in sequential order based upon its 'sequence' identifier.
THs need have the following key information:
'Landtype' specified either 'Flood', 'Land', 'Mount'
'Type' specified either 'Height', or 'Normal'
'TBracket' or Threshold bracket range these need supplied ordered csale
2 tuple 0 <= value <= 1. Note: any overlap in the bracketing range from one dictionary value to the next on the same landtype will lead to mixing of modules which may or may not be what you are looking for. If you want distinct textures for specific normal ranges you will need to keep the Tbracket ranges non overlapping for min max cscale ranges chosen for each of the same landtype. Note: TBracket set [0,1] means thresholding is off (or covers the range).
'Fractal' boolean means color mixing is either fractalized between on the modules 1d polar spectrum or not. If not chosen mixing method is by default given (ratio of measured distance of a normal relative to threshold relative to the maximum normal distance for such threshold range)
A list will at a basis at least a 2 tone 1 dimensional polar spectrum.
Meaning these will be assigned at least two color tones at either polar end.
Position values of any color tone range from 0 to 1.
Open poles and all positions between such applied to the nearest (to pole)
color position will be the same color as such as nearest neighboring color.
Linear interpolation will apply in so far as mixing between colors.
'Colors' is a 2 dimensional list. A nested list contains a rgb color
assignment 3-tuple and its position marker
'nsize' (applies if 'Fractal' is true) This sets the fractal size.
'nbasis' ('Fractal' true). This selects the basis of the fractal (see below).
'lacunarity' ('Fractal' true). This sets the lacunarity of the fractal noise.
'depth' ('Fractal' true). Depth (see below)
'dimension' ('Fractal true). see below.
'Name' This is non used in terrain generation but kept for organizational purpose.
'Id'. This is the corresponding driver id for color mixing.
It is noted that internal color mixing is given with all the internal
instructions given by the TM itself, but this doesn't provide external mixing instructions for a given output color determination.
Calls to TM are done especially with calls to fractalization for color mixing that are not handled by the color mixing modules directly (no mixing driver interface provided here).
Mixing (MM)
Dictionary key: Module ID, Value:
All mixing module ins and outs are routed through ColorInOut module.
Mixing Modules is a list dictionary with the following properties:
'Id' Module Id.
'Ins' Module input identifiers are provided here. 2 are necessary to proper functioning of the module. These are 2 tuple defined.
'Outs' Module output identifiers here. Minimum of 1 supplied.
'Type' Type is given by one of the following:
'Multiply, Screen, Overlay, Hard light, Soft Light, Dodge, Burn,
Divide, Addition, Subtract, Difference, Darken Only, Lighten Only,
Normal (colorlerp), Normal2 (colorlerp2)'
'FactorType' either 'fixed' or 'variable'
'FactorVar' (if FactorType set 'variable' only) set either 'normal' or
'height'
'Factor' (FactorType set 'fixed' only). This is a real value from 0 to 1. The factor amount for the mixing type.
'Falloff'. This is the amount of feathering applied for a given threshold
you must use the cf ranges specified below. You can choose, .05, .1, .2
to .7. The cf value must exist in the cf dictionary (see below).
Setting 'Falloff' to 0 (zero) otherwise, specifies that mixing falloff is turned off.
'Landtype' is given by 'Flood, Land, or Mount'
All 'variable' factor is given by 'RH(N)D/TH(N)D' (ratio of measured
height or normal distance
on a given height/normal land type range relative to total height/normal distance for such land type range...
ColorInOut (CIOM)
dictionary
'id' This is the module id for a given color input assignment
Note any module ID is given either by a threshold module or mixing module.
so it is likely important that any identifier provided for either module type neither has id overlap.
'RGB' is the rgb standard 3 tuple given value (non normalized).
ColorInOut Module is a dictionary database for the mixing driver.
Mixing Driver (MD)
ordered list
given by a operating mixing module ID sequence. It is up to a user to supply a valid sequence so that all chain inter dependencies in a given computation
set are appropriately handled...if this were given in a visual context, it is up to the user supplying a valid and properly linked chain node from one mixing module node to the next.
Node Chains (NCs)
Dictionary: key - Id - Mixing node chain[mixing id list]
These are a given layer between the mixing driver and threshold modules
The way that these are structured is 'if, then' That is 'if' threshold module ID is computed 'then' the following mixing module nodes are linked to this tm.
DirectColorInput(DCI)
This allows one to directly input colors into the ColorInOut dictionary so that it is stored with a reference identifier in the CIOM. That is, it is not an identifier that is given either as a result of TM computation or a MM computation.
Schematics of overall terrain colorization goes as follows:
unpack threshold (TH) having placed these into three categories:
'flood', 'land' , 'mount'.
Mixing modules will also be unpacked, these will contain both input and output channel information along with any sequence assignment for computation work (to ensure necessary data is put in place) before sequentially passing to such module for computation.
Do everything as necessary in preparation as shown below prior to pixel by pixel computation of rgb terrain colorization routine.
In pixel by pixel routines, extract height and normal.
Height data determines which land type modules are used computation wise.
'Land' will use all terrain types computation wise (for threshold feathering between land types).
All threshold computations and any subsequent mixing computations will have data pathed to a ColorInOut, and also trigger a pixel mixer driver configuration through the NodeChains dictionary. Basically after computation work is done on TM, the CIOM is read which is then key parsed to the Node Chains in constructing Mixing driver instructions. That is, before formal calls in constructing the sequential chain in computing mixing beyond computed thresholds.
ColorInOut (CIOM) is basically identified computed work already having been task accomplished as given by its parent module identifier (whether such parent is a 'Threshold' or a 'Mixing' or given from the DirectColorInput).
ColorInOut will be in part used by the Mixing Driver which outside of preliminary threshold module 'basis' work will be the overarching driver for sequentially producing a given terrain pixel output.
The mixing driver is read on a simple loop iterator. The mixing driver loop iterator traverses the Mixing ID sequence. The appropriate Mixing (MM) is loaded. This data is passed to mixing function, repeating the process until the Mixing driver loop is finished.
Mixing (MM) may have variably written per pixel given instructions that is, each driver instruction is not the same for pixel to pixel, if for instance, thresholding dictates that added color mixing schemes
need exist for a given pixel position. Once pixel computation is complete reinitialize the ColorInOut (CIOM).
So eventually this should hopefully be abstracted well enough to allow for modularity in design as found in Blender's node system so that one can custom design any configuration of all of the above in building colorization generators without having to modify code which isn't exactly that hard if you know how to read it and program it.
Thresholding how it works:
Thresholding (TH) are housed in a list nested dictionary called TH are read and unpacked and accordingly applied in sequential order based upon its 'sequence' identifier.
THs need have the following key information:
'Landtype' specified either 'Flood', 'Land', 'Mount'
'Type' specified either 'Height', or 'Normal'
'TBracket' or Threshold bracket range these need supplied ordered csale
2 tuple 0 <= value <= 1. Note: any overlap in the bracketing range from one dictionary value to the next on the same landtype will lead to mixing of modules which may or may not be what you are looking for. If you want distinct textures for specific normal ranges you will need to keep the Tbracket ranges non overlapping for min max cscale ranges chosen for each of the same landtype. Note: TBracket set [0,1] means thresholding is off (or covers the range).
'Fractal' boolean means color mixing is either fractalized between on the modules 1d polar spectrum or not. If not chosen mixing method is by default given (ratio of measured distance of a normal relative to threshold relative to the maximum normal distance for such threshold range)
A list will at a basis at least a 2 tone 1 dimensional polar spectrum.
Meaning these will be assigned at least two color tones at either polar end.
Position values of any color tone range from 0 to 1.
Open poles and all positions between such applied to the nearest (to pole)
color position will be the same color as such as nearest neighboring color.
Linear interpolation will apply in so far as mixing between colors.
'Colors' is a 2 dimensional list. A nested list contains a rgb color
assignment 3-tuple and its position marker
'nsize' (applies if 'Fractal' is true) This sets the fractal size.
'nbasis' ('Fractal' true). This selects the basis of the fractal (see below).
'lacunarity' ('Fractal' true). This sets the lacunarity of the fractal noise.
'depth' ('Fractal' true). Depth (see below)
'dimension' ('Fractal true). see below.
'Name' This is non used in terrain generation but kept for organizational purpose.
'Id'. This is the corresponding driver id for color mixing.
It is noted that internal color mixing is given with all the internal
instructions given by the TM itself, but this doesn't provide external mixing instructions for a given output color determination.
Calls to TM are done especially with calls to fractalization for color mixing that are not handled by the color mixing modules directly (no mixing driver interface provided here).
Mixing (MM)
Dictionary key: Module ID, Value:
All mixing module ins and outs are routed through ColorInOut module.
Mixing Modules is a list dictionary with the following properties:
'Id' Module Id.
'Ins' Module input identifiers are provided here. 2 are necessary to proper functioning of the module. These are 2 tuple defined.
'Outs' Module output identifiers here. Minimum of 1 supplied.
'Type' Type is given by one of the following:
'Multiply, Screen, Overlay, Hard light, Soft Light, Dodge, Burn,
Divide, Addition, Subtract, Difference, Darken Only, Lighten Only,
Normal (colorlerp), Normal2 (colorlerp2)'
'FactorType' either 'fixed' or 'variable'
'FactorVar' (if FactorType set 'variable' only) set either 'normal' or
'height'
'Factor' (FactorType set 'fixed' only). This is a real value from 0 to 1. The factor amount for the mixing type.
'Falloff'. This is the amount of feathering applied for a given threshold
you must use the cf ranges specified below. You can choose, .05, .1, .2
to .7. The cf value must exist in the cf dictionary (see below).
Setting 'Falloff' to 0 (zero) otherwise, specifies that mixing falloff is turned off.
'Landtype' is given by 'Flood, Land, or Mount'
All 'variable' factor is given by 'RH(N)D/TH(N)D' (ratio of measured
height or normal distance
on a given height/normal land type range relative to total height/normal distance for such land type range...
ColorInOut (CIOM)
dictionary
'id' This is the module id for a given color input assignment
Note any module ID is given either by a threshold module or mixing module.
so it is likely important that any identifier provided for either module type neither has id overlap.
'RGB' is the rgb standard 3 tuple given value (non normalized).
ColorInOut Module is a dictionary database for the mixing driver.
Mixing Driver (MD)
ordered list
given by a operating mixing module ID sequence. It is up to a user to supply a valid sequence so that all chain inter dependencies in a given computation
set are appropriately handled...if this were given in a visual context, it is up to the user supplying a valid and properly linked chain node from one mixing module node to the next.
Node Chains (NCs)
Dictionary: key - Id - Mixing node chain[mixing id list]
These are a given layer between the mixing driver and threshold modules
The way that these are structured is 'if, then' That is 'if' threshold module ID is computed 'then' the following mixing module nodes are linked to this tm.
DirectColorInput(DCI)
This allows one to directly input colors into the ColorInOut dictionary so that it is stored with a reference identifier in the CIOM. That is, it is not an identifier that is given either as a result of TM computation or a MM computation.
Schematics of overall terrain colorization goes as follows:
unpack threshold (TH) having placed these into three categories:
'flood', 'land' , 'mount'.
Mixing modules will also be unpacked, these will contain both input and output channel information along with any sequence assignment for computation work (to ensure necessary data is put in place) before sequentially passing to such module for computation.
Do everything as necessary in preparation as shown below prior to pixel by pixel computation of rgb terrain colorization routine.
In pixel by pixel routines, extract height and normal.
Height data determines which land type modules are used computation wise.
'Land' will use all terrain types computation wise (for threshold feathering between land types).
All threshold computations and any subsequent mixing computations will have data pathed to a ColorInOut, and also trigger a pixel mixer driver configuration through the NodeChains dictionary. Basically after computation work is done on TM, the CIOM is read which is then key parsed to the Node Chains in constructing Mixing driver instructions. That is, before formal calls in constructing the sequential chain in computing mixing beyond computed thresholds.
ColorInOut (CIOM) is basically identified computed work already having been task accomplished as given by its parent module identifier (whether such parent is a 'Threshold' or a 'Mixing' or given from the DirectColorInput).
ColorInOut will be in part used by the Mixing Driver which outside of preliminary threshold module 'basis' work will be the overarching driver for sequentially producing a given terrain pixel output.
The mixing driver is read on a simple loop iterator. The mixing driver loop iterator traverses the Mixing ID sequence. The appropriate Mixing (MM) is loaded. This data is passed to mixing function, repeating the process until the Mixing driver loop is finished.
Mixing (MM) may have variably written per pixel given instructions that is, each driver instruction is not the same for pixel to pixel, if for instance, thresholding dictates that added color mixing schemes
need exist for a given pixel position. Once pixel computation is complete reinitialize the ColorInOut (CIOM).
So eventually this should hopefully be abstracted well enough to allow for modularity in design as found in Blender's node system so that one can custom design any configuration of all of the above in building colorization generators without having to modify code which isn't exactly that hard if you know how to read it and program it.
No comments:
Post a Comment