vihdzp / miratope-rs Goto Github PK

How to reproduce?

Go to Uniform Antiprisms in the library. Set d = 2. Then drag n down to 2. Even though d is now visually updated as 1, it still holds the value 2, which makes Miratope crash as a {2 / 2} polygon isn't valid. Setting d = 1 and then n = 2 works fine.

We should check which other inputs have this issue.

Currently, Miratope consists of lots of complex polytope building code, and lots of complex polytope rendering code. We ought to separate these so that the crate is easier to use by others.

Before this separation is fully complete, there's a few things we need to sort out:

• Verify that the public and private parts of the API make sense.
• Feature-gate all parts of the code that might not be strictly helpful.
• Feature-gate the abstract name representations and the language module.
• Add thorough documentations.

This would be a really nice feature, though a difficult one to implement. There are quite a few things we'll need to do first:

• Parse CDs into graphs.
• Add a way to generate "snub" groups.
• Formalize what CDs even mean mathematically.
• Put everything together.

As described in the title, sometimes the wrong polytope is displayed. Instructions for replication are as follows:

1. Enter cross-section mode on any polytope
2. Load a different .off file
3. Press the cross-section button again

This loads sections of the previous polytope instead.

No idea why this happens? Says something about 16 not equaling 0. We could figure out how to set the backtrace in GitHub actions and use this to see exactly where the error lies.

Would be nice to stay up to date with the project.

should be better than recompiling every time :unknown:

When I try to compile miratope, I get this error

Compiling crossbeam-epoch v0.9.5
error[E0635]: unknown feature `proc_macro_span_shrink`
  --> /Users/adamnemecek/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.47/src/lib.rs:92:30
   |
92 |     feature(proc_macro_span, proc_macro_span_shrink)
   |                              ^^^^^^^^^^^^^^^^^^^^^^

   Compiling crossbeam-utils v0.8.5

Some code to generate a section of an abstract polytope (from the ranks of the elements and its indices, say) would be nice. It would also allow us to grab concrete elements or element figures (though we might want to do these separately, as most likely the code will be both faster and easier).

In 2D, OFF files write the single face instead of the components. We haven't checked what the code does in 1D and lower. This is a regression that was introduced when we changed the internal format of polytopes.

Stella sometimes bundles color info in OFF files, which screws up the parsing. In fact, it screws up the entire format, because the parser treats newlines as any other whitespace. We need to add some sort of flag to the OFF parser so that if the file "comes from Stella," it separates elements by newlines, and reads only the correct amount of elements from each line.

I got this error for some reason.

thread 'main' panicked at 'Error in Adapter::request_device: connection to device was lost during initialization', C:\Users\abcdefg.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.9.0\src\backend\direct.rs:113:9
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

and other GUI features like that, can't think of any at the moment

This would slice the polytope by some hyperplane to create a polytope of one rank lower.

Os: Linux Raiku 5.11.21-hardened1-2-hardened #1 SMP PREEMPT Fri, 14 May 2021 21:06:07 +0000 x86_64 GNU/Linux

Miratope version git hash: 70811e1

Problem:

Whenever browsing through a menu it closes even if it isn't a leaf.

VIdeo: https://youtu.be/iHyF1gcDy4g

Perhaps hex code boxes for the background and wireframe, with more options for different facets and elements later on.

The info would be:

• element counts of the element, maybe in the long term the name of the polytope (#15)
• info of the element figure
• measures like volume (#16)

Not sure how grouping by type would be done, probably using heuristics like Stella does. There was talk about using graph isomorphism to check which abstract polytope it is

I'm thinking of, for each element type, have a button to load it in the secondary view. Currently we don't even have the secondary view yet... (#17) This would also require reworking the element counts code a bit.

Miratope JS could do this, so we should be able to as well.

Currently, we can only visualize one polytope at a time. Would be nice to be able to visualize various polytopes, and maybe things that aren't exactly polytopes like abstract polytope graphs.

Currently, we triangulate a polygon by simply going around it clockwise. This works fine for convex polygons but fails spectacularly for nonconvex ones. We should implement a better triangulation algorithm, hopefully from some crate, to be able to do both binary filling and density filling.

Includes some of #10, and also the code to print element counts

The current convex hull code works only when all of the facets of the polytope are simplices. We ought to make it work in more general settings. We could implement Quickhull to do this.

Wikipedia seems to suggest the way we're currently defining the basis in our Hyperplane struct might be badly numerically unstable. Someone should check into that.

This is a sort of follow up to #23. Currently, cross-sections have two major bugs, and something else we should figure out:

• Cross-sections of polytopes in less than 2D generate invalid polytopes.
• A cross-section passing through an element can give unpredictable and sometimes invalid results.
• Petrials' cross-sections are weird (obviously, they weren't meant for this)

As a newcomer for Rust and a full-time Linux user, (I have NPM knowledge), I originally had trouble cargo-running the application due to Failed to run ```"pkg-config" "--libs" "--cflags" "glib-2.0" "glib-2.0 >= 2.48": No such file or directory (os error 2)```.

I am wondering how can I resolve this problem?

Edit You need to install a GTK, ATK, package

Update I realized some of the variables did not live long enough.

mulliganaceous@MULLIGANACEOUS2:/media/mulliganaceous/Mulliganaceous_S/Gits/miratope-rs$ cargo run
   Compiling wgpu-core v0.9.2
   Compiling xcb v0.8.2
   Compiling bevy_winit v0.5.0 (https://github.com/bevyengine/bevy?branch=main#e74f7a73)
   Compiling stretch v0.3.2
   Compiling bevy_text v0.5.0 (https://github.com/bevyengine/bevy?branch=main#e74f7a73)
   Compiling bevy_scene v0.5.0 (https://github.com/bevyengine/bevy?branch=main#e74f7a73)
   Compiling gio-sys v0.14.0
error[E0597]: `desc_set` does not live long enough
    --> /home/mulliganaceous/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.9.2/src/device/mod.rs:1792:26
     |
1792 |                     set: desc_set.raw_mut(),
     |                          ^^^^^^^^^^^^^^^^^^ borrowed value does not live long enough
...
1813 |     }
     |     -
     |     |
     |     `desc_set` dropped here while still borrowed
     |     borrow might be used here, when `write_map` is dropped and runs the `Drop` code for type `BTreeMap`
     |
     = note: values in a scope are dropped in the opposite order they are defined

For more information about this error, try `rustc --explain E0597`.
error: could not compile `wgpu-core` due to previous error
warning: build failed, waiting for other jobs to finish...

This is a feature that had already been considerably worked into Miratope JS. We'll need to rethink a few key aspects, particularly which crate we'll use for localization, exactly what will get translated, how we'll store names internally, and what we'll assume about the grammar of languages we'll localize Miratope into.

To compute the volume of a polytope, we need to first check for planarity, then build an oriented simplex for each flag and add up all of their areas. The part of the oriented simplices might be made easier if we first made some sort of iterator object over flags of a polytope (which might then be reusable for other functions).

Decrease the amount of actions required to open miratope, i.e porting miratope to WASM or a downloadable; This issue will be for after most of the other issues are solved or the project is considered public and finished.

As soon as emilk/egui#405 and mvlabat/bevy_egui#27 get merged on their respective repositories, we can stop using custom forks for them. Can't do nothing but wait.