leap71 / picogkruntime Goto Github PK

PicoGK Runtime is the C++ framework behind PicoGK a compact and robust geometry kernel for Computational Engineering

License: Apache License 2.0

C 51.82% C++ 45.91% CMake 1.98% Shell 0.18% Batchfile 0.11%

picogkruntime's Introduction

Welcome to the LEAP 71 GitHub

At LEAP 71 we build complex technical objects using Computational Engineering Models (CEM). These models output parts, structures, and entire functional assemblies of machines, ready for production using advanced digital production technologies, such as industrial 3D Printing.

We use our technology to build anything from rocket engines to energy efficient heat exchangers and electric motors.

Check out our gallery here.

We are committed to supporting a growing open-source community around Computational Engineering, and are in the process of releasing many of our foundational technologies and computational models to the public.

Resources


	PicoGK ("peacock") is the open source foundation of all of our work at LEAP 71. Get started with PicoGK here.
	Coding for engineers is an ongoing book project about learning how to code on PicoGK, which is released chapter by chapter by Lin Kayser.
	Check out our GitHub Discussions, to talk about Computational Engineering, PicoGK, give feedback, ask questions, and see what others are doing,
	Visit PicoGK.org for more resources.

PicoGK

At the core of our work lies PicoGK ("peacock"), a compact and robust geometry kernel. We have released PicoGK under the permissive Free and Open Source (FOSS) Apache 2.0 license.

To get started with PicoGK, check out the documentation.

Computational Engineering benefits greatly from the free exchange of knowledge and algorithms. While much of LEAP 71's work is proprietary, we are constantly publishing foundational modules and examples as open-source.

At this time, the following repositories are available:

Base libraries

Use these libraries as submodules in your own Computational Engineering projects.

	Repository
	PicoGK	The C#-based geometry foundation for all of our work at LEAP 71
	ShapeKernel	A generalized framework for creating computational geometry, based on PicoGK.
	LatticeLibrary	An advanced library for creating complex lattice structures, based on ShapeKernel and PicoGK.
	QuasiCrystals	A library to generate aperiodic tilings, such as Penrose Patterns (in 2D) and quasi-crystalline structures (in 3D).

Example projects

Check out these example projects to see how to build objects in PicoGK.

	Repository
	Helix Heat Exchanger	An example how to build a heat exchanger using ShapeKernel and PicoGK
	Rover Wheel	An example how to build rover-wheel-like objects using ShapeKernel and PicoGK

Under the hood

If you want to compile your own version of the PicoGK runtime and build custom installers, here's the source code.

You are usually not interested in these repositories as an end user of PicoGK.

Repository
PicoGKRuntime	C++ source code for the PicoGK runtime module.
PicoGKInstaller	Source code for the PicoGK installers

Tip

If you are looking for the PicoGK installers, download them here.

More information

To understand the motivation behind PicoGK, check out this series of articles on the authors' personal website.

For more examples of what you can do with PicoGK, check out our Instagram. follow us on X, and visit the LEAP 71 website.

Image credits LEAP 71 / Fraunhofer IGCV (for multi material metal prints)

picogkruntime's People

Contributors

Stargazers

Watchers

Forkers

pjdixit mosri manupdz amzuko corrievs drlukeparry niels-io shapediver wilko339 msamiolo

picogkruntime's Issues

NaN numbers in LatticeBeam::fSdvFlatCone()

On the following line, it is possible under rare occasions to get NaN due to round-off errors leading to strange artefacts in the signed distance field for the flat capped cone in the render lattice methods for beams.

https://github.com/leap71/PicoGKRuntime/blob/d5f5ac38ab1c2090fb47b4c4f700553dd2c912aa/Source/PicoGKLattice.h#L163C56-L163C56

float x = std::sqrt(papa - paba * paba * baba);

Although not in the original implementation by Inigo - it may be worth considering absolute values or lower-bound clipping within the square root.

Results between different voxel size for offsets are inconsistent

There is a bug when rendering meshes, which is very apparent when offsetting at very small voxel sizes.

The discretized signed distance field we are using to represent our voxels shows aliasing artifacts and general "weirdness" the further (up and down) the voxel size deviates from 1.

This results in fairly "ugly" offsetted voxels for voxel sizes smaller than 0.1mm.

API Tests - Hardcoded files

The API Test mesh & images files are hardcoded and are not included in the release or repository.

Specifiying strPicoGKLibPath does not work

Hi,

After building the runtime, I was not able to get it to run with the dylib inside the Dist folder as it is specified in the readme here.

After copying the dylib to the /usr/local/lib directory, it worked. 🙂

GLFW as git submodule + cmake version

Is it possible to make the glfw source as a git submodule component, rather than rely on retrieving the repository via cmake? The build script failed to retrieve the repository on Mac OSX Sonoma.

We already have to initialise the submodules for openVDB so it would seem sensible that it could be done for GLFW library.

Finally, is it necessary to have the latest version of cmake at v3.27? Is it a prerequisite for compiling the static library for openVDB?

Option to statically compile dependencies?

Would it be possible to add a configuration where the dependencies are statically compiled, instead of using .dll dependencies? It would be nice to be able to distribute just the picogk.dll.

Voxels.ProjectZSlice stopped working in v1.5

The Voxels.ProjectZSlice function stopped working in the latest v1.5 release. This can easily be recreated by launching PicoGKExamples.PrepForPrint.Task. Instead of building a solid base, it creates a stripe-like artifact in the voxel field.

Voxels.ProjectZSlice create degenerate signed distance field

The Voxels.ProjectZSlice function creates a degenerate signed distance field, because the signed distance values further away from the last slice are not updated accordingly. This needs a bit more elaborate solution.

If you are using ProjectZSlice to build a base for your object (which is the most common use), you can work around this, by projecting down below zero and then performing a boolean operation, cutting off the degenerate base.

See Ex_PrepForPrint.cs for a good example.

Conversion of real world coordinates to voxel coordinates is imprecise in some circumstances

The converted voxel coordinated is cast to int without adding 0.5f first, which leads to the coordinate always being rounded down.

There is a significant difference between offsetted lattices in different voxel sizes

Lattices drawn into voxel fields of the same dimensions in voxels, but different voxel sizes, have significant differences when offsetted.

This is voxel size 0.002mm

This is voxel size 2mm

Use in Godot Engine for mesh boolean operators on triangle meshes

Hi!

I am interested to know if I can use PicoGKRuntime for mesh boolean operators for intersection, subtraction and difference on triangle meshes in Godot Engine. I cannot use C# in the core Godot Engine.