Missing Rhino and Grasshopper Plugin about dhart HOT 19 OPEN

I don't have much experience packaging C# libraries (compared to e.g. pypi for python). From what I saw on Rhino, they show how to do it using Nuget https://developer.rhino3d.com/guides/rhinocommon/using-nuget/ . Does Fody weavers just package it up so you can upload to nuget?

The cmake reference I made might be misplaced. If you don't actually need the C# source files to link to a rhino app and only need the dll's, then its fine. This is a good reminder I don't have any screenshots for the build.md and I need to add them.

Ideally all of DHART could be exposed through the nodes. My general idea is (and please provide your own thoughts on the user experience or if its awkward):

Some example node ideas:

This was a nice exercise for me. Its hard to find a good way to provide graphs back. I am not familiar with what GH has for graphs. If it does, it would be nice to have a node convert to a GH graph. I think generating the graph and doing path planning is obvious use for many people. For myself, I would want to be able to do things like select a node and get its outgoing neighbors and edge weights, but I don't know how many others want these features so perhaps it stays on hold until people ask.

The one thing that will be interesting and I haven't tested is the ability to use the same bvh for multiple raycasts on different nodes, especially with the new GH that has multiprocessing. I think this is threadsafe, but I don't think I have ever tested it because it would be an awkward thing to implement in python (i.e. spawning multiple processes, passing each one the bvh and having each process do their own raycast). I also don't know how GH cleans up stuff on shutdown.

Is this similar to what you were thinking?

from dhart.

Hey @cadop,
I started working on a Grasshopper plugin for my own purposes and would be happy to contribute to this codebase.

Data translation is very straightforward. Here is an example of a mesh intersection with a bunch of vectors representing sun rays:

Mesh _context;
MeshInfo contextMesh = new MeshInfo(_context.Faces.ToIntArray(true), _context.Vertices.ToFloatArray());
EmbreeBVH bvh = new EmbreeBVH(contextMesh);

Vector3D[] sunDirections = ConvertListOfVectors(_sunDirections);
Vector3D[] analysisPoints = ConvertListOfVectors(_analysisPoints);

            for (int i = 0; i < sunDirections.Length; i++)
                EmbreeRaytracer.IntersectOccluded(bvh, analysisPoints, new Vector3D[] { sunDirections[i] });

where:

        private Vector3D[] ConvertListOfVectors(List<Vector3d> inputVectors)
        {
            Vector3D[] convertedArrayOfVectors = new Vector3D[inputVectors.Count];

            for (int i = 0; i < inputVectors.Count; i++)
                convertedArrayOfVectors[i] = new Vector3D((float)inputVectors[i].X, (float)inputVectors[i].Y, (float)inputVectors[i].Z);
        
            return convertedArrayOfVectors;
        }

from dhart.

HI @Sonderwoods, DHART turned out to have too many dependencies for my needs and I ended up writing my own wrapper around Embree.

from dhart.

@mariuszhermansdorfer sorry i didn't realize you were having issues with dependencies (i think its just boost/eigen?). You should be able to compile dhart with only the raytracing package. It's been awhile since I did it, but that is the reason in visual studio you see the separate packages.

so @Sonderwoods if you only need single ray casting support, that would be the way to compile dhart (or if marius would share his wrapper). Otherwise the features like navigation graph, pathfinding, visibility graph etc. would need the dhart package. As a note, dhart only needs dependencies if you are building from scratch. If you just use the dll provided it doesn't need anything else.

Are you using rhino 8? since it now supports CPython, its really easy to use dhart... it's the same as the python code api. The original challenge for integrating it in rhino was that dhart didn't work with IronPython, and writing an interface with C# more a bit more effort. I tested it this past week and it just requires using the Rhino requirements method of putting
# requirements: dhart at the top of the script. If you need help on using it in grasshopper just let me know.

from dhart.

@Sonderwoods Stay tuned! Might show something this week :)

from dhart.

Hi @mariuszhermansdorfer that would be great!

I've been wanting to make an interface with RhinoCommon and create some grasshopper nodes, but haven't found the time to go through the docs and figure out a nice way to setup the solution to build and link to rhino. If you could extend the cmake project configuration to add a C# Rhino build/release option that would be ideal, but any build system for a start would be appreciated :)

There were a couple "gh nodes" I was thinking of, one being the graph generator (which would then also lead to the path planning), and the others as the raycasting. If you are only interested in the raycasting but can help get the project build setup I can do the rest.

from dhart.

Hey @cadop,

happy to help with creating a few GH nodes going beyond raycasting. I'm fairly experienced with c# but have very rudimentary understanding of the c++/cmake workflow.

For now, I simply referenced the DLLs you provided in my VS Solution and build it. These could be easily weaved into the assembly with Fody weavers so that users need to download only one file and are always using the correct DLLs.

Maybe you could share your idea for the GH nodes? We could sketch the input/outputs here first and then I could implement these in code.

from dhart.

I don't have much experience packaging C# libraries (compared to e.g. pypi for python). From what I saw on Rhino, they show how to do it using Nuget https://developer.rhino3d.com/guides/rhinocommon/using-nuget/ . Does Fody weavers just package it up so you can upload to nuget?

The Nuget part refers to referencing external libraries. In this case, you'd publish the DHARTAPI.DLL as a Nuget package (as well as the System.XXX ones). It makes it easier for plugin developers to keep up to date with any API changes. Currently we need to manually download the DLLs and place them in the dev folder, with a NuGet package, they'd be pulled from an online source.

Fody weaves any local external DLLs (also unmanaged) into one DLL. So it's either NuGet or Fody. NuGet is definitely more flexible and easier to use for other people as well.

The sketch looks good for the raycasting part. I haven't yet worked with DHART's graphs. Let me start working on the first 3 components BVH, Raycast and Visibility and let's see what comes up as we go. I'll create a dedicated branch and push it once I have something to show.

from dhart.

Great thank you!

I made this branch for you to make PRs on the issue https://github.com/cadop/dhart/tree/rhino-and-grasshopper-plugin

from dhart.

Something is off with the Git setup, I can clone the repo and see the master branch, but can't switch to any other branch:
That's the error message:

Opening repositories:
C:\Users\mrhe\Source\Repos\dhart
Git failed with a fatal error.
fatal: protocol error: bad line length character: Not
Git failed with a fatal error.
fatal: protocol error: bad line length character: Not

Hmm, I've managed to clone it outside of VS, but can't push anything to the branch. You'd need to add me to the collaborators.

Commit ef26efa3 created locally in repository C:\Users\mrhe\Documents\GitHub\dhart
Pushing rhino-and-grasshopper-plugin
Pushing refs/heads/rhino-and-grasshopper-plugin
Remote: Permission to cadop/dhart.git denied to mariuszhermansdorfer.

from dhart.

Sorry if it wasn't clear, you should fork the repo and do any changes/additions you want, then you go to https://github.com/cadop/dhart/pulls and click "New Pull Request". The source branch is your personal fork, but make the destination branch the one I created (not the main branch).

from dhart.

OK, makes sense. I will proceed accordingly.

from dhart.

hi @mariuszhermansdorfer and @cadop is this development still in progress?

from dhart.

Really cool, @cadop .. It was mainly to play around and get an overview of the features. Mariusz referred me to this repo previously for the embree wrapper but now I got curious about the rest of the package.

Let me know if you end up with some example files in GH/CPython3! Best

from dhart.

@Sonderwoods Heres a few references. The important thing for this issue originally was that there was no CPython so we needed to make some C# library for it. now there is cpython, so the regular python API works in both rhino and GH (it's just a matter of how to visualize the data). Since there is a pypi package, rhino will now install it automatically. I still haven't figured out the C# nuget (but it seems its now supported as well).

This article has some info and text overlay on the video https://blogs.nvidia.com/blog/mathew-schwartz-openusd-omniverse/

I also attached a GH script that goes with this rhino model (its been a long time since I used GH, so I couldn't figure out how to make some basic geometry without the need for a mesh.

Attached is also a demo recording of what it should do.

There are some other features

DHART_DemoGH.zip

Let me know if there are other features you were looking into or wanted to demo.

And finally, of course I would appreciate any contributions to improving the rhino workflow aspect of it.

from dhart.

@cadop, this is super good stuff!

Could you please elaborate on how to interpret the color coding in the visibility graph?

When you set the building mesh as input, intuitively I'd think that the whole building is visible from the selected points, but I don't understand the brighter colors in the ground floor corridor.

from dhart.

Hi @mariuszhermansdorfer !

There are a few things that are going on.

• The visibility graph returns the distance between each node and the target nodes (it could be all nodes, full visibility graph; or a few, POIs). There is a few ways to define a 'score' for the graph.
  • The method I was showing here is an 'average' instead of a count, meaning it is averaging the distances, which is why there is a falloff.
  • If you change to 'count' it will look more like a visibility graph (or what I think you are wondering about).
• There is a mesh (BVH) that is defined for both the navgraph and the visibility graph. It could be the same, but you can also make them different (like have the navgraph use the full building, but the visibility graph be the building without windows).
• In the images you copied,
  • the first one I set the visibiltiy mesh to be just the box, passed the nodes of the navgraph and set a POI behind the box.
  • In the second one I had the building as the visibility graph and the POI is on the ramp, so nothing is visible except what is on the ramp and two windows that are missing in the original model.

from dhart.

Thanks @cadop! Makes a lot of sense. I'll have to test it out on projects now.

from dhart.

Cool, let me know if you have any questions, or open some issues. We can also follow-up in discussions for more things you are wondering about... I have definitely had feedback that its hard to understand the features without hours of studying documentation haha :D

the python docs usually have the visual examples/tutorials because its easier for me to make and autobuild with ghpages like visibility , but the API should be the same for C#

@mariuszhermansdorfer if by any chance you made your embree wrapper a similar C interface as the dhart package, it would be nice to integrate your extra features (maybe as a custom package that is disconnected from the rest for now).

p.s. the reference I made to 'showing something this week' was supposed to be for the omniverse livestream which only got a little bit shown, but figured you guys as computational people may enjoy the pointcloud stuff with rhino 8.

from dhart.