3D

Package go3d is a performance oriented vector and matrix math package for 2D and 3D graphics. Every type has its own sub-package and is named T. So vec3.T is the 3D vector type. For every vector and matrix type there is a String() method and a Parse() function. Besides methods of T there are also functions in the packages, like vec3.Dot(a, b). Packages under the float64 directory are using float64 values instead of float32. Matrices are organized as arrays of columns which is also the way OpenGL expects matrices. DirectX expects "arrays of rows" matrices, use the Transpose() to convert. Methods that don't return a specific value, return a pointer to the struct to allow method call chaining. Example: Method names in the past tense return a copy of the struct instead of a pointer to it. Example: Documentation: http://godoc.org/github.com/rekrad/go3d

Package three provides a simple API to create and display animated 3D computer graphics.

Package gosg is a lightweight scenegraph/scenetree based rendering toolkit. It provides a set of tools to build standalone windowed 3D applications for MacOS, Linux and Windows. This package is experimental. Expect it to break at any time.

mat32 is our version of the G3N math32 32-bit, 3D rendering-based math library. Initially copied from G3N: github.com/g3n/engine/math32 Copyright 2016 The G3N Authors. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file. A major modification from the G3N version is to use value-based logic instead of pointer-based self-modification in the Vector classes, As used in e.g., go-gl/mathgl (which uses slice-based vectors instead of the more intuitive and likely more efficient struct-based ones here). The pointer-based approach was retained for the Matrix classes, which are larger and that is likely more performant. Many names were shortened, consistent with more idiomatic Go naming. and again with the go-gl/mathgl library

Package stl implements functions to read, write, and transform files in the Stereolithography/Surface Tesselation Language (.stl) file format used in 3D modelling. The format specification was taken from http://www.ennex.com/~fabbers/StL.asp, found at http://en.wikipedia.org/wiki/STL_%28file_format%29. While STL stores the data in single precision 32 bit floating point numbers, the stl package does all calculations beyond simple addition in double precision 64 bit (float64). Usage Example Everything that operates on a model is defined as a method of Solid. Note that The STL format has two variants, a human-readable ASCII variant, and a more compact and precise binary variant which is preferrable. The Solid.BinaryHeader field and the Triangle.Attributes fields will be empty, after reading, as these are not part of the ASCII format. The Solid.Name field is read from the first line after "solid ". It is not checked against the name at the end of the file after "endsolid ". The stl package will also not cope with Unicode byte order marks, which some text editors might automatically place at the beginning of a file. The Solid.BinaryHeader field is filled with all 80 bytes of header data. Then, ReadFile will try to fill solid.Name with an ASCII string read from the header data from the first byte until a \0 or a non-ASCII character is detected. As always when you do linear transformations on floating point numbers, you get numerical errors. So you should expect a vertex being rotated for 360° not to end up at exactly the original coordinates, but instead just very close to them. As the error is usually far smaller than the available precision of 3D printing applications, this is not an issue in most cases.

Package args is used to configure programs using command line arguments and other sources. A program usually gets its parameters from a string array supplied by the system. This array is named "args" in many programming languages, or something close. By an incredible coincidence, this is precisely the name of this package. The package keeps simple things simple and makes complicated things possible. A first example shows how to provide help when the user says or maybe "-help", or "--help", or "-h": Parameters can be defined to take values for simple variables of builtin types and for arrays and slices. If needed, custom scanners can be used, so non-standard types are supported too. From the programmer's point of view, configuring parameters and taking values looks like this: From the user's point of view, here are 3 different ways of specifying 3 different things: Now, writing all this repeatedly on the command line is tedious. Fortunately the parser can take parameters from a file, like this: Assuming the 3 lines above have been written verbatim to the file, there will 9 things, not 3. But the parser is capable of ignoring parameters, so let's ignore the first two lines. The file could look like this (white space can be inserted freely): Symbols make it easy to override parameters in a file. Modify the file to use a symbol for the 3d value: The value can be overriden by setting the symbol DEFAULT3 before including the file: This works because the first value of a symbol wins. (For a scalar parameter it is the last one.) The syntax uses special characters, like $, [, and ] in these examples. In some environments, the predefined special characters can be problematic, but they can be reconfigured easily by the program, and the above input could look like this: In the args package, everything is a name-value pair: parameters, operators like include and -- (yes, it's a name). To keep simple things simple, it is possible to omit the name when defined as empty, the parameter is of type bool, and the value is true. This is the case of the "help" parameter in first example. So, to get help, the user does not need to write "help=true" but simply When no help is wanted, it is not necessary to say "help = false". The reason is that the initial value of the parameter is false. The programming interface is explained in the type and method documentation. The following sections describe the package from the point of view of the user. Parameters are formulated using a mini-language where words belong either to a name or to a value. Names and values must agree with parameter definitions made in the program. Names are composed of letters, digits (as tested by unicode.IsLetter and IsDigit), hyphens, or underscores. Syntactically, names and values are recognizable by the presence of a separator between them. The separator is one of five specially designated characters supporting the language syntax, in addition to white space: the symbol prefix, the name-value separator, the opening quote, the closing quote, and the escape character. Unless configured otherwise, these characters are: White space is a sequence of one or more characters for which unicode.IsSpace returns true. The escape character suppresses the effect of white space and special characters. When it has no effect, the escape is a normal character. An empty name is usually omitted, and in this case the separator must also be omitted. Parameters with an empty name are known as anonymous and their values as standalone values. When a standalone value is the name of a parameter, it is interpreted as that name with the value "true". This effect is usually what is wanted, but if necessary, can be avoided by using a quoted empty string: []. White space around separators is ignored but is significant between words, as it separates distinct values. It can be included in values by quoting. When a quoted string contains a nested quoted string, quotes must be balanced. Outermost quotes are removed but nested quotes are kept. A symbol is a name preceded by the symbol prefix. A symbol reference is a symbol prefix followed by a name between quotes. The following examples use the default set of special characters: The order in which parameters with different names are specified is not significant. The program will not know if parameter foo was specified before parameter bar. Multiple values of parameters can be mixed in any order. On the other hand, multiple parameter values are kept in specification sequence. If foo and bar are array or slice parameters, with an input like "foo=1 bar=a foo=2 bar=b bar=c foo=3", the program will see foo=[1 2 3] and bar=[a b c] but will not know if foo came before bar. if foo and bar are scalar parameters, the last value wins and the program will see foo=3 and bar=c. Parameter names are given by the program but symbols can be freely chosen, as long as they follow the same syntax rules as parameter names. A symbol is defined by prefixing it once with the symbol prefix. A reference consists of a symbol followed by name between quotes (as in the string "my $[foo] is rich"). Parameters and symbols are in distinct name spaces, and it is possible to use the name of a parameter for a symbol, as in "$foo=bar foo=$[foo]" which is equivalent to "foo=bar". Symbols must be defined before use: in "foo=$[x] $x=bar", the value of "foo" cannot be resolved. Redefining a symbol has no effect: the first wins (unlike parameters, where the last wins). The specification "$x=bar $x=quux foo=$[x]" is equivalent to "foo=bar". When a parameter is defined, it gets a target, which is the program variable that will take values from the parameter. The target's type determines the number and type of values the parameter can take. A target with a simple type can take one value. If multiple values are specified, the last value wins (again, contrast this with symbols, where the first wins). If no value is specified, an error occurs, unless the parameter has been defined as optional. The initial value of the target is the default value of an optional parameter. If the target is an array type, the number of values specified must be exactly equal to the array length. If the target is a slice type, the number of values can be at most equal to the slice capacity. If the slice capacity is zero, the parameter can take any number of values. A parameter with a slice target can be omitted or it can take a number of values less than its current length. In such cases the initial values in the slice provide the default values of the parameter. Instead of requiring repeating values, a parameter can be defined with a splitter, which is a regular expression. For example, if a splitter is defined to split a string around a colon (with optional white space) the specification "foo=[1:2:3] foo=[ 4 : 5]" sets 5 values. There are 7 operators built into args. Operators are built-in commands which have an effect on the state of the parser. From a user perspective, they look like any other parameter, with a name, a name-value separator, and a value containing subparameters. In increasing order of sophistication, they are -- (pronounced "comment"), dump, reset, import, macro, cond, and include. Operator subparameters are all defined as verbatim (see Param.Verbatim) except for two subparameters of include. The -- ("comment") operator ignores its value. The value can be anything, as long as it can be scanned by the parser, which means that quotes must be balanced. The operator is used to insert comments into a string of parameters. The operator is especially useful for commenting out blocks of parameters, which can span multiple lines and can contain nested comments. The dump operator is useful for debugging a complex args specification. It takes an optional "comment" parameter, and zero or more standalone values. dump interprets the values as parameter names and symbols and prints them line by line on standard error with their current values. The value of a symbol is followed by R if resolved, else by U. A name or symbol is preceded by ? if undefined. The empty parameter name is printed between quotes. If a comment is specified, it is printed first. A typical use may look like (import is explained ahead): and produce the output: The reset operator is used to remove symbols. It takes a series of values, which it interprets as symbols and removes them from the symbol table, if present. An error occurs if values are not symbols. It is useful because of the "first wins" principle. Contrary to parameter values, where the "last wins", once a symbol has been set, its value cannot be changed. When for some reason this is annoying, the symbol can be reset before taking a new value. For example, the specification: produces: The import operator is used to import environment variables. It takes a series of values, which it interprets as symbols. For each symbol a value is taken from the environment variable with the corresponding name (after removing the symbol prefix). The value is inserted into the symbol table unless there is already an entry for the symbol ("first wins" principle). If the environment variable does not exist, nothing is done. For example, the specification: produces the output: The macro operator is used to expand standalone symbol references. Without special care, standalone symbol references are either invalid (when no anonymous parameter was defined) or are taken up as values of anonymous parameters. They can be used when contained in verbatim parameters, typically intended to be parsed by sub-commands, as shown in the example with Param.Verbatim. The macro operator makes this pattern available at the top level without needing any auxiliary parameters. The operator takes a series of values, which it interprets as symbols, gets their values from the symbol table without resolving them, and passes them recursively to Parser.Parse. An error occurs if values are not symbols, if any symbol is not found, or if parsing fails. As an example, after parsing the input the string slice foo has the values "number 1" and "number 2". Notice the reset operator, necessary for the new count to take effect (because of the "first wins" principle). The cond operator allows conditional parsing. It has two mandatory parameters, "if" and "then" and an optional one, "else", all taking one value. The value of "if" is interpreted as a parameter name or symbol. It evaluates to true if the symbol exists or if the parameter has been set at least once. If the value is an undefined parameter, an error occurs. When the value of "if" is true the value of "then" is parsed, else it is the value of "else" which is parsed, if specified. For example, after parsing the input the string foo has the value "bar". The include operator has two different modes: a basic mode for recursively parsing a file containing parameters and a key-selection mode for extracting name-value pairs from a file. In basic mode, include takes a file name as anonymous parameter. It reads the file and parses its content recursively. Files can be included recursively and any cyclical dependency is detected. The anonymous parameter taking the file name is one the two operator parameters not defined as verbatim. In key-selection mode, include takes a file name, a "keys" parameter, and an optional "extractor" parameter. (The extractor parameter is the second operator parameter which is not verbatim.) The value of "keys" is interpreted as a series of standalone keys or key-translation pairs (using the current separator character of the parser). If there is no translation, the key translates to itself. include extracts name-value pairs from each line of the file, and if it finds a name matching one of the keys, it uses the value to set a parameter or a symbol, depending on the translated key. As always a symbol is set only if it does not already exist ("first wins" principle). The "extractor" parameter specifies a custom regular expression for extracting key-value pairs. The default extractor is \s*(\S+)\s*=\s*(\S+)\s*. It is an error to specify an extractor in basic mode (when no keys are specified). As an example, suppose there is file /home/u649/.db.conf with data we can use. Only the user and password information is needed. Parsing the input produces this dump output: This example will parse successfully only if the user running the program has read access to the file.

Package stl implements functions to read, write, and transform files in the Stereolithography/Surface Tesselation Language (.stl) file format used in 3D modelling. The format specification was taken from http://www.ennex.com/~fabbers/StL.asp, found at http://en.wikipedia.org/wiki/STL_%28file_format%29. While STL stores the data in single precision 32 bit floating point numbers, the stl package does all calculations beyond simple addition in double precision 64 bit (float64). Usage Example Everything that operates on a model is defined as a method of Solid. Note that The STL format has two variants, a human-readable ASCII variant, and a more compact and precise binary variant which is preferrable. The Solid.BinaryHeader field and the Triangle.Attributes fields will be empty, after reading, as these are not part of the ASCII format. The Solid.Name field is read from the first line after "solid ". It is not checked against the name at the end of the file after "endsolid ". The stl package will also not cope with Unicode byte order marks, which some text editors might automatically place at the beginning of a file. The Solid.BinaryHeader field is filled with all 80 bytes of header data. Then, ReadFile will try to fill solid.Name with an ASCII string read from the header data from the first byte until a \0 or a non-ASCII character is detected. As always when you do linear transformations on floating point numbers, you get numerical errors. So you should expect a vertex being rotated for 360° not to end up at exactly the original coordinates, but instead just very close to them. As the error is usually far smaller than the available precision of 3D printing applications, this is not an issue in most cases.

Package emergent is the overall repository for the emergent neural network simulation software, written in Go (golang) with Python wrappers. This top-level of the repository has no functional code -- everything is organized into the following sub-repositories: * emer: defines the primary structural interfaces for emergent, at the level of Network, Layer, and Prjn (projection). These contain no algorithm-specific code and are only about the overall structure of a network, sufficient to support general purpose tools such as the 3D NetView. It also houses widely-used support classes used in algorithm-specific code, including things like MinMax and AvgMax, and also the parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and emer.ParamSets). * erand has misc random-number generation support functionality, including erand.RndParams for parameterizing the type of random noise to add to a model, and easier support for making permuted random lists, etc. * netview provides the NetView interactive 3D network viewer, implemented in the GoGi 3D framework. * prjn is a separate package for defining patterns of connectivity between layers (i.e., the ProjectionSpecs from C++ emergent). This is done using a fully independent structure that *only* knows about the shapes of the two layers, and it returns a fully general bitmap representation of the pattern of connectivity between them. The leabra.Prjn code then uses these patterns to do all the nitty-gritty of connecting up neurons. This makes the projection code *much* simpler compared to the ProjectionSpec in C++ emergent, which was involved in both creating the pattern and also all the complexity of setting up the actual connections themselves. This should be the *last* time any of those projection patterns need to be written (having re-written this code too many times in the C++ version as the details of memory allocations changed). * patgen supports various pattern-generation algorithms, as implemented in taDataGen in C++ emergent (e.g., PermutedBinary and FlipBits). * timer is a simple interval timing struct, used for benchmarking / profiling etc. * python contains a template Makefile that uses [GoPy](https://github.com/goki/gopy) to generate python bindings to the entire emergent system. See the leabra package version to actually run an example.

Package globe builds 3D visualizations on the earth.

Package slice provides types and functions for slicing and compiling STL format 3D models into G-code to be used for 3D printing.

Package stl implements functions to read, write, and transform files in the Stereolithography/Surface Tesselation Language (.stl) file format used in 3D modelling. The format specification was taken from http://www.ennex.com/~fabbers/StL.asp, found at http://en.wikipedia.org/wiki/STL_%28file_format%29. While STL stores the data in single precision 32 bit floating point numbers, the stl package does all calculations beyond simple addition in double precision 64 bit (float64). Usage Example Everything that operates on a model is defined as a method of Solid. Note that The STL format has two variants, a human-readable ASCII variant, and a more compact and precise binary variant which is preferrable. The Solid.BinaryHeader field and the Triangle.Attributes fields will be empty, after reading, as these are not part of the ASCII format. The Solid.Name field is read from the first line after "solid ". It is not checked against the name at the end of the file after "endsolid ". The stl package will also not cope with Unicode byte order marks, which some text editors might automatically place at the beginning of a file. The Solid.BinaryHeader field is filled with all 80 bytes of header data. Then, ReadFile will try to fill solid.Name with an ASCII string read from the header data from the first byte until a \0 or a non-ASCII character is detected. As always when you do linear transformations on floating point numbers, you get numerical errors. So you should expect a vertex being rotated for 360° not to end up at exactly the original coordinates, but instead just very close to them. As the error is usually far smaller than the available precision of 3D printing applications, this is not an issue in most cases.

Package cozely is the starting point of the Cozely framework, a simple, all-in-one set of packages for making games in Go. It focuses on pixel art for 2D, and polygonal art (aka low-poly) for 3D, supports windows and linux, and has only two dependencies (SDL2 and Opengl 4.6). **THIS IS A WORK IN PROGRESS**, not usable yet: the framework is *very* incomplete, and the API is subject to frequent changes. Hello World example:

Package emergent is the overall repository for the emergent neural network simulation software, written in Go (golang) with Python wrappers. This top-level of the repository has no functional code -- everything is organized into the following sub-repositories: * emer: defines the primary structural interfaces for emergent, at the level of Network, Layer, and Prjn (projection). These contain no algorithm-specific code and are only about the overall structure of a network, sufficient to support general purpose tools such as the 3D NetView. It also houses widely-used support classes used in algorithm-specific code, including things like MinMax and AvgMax, and also the parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and emer.ParamSets). * erand has misc random-number generation support functionality, including erand.RndParams for parameterizing the type of random noise to add to a model, and easier support for making permuted random lists, etc. * netview provides the NetView interactive 3D network viewer, implemented in the GoGi 3D framework. * prjn is a separate package for defining patterns of connectivity between layers (i.e., the ProjectionSpecs from C++ emergent). This is done using a fully independent structure that *only* knows about the shapes of the two layers, and it returns a fully general bitmap representation of the pattern of connectivity between them. The leabra.Prjn code then uses these patterns to do all the nitty-gritty of connecting up neurons. This makes the projection code *much* simpler compared to the ProjectionSpec in C++ emergent, which was involved in both creating the pattern and also all the complexity of setting up the actual connections themselves. This should be the *last* time any of those projection patterns need to be written (having re-written this code too many times in the C++ version as the details of memory allocations changed). * patgen supports various pattern-generation algorithms, as implemented in taDataGen in C++ emergent (e.g., PermutedBinary and FlipBits). * timer is a simple interval timing struct, used for benchmarking / profiling etc. * python contains a template Makefile that uses [GoPy](https://github.com/goki/gopy) to generate python bindings to the entire emergent system. See the leabra package version to actually run an example.

Package cozely is the starting point of the Cozely framework, a simple, all-in-one set of packages for making games in Go. It focuses on pixel art for 2D, and polygonal art (aka low-poly) for 3D, supports windows and linux, and has only two dependencies (SDL2 and Opengl 4.6). **THIS IS A WORK IN PROGRESS**, not usable yet: the framework is *very* incomplete, and the API is subject to frequent changes. Hello World example:

Package bampf is a 3D arcade collection game with random levels. Bampf is the sound made when players teleport to safety. The subdirectories contain the game resource data.

Package gosg is a lightweight scenegraph/scenetree based rendering toolkit. It provides a set of tools to build standalone windowed 3D applications for MacOS, Linux and Windows. This package is experimental. Expect it to break at any time.

Package gwob is a pure Go parser for Wavefront .OBJ 3D geometry file format. Example: See also: https://github.com/udhos/gwob

Package emergent is the overall repository for the emergent neural network simulation software, written in Go (golang) with Python wrappers. This top-level of the repository has no functional code -- everything is organized into the following sub-repositories: * emer: defines the primary structural interfaces for emergent, at the level of Network, Layer, and Prjn (projection). These contain no algorithm-specific code and are only about the overall structure of a network, sufficient to support general purpose tools such as the 3D NetView. It also houses widely-used support classes used in algorithm-specific code, including things like MinMax and AvgMax, and also the parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and emer.ParamSets). * erand has misc random-number generation support functionality, including erand.RndParams for parameterizing the type of random noise to add to a model, and easier support for making permuted random lists, etc. * netview provides the NetView interactive 3D network viewer, implemented in the GoGi 3D framework. * prjn is a separate package for defining patterns of connectivity between layers (i.e., the ProjectionSpecs from C++ emergent). This is done using a fully independent structure that *only* knows about the shapes of the two layers, and it returns a fully general bitmap representation of the pattern of connectivity between them. The leabra.Prjn code then uses these patterns to do all the nitty-gritty of connecting up neurons. This makes the projection code *much* simpler compared to the ProjectionSpec in C++ emergent, which was involved in both creating the pattern and also all the complexity of setting up the actual connections themselves. This should be the *last* time any of those projection patterns need to be written (having re-written this code too many times in the C++ version as the details of memory allocations changed). * patgen supports various pattern-generation algorithms, as implemented in taDataGen in C++ emergent (e.g., PermutedBinary and FlipBits). * timer is a simple interval timing struct, used for benchmarking / profiling etc. * python contains a template Makefile that uses [GoPy](https://github.com/goki/gopy) to generate python bindings to the entire emergent system. See the leabra package version to actually run an example.

Package vkg implements an abstraction atop the Vulkan graphics framework for go. Vulkan is a very powerful graphics and compute framework, which expands upon what is possible with OpenGL and OpenCL, but at a cost - it is very difficult and complex to use, yet very powerful. This package provides utility functions and objects which make Vulkan a little more paltable to gophers, with the drawback that it cannot possibly expose all the power inherent in Vulkan, so it strives to avoid limiting users when they desire to utilize the full power of Vulkan. Vulkan overcomes many of the drawbacks of OpenGL by providing a much less abstracted interface to GPUs at a pretty hefty cost, all the things OpenGL managed previously are now up to the implementing application to manage. This documentation is woefully inadequate at fully descrbing how Vulkan works, and is meant to provide a refersher and perhaps some bread crumbs which will aid in undersatnding the system. At a high level vulkan provides a method of submiting work to command queues which execute various pipeline (which the application has configured) to either display graphics or peform compute work. An example of a pipeline might be one which displays a set of vertex data in a specific way, or a compute pipeline which pefroms some massively parallel mathmatical operation on a large set of data. The challenge then becomes providing the data in a way which these pipelines can utilize, so the data must be described adqueately enough so that the GPU can work with the data in an optimal way. To allow application developers to better utilize the underlying hardware, many decisions about how this data is managed is now left up to the application developer, rather than manged by a framework like OpenGL. This means the application developer is now responsible for deciding where the data which is to be processed by the pipeline will reside, what the format of the data is and how to make sure the data arrives at the appopriate time to best utilize the underlying hardware (this is a daunting task and application specific). So a game developed with Vulkan will have different needs and priorites than a scientific computing application developed with Vulkan, or even a 3D editor. This package can provide some assitance in getting started with vulkan but cannot possibly provide apporpaite abstractions for all possible use cases, or else it would fall into the trap of OpenGL - doing too much in a sub optimal way. Back to a discussion of Vulkan, we have command queues, which are feeding pipelines, which are using data provided by the application. Native Vulkan terms When thinking about how a graphics application with Vulkan works a very high level sequences of might be: This package provides a basic set of APIs which wrap some of the Vulkan APIs to make them a bit less painful to work with, the trade off being that many of the native Vulkan APIs expose options which are not exposed in the APIs provided by the package. To mitigate the drawback of this approach native vulkan structures are exposed in all the objects prefixed with the 'VK' in the name - so applications aren't limited by what this package provides. This package goes beyond what Vulkan natively provides to make Vulkan a bit easier to work with: GraphicsApp: ResourceManager: Utility interfaces:

Package cozely is the starting point of the Cozely framework, a simple, all-in-one set of packages for making games in Go. It focuses on pixel art for 2D, and polygonal art (aka low-poly) for 3D, supports windows and linux, and has only two dependencies (SDL2 and Opengl 4.6). **THIS IS A WORK IN PROGRESS**, not usable yet: the framework is *very* incomplete, and the API is subject to frequent changes. Hello World example:

Package noodle is a WebGL game engine, designed for low level access for fast and efficent 3D applications

Package vu - virtual universe, provides 3D application support. Vu wraps subsystems like rendering, physics, asset loading, audio, etc. to provide higher level functionality that includes: Refer to the vu/eg package for examples of engine functionality. Vu dependencies are:

Package emergent is the overall repository for the emergent neural network simulation software, written in Go (golang) with Python wrappers. This top-level of the repository has no functional code -- everything is organized into the following sub-repositories: * emer: defines the primary structural interfaces for emergent, at the level of Network, Layer, and Prjn (projection). These contain no algorithm-specific code and are only about the overall structure of a network, sufficient to support general purpose tools such as the 3D NetView. It also houses widely-used support classes used in algorithm-specific code, including things like MinMax and AvgMax, and also the parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and emer.ParamSets). * erand has misc random-number generation support functionality, including erand.RndParams for parameterizing the type of random noise to add to a model, and easier support for making permuted random lists, etc. * netview provides the NetView interactive 3D network viewer, implemented in the GoGi 3D framework. * prjn is a separate package for defining patterns of connectivity between layers (i.e., the ProjectionSpecs from C++ emergent). This is done using a fully independent structure that *only* knows about the shapes of the two layers, and it returns a fully general bitmap representation of the pattern of connectivity between them. The leabra.Prjn code then uses these patterns to do all the nitty-gritty of connecting up neurons. This makes the projection code *much* simpler compared to the ProjectionSpec in C++ emergent, which was involved in both creating the pattern and also all the complexity of setting up the actual connections themselves. This should be the *last* time any of those projection patterns need to be written (having re-written this code too many times in the C++ version as the details of memory allocations changed). * patgen supports various pattern-generation algorithms, as implemented in taDataGen in C++ emergent (e.g., PermutedBinary and FlipBits). * timer is a simple interval timing struct, used for benchmarking / profiling etc. * python contains a template Makefile that uses [GoPy](https://github.com/goki/gopy) to generate python bindings to the entire emergent system. See the leabra package version to actually run an example.

Package gomesh provides functions for basic handling of 3D mesh data in Go.

Package glider is a library that handles 3d collision testing.

Package emergent is the overall repository for the emergent neural network simulation software, written in Go (golang) with Python wrappers. This top-level of the repository has no functional code -- everything is organized into the following sub-repositories: * emer: defines the primary structural interfaces for emergent, at the level of Network, Layer, and Prjn (projection). These contain no algorithm-specific code and are only about the overall structure of a network, sufficient to support general purpose tools such as the 3D NetView. It also houses widely-used support classes used in algorithm-specific code, including things like MinMax and AvgMax, and also the parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and emer.ParamSets). * erand has misc random-number generation support functionality, including erand.RndParams for parameterizing the type of random noise to add to a model, and easier support for making permuted random lists, etc. * netview provides the NetView interactive 3D network viewer, implemented in the GoGi 3D framework. * prjn is a separate package for defining patterns of connectivity between layers (i.e., the ProjectionSpecs from C++ emergent). This is done using a fully independent structure that *only* knows about the shapes of the two layers, and it returns a fully general bitmap representation of the pattern of connectivity between them. The leabra.Prjn code then uses these patterns to do all the nitty-gritty of connecting up neurons. This makes the projection code *much* simpler compared to the ProjectionSpec in C++ emergent, which was involved in both creating the pattern and also all the complexity of setting up the actual connections themselves. This should be the *last* time any of those projection patterns need to be written (having re-written this code too many times in the C++ version as the details of memory allocations changed). * patgen supports various pattern-generation algorithms, as implemented in taDataGen in C++ emergent (e.g., PermutedBinary and FlipBits). * timer is a simple interval timing struct, used for benchmarking / profiling etc. * python contains a template Makefile that uses [GoPy](https://github.com/goki/gopy) to generate python bindings to the entire emergent system. See the leabra package version to actually run an example.

Package emergent is the overall repository for the emergent neural network simulation software, written in Go (golang) with Python wrappers. This top-level of the repository has no functional code -- everything is organized into the following sub-repositories: * emer: defines the primary structural interfaces for emergent, at the level of Network, Layer, and Prjn (projection). These contain no algorithm-specific code and are only about the overall structure of a network, sufficient to support general purpose tools such as the 3D NetView. It also houses widely-used support classes used in algorithm-specific code, including things like MinMax and AvgMax, and also the parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and emer.ParamSets). * erand has misc random-number generation support functionality, including erand.RndParams for parameterizing the type of random noise to add to a model, and easier support for making permuted random lists, etc. * netview provides the NetView interactive 3D network viewer, implemented in the GoGi 3D framework. * prjn is a separate package for defining patterns of connectivity between layers (i.e., the ProjectionSpecs from C++ emergent). This is done using a fully independent structure that *only* knows about the shapes of the two layers, and it returns a fully general bitmap representation of the pattern of connectivity between them. The leabra.Prjn code then uses these patterns to do all the nitty-gritty of connecting up neurons. This makes the projection code *much* simpler compared to the ProjectionSpec in C++ emergent, which was involved in both creating the pattern and also all the complexity of setting up the actual connections themselves. This should be the *last* time any of those projection patterns need to be written (having re-written this code too many times in the C++ version as the details of memory allocations changed). * patgen supports various pattern-generation algorithms, as implemented in taDataGen in C++ emergent (e.g., PermutedBinary and FlipBits). * timer is a simple interval timing struct, used for benchmarking / profiling etc. * python contains a template Makefile that uses [GoPy](https://github.com/goki/gopy) to generate python bindings to the entire emergent system. See the leabra package version to actually run an example.

Package ds provides a wrapper for Microsoft's DirectSound API in pure Go. It can only be used on Windows. When running a DirectSound application you need to have dsound.dll installed on the system, which fortunately has been deployed with all Windows versions since XP. This means if you have Go installed, you also have the DLL installed. This also means that your application can be deployed without the DirectX DLLs and if you have no other dependencies you can just give the executable file to the users. NOTE that the prefix DS is left out of all identifiers. In cases where this makes the name start with "3D", the 3D part is appended to the name instead, e.g. DS3DBUFFER becomes BUFFER3D.

Package "vu" creates dynamic 3D and 2D visualization with OpenGL. For example, the following produces multiple 3D views of a dynamic dataset: To create a custom renderer, implement the Render interface.

doc.go (c) 2013-2015 David Rook - all rights reserved Eclectic Set of Utility Functions Real BUGS -##0{ None Known - but beware of limitations While the polyline can be used to depict GPS coordinates that is NOT a requirement. Use []GPSloc aka GPSlist if you need that (3D) capability.

Package autostereo provides routines for creating 3D optical illusions from 2D images.

Package globe builds 3D visualizations on the earth.

Package mechane is an app that implements a number of interactive 3D worlds.

Package e2 is a 3D isometric game framework.

eTorch provides the emergent GUI and other support for PyTorch https://pytorch.org networks, including an interactive 3D NetView for visualizing network dynamics, and other GUI elements for controlling the model and plotting training and testing performance, etc. The key idea for the NetView is that each `etorch.Layer` stores the state variables as a `etensor.Float32`, which are just copied via Python code from the torch.FloatTensor` state values recorded from running the network. The `etor` python-side library provides a `State` object that handles the recording of state during the `forward` pass through a torch model. You just need to call the `rec` method for each step that you want to record. The `set_net` method is called with the `torch.Network` to record state to.

Package noodle is a WebGL game engine, designed for low level access for fast and efficent 3D applications

Structures used to represent 3D scenes (imported using Open Asset Importer). This file contains the strucutres used in the program

Package gi is the top-level repository for the GoGi GUI framework. All of the code is in the sub-packages within this repository: * gist: css-based styling settings, including Color * girl: rendering library, can be used standalone, SVG compliant * gi: the main 2D GUI Node, Widgets, and Window * giv: more complex Views of Go data structures, supporting Model-View paradigm. * svg: full SVG rendering framework, used for Icons in gi. * gi3d: 3D rendering of a Scene within 2D windows -- full interactive 3D scenegraph. * histyle: text syntax-based highlighting styles -- used in giv.TextView * python: access all of GoGi from within Python using GoPy system.