Free dwg 9.5 software for windows

ngPlant is a 3D plant modeling software package. Designers can use interactive tool to create 3D models of different plants and trees.
With ngPlant software devs can use the 3D API-independent library to use generated plant models in their 3D applications, or to create plant modeling plugins for different 3D modeling tools

Enhancements:
- ngpcore, ngput and pywrapper libraries now distributed under the terms of BSD License.
- Now it is possible to add up to 8 branch sub-groups per branch (in previous versions up to 4 sub-groups could be added).
- GLEW library (http://glew.sourceforge.net) is now required to compile ngplant, ngpshot and ngpview. GLEW-related configuration options are described in config/cross-sample.py.
- GLSL support added to ngplant. With GLSL support it is possible to see per-pixel diffuse lighting applied to plant models in real-time (normal-map support). Source code for shaders used by ngplant is located in "shaders/ngplant_default_vs.glsl" and "shaders/ngplant_default_fs.glsl" files.
- "-es" option added to ngplant. This option enables error reporting to stderr.
- "-ns" option added to ngplant. This option disables shaders usage.
- 3d-view flicker which appeared in some configurations have been fixed.
- Now it is possible to use GLSL shaders for snapshot rendering. To use shaders your video card must support GLSL. Look at ngpshot_nor_vs.glsl and ngpshot_nor_fs.glsl files at shaders directory. These shaders allow to render plant model normal-map instead of plant image. Using generated color image and normal map it is possible to create normal-mapped billboards with dynamic lighting support. To use shaders "-vs" and/or "-fs" options must be used.
- "-vs" and "-fs" command line options added. "-vs" option is used to select file from which vertex shader source should be loaded. "-fs" option allows to select file from which fragment shader should be loaded.
- P-Buffer off-screen rendering mode support added to ngpshot. It allows to use hardware acceleration for rendering.
- New "-o" command line option allows to choose between pixmaps/pbuffer off-screen rendering mode. By default ngpshot uses best supported mode. Possible modes are: "auto" - default, "pixmap" - pixmap/bitmap mode and "pbuffer" - p-buffer mode.
- C compiler presence check added to configuration step
- P3D_PLATFORM_WINDOWS macro is not used anymore
- P3D_DLL_ENTRY macros added to HLI classes which should be visible outside ngpcore in case of DLL build. To make classes visible define P3D_DLL_BUILD macros while building ngpcore DLL and define P3D_DLL_USE macros while building your application.
- It is not needed to define snprintf as _snprintf for MSVC compilers anymore
- API (HLI) change: C : Now it is possible to get tangent and bi-normal vertex attributes in addition to position, normal and texture coordinates using new P3D_ATTR_TANGENT and P3D_ATTR_BINORMAL constants.
- API (HLI) change: C : Branch group name now can be accessed using new P3DHLIPlantTemplate::GetGroupName method.
- API (HLI) change: Python : Now it is possible to get tangent and bi-normal vertex attributes in addition to position, normal and texture coordinates using new ATTR_TANGENT and ATTR_BINORMAL constants.
- API (HLI) change: Python : Branch group name now can be accessed using new BranchGroup.GetName method.

MLDonkey was originally intended as a pure eDonkey2000 clone, running on Unix and Linux, a sector that the original client never served well. Since the release of version 2, there has also been development to access other networks (see OtherNetworksSupported), most notably the eDonkey2000 offspring Overnet.
The history of MLDonkey has been lined with controversy, mostly based on the fact that the original client has always been proprietary, in terms of source code as well as transfer protocol. This has forced the MLDonkey developers to reverse engineer the basic mechanisms, but they didnt stop at that. In many cases, new functionality has been introduced, sometimes great and sometimes questionable.
MLDonkey introduced a method to connect to several servers simultaneously, thereby increasing search efficiency greatly. This was at a time when servers were quite small, and already strained (mainly by bots). Too many users, a few servers, new solutions needed.
Later on, certain pretentious server admins became more and more interested in the numbers of users assigned to their servers, rather than in the efficiency of the network. This meant that a client connecting to more than one server was a threat to their internal "high score" competition of served users.
Complaints started to come in from eDonkey users about MLDonkey being too efficient, i.e. utilizing an unfair amount of network resources. This probably has to do with the extreme reluctance of the developers of eDonkey2000 to improve their product, which led to larger and larger servers, instead of following the approach MLDonkey stood for: increasing the connectivity of the network as a whole. But, then again, making the eDonkey2000 network too efficient would probably not be in line with the plans to develop the Overnet, which is indeed a high connectivity serverless network.
MLDonkey also features a way to exchange file sources between clients, thereby making the servers less important, of course another threat to the pride of the server admins. Soon, a strange alliance was formed by the developer of the popular Lugdunum server and MetaMachine, the eDonkey2000 development company. This resulted in a long series of attempts to ban MLDonkey, bans which were easily worked around, and due to the nature of open source projects, also easy to deploy among users.
Main features:
- 100% OpenSource, GPL license
- Core and Guis are separated or linked.
- written in ObjectiveCaml, with some C and even some Assembler parts.
- OtherNetworksSupported, using separate executables
- built to run as daemon for days, weeks