vsg plugin framework

[kannode]

@robertosfield Is there a plugin framework that VSG uses similar to the robust one in OpenSceneGraph? If so, where is a good start within the codebase.

Suresh.

[robertosfield]

I decided not to implement a dynamic plugin scheme like the OSG has for the VSG, while very flexible the OSG plugin system caused lots of support headaches over the years.

The VSG is designed to more compiled as static library from the outset rather than as shared library like the OSG. I did this to make it easier to distribute executables and to keep the memory overhead low for embedded platforms. This decision in turn leads to the VSG's equivalent to osgDB to build loaders statically as part of the vsgXchange library,

None of this preclude the VSG being compiled as a shared library, you can do this with by just setting the standard CMake BUILD_SHARED_LIBS option.

The VSG is still extensible, and is more convenient to than the OSG as you can subclass your own nodes etc, and locally implement serialization directly in the subclass by overloading the read/write methods. You can also write your own vsg::ReaderWriters and assign then to the vsg::Options object you pass in when call vsg::read(..) and vsg::write(...) to tell the loader you want to use a specific reader/writer.

This ability to define which ReaderWriters you want to use, and the order in which they should be tried is much more flexible than the OSG's osgDB::Registry singleton that assigns them in the order that the plugins are loaded.

To see how vsg::Options is used have a look through the vsgExamples, for instance the vsgviewer example illustrates how the vsg::Options is set up to guide how to read/write data, with #ifdef block that adds the ReaderWriter's provide by vsgXchange.

https://github.com/vsg-dev/vsgExamples/blob/master/examples/app/vsgviewer/vsgviewer.cpp#L177

If you are looking for examples that extend the scene graph then the vsgImGui and vsgPoints libraries extend the scene graph, with the later implement serialization.

[kannode]

Good decision. Static is preferred for us as well. Your reasoning helps make our decision as well. Sincerely, Suresh. Sent from a mobile device for quick responses. Please excuse succinctness.

…

On Jan 6, 2023, at 2:15 PM, Robert Osfield ***@***.***> wrote:  I decided not to implement a dynamic plugin scheme like the OSG has for the VSG, while very flexible the OSG plugin system caused lots of support headaches over the years. The VSG is designed to more compiled as static library from the outset rather than as shared library like the OSG. I did this to make it easier to distribute executables and to keep the memory overhead low for embedded platforms. This decision in turn leads to the VSG's equivalent to osgDB to build loaders statically as part of the vsgXchange library, None of this preclude the VSG being compiled as a shared library, you can do this with by just setting the standard CMake BUILD_SHARED_LIBS option. The VSG is still extensible, and is more convenient to than the OSG as you can subclass your own nodes etc, and locally implement serialization directly in the subclass by overloading the read/write methods. You can also write your own vsg::ReaderWriters and assign then to the vsg::Options object you pass in when call vsg::read(..) and vsg::write(...) to tell the loader you want to use a specific reader/writer. This ability to define which ReaderWriters you want to use, and the order in which they should be tried is much more flexible than the OSG's osgDB::Registry singleton that assigns them in the order that the plugins are loaded. To see how vsg::Options is used have a look through the vsgExamples, for instance the vsgviewer example illustrates how the vsg::Options is set up to guide how to read/write data, with #ifdef block that adds the ReaderWriter's provide by vsgXchange. https://github.com/vsg-dev/vsgExamples/blob/master/examples/app/vsgviewer/vsgviewer.cpp#L177 If you are looking for examples that extend the scene graph then the vsgImGui and vsgPoints libraries extend the scene graph, with the later implement serialization. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[rolandhill]

Hi Robert, You've mentioned vsgPoints a few times and I went looking for it last week. I can't find it. Also the link you provide goes to a page not found message. Could it be that vsgPoints hasn't been made public? Regards, Roland

…

On Sat, 7 Jan 2023 at 06:15, Robert Osfield ***@***.***> wrote: I decided not to implement a dynamic plugin scheme like the OSG has for the VSG, while very flexible the OSG plugin system caused lots of support headaches over the years. The VSG is designed to more compiled as static library from the outset rather than as shared library like the OSG. I did this to make it easier to distribute executables and to keep the memory overhead low for embedded platforms. This decision in turn leads to the VSG's equivalent to osgDB to build loaders statically as part of the vsgXchange <https://github.com/vsg-dev/vsgXchange> library, None of this preclude the VSG being compiled as a shared library, you can do this with by just setting the standard CMake BUILD_SHARED_LIBS option. The VSG is still extensible, and is more convenient to than the OSG as you can subclass your own nodes etc, and locally implement serialization directly in the subclass by overloading the read/write methods. You can also write your own vsg::ReaderWriters and assign then to the vsg::Options object you pass in when call vsg::read(..) and vsg::write(...) to tell the loader you want to use a specific reader/writer. This ability to define which ReaderWriters you want to use, and the order in which they should be tried is much more flexible than the OSG's osgDB::Registry singleton that assigns them in the order that the plugins are loaded. To see how vsg::Options is used have a look through the vsgExamples, for instance the vsgviewer example illustrates how the vsg::Options is set up to guide how to read/write data, with #ifdef block that adds the ReaderWriter's provide by vsgXchange. https://github.com/vsg-dev/vsgExamples/blob/master/examples/app/vsgviewer/vsgviewer.cpp#L177 If you are looking for examples that extend the scene graph then the vsgImGui <https://github.com/vsg-dev/vsgImGyu> and vsgPoints <https://github.com/vsg-dev/vsgPoints> libraries extend the scene graph, with the later implement serialization. — Reply to this email directly, view it on GitHub <#682 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPOEQYBEVSICKDNG4HPVGLWRBVLNANCNFSM6AAAAAATTKCZ6A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** .com>

[vsg-dev]

I have just checked and vsgPoints is public and the link takes me directly to it. Could you try the link again?

[kannode]

Its public for me. https://github.com/robertosfield/vsgPoints

…

On Sat, Jan 7, 2023 at 5:36 AM Vulkan made easy ***@***.***> wrote: I have just checked and vsgPoints is public and the link takes me directly to it. Could you try the link again? — Reply to this email directly, view it on GitHub <#682 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWFHINEFEPOVVSXOJGPANDWRFBKXANCNFSM6AAAAAATTKCZ6A> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

-- S <https://www.nodein.com/>uresh K. Kannan, Ph.D., Chief Scientist, Nodein https://www.nodein.com

[rolandhill]

Figured it out. The link goes to https://github.com/vsg-dev/vsgPoints, but it should be https://github.com/robertosfield/vsgPoints.

[robertosfield]

Which link, the one on this thread points to the correct one.

[rolandhill]

The one in this thread was edited to be correct. I clicked on the original version in the notification email prior to the edit, which pointed to vsg-dev/vsgPoints. All good, just a version problem.