search

realXtend / tundra

realXtend Tundra SDK, a 3D virtual world application platform.
www.realxtend.org
Apache License 2.0
84 stars 70 forks source link

Python support in Tundra is rotten #652

Closed Stinkfist0 closed 11 years ago

Stinkfist0 commented 11 years ago

If Python want to be a first-class citizen in Tundra, a Python(Qt) script binding tool must be implemented and used for exposing f.ex. all of the MathGeoLib and many Tundra classes to Python.

I would suggest that we either drop Python for good, or move it away from core Tundra repository.

antont commented 11 years ago

even as a second class citizen it is now useful in some cases, and used daily ..current manual math exposing suffices for e.g. the render image server to move & rotate camera etc (we have a demo server online with it), and at least one guy at chiru seems to still dev quite sophisticated avatar navmesh etc. using code using py.

it is convenient that it is on by default on ubuntu, the console is often useful when exploring the API etc, so is consequently convenient that it is in the central repo .. but if it is a problem somehow perhaps we can figure out a nice for it to live in a different repo

cadaver commented 11 years ago

The primary problem to me, which would support moving PythonScriptModule to a separate app repo once that's up, is that it is not enabled in all platforms' builds, so it will not get continuous testing.

(when testing on Ubuntu, I get a segfault from PythonScriptModule on startup but that's another story..)

jonnenauha commented 11 years ago

There are no maintainers for the windows deps build path unfortunately. We here at Admino don't see much value in our production/end user use for PythonScriptModule. I did port it to tundra2 and did tweaks to it even after that, just so that its kept on the loop. Without those it would not run anywhere today. But I don't want to bother with automating the windows path as we are not using it for anything.

Someone needs to step up or it stays like it is, a toy for certain linux guys who know how to set it up :) But if thats the case maybe we could remove it from the core repo all together.

antont commented 11 years ago

yes i agree with cadaver that the main issue is lack of platform support in the build scripts, and therefore lack of testing and indeed rotting. i suppose that's also the cause of the current segfault, i haven't tested with recent versions -- what we have running is a few months old branch, the server that's doing server side rendering for this panorama viewer test setup, http://studio.kyperjokki.fi:8880/tundra/worldpanoramaview.html (the client is in the WorldWebView repo and the readme there has the info about the Tundra branch used as the server)

besides such server use, my upcoming use cases are specific installations -- e.g. the big touch wall, where touch works so that each tile in the wall is actually a pc doing machine vision and they send touch events over UDP, and for that i have a little udp - osc - tuio receiver, https://github.com/antont/tuioinput). so actually also in this case there would be a custom net server running inside tundra. now i do it via mouse emulation in a standalone py app, but the nice thing is that can use exactly same networking code both with and without tundra, when the net code is in py.

i don't foresee a need for windows builds e.g. for the wall and similar (caves etc) installations so don't think that track of work at the uni will take up updating the windows scripts to build the pythonqt dep etc.

like Jonne, I also don't see it useful for typical meshmoon client usage where folks just use tundra like a browser and work on scenes, not custom server plugins or some system integration.

so i suppose it is good to move outside for now at least, hopefully can be still made so that is very easy to include in a Tundra build.

erno commented 11 years ago

The killer app for the Python module has been easy interfacing to the outside world. Maybe in the future there could be another mechanism that would serve that need in a simpler and more direct way. For example a JSON-based (JSON-RPC?) protocol that would let other programs talk to the Tundra JS API without imposing a big maintainance burden when the Tundra APIs changes. Or at least invoke actions and listen to some events...

peterclemenko commented 11 years ago

Python 3 support would be worthwhile. Blender uses Python 3, and while linking to the actual Blender libraries would cause license issues, my understanding is that the GPL's viral nature does not apply to scripts. It might be possible to use Python 3 to allow for better interop with Blender (although I would suggest talking to the Blender guys before doing it).

Stinkfist0 commented 11 years ago

Closing and migrating this issue to https://github.com/realXtend/TundraAddons/issues/6