GH_GeometricGoo - Render Help Needed

Hi All,

Firstly, apologies for the lengthy post.

Can anyone please help me trouble shoot why the objects are not rendered correctly in the Viewport. See image below. The faces look dodgy, some are transparent and some not.

I have followed this example from @DavidRutten Custom Data Type : GH_GeometricGoo or GH_Goo ? . David coded up a Boat.cs example.

My understanding of the workflow and approach was:

  1. public class Column - (This is my Custom Object Class)

  2. public class GH_Column : GH_GeometricGoo<Column>, IGH_PreviewData - (Custom Class Goo wrapper)

  3. public class ColumnParameter : GH_PersistentGeometryParam<GH_Column>, IGH_PreviewObject - (Custom Class Parameter)

  4. public class ColumnComponent : GH_Component - (The Component)

I have implemented the CastTo, CastFrom, DrawViewportMeshes, DrawViewportWires etc. Basically all requirements as per the absatract classes and Interfaces above.

All compiles well. The component work as intended. I have scrutinised the object. All good.

Code extract from GH_Column

public BoundingBox ClippingBox
        {
            get { return Boundingbox; }
        }
        public void DrawViewportMeshes(GH_PreviewMeshArgs args)
        {
            if (Value == null) { return; }
            if (Value.ColumnBrep != null)
            {
                args.Pipeline.DrawBrepShaded(Value.ColumnBrep, args.Material);
            }
        }
        public void DrawViewportWires(GH_PreviewWireArgs args)
        {
            if (Value == null) { return; }
            if (Value.ColumnBrep != null)
            {
                args.Pipeline.DrawBrepWires(Value.ColumnBrep, args.Color, -1);
            }
        }

Code Extract from ColumnParameter

public BoundingBox ClippingBox
        {
            get
            {
                return Preview_ComputeClippingBox();
            }
        }
        public void DrawViewportMeshes(IGH_PreviewArgs args)
        {
            Preview_DrawMeshes(args);
        }
        public void DrawViewportWires(IGH_PreviewArgs args)
        {
            Preview_DrawWires(args);
        }
        public bool IsPreviewCapable
        {
            get { return true; }
        }

What is to go with the Preview Methods? Why is this not working? Is this a BoundingBox issue?

Happy to share code, just not sure what part as there is a lot of it.

Are you sure the opaque areas aren’t just there because you draw a lot of transparent objects on top of each other?

@DavidRutten, this was my first thought as well and check this specifically. No duplicates.

Funny thing is, when I change my SolveInstance (see the comment lines for explanation), then all works fine.

protected override void SolveInstance(IGH_DataAccess DA)
        {
            int j = 0;
            //This doesn't work for preview
            //GH_Structure<GH_Column> ColumnTree = new GH_Structure<GH_Column>();
            
            //This works for preview
            List<Brep> ColumnBreps = new List<Brep>();

            if (!DA.GetDataTree(0, out GH_Structure<GH_Level> LevelTree)) return;

            foreach (GH_Path path in LevelTree.Paths)
            {
                var branch = LevelTree.get_Branch(path);

                foreach (GH_Level level in branch)
                {
                    foreach (var column in level.Value.Columns)
                    {
                        //This doesn't work for preview
                        //ColumnTree.Append(new GH_Column(column), new GH_Path(j));

                        //This works for preview
                        ColumnBreps.Add(column.ColumnBrep);
                    }
                }
                j++;
            }
            //This doesn't work for preview
            //DA.SetDataTree(0, ColumnTree);

            //This works for preview
            DA.SetDataList(0, ColumnBreps);
        }

Edit: Forgot to add the Input and Output methods

protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager)
        {
            pManager.AddParameter(new LevelParameter(), "Level", "L", "Level collection", GH_ParamAccess.tree);
        }

protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager)
        {
            //This doesn't work for preview
            //pManager.RegisterParam(new ColumnParameter(), "Column", "C", "Column collection", GH_ParamAccess.tree);

            //This works for preview
            pManager.AddBrepParameter("Brep", "B", "Column breps", GH_ParamAccess.list);
        }

@DavidRutten I am happy to share my solution with you if you have time. Will be appreciated.

I’ll have to test this myself in Visual Studio, but I’m home sick a few more days probably. Please ping this discussion by Monday if I haven’t replied yet…

Thanks David, I have send you a message with all the data.

@DavidRutten, hope you feeling better.

Just pinging you to check if your received my solution via private message, and had an opportunity to look at it?

Yep, got it, just compiled and ran it. Refreshing my memory now to see what exactly was expected of me :slight_smile:

So it doesn’t look anywhere near as weird in my viewport as yours, although it does look somewhat different than expected. I blame the args.Pipeline.DrawBrepShaded() method, so I’ll go and swap it out with my usual approach to see if it improves matters.

@DavidRutten

Yep David, replacing the args.Pipeline.DrawBrepShaded() with args.Pipeline.DrawMeshShaded() certainly does the trick. It does however require a additional (but small) step to create a mesh from the Brep Faces.

This begs the question though, what it the deal with args.Pipeline.DrawBrepShaded()?

Is it a double face issue as in front face / back face
or
is it the way I created my Brep’s.

  1. Surface.CreateExtrusion(Rhino.Geometry.Curve, Rhino.Geometry.Vector3d)
  2. Convert resulting surface using .ToBrep()
  3. BrepFaceList.SplitKinkyFaces(double, bool)
  4. Brep.CapPlanarHoles(double)
  5. Check Rhino.Geometry.BrepSolidOrientation

I don’t know what’s causing it, all I can do is create a test-case for our display developers and let them worry about it.

For organisational reasons I would very much like to switch to DrawShadedBrep() myself in GH2*, so this needs to be figured out sooner or later.

* reasons being the disappearance of the goo api. Data will be stored as is without wrapping meaning there’s no easy place to put those extra meshes.

So every plugin would need a full rewrite if they rely on IGH_Goo?

Oh any plugin needs a full rewrite anyway, GH2 has been redesigned from the ground-up and there’s zero overlap. One of the major problems is that GH1 could never be threadsafe, as it wasn’t designed to be. There’s no good ad-hoc solutions to making it threadsafe, it would be like converting a propeller-engine into a jet-engine piece by piece. Starting over is the only realistic approach.

Though with a bit of luck the standard components will only need changes to boiler-plate code. I’m hopeful that 90% of all components are very easy to update. But the ones which rely heavily on Goo or the way DataTrees work will need to be changed a lot.

All for the better, proper multi-threading and async is a must