Jörg Birkhold wrote: > thanks for the the quick answer. > i want to use the most current possible version....
If that means getting all code directly from source repositories rather than using frozen releases, then that mentality works well with PyOpenSG. ;) > hm for me is like i don't know much much about c++, compilers and all > that ;-) > i like python and we are about to evaluate 3d engines having python > bindings... PyOpenSG would fit the bill in that case, but there are some things to bear in mind. See below. > so are there maybe some binaries for win32 avaiable? Not that I know of. I haven't tried compiling the PyOpenSG bindings for OpenSG 2 on Windows, but I have heard that they do not compile out of the box. Apparently the main function that calls all the registration functions is too big for Visual C++ and has to be broken up into multiple files. Very weird stuff. > or is there a plan for creating some for the 2.0 release? I don't know, but I would have to think so. The maintainers would have to answer that. Of course, I don't know how close the OpenSG 2.0 release is, and using PyOpenSG at this point involves keeping track of the in-progress development of multiple projects: OpenSG, PyOpenSG, and Py++. There is also GCC-XML and pygccxml, though I do not know how frequently those change. No release of GCC-XML has been made in a long time, so everyone is forced to use the code from their CVS repository. As for Boost.Python, version 1.32 and 1.33.1 will work. It's no picnic I am afraid, but it can be done. Finally, PyOpenGL is needed to fill in the Python interface to low-level OpenGL bits. If you are not familiar with C++ and compilers, then you may find getting rolling with PyOpenSG to be a very challenging exercise. Basically, the Python interface presented by PyOpenSG is achieved by layering gobs of C++ code. -Patrick > Thanks > > Jörg > > > > Patrick Hartling schrieb: >> What version of OpenSG do you want to use with Python? PyOpenSG development >> is currently focused on OpenSG 2, though there are two branches in the >> Subversion repository for OpenSG 1.7/1.8. One of them, 0.1.0, is pretty old, >> but it worked the one time that I tried it about two weeks ago. The other, >> 1.7, did not compile on Windows when I tried it a few months ago. Running >> Py++ again for the 1.7 branch might generate that would be more portable, >> but I am not sure of that. Allen, the PyOpenSG maintainer, says that there >> is some flag that can be used to control output from GCC-XML so that >> non-portable namespaces (__gnu_cxx in this case) do not make their way into >> the generated code. That flag may yet need to be added to the script that >> generates the Python bindings for the 1.7 branch. >> >> -Patrick >> >> >> P.S. I do not know the significance of the Subversion branch names. My guess >> is that the 0.1.0 branch is supposed to designate a PyOpenSG version while >> the 1.7 branch is supposed to correspond to an OpenSG version. -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
