Coder Social home page Coder Social logo

happly's Issues

Small bug in read basic data example

It seems this line
std::vector<int> elementA_prop2 = plyIn.getElement("elementA").getProperty<double>("prop1");
should be
std::vector<double> elementA_prop2 = plyIn.getElement("elementA").getProperty<double>("prop1");

Google Test branch is now main

CMake fails in the test directory due to a configuration error in Google Test. They have changed the "master" branch to "main". This issue can be resolved by changing line 8 in the test/CMakeLists.txt.in file to reflect the change in branch tag.

Make lack of implict copy very clear. Add .copy() function.

Right now the main PlyData class cannot be implicitly copied. This is probably the right behavior; doing so is likely a mistake.

However, we can improve the situation in two ways

  • Explicitly delete the copy constructor, to make it clear that the behavior is intentional
  • Provide a .copy() function for the few situations where one really does want to explicitly copy

Error after the last commit.

I am getting the following error:
error: the operand of a pointer dynamic_cast must be a pointer to a complete class type
lines: 954, 997

However, when I roll back to commit 88f7972 it works fine.

Improve exception message when trying to read list property as scalar

I have a custom element with a list property:

element track 572
property list uint16 uint32 vertex_index

When trying to read it via:

const std::vector<uint32_t> track_ids = tracks.getElement("track").getProperty<uint32_t>("vertex_index");

I am getting the exception:

PLY parser: property vertex_index cannot be coerced to requested type uint. Has type unit

which is a bit confusing, since it detects the correct type (Has type unit) but fails to convert the type to the same type (cannot be coerced to requested type uint).

Is this a bug in the conversion, or is the uint32 type just not supported?

Parallelizing ply parser

Hi, I'm recently working with analysis of large PLY-formatted mesh model. Since, 3D model I/O is really big bottleneck of my analysis pipeline, I'm trying to parallelizing ply parser based on this repository using the idea of [1].
If you think that this feature is worth and suitable to this repository, I'd like to contribute my implementation here.

Thanks for reading this issue.

Reference
[1] Jo, Sunghun, Yuna Jeong, and Sungkil Lee. "GPU-driven scalable parser for OBJ models." Journal of Computer Science and Technology 33.2 (2018): 417-428.

could we add a CMakeLists.txt file to make it cowork with cmake or vcpkg?

Hi,
could we add a CMakeLists.txt file so that this library can be included using cmake or even vcpkg?
I've written an example of CMakeLists.txt, but I am no export of cmake, so I am not making a pull request.
This file can be found here for your reference.
single header makes this library easy to use. But I think cmake or vcpkg will make it easier for people to include it into their projects.

Significant slowdown on large files

The current version of happly is quite slow for large files compared to an home-brewed solution I cooked up. The profiler suggest that the problem is allocating many small vectors in list properties. On the Lucy model from the Stanford repo, happly takes about 16 seconds of which 7 are just vector allocs. My home-brewed solution takes half that time.

I propose the following changes:

  1. change the storage of list props from vector<vector<T>> data to three vectors for start, count and data std::vector<size_t> start; std::vector<uint8_t> count; vector<T> data;, where data has the concatenated list of elements, start has the starting index for each list and count contains the lists sizes
  2. in a backward compatible manner, add getListProperty(vector<array<T, N>>& data, vector<uint8_t>& count) to read the data in preallocated lists; maintain previous versions for backward compatibility

If this sounds good, I may even take a crack at it, but only if this feels right.

Pointcload read/write

Hi,

This is not a bug.
Could you please give an example how to read and write a pointclošd with colors?

Clean up CanonicalName things

I noticed some of the template use in Happly is not ideal. Go back and look closer:

  • CanonicalName<size_t> looks like it has a bug, perhaps not caught because no one uses 32bit machines?
  • Try to avoid copy when converting to canonical
  • Several places where we through runtime_errors could be compile time checks (though the compile checks might have much more confusing error message...)

Auto-convert floats to double?

We already auto-convert signed to unsigned ints in some cases, to support the common situation where indices have (strangely) been stored as a signed value.

A similar issue is downconverting doubles to floats. Personally, I tend towards using double everywhere, but I think others follow the opposite policy, and they would probably be fine with the narrowing conversion.

This is probably best implemented with a special-case check, as was done with size_t.

Small bug in example code

The "Write mesh-like data" example in the Readme references fInd, which should be meshFaceIndices

Can't read obj_info header written by CloudCompare

Thanks for the great parser! We were so happy to find it. ❤️😄🌈🎉

One issue we ran into: CloudCompare writes a obj_info header, e.g.

ply
format ascii 1.0
comment Created by CloudCompare v2.10.2 (Zephyrus)
comment Created 8/1/19 9:04 AM
obj_info Generated by CloudCompare!
element vertex 4308
property float x
property float y
property float z
element face 8612
property list uchar int vertex_indices
end_header
74.5034 161.291 168.961 
77.047 149.808 164.128 
73.8367 161.097 169.151 
73.1975 160.869 169.417 
...

I can ping someone to track down the exact line of code that's failing, but it seems pretty cut and dry that you simply have to remove the obj_info line to avoid getting an error about an invalid header. Seems like just a simple obscure PLY header field that's not handled.

We'll probably have to fix this, but at the very least wanted to get it reported. Thanks again!

See also: PointCloudLibrary/pcl#2763 (comment)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.