Comments (6)
Have you considered using some kind of generic generator?
Some way to decouple the format from plexus mesh implementation? PLY, Obj, stl? please correct me if I am talking nonsense.
Something like: https://doc.cgal.org/latest/Polyhedron/classCGAL_1_1Polyhedron__incremental__builder__3.html
I really like your library, this is pretty well done work.
from plexus.
Have you considered using some kind of generic generator? ... Something like: ...
Thanks for the link! It'll take me some time to wrap my head around those docs, but I'll take a look and see if I can apply that here somehow. For PLY, I'd like to provide some mapping from user geometry to properties, probably via traits. Ideally this wouldn't be too intrusive and would be as automatic as possible. That may not be general enough of an approach for other formats though.
from plexus.
I think serde might not be the best option for this use case and a more specialized API might be of interest. In a recent project of mine I have used meshio (Python) and I think something like that would be great to have in Rust, in its own crate standardizing mesh representation using expressive typing.
My idea is to have a deserializer generic over the mesh representation (MeshInsert
trait or something like that) and provide a vec based one and a half edge data structure. This would allow to reuse deseralizers directly with a desired format. Serialization would be handled in a similar way. (It might take an attempt or two until a design is found so that no copying is needed.) I'll try to prototype this in a few days and provide more details.
from plexus.
There's currently some working code on the ply
branch, but it only provides decoding so far (not encoding). It also does not yet handle arcs nor edges; I expect this can be done by providing traits for this that are unused for buffers and are easily stubbed for graphs.
To support decoding, there are some core traits: VertexDecoder
, FaceDecoder
, and FromEncoding
. These are generic w.r.t. mesh data structures and provide basic type information about geometry and indexing. Both buffer and graph types implement FromEncoding
.
Each encoding then provides more specific traits, which can be implemented in terms of the core traits. For PLY, there is a general Encoding
trait for metadata and then decoder traits for elements and properties. These are used with FromPly
(and ToPly
) to handle marshaling the data.
A simple encoding scheme takes approximately 80 LoC to implement this way. See PointEncoding
for an example. The bulk of that implementation is here and here. Usage looks something like this:
let ply: &[u8] = include_bytes!("cube.ply");
let (graph, _) = MeshGraph::<Point3<f64>>::from_ply(PointEncoding::default(), ply).unwrap();
The PLY implementation is supported by ply-rs
. Some of its types are re-exported and others are hidden. Some extension traits are provided to ease conversions and error handling (see read_scalar
and read_list
).
from plexus.
(Most of) the changes described above landed in e57f096. There's still no support for serializing meshes into PLY format, but I'm happy enough with the way deserialization is implemented.
As always, naming is tricky, and I worry I've overloaded the term "encoding" too much. In particular, formats like PLY are referred to as "encodings", but the types that marshal data (handle the details of conversions) to and from PLY are also called "encodings". PointEncoding
is an example of this. These should probably use a different name!
from plexus.
I'm experimenting with both internal and public APIs for mutating and initializing mesh data structures on the transact
branch. This temporary test demonstrates a builder API that is similar to CGAL's incremental polyhedron builder mentioned previously. This could act as the basic interface for initializing meshes and I plan to try implementing other APIs like FromEncoding
and FromIndexer
in terms of MeshBuilder
.
Just a note, but the implementation for MeshGraph
used in the linked code just wraps the mutation API. This leads to some awkwardness in the implementation, because Mutation
doesn't use transitionary types like the builder API does. Top-level types must support moving MeshGraph
and Mutation
in and out of Option
s. 🤢 See the Drain
trait.
from plexus.
Related Issues (20)
- Examples crash due to winit version HOT 4
- Consider removing vertex generators. HOT 2
- master build broken HOT 4
- Represent composite edges in graphs with independent geometry. HOT 5
- Differentiate purely topological and geometric operations on graphs. HOT 1
- Remove the `Attribute` trait. HOT 1
- Factor spatial and geometric traits into a separate crate. HOT 5
- Master fails to build HOT 2
- Factor primitives into a separate crate (Theon). HOT 2
- Consider a non-manifold graph representation. HOT 1
- Is there a way to copy/isolate part of a graph into a new graph? HOT 6
- Splitting arcs in a graph causes corruption. HOT 7
- Reevaluate the constraints on non-manifold topology in graphs. HOT 2
- Use more consistent taxonomy and APIs for representing arity. HOT 2
- Remove redundant input type parameters for geometry in graph APIs. HOT 2
- Use paths for topological mutations over arcs and faces. HOT 1
- CI fails due to dynamic linking errors with Intel MKL during doctests. HOT 4
- Support ultraviolet crate HOT 5
- iteration methods on `FaceView` not found HOT 2
- Use hash maps exclusively in storage. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plexus.