AppGrabber plugin can't be compitable with AppPanorama plugin

[htdeveloper]

We want to recorder the video from app, with panorama  fisheye mode. so we choose to use AppPanorama plugin and AppGrabber plugin together.

In shell commands,   we choose to use  "-extern_plugin AppPanorama, AppGrabber" or   "-extern_plugin AppGrabber,AppPanorama" ,  but the result show that only one plugin can take effect.

 

In the log file, we get  the information about  "AppGrabberPlugin::AppGrabberPlugin(): App is not NULL"     or  "AppPanoramaPlugin::AppPanoramaPlugin():  App is not Null". 

The detail info can be seen at attachment files.

111.bmp

11.bmp

[esger.abbink_]

see also this thread:

 

https://developer.unigine.com/forum/topic/2608-solved-combining-stereo-with-fisheye-and-appwall-pluginsis-it-going-to-be-possible-at-any-point/

 

 

The reason you can't combine those plugins is they all implement a derived Unigine::App that replaces the default unigine "app", and there can be only one "app".

 

If you want to combine them you have to reimplement (copy) their functionality. Either in a non Unigine::App derived class that is then hooked differently into the rendering, or by putting everything into a single class that derives from Unigine::App.

 

We had the same problem with our AppWidget based on GLAppQt and AppProjection and made a projection class that is not Unigine::App derived which is controlled by the AppWidget.

 

(Would be nice if Unigine would transform (many of) those plugins into something else than an 'App'. Really not much reason for most of them to be an App, especially with the 'there can be only one App' restriction. While there are probably lots of use-cases where combining plugins would be desired)

[unclebob]

Hi there!

 

There are two solutions:

 

1) Create separate C++ plugin and use our TextureRender class in order to get current framebuffer and save it to file or video;

2) Use editor plugin called "video grabber" to grab video in edit time (could be useful for fly-through via tracker).

[esger.abbink_]

any development/movement around plugins planned? Both your solutions are either a lot of work, or possibly not really fitting, to duplicate (the combination of) two functionalities Unigine already has. It just can't do both at the same time for an imho not so good reason.

 

Where I can imagine some plugins would be difficult to combine some others should (conceptually) not interfere at all. The 'there can be only one App' restriction effectively resulting in 'there can be only one Plugin' can be very annoying and feels artificial. I can see how it eases introduction of a new feature (being able to disregard certain existing features), but at the same time it can severely limit the practical application of said features. If the hard work is in the integration of having multiple features work concurrently this burden is now being moved to the end-users, meaning duplication of effort and harder maintenance when updating.

 

To be clear, if this would concern items that would classify mainly as tech examples such an approach would be fine and justifiable. However, many (of the capabilities) of these plugins are presented as Unigine features. The use of a single feature should (imho) not exclude the use of 10 other more or less unrelated features.

 

Other customer experiences may be different but this is something we've experienced also in other areas of Unigine. The feature list is great, at first glance you seem to get a running start, but if you really want to use something in a practical setting it falls short and you have to do it yourself/otherwise anyway. (warping and syncker come to mind here for instance)

 

Not regretting moving to Unigine though ;) it contains lots of quality and useful stuff, just that sometimes a little bit more focus on the practical applicability of certain features might be good.