VISTAS is still under active development. It is implemented in C++ using
Below please note links to documentation and software downloads. We remind potential users that VISTAS is still a research prototype, and though ease of use is a priority for us, we focus on functionality.
Note: VISTAS is available only for PCs running Windows .
- User Documentation, the VISTAS QuickStartGuide gives you a feeling for what the system looks like, and Dani’s OnePageQuickStartGuide can provide helpful hints when using the system. Dani has completed a new quickstart guide.
The Evergreen VISTAS fileshare and Atlassian Issue & Task Tracker for the project are available only to project participants. Issues and software reviews are currently handled on atlassian (jira, bitbucket, sourcetree)
|VISTAS 4 VEL 1-sheet|
|Revised Anatomy of VISTAS|
|VISTAS 4 ENV 1-sheet|
DANI – PLEASE CONFIRM THESE URL’S – I could not access them.
Project team members and collaborators are welcome to download the most recent version of VISTAS; note that one version has been compiled to run on OpenGL 2.0. Another is available for OpenGL 3.0. More details available in the Readme.txt. If you want to find out what version of opengl is on your computer, you can download and run the OpenGLExtensions Viewer . When you run it, you will see something like this.
VISTAS code is available on Mecurial at the VISTAS Bitbucket repository. Some important points:
- VISTAS team members need to create a Bitbucket account and send Nik their usernames so he can give you write permissions to the repository.
- For interacting with the repository, Nik recommends TortoiseHg on Windows (you’ll often see Mercurial referred to as Hg, its short name–the element code for mercury) or SourceTree on Mac.
- For those used to Google subversion, the transition should be fairly easy, but there are some important differences. First, take a look at the Mercurial quickstart: http://mercurial.selenic.com/quickstart/. Note: a) commit and push are separate operations, as are pull and update. Thus, when you pull commits from the central repository, Hg won’t update your codebase on disk until you “Update” to the latest revision. b) merging is a common operation. For example, let’s say you commit some code, creating a changeset, and then pull down a changeset from the central repository. This will result in two heads for that branch; you’ll need to merge them, which creates a third changeset, bringing the divergent paths together. This is a common operation, and once you do it a few times it will become second nature.
- Switching branches is super easy. First, make sure all your uncommitted changes are committed or shelved, then (in TortoiseHg) right-click on the latest changeset in the branch you want to work on and choose “Update”.
- Please use the branching model described in this article: http://nvie.com/posts/a-successful-git-branching-model/. The upshot: development happens on the “develop” branch (for short, self-contined updates only), or on “feature” branches, which when finished are merged into develop. “Release” branches are created from the develop branch, which are them merged into the “master” (or in our case “default”) branch which is where production-ready builds are created from. Any bugs which need to be fixed before the next planned release can be represented as “hotfix” branches, which stem from the default (production) branch, and then merge back into default (for an updated production-ready build) and into develop. The graph at the top of the article does the best job of explaining this. There is an extension to hg, called hg flow which facilitates all these operations; all the installation and usage info here: https://bitbucket.org/yinwm/hgflow/wiki/UserManual
- Many small commits are best: try for single-topic commits where the commit message fully represents the changes. This is especially easy when developing on a “feature” branch, as you don’t need to worry about breaking the everyone else’s build before your feature is complete.
- Nik is currently migrating the wiki pages. Please go through the issues list on Google Code: copy the issues you want to keep to Bitbucket, and then delete your issues from Google Code.
In case you are wondering: gd-2.0.34-win32.zip on the download page is a dependency to build VISTAS Nik didn’t find it in its original location (or anywhere else), so he re-uploaded it to our repository.