Exposing objects managed by another object

tdappertdapper Posts: 3
edited April 4 in Extensions

Hi there,

we are working on exposing an API to Fabric. A pretty central part of the API has a structure where there is a hierarchy of objects that store and manage potentially multiple instances of other classes. Think of it as a hierarchy like this:

Polygon (stores polygons)
Object (stores a bunch of polygons)
Material (stores a material)
Scene (stores a bunch of objects and a bunch of materials)

Now I want to expose the objects contained in the scene, but do not want to make a full copy of every object each time I grab one from the scene. At the same time, we want to allow objects to also be standalone without being embedded in a scene (or for later addition - in which case a copy would be in order). I am a little lost on how to implement this for a KL extension.

It seems like this section kinda covers it partly: http://docs.fabric-engine.com/FabricEngine/2.4.0/HTML/ExtensionAuthoringGuide/cPlusPlusApis.html#managing-data-ownership-and-bidirectional-relationships

However, the above example seems to apply to the second situation I mentioned. The more common one is to try and access the Object obtained from a scene. To make sure the scene does not get discarded, the Object keeps a reference to the scene around. The relevant KL code kinda looks like this (I removed implementation details for clarity):

object Scene {
    private Data pointer;
};

object Object {
    private Data pointer;
    private Scene scene;
};

function Object Scene.getDefaultObject?() = "Scene_getDefaultObject";

The implementation of Scene_getDefaultObject() in C++ looks like this:

FABRIC_EXT_EXPORT void Scene_getDefaultObject(
    Fabric::EDK::KL::Traits< Fabric::EDK::KL::Object >::Result _result,
    Fabric::EDK::KL::Traits< Fabric::EDK::KL::Scene >::INParam this_
) {
    if (this_->pointer) {
        lbw::Scene *scene = static_cast<lbw::Scene*>(this_->pointer);
        _result->pointer = &(scene->objects[scene->m_iDefaultObject]);
    }
}

This was working in an earlier version of Fabric, but we can't get it to work with the current 2.4. It crashes with a pointer exception as soon as we try to access properties in any Object returned from Scene_getDefaultObject().

Any idea where I might've made a wrong turn? And just in case, I am using Visual Studio 2015 to build the Extension (both, the old one that worked, as well as the one that stopped working).

Best
Timm

Comments

  • HelgeHelge Moderator, Fabric Employee Posts: 278 Fabric Employee

    Hey Timm,

    2.5 which is due in a short time from now comes with a completely new wrapping tool called kludge. Given you have a C/C++ API kludge can be used to automatically wrap this API for KL. At that point the laziness and conversion upon access is then down to you implementation.

    The kludge tool is already available in the daily builds - documented and comes with a bunch of examples in our trainingmaterial repo.

    I hope this helps!

    Research Engineer @ Fabric Software

  • tdappertdapper Posts: 3

    Hi Helge,

    you mentioned clutch before, but it seemed that our common judgement was that is wasn't well suited for our library, because our SDK is very much a work in progress and it would make sense to have right control about what was exposed and how. Did Kludge become more customizable in that regard?

    Best
    Timm

  • HelgeHelge Moderator, Fabric Employee Posts: 278 Fabric Employee
    edited April 5

    Well - as mentioned - you need a C/C++ API for this to work. I am not sure what you mean. The right approach here is: Write an API for your software... wrap the API.

    Best,

    Helge

    Research Engineer @ Fabric Software

  • tdappertdapper Posts: 3

    Hi Helge,

    I know the approach. Like I mentioned, we had an API wrapping already, that we created together with you last year. We do have a C++ API, it's just in a somewhat unorderly state, so we together (you included) came to the conclusion that Kludge is not currently the correct tool for the job. Now I'm just trying to revive what we did back then (to extend it).

    I know you're busy and I don't need every button pressed for me, but I am trying to make sure to make no conceptual error.

    Best
    Timm

  • HelgeHelge Moderator, Fabric Employee Posts: 278 Fabric Employee

    I see - thanks for understanding. You can use that intermediate layer C++ api. Kludge works by specifying which headers to wrap. So you should be fine.

    Research Engineer @ Fabric Software

Sign In or Register to comment.