Stream: brlcad

Topic: coreInterface

Sadeep Darshana (Jun 10 2020 at 20:10):

Is there an easy way to obtain this to a list?

        std::vector<BRLCAD::VectorList::Element> list;
        VectorList vl;
        db->Plot(objectName.c_str(), vl);

        class Callback : public BRLCAD::VectorList::ElementCallback {
            bool operator()(BRLCAD::VectorList::Element *element) {
                list.push_back(*element);
                return true;
            }
        };

        Callback b;
        vl.Iterate(b);

I need to get the elements in a VectorList to a list (vector) @Daniel Rossberg

Sadeep Darshana (Jun 11 2020 at 05:41):

Apparently I can't get them to a list even if use globally available lists.
Since *element is stack allocated it will have been destroyed if I just add element (pointer) to a list (vector<Element*>) by the time I actually access it.
Also I cannot copy it and create a new object since Element is an abstract class. Can somebody help me with this?

Daniel Rossberg (Jun 11 2020 at 15:45):

It is possible to create a list of copies from the elements, but I decided no not explicitly support it (e.g. by providing a Clone() method), because this is not how this list should be used. It would slow down the process. Instead, you should move the corresponding drawing functions to a call-back class:

class ElementOpenGL : public BRLCAD::VectorList::ConstElementCallback {
public:
    virtual bool operator()(const Element* element) {
        switch (element->Type()) {
        case BRLCAD::VectorList::Element::PointDraw:
            BRLCAD::VectorList::PointDraw* pointDraw = static_cast<BRLCAD::VectorList::PointDraw*>(element);
            // put your OpenGL code here
            break;

        case BRLCAD::VectorList::Element::PointSize:
             BRLCAD::VectorList::PointSize* pointSize = static_cast<BRLCAD::VectorList::PointSize*>(element);
            // put your OpenGL code here
            break;
        // ...
       }
    }
};

void DrawVectorList(const VectorList& vectorList) {
    ElementOpenGL elementOpenGL;
    vectorList.Iterate(elementOpenGL);
}

This code demonstrates the principle only. It doesn't contain all necessary methods, checks, etc..

Sadeep Darshana (Jun 26 2020 at 19:25):

Any future plans to bring coreinterface to the main repo? What if I want to access coreinterfaces from there? My current plan is to rewrite stuff not to include things from coreinterfaces. Alternatively do we plan to bring it there?

starseeker (Jun 26 2020 at 19:26):

We're actually planning to migrate the main repository to github - once we do that, we may do something like include coreInterface as a submodule - not decided yet.

Sean (Jun 26 2020 at 19:27):

@Sadeep Darshana By keeping it separate, the MOOSE API cannot not become tangled with the low-level C API. That's entirely intentional and helps keep the implementation clean.

Sean (Jun 26 2020 at 19:27):

It does complicate some things, but for now it's worth it.

Sumagna Das (Jun 26 2020 at 19:28):

starseeker said:

We're actually planning to migrate the main repository to github - once we do that, we may do something like include coreInterface as a submodule - not decided yet.

you might keep it as a seperate branch actually

Sean (Jun 26 2020 at 19:29):

It's also pure C++, and while we do allow C++ in the low-level library implementation (i.e., not in public headers), they are nowhere close to being good C++ designwise even on the backend.

Sean (Jun 26 2020 at 19:30):

starseeker said:

We're actually planning to migrate the main repository to github - once we do that, we may do something like include coreInterface as a submodule - not decided yet.

Possibly the other way around since it's layered on top. It's more like some of the BRL-CAD libs are proper 3rd party dependencies.

Sean (Jun 26 2020 at 19:31):

Where it gets complicated is wanting to use MOOSE in utilities and new commands, as they can't live in the main repo, but that's the tradeoff for now.

starseeker (Jun 26 2020 at 19:35):

Once the main build is shifted to the superbuild pattern, we can actually start making pieces of BRL-CAD into "proper" projects that are built as part of the parent build. Once we do that, coreInteface could do the same thing and reference those subprojects.

Daniel Rossberg (Jun 30 2020 at 17:51):

Sadeep Darshana said:

Any future plans to bring coreinterface to the main repo?

The MOOSE is designed to be entirely on top of the BRL-CAD core libraries. There is no need to move it to the main (or more precisely core) repository. Vice versa, MOOSE classes should not be used in the core libraries.

Sean (Jul 01 2020 at 07:16):

Not to be confused with the core interface ;)

Daniel Rossberg (Jul 01 2020 at 17:52):

MOOSE demonstrates how I think the interface should be constructed on top of the classical BRL-CAD libraries. The functionality is the same as the one of rt^3's coreInterface, but if you talk about integration and software architecture, the development direction is more MOOSE than coreIntterface.

Sean (Jul 01 2020 at 18:13):

What do you see as the biggest architecture and integration difference between coreInterface and MOOSE?? I kind of viewed them as "the same", just with MOOSE now slightly more cleaned up and evolved but architecturally the same. Both present a canonical OO API over the low-level libs. Are there major implementation differences?

Sadeep Darshana (Jul 01 2020 at 19:37):

What does MOOSE mean? Do the letters stand for words?

Sean (Jul 01 2020 at 19:38):

It's fluctuated, but this is what has stuck with me:
Modular Object-Oriented Solidity Engine

Sean (Jul 01 2020 at 19:40):

It's also a play on words homage as it's how you pronounce the last name of the person that started BRL-CAD, Mike Muuss.

Sean (Jul 01 2020 at 19:40):

Ubject-Uriented doesn't quite work, though ;)

Sadeep Darshana (Jul 01 2020 at 19:41):

noticed his name in dedication

Sean (Jul 01 2020 at 19:42):

brilliant scientist, huge personality, super friendly, got me latched onto the project young :)

Sadeep Darshana (Jul 01 2020 at 19:45):

I also encountered his name when for some reason I was looking at ping command

Sadeep Darshana (Jul 01 2020 at 19:45):

Was the same person when I looked back at the dedication

Daniel Rossberg (Jul 02 2020 at 09:55):

The API of MOOSE and coreInterface are essentially the same. The difference is how they are build, how their libraries depend on the BRL-CAD installation.

The brlcad.dll for Windows is a hack in the main repository. I tried to to extend it to build a library for Linux too, but without success. I.e., I succeeded to build a shared library, but it still depends on the BRL-CAD installation. The standard build in rt^3 depends on the BRL-CAD installation too.

The problem with the BRL-CAD installation is that a program from for example Debian doesn't has it. And, without being available in the big distributions, the number of users is very limited.

Therefore MOOSE demonstrates an approach and architecture to overcome this. Without affecting the standard BRL-CAD repository and build, it generates a single self-consistent library (i.e., it depends only on some libraries contained in every big Linux distribution) which can go into a libbrlcad package, defines a SDK which can go into a libbrlcad-dev package, and there is an example for an application using these too.

Therefore, the difference is not in the features of the API, but the integration with the other software.

Sean (Jul 02 2020 at 22:01):

Ah, I took your earlier comment to mean that the APIs were different, hence a little surprise.

For what it's worth, cmake now finally does provide a sublibrary mechanism that would make a libbrlcad possible without recompilation so it could once again simply be the union of its sublibs.

Sean (Jul 02 2020 at 22:03):

I mean, to be clear, MOOSE also requires a build of BRL-CAD, it just presumably doesn't need to be installed since it's linking in all the libs statically. It's the result that is standalone because of the static linkage.

Daniel Rossberg (Jul 03 2020 at 13:26):

BTW, there are minor differences in the C++ APIs:

• MOOSE has the Database module directory
• coreInterface must not use C++11 or above features (I'm still using it with VS2008)

Sadeep Darshana (Jul 18 2020 at 18:27):

@Daniel Rossberg Any chance I can get a permanent Object* instead of void Database::Get ( const char* objectName, ObjectCallback& callback)?

Sadeep Darshana (Jul 18 2020 at 18:28):

Because this is very slow when editing properties

Sadeep Darshana (Jul 18 2020 at 18:30):

Think about dragging an object with mouse, I have to call Get (which will search the entire db for the string path I give) for every delta change of a property

Sadeep Darshana (Jul 18 2020 at 19:36):

The drawing speed is also not sufficient for such a scenario.

Daniel Rossberg (Jul 19 2020 at 15:09):

Sadeep Darshana said:

Daniel Rossberg Any chance I can get a permanent Object* instead of void Database::Get ( const char* objectName, ObjectCallback& callback)?

There is a Object* Get(const char* objectName) const; method (right below the other Get() method you mentioned in brlcad/ConstDatabase.h ;). But, you need to Destroy() it when you are done. And, don't forget to write it back to the database to see the effect.

Sadeep Darshana (Jul 19 2020 at 19:43):

I didn't think I could use it since it was a copy. Didn't occur to me that I could write it back.
Does Object::Name() contains the entire path too as opposed to just the name, to determine where in the hierarchy it is added?

Thusal Ranawaka (Jul 20 2020 at 02:28):

Hey @Sean

Daniel Rossberg (Jul 20 2020 at 05:51):

The Object subclasses are just wrappers for the rt_~_internal structs and just is their behavior. Modifying these structs doesn't change the database either. You have to use rt_~_import5() and rt_~_export5() to read/write them from/to the database. The Get() method with the call-back in the C++ interface does the write-back automatically. If you use the other Get(), you need to export the struct explicitly to the database if you want to have the changes an effect to it.

However, this should make it easier to implement the dialogs. "OK" calls Set(), "Cancel" not.

Daniel Rossberg (Jul 20 2020 at 05:55):

The name is just the name of the object. The path is build from the combinations in between the selected object (usually a group combination) and the object in question. This path doesn't have to be unique.

You can get the path from a tree walk algorithm.

Sadeep Darshana (Aug 13 2020 at 12:35):

is Combination::SetHasColor(false) working?
because when I query with Combination::HasColor() after calling Combination::SetHasColor(false) on a combination it still gives true.

Sadeep Darshana (Aug 13 2020 at 12:36):

Combination::SetHasColor(true) is working as expected

Sadeep Darshana (Aug 13 2020 at 16:36):

I also have trouble with setting color

Sadeep Darshana (Aug 13 2020 at 16:43):

Combination::SetGreen, Combination::SetBlue, Combination::SetRed apparently don't change the colors.
Database::Set gives an error when setting Combinations, it worked fine for solids. So I'm setting via ObjectCallback.
What am I doing wrong?

Daniel Rossberg (Aug 14 2020 at 12:22):

Sadeep Darshana said:

is Combination::SetHasColor(false) working?
because when I query with Combination::HasColor() after calling Combination::SetHasColor(false) on a combination it still gives true.

Can you debug this and see what happens in line 992 of Combination.cpp? Maybe

    Internal()->rgb_valid = (value ? '\1' : '\0');

would be better there.

Daniel Rossberg (Aug 14 2020 at 12:24):

Or

    Internal()->rgb_valid = (value ? 1 : 0);

?

Daniel Rossberg (Aug 14 2020 at 12:25):

Sadeep Darshana said:

Combination::SetGreen, Combination::SetBlue, Combination::SetRed apparently don't change the colors.
Database::Set gives an error when setting Combinations, it worked fine for solids. So I'm setting via ObjectCallback.
What am I doing wrong?

Which values do your colors have?

Daniel Rossberg (Aug 14 2020 at 12:25):

And - which error?

Last updated: Oct 09 2024 at 00:44 UTC