Hello Ventuzians!
THE FORUMS ARE CLOSED!
Please join our discord server HERE!! << click me
We are shutting our Ventuz Forum, but don't worry, it will all be archived for you to search in if you have a query. From now on, please add all your comments, questions or observations into our Discord Server
Thanks for the great time - see you on discord!!
Dee, Karol, Daniel and the whoooole Product and Support team!
THE FORUMS ARE CLOSED!
Please join our discord server HERE!! << click me
We are shutting our Ventuz Forum, but don't worry, it will all be archived for you to search in if you have a query. From now on, please add all your comments, questions or observations into our Discord Server
Thanks for the great time - see you on discord!!
Dee, Karol, Daniel and the whoooole Product and Support team!
Ventuz Scene Instance IDs - remoting
Moderator: Support
Ventuz Scene Instance IDs - remoting
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
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
Re: Ventuz Scene Instance IDs - remoting
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.
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.
Re: Ventuz Scene Instance IDs - remoting
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...????
Anyone...????
Re: Ventuz Scene Instance IDs - remoting
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
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
Re: Ventuz Scene Instance IDs - remoting
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.
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.
Re: Ventuz Scene Instance IDs - remoting
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
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
Re: Ventuz Scene Instance IDs - remoting
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 -
So as you said, I was connecting to a different instance of the scene. Two questions arise from this however -
Craig.
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 -
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?
Craig.
Re: Ventuz Scene Instance IDs - remoting
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
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
Re: Ventuz Scene Instance IDs - remoting
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.
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.