-
Notifications
You must be signed in to change notification settings - Fork 56
Feat: PlotPrismLine #129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Feat: PlotPrismLine #129
Conversation
…ne to make it better looking in 3D and avoid plain-line intersection
…ne to make it better looking in 3D and avoid plain-line intersection
Do you think you can take a look at this to get an initial idea of whether or not to continue in this direction? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all, sorry for taking so long to review it; a personal problem came up. I left some reviews regarding the unspoken code standards that we are following.
I was thinking that maybe we could rename this method to PlotPrism
, and there could be some ImPlot3DPrismFlags
to choose between rendering a closed prism (which is useful is someone wants to render a square prism, pentagonal prism, hexagonal prism, etc) or a prism with open ends (which can be used to remove the line artifacts for advanced users). There could also be flags to define if the const T* xs, const T* ys, const T* zs
define individual prisms or chained prisms.
The prism could still be defined by two points, just like you implemented (a few prism types below)
I'm not sure what the best arguments are for the PlotPrism
method. We could also have multiple PlotPrism
methods with different arguments, maybe a PlotCube
, PlotPipe
, etc. Just throwing ideas here, being able to plot different types of prisms with ImPlot3D sounds quite useful :)
It would be great to also add a demo plotting different types of prisms.
Let me know what you think!
@@ -37,6 +38,7 @@ | |||
|
|||
#ifndef IMGUI_DEFINE_MATH_OPERATORS | |||
#define IMGUI_DEFINE_MATH_OPERATORS | |||
#include <type_traits> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In ImPlot3D/ImPlot/ImGui, we don't use C++ containers (I think it is mainly to avoid the compilation/performance overhead, but I'm not sure)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not for container types it's a type trait to use in concepts to limit the types for type safety.
but, we could do without.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh sorry! Yes, you're right. What I mean is trying to stick to the includes already present in ImGui/ImPlot as much as possible to avoid increasing compilation time with C/C++ libraries.
//[Section] PlotPrismLine | ||
//----------------------------------------------------------------------------- | ||
|
||
template<typename T> requires(std::is_floating_point_v<T>) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome to see you using C++20! For now, since ImPlot doesn't use C++20 and we haven't used it in ImPlot3D yet, it would be nice to stick to C++17 features so people with older compilers can continue compiling ImPlot3D without problems.
(Note that the CMakeLists.txt
specifies C++17, so this code wouldn't compile)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, i'll take it off it's not really nessary.
It was an attempt to code deffensively to prevent someone from using the wrong data type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see! The CALL_INSTANTIATE_FOR_NUMERIC_TYPES
macro takes care of only creating instances for the valid types; you can read more about it in [SECTION] Template instantiation utility
.
auto quad_xs = (T*)malloc(count * sides * 4 * sizeof(T)); | ||
auto quad_ys = (T*)malloc(count * sides * 4 * sizeof(T)); | ||
auto quad_zs = (T*)malloc(count * sides * 4 * sizeof(T)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
malloc
is a bit error-prone. It would be better to use ImVector<T>
when possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great, didn't know the ImGui had a dynamic array.
will look into it and change the code accordingly.
free(octagonPoints1); | ||
free(octagonPoints2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to run clang-format
before each commit! Most editors can run clang-format
when the file is saved. Alternatively, you could also have a pre-commit hook running clang-format
if you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will look into it.
although I think if i use ImVector that wouldn't be neccessary.
//----------------------------------------------------------------------------- | ||
|
||
template<typename T> requires(std::is_floating_point_v<T>) | ||
struct Vec3 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a bit counterintuitive, but the ImPlot3DPoint
struct in implot3d.h
already implements most of these vector operations, so you can use ImPlot3DPoint
instead. This Vec3
code is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will take that into account
|
||
## clangd | ||
compile_flags.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering, what did you use the compile_flags.txt
for? 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is for my neovim highlighting.
so it doesn't get added to the files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nvim best editor, yes or yes?
} | ||
} | ||
|
||
PlotQuad(label_id, quad_xs, quad_ys, quad_zs, (count - 1) * sides * 4); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great to see that you are using PlotQuad
for the rendering! It makes the code much easier to maintain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, that was the objective.
Closes #126
Adding the PlotPrismLine function: plots an N-Sided Prism around a line to make it better looking in 3D and avoid plain-line intersection