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.
My understanding of the workflow and approach was:
public class Column - (This is my Custom Object Class)
public class GH_Column : GH_GeometricGoo<Column>, IGH_PreviewData - (Custom Class Goo wrapper)
public class ColumnParameter : GH_PersistentGeometryParam<GH_Column>, IGH_PreviewObject - (Custom Class Parameter)
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.
@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);
}
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…
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.
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.
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.