On Thu, 2011-07-14 at 10:38 -0700, ilikia wrote:
> Many thanks again Ali. But what about PythonScriptModule? Probably
> something analogous?

To make it compile, yes. 

To make it actually work for e.g. moving objects in the 3d scene, a bit
of porting is needed as 2.0 proposes a new math library, with new
vector, matrix and quat types. I took a look now and seems that porting
the existing Vector3dfDecorator etc. should be simple and
straightforward to get basics working first. For full support of all the
nice math utils in the bit longer run, making a bindings generator
(perhaps for that decorator technique) based on the one Jukka made for
the qtscript (js) is probably the way .. and might be really simple to
do.

The websocket server for WebNaali (the browser based client impl) is
written in py and supports moving objects, and is in active dev now and
targetting some sort of production (at least test) usage soon, so if we
go with this 2.0 proposal with the math lib etc. may do at least the
little porting and perhaps the full bindings generating after holidays
in August. If you wanna do it before, patches are welcome :)

BTW: do you think 2.0 brings some improvements that you actually need in
your CAVE project, or have you looked at it just out of curiosity?
There's of course no problem in continuing to use the existing 1.*
releases, and we can make little updates there too if necessary for a
while before 2 matures and everyone can switch over. I mean, in general,
that there is no rush for an app dev like you if 1 has what you need.
Sure is great you look and test, exactly so that we find out what's
missing perhaps.

(About websockets/WebNaali otherwise: I've been also thinking if the
browser client could just use the normal Tundra connections --
websockets is supposedly kind of normal TCP anyways, just with some
httpish handshake or so? So we could perhaps add websocket support to
knet itself. But that'd then bring the problem of dealing with the
binary encoded knet data. Using kripken's c++ -> js compiler might work
to translate knet to js to get to use the same code for handling the
data in browers, but am not sure if that'd work .. he did already
compile e.g. the much more complex bullet physics with it, and it runs:
http://emscripten.org . Anyhow if we'll look into that it's gonna be
later, the simple json messages from the py written server module we use
now with WebNaali is what's there'll be for now.)

~Toni

> On Jul 14, 5:16 pm, Ali Kämäräinen <[email protected]> wrote:
> > Apply the following changes in order to get CAVEStereoModule compilable and
> > in use again with Tundra 2.
> >
> > CMakeLists.txt:
> > Replace "init_target (CAVEStereoModule OUTPUT modules/core)" with
> > "init_target (EnvironmentModule OUTPUT plugins)"
> > Remove "CopyModuleXMLFile()"
> >
> > StereoController.h:
> > Remove #include "Foundation.h"
> > Add #include <QObject>
> >
> > StereoController.cpp
> > Add #include "LoggingFunctions.h"
> > Replace all CAVEStereoModule::LogWarning etc With LogWarning etc
> >
> > StableHeaders.h:
> > Remove #include "CoreStdIncludes.h"
> > Remove #include "Core.h"
> > Remove #include "Foundation.h"
> > Add #include "CoreDefines.h"
> >
> > CAVEStereoModule.h
> > Remove #include "ModuleLoggingFunctions.h"
> > Remove "namespace Foundation { class Framework; }" forward declaration
> > On line "class CAVESTEREO_MODULE_API CAVEStereoModule : public QObject,
> > public IModule remove "public QObject," as IModule already inherits QObject
> > Remove MODULE_LOGGING_FUNCTIONS;
> >
> > StereoWidget.h
> > Replace "namespace Foundation { class Framework; }" with " class Framework
> > Replace "Foundation::Framework" with Framework
> >
> > StereoWidget.cpp
> > Remove #include "ServiceManager.h"
> > Remove #include "UiServiceInterface.h"
> >
> > Replace "Foundation::Framework" with Framework
> >
> > ExternalRenderWindow.cpp
> > Add #include "CoreStringUtils.h"
> >
> > CAVEView.cpp
> > Add #include "OgreWorld.h"
> > Replace all "renderer_.lock()->GetSceneManager()" with
> > "renderer_.lock()->GetActiveOgreWorld()->GetSceneManager()"
> > Replace all "renderer_.lock()->GetCurrentCamera()" with
> > "renderer_.lock()->GetActiveOgreCamera();
> >
> > CAVEStereoModule.cpp
> > Replace
> > "framework_->GetModuleManager()->GetModule<OgreRenderer::OgreRenderingModul 
> > e>().lock().get();"
> > with "framework_->GetModule<OgreRenderer::OgreRenderingModule>();"
> > Add #include "Profiler.h"
> > Remove
> > "
> > extern "C" void POCO_LIBRARY_API SetProfiler(Foundation::Profiler
> > *profiler);
> > void SetProfiler(Foundation::Profiler *profiler)
> > {
> > Foundation::ProfilerSection::SetProfiler(profiler);
> >
> > }
> >
> > using namespace CAVEStereo;
> >
> > POCO_BEGIN_MANIFEST(IModule)
> > POCO_EXPORT_CLASS(CAVEStereoModule)
> > POCO_END_MANIFEST
> > "
> > and replace with
> > "
> > extern "C"
> > {
> > DLLEXPORT void TundraPluginMain(Framework *fw)
> > {
> >    Framework::SetInstance(fw); // Inside this DLL, remember the pointer to
> > the global framework object.
> >    IModule *module = new CAVEStereo::CAVEStereoModule();
> >    fw->RegisterModule(module);}
> > }
> >
> > "
> >
> > CAVESettingsWidget.h
> > Replace "namespace Foundation { class Framework; }" with "class Framework;"
> > Replace "Foundation::Framework" with "Framework"
> >
> > CAVESettingsWidget.cpp
> > Remove #include "ModuleManager.h"
> > Remove #include "ServiceManager.h"
> > Remove #include "UiServiceInterface.h"
> > Replace "Foundation::Framework" with "Framework"
> >
> > MenuBar.js
> > Add to appropriate spot:
> > "
> > // Settings
> > var settingsMenu = menu.addMenu("&Settings");
> > if (framework.GetModuleByName("CAVEStereo"))
> > {
> >    var caveSettings = settingsMenu.addAction("&Settings", "Cave");
> >    caveSettings.triggered.connect(OpenCaveWindow);
> >    var stereoSettings = settingsMenu.addAction("&Settings", "Stereoscopy");
> >    stereoSettings.triggered.connect(OpenStereoscopyWindow);}
> >
> > "
> > The OpenCaveWindow and OpenStereoscopyWindow ftunctions should be already
> > there.
> >
> > Finally add CAVEStereoModule to bin/plugins.xml after OgreRenderingModule,
> > or you can also create your own plugins XML file if you want. Remember to
> > use it when starting Tundra, e.g. "Tundra --config MyConfig.xml".
> > plugins.xml is used by default if --config is not used.
> >
> > Grey skies,
> > Ali Kämäräinen
> 


-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Reply via email to