2.19: How to start with multiple windows on a single instance?

[Amerio.Stephane]

Hi,

As things have changed in 2.19 with SpiderVision, I wonder what is now the correct way for this scenario:

• on a single PC, with a single application instance, create 2 separate windows, each assigned to a specific CIGI view ID

I guess SpiderVision will take care of the windows size and position, but how do I correctly create & assign at startup the different IG windows?

Thanks

[silent]

Hi Stephane,

Right now you can do it only via SpiderVision API, by calling setViewportCustomPlayer() method and passing CIGI view camera to it:

int AppWorldLogic::update()
{
	auto setup_view = [](int index) {
		auto ig = Plugins::IG::Manager::get();
		auto sv = Plugins::SpiderVision::Manager::get();
		auto config = sv->getConfig();
	
		Unigine::Vector<Plugins::IG::View *> views;
		ig->getViews(views);
	
		if (views.size() > index && config->getNumViewports() > index)
		{
			auto viewport = config->getViewportByIndex(index);
			auto view = views[index];
	
			sv->setViewportCustomPlayer(viewport->getID(), view->getPlayer());
		}
	};

	setup_view(0);
	setup_view(1);

	return 1;
}

Thanks!

AppWorldLogic_IG_SV.cpp

[Amerio.Stephane]

Hi, this method works (meaning, the view point is the correct one) but there are some drawbacks/questions. 

• ig->getCurrentView() : this method clearly is no longer suited when using multiple viewport
• WindowManager: there is no way to find the viewport associated with a window
  • I'd like to change each window title to dynamically show the corresponding view ID (as we need to dynamically change view ID on some viewport)
• sv->setViewportCustomPlayer: this changes the player for the viewport, but there is no way to figure out afterward what view is actually associated with each viewport (apart from storing the info ourselves, of course)
• some API naming convention are inconsistent, and could lead to a confusion and bugs when mixing ID with Index (config->getViewportByIndex, ..)
• are viewport ID and viewport Index the same thing?

On a related topic: a view type allows to specify a post-process material, which is great, but can be lacking for some specific requirement, like a specific view type cloud visualization, or specific sky color, or specific water color). In a slaves configuration, this can be done per slave, but how could we still do it in a multiple viewports setup?

[silent]

Hi Stephane,

There are indeed some drawbacks when you are using manual viewport control via code. Please find some clarifications below:

Quote

ig->getCurrentView() : this method clearly is no longer suited when using multiple viewport

Yes, this method is no longer suitable. The current view refers to the camera from which the image is rendered into the window. However, if we have multiple windows and specify the cameras for rendering into each one, the current view becomes unnecessary.

 

Quote

WindowManager: there is no way to find the viewport associated with a window
I'd like to change each window title to dynamically show the corresponding view ID (as we need to dynamically change view ID on some viewport)

You can set a title for the window when setting up the camera. For example:

auto setup_view = [](int index) {
    auto ig = Plugins::IG::Manager::get();
    auto sv = Plugins::SpiderVision::Manager::get();
    auto config = sv->getConfig();

    Unigine::Vector<Plugins::IG::View *> views;
    ig->getViews(views);

    if (views.size() > index && config->getNumViewports() > index)
    {
        auto viewport = config->getViewportByIndex(index);
        auto view = views[index];

        sv->setViewportCustomPlayer(viewport->getID(), view->getPlayer());
        auto window = sv->getEngineWindow(viewport->getID());
        if (window)
            window->setTitle("your_title");
    }
};

 

Quote

sv->setViewportCustomPlayer: this changes the player for the viewport, but there is no way to figure out afterward what view is actually associated with each viewport (apart from storing the info ourselves, of course)

Yes, that's correct; you need to manage the information regarding which view is currently associated with the window on your own.

 

Quote

some API naming convention are inconsistent, and could lead to a confusion and bugs when mixing ID with Index (config->getViewportByIndex, ..)
are viewport ID and viewport Index the same thing?

No, the viewport ID and the index are not the same thing. Method getViewportByIndex(int index) is basically returning viewports[viewports.keys()[index]];
Where viewports are Unigine::HashMap<int, ViewportData *>. This is helpful when you don't know IDs of viewport, you can just iterate through all IDs.

for(int i = 0; i < config->getNumViewports(); ++i)
{
    auto viewport = config->getViewportByIndex(i);
    // ... some actions with viewport
}

We will update the documentation on this method soon. Maybe we would come up later with a different solution to obtain Vector (just to make things a bit easier to understand).

 

Quote

On a related topic: a view type allows to specify a post-process material, which is great, but can be lacking for some specific requirement, like a specific view type cloud visualization, or specific sky color, or specific water color). In a slaves configuration, this can be done per slave, but how could we still do it in a multiple viewports setup?

You can apply post-processing materials for each player using the API method addScriptableMaterial().

Thanks!

[Amerio.Stephane]

21 hours ago, silent said:

You can apply post-processing materials for each player using the API method addScriptableMaterial().

Indeed, but I was referring to the fact that a sensor may need much more than just a post-process. For example, in IR sensor cases, we have to change the sky color, the water color, change clouds opacity, change depth of field, and add a dirt mask on the sensor lens. 

This is why I thought a view should have a "render preset", and not just a post-process, but in the meantime, maybe a callback (pre-post-)render for each view would be enough for us to do the required adjustments per viewport? (granted, I'm digressing from the original question here...)

[silent]

Yes, so far only per-viewport callbacks are capable of doing what you need (I thought that you already used them in your project, btw).