Ventuz Scene Instance IDs - remoting

[craig]

Hi all,

Kinetic Pixel are finally moving ahead with our migration to Ventuz 5, and we've ported our old Remoting libraries with some success so far. One thing that's confusing me though - When running a scene in designer, the IID I get back from Remoting in the FlaggedIID object is different to the one I see in the tooltip when hovering over the loaded scene in Designer.

Is there any significance to this?

Thanks,
Craig

[craig]

To follow up - I think there's something I'm not quite getting about the scene lifecycle.

When I test my cluster to see if it's in Designer, I assume I have to attach to a running scene.
(Me.VCluster.VentuzInfo.Value.Mode = MachineMode.Designer)

I can enumerate the loaded scenes by calling Cluster.Scenes with no IID.

What do I do from there? If I try and Validate the IIDs in the Scenes enumeration I just get an error "Validation Failed".

All suggestions gratefully received!

Craig.

[craig]

I'd really appreciate some advice from the community on how the relationship between scenes and the IIDs work - there's nothing in the help files.

Anyone...????

[Karol]

Hi Craig!

I have no idea how this can happen that you see different Scene IIDs. The only explanation I have is that you compare a scene loaded with Designer with different instance of the scene loaded via remoting.
Did you take look at the Remoting 4 demo here: http://forum.ventuz.com/viewtopic.php?f=14&t=3407#p7427
You will find 4 remoting clients with increasing complexity.

Best Regards
Karol

[craig]

Hi Karol,

Thanks for the reply. I'm seeing the same behaviour running the Remoting4 Demo 1 application too - see screen grabs below. Again, I can close the scene in the designer, and still the renderer shows the loaded scene and I can still control it.

I'm running Ventuz 5 Designer and Visual Studio on the same machine, if that's relevant.

Regards,
Craig.

[Karol]

Hi Craig!

As I already said: your are comparing a scene loaded via Remoting with a scene loaded with Designer! These are two different scene instances!!!

The Demo works as follows:
- open Designer
- do NOT load any scene with File->Open
- start Demo and Press Connect & Load buttons until the scene appears in the Render Window
- open the Scene Tree to see which scene are loaded and which IIDs they have

Best Regards
Karol

[craig]

Hi Karol,

OK - the Scene Tree is something we've not had to use before. This is all making a little more sense. I can see by stepping through my code that loading/validating the named scene creates it in the scene tree, but does not map it to a port. Activating the scene does that, and if I follow your pattern below then I DO end up connecting to the same scene instance as the one in designer. Looking at the scene tree, I was ending up with this situation -

scenetree.PNG (5.8 KiB) Viewed 5523 times

So as you said, I was connecting to a different instance of the scene. Two questions arise from this however -

• This changes our workflow considerably when building a project. My programmers work between Visual Studio and Ventuz, and often they'll open Ventuz, load the scene, then start debugging in visual studio. Is there a way of detecting the loaded scenes, and allocating the one that's already loaded to the remoting port?

• At runtime, we used to put the scene name in a shortcut, as our deployment process in studio normally meant starting the ventuz instance, then starting our control software. Is the best practice to use the VMS to find our machines, and load the correct project/scene onto the machines over remoting instead?

Thanks,
Craig.

[Karol]

Hi Craig!

You definitely need to go through the Remoting Demos; especially Demo 2 & 4!
There you will find how to determine the status of a scene (or according IID) -> search for R4Helper.IIDItem class!
This will solve both of your problems.

I have to admit that the Remoting 4 API is a low-level API. We actually planned to provide a higher-lever wrapper to make things easier for developer...
But we unfortunately did not made it yet

Cheers
Karol

[craig]

Hi Karol,

I'll look at those two examples in detail as soon as I can.

Regarding the API - A higher level wrapper would lower the barrier to entry for Ventuz I think. I'm happy working with a lower-level API, but where I feel there is definitely room for improvement is in the provision of more comprehensive sample code (especially working with scene ports/multiple sub-scenes), and better documentation. The current documentation is really just an API reference - some sample use-cases and case studies would be very valuable to the Ventuz community as a whole, I think.

Thanks again for your assistance today, I greatly appreciate it!

Regards,
Craig.