guillaumefavelier / blockbuilder Goto Github PK

Publishing coverage on codacy in github actions is possible with:

https://github.com/codacy/codacy-coverage-reporter-action

pytest-xdist is a great tool to have that can embed each test in a dedicated worker process. It's especially useful to handle segfaults and continue testing.

Reference: https://pypi.org/project/pytest-xdist/

Create a Github Action to send the coverage report to Codacy

The graphic quality should then be low, medium and high

low:

• no line or polygon smoothing
• no anti aliasing

medium:

• line and polygon smoothing
• anti-aliasing is enabled

high:

• use physically based rendering (https://blog.kitware.com/vtk-pbr/, https://lorensen.github.io/VTKExamples/site/Python/Rendering/PhysicallyBasedRendering/)

I think BlockSet better suits the intention of this class.

Export the current blockset into a VTK file as a proof of concept.

The title of the window should be blockbuilder. Maybe the version can be displayed too.

All the elements of the scene have a dependency to plotter.

Is there a way to refactor the code so that the elements can be instantiated without being given a plotter?

Create a blockbuilder.qrc resource configuration file then build the resources with:

pyrcc5 -o blockbuilder/icons/resources.py blockbuilder/icons/mne.qrc

Then load the resources in the code with:

from .icons import resources
resources.qInitResources()
icon = QIcon(':/icon.svg')

It should be possible to Undo/Redo 'actions'. At first, maybe one action saved.

The code should leverage property and setter decorators.
For example, Block.origin.

Create a standalone mode (additionally to add mode and delete mode) called paint mode. The selector of this mode modifies the color of it's selection.

This requires a color picker somehow.

This reference made it possible for Qt 5.15.0:

https://forum.qt.io/topic/115418/test-under-xvfb-fail-after-upgrade-to-qt-5-15-0-for-python/11

The goal is to import/reuse previously built set of blocks.
Those sets would be saved in a library.

Is it possible to use this issue to link all the wiki GIFs without tracking the files in the repo?

Let's find out!

Basic

• Plane
• Grid
• Selector

Toolbar

• Build
• Delete
• Area
• Edges

Publishing coverage on codecov in github actions is possible with:

https://github.com/codecov/codecov-action

• Follow semantic versioning, latest version is 0.03 wich contains a leading zero and is thus incorrect
• Update release process accordingly

The toolbar can be set by default at different locations: left, right, top, bottom

This should be configured in rcParams.

The coverage should be above 95%

The color button does not update it's color when blockbuilder just starts. Resetting the scene can fix this as a short term solution but this needs to be fixed.

Issue templates are really useful for user feedbacks (bugs, requests, ...etc). At least basic templates should be added.

Among the goals of the roadmap, the following will be available for the next milestone:

• Refactor area selection (experimental code)
• Allow the app to hold it's own event loop
• Add an option to toggle the block edges visibility
• Fix OpenGL context creation issue (at Initialize())
• Disable default VTK interaction
• Fix bug with coincident topology between grid and blocks
• Add key bindings to rcParams (at least for camera bindings)
• Refactor graphics completely and rename into plotter
• Remove dependency to pyvista
• Add an area selection toggle
• Add docstrings and make pydocstyle happy
• Add directory changes and use one changelog for each release

Maybe leverage subgrid/subsample and it may require an update of the pipeline

Add a button in the toolbar that displays a short description of the features with the associated key bindings.

These classes are not so different feature-wise or even in concepts.

Add a way to configure basic app settings at runtime.
Think about the influence on rcParams.

Dear Guillaume,
Using the reset button reset the scene and the brush as expected, hela it does not reset the color widget in the IHM which could be misleadeing for the user.

Great project otherwise !

To start the app on Windows, one needs to use the dedicated script file.

From the blockbuilder code source directory:

> scripts\blockbuilder.bat

This needs to be fixed, the user should not require the source code and be able to start the app by just typing:

> blockbuilder

But right now, doing so causes:

C:\anaconda3\envs\Blockbuilder\Scripts\blockbuilder....\python.exe: can't open file 'C:\anaconda3\envs\Blockbuilder\Scripts\blockbuilder': [Errno 2] No such file or directory

All the core elements of blockbuilder should be tested properly with pytest.

Filter more unrelated files by updating .gitignore

The interactions are handled locally in the Builder class. This should refactored into its own class instead.

Create a basic conda env for blockbuilder?

Dear Guillaume,

I have installed blockbuilder using pip and forced the vtk version to be 9 (python 3.8.3)
On the current state, the scene is only a black screen.

Additionally, the color picker has a strange behavior as it seems to show a random color (not the one picked) except when the window is not focused, then it shows the right color.

C.

The README.md is really short. This project deserves a real description.

The goal is to resize the block dimensions without losing the block cell informations. It would be a conservative approach.

Migrate from Azure DevOps to Github Actions

The goal is to install the app with pip install blockbuilder and then just call blockbuilder to launch.

This requires #30 and #31

First, perform a 3d area selection by click and drag on the 3 axes. At the mouse button release, the selection is registered and is bound to the cursor. The mouse can then freely decide on the new postion using the 3d selection as a preview for the final destination. Finally, click and release to move the blockset.

The end gold is to set up the project as an app.

A good way to achieve this is to make Builder inherits from Plotter and Plotter inherits directly from QMainWindow.

That way, one Builder instance contains all the informations needed without the need to use association. It's then easier to maintain and configure.

This change requires #6

The basic operation here consists in removing the selected vertex of the block. Its geometry will change accordingly so it won't be a cube anymore but many new shapes are available with this feature.

All the configuration should be saved plus the state of the blocks.

Idea:

• Based on XML

• Add a photorealistic mode (graphic quality should then be low, medium and ultra)

• Follow semantic versioning and update release process

• Set the project as an app (pip install blockbuilder then just blockbuilder to launch)

• Show only the current floor (with subgrid/subsample, requires to update the pipeline)

• Refactor interaction support into a dedicated class

• Add support for logging

• Paint mode (default painting color to build mode)

• Add support for PySide

• Add a way to load/save a project (all config plus state of block, xml based?)

• Add a benchmark and show fps

• Add a basic description of the project (README.md)

• Add support for pytest

• Use Qt resources package to organize icons

• ReDo/UnDo action buttons

• Refine the documentation (Parameters, Returns)

• Add a way to control the camera with the mouse right-click

• Add a way to configure the app settings (based on params?)

• Add property/setter functions (i.e. Block.origin)

• Add suppport for library (reuse previously built blockset)

• Add basic help (short description of features plus key bindings)

• Add a way to change the geometry of a block (deletion of block vertices -> not block anymore)

• The selectors are duplicated in the middle when symmetry is on (low priority)

• Is there a way to improve dependency to Plotter? (all over the place)

• Move Roadmap into Github Projects

The internal dialogs of MainPlotterneed to be tested:

• QColorDialog
• QFileDialog

Support for the other major python Qt API would be nice to have.

The new setting widget has a different result from the same code on the Windows platform.

Related to #45 (comment)

The docstrings are too short. They should include at least:

• Parameters
• Returns

The choice is BSD (3-clause).

Adapt the AreaSelector to process 3d zones

These are the steps to follow:

1. Archive all the cards of the Done tab in the Global Roadmap project:

2. Close the corresponding release milestone:

3. Rename the __version__ variable in __init__ and remove the dev suffix e.g. from 0.4.dev0 to 0.4

4. Create a new list of changes corresponding to the new milestone (e.g. 0.4.md), update the latest.md changelog and publish on master.

5. Merge master into release:

git checkout release
git merge master
git push origin release

6. Draft a new release and tag the release branch:

7. Bump the __version__ variable in __init__.py to 0.5.dev0

8. Create a new milestone Release 0.5