CMake glm problem

[catbao]

Hi！ When I try to run it, I meet a problem like this after I download the needed dependencies.

And in the /src/CMakeLists, there is one line "set(glm_DIR ${CMAKE_SOURCE_DIR}/lib/glm/cmake/glm)" but when I download the dependencies, I found the catalogue is below:

It is not right compared with the above one line.

Thank you for taking up your time!

[TTrautner]

Hey, cool to see that you are trying out our project!

The cmake as it is, supports Visual Studio 2017 (see CMakeLists.txt and CMakeSettings.json) and windows 64 bit. When fetching and building the libraries, I would also suggest using “x64 Command Prompt for VS 2017”, run as administrator. Check if it runs without errors, it might be easy to overlook while more and more is printed on the console.

I assume it can’t find it because you maybe haven’t built the right version for your system. I don’t have a line "set(glm_DIR ${CMAKE_SOURCE_DIR}/lib/glm/cmake/glm)" in my /src/CMakeLists and can run it.

One more thing, check the file “.vs/launch.vs.json”. It contains two times "projectTarget" and "name". Make sure that they lead to the correct path, i.e, executable, on your machine.

Best, Thomas

[catbao]

Thank you for your anwser, I have solved this problem.Very thank you！

After I read this article, my first impression is that this approach is similar to order-independent transparency rendering, but you introduce an importance function to neatly calculate the result of the final rendering. But I still have some doubts. I would like to ask what you think is the similarity and difference between this method and the order-independent method.

Sorry for taking up your time！It's very nice of you!

Best wishes!

[TTrautner]

Hey, good work, nice it’s running!

Well, the answer is luckily quite simple. Order-independent transparency renders the lines as they arrive on the GPU (not necessarily sorted in any way) and tries to achieve a visual result that looks as if the lines were sorted from back to front and then blended. It is often used when rendering many overlapping lines (e.g., a massive hairball), where it would not be feasible to sort them because it would take too long and result in a frames-per-second drop making the application non-interactive.

We, however, do not want to approximate the result but calculate it most accurate and, therefore, sort the lines using their importance/relevance and then blend them accordingly. I also experimented with order-independent transparency, but I would consider this as fallback in our situation. For example, do the precise calculation as long as it can be done and when the used data sets increase so much, potentially fall back to the approximation avoiding an FPS drop and reduced interactivity.

Hope I could help you, all the best!

[catbao]

Thanks again for your answer, it has taught me a lot！

I really admire your ideas and papers. But I also have a small question in your anwser (Maybe because I'm just getting started in this direction so the question is not so professional ). That is, you say you also experimented with order-independent transparency, as I think, lineweaver is used for 2D line chart, but I also checked some literature, the OIT is used for 3D scene. And this makes me a little confused. I want to know can OIT used in 2D or how can it used in 2D scenes? And, the example given in the paper has the button "depth" shown in the below, but in 2D I think there is no concept of depth because they are on a plane, is the 'depth' specified in the order of rendering? That is, the line drawn first is deeper?

Also, if I want to do transparency in 2D, do you have any insights or suggestions?

I'm very grateful for you! Best wishes!

[TTrautner]

Hey catbao,

the order of lines is relevant to consider in 2D as well as in 3D. In 3D, however, there are many related and already published approaches that focus on, for example, the enhancement of their, i.e., lines and line bundles, perception; efficient ways to render them, etc. In 2D, the dependency on the blending order is often ignored although it is a strong influencing factor, which is why we published our findings (using classic 2D line charts).

Full-Text PDF: https://www.researchgate.net/publication/351099907_Line_Weaver_Importance-Driven_Order_Enhanced_Rendering_of_Dense_Line_Charts

The video of the presentation is also available, and I would highly recommend watching it in case you haven’t seen it yet, as it could help to understand the concept of the paper better. YouTube video of the presentation: https://youtu.be/-hLF5XSR_ws

For example, the order will influence the 2D result if lines are not just monochromatic (e.g., all black and fully opaque), when they have a certain line thickness (e.g., more than just a pixel), when they overlap each other, etc. This means that order and depth (referring to how lines are stacked on top of each other) will influence the visualization result. In order to show the influence of order(ing), our renderer has its own “Color Modes”. One example is "Depth", in which lines are no longer displayed in one color but have an additional color gradient that shows the progression from the front-most layer to the back-most layer.

Since you also asked about transparency in 2D, which is also referred to as “alpha compositing”, here a useful link to start your research: https://en.wikipedia.org/wiki/Alpha_compositing

As we move further and further away from the actual technical problem, i.e., getting the project up and running using CMake, I'm closing this thread! If you are working for a research institution and are interested in a potential future collaboration, please feel free to reach out to me using the usual channels.

Best, Thomas

[catbao]

Thank you for your patience! I have learned a lot from your anwser. I'm new to this field and I hope I can have a chance. Thanks again!

Best wishes!

[TTrautner]

Hey, good work, nice it’s running!

Well, the answer is luckily quite simple. Order-independent transparency renders the lines as they arrive on the GPU (not necessarily sorted in any way) and tries to achieve a visual result that looks as if the lines were sorted from back to front and then blended. It is often used when rendering many overlapping lines (e.g., a massive hairball), where it would not be feasible to sort them because it would take too long and result in a frames-per-second drop making the application non-interactive.

We, however, do not want to approximate the result but calculate it most accurate and, therefore, sort the lines using their importance/relevance and then blend them accordingly. I also experimented with order-independent transparency, but I would consider this as fallback in our situation. For example, do the precise calculation as long as it can be done and when the used data sets increase so much, potentially fall back to the approximation avoiding an FPS drop and reduced interactivity.

Hope I could help you, all the best!

From: catbao @.> Sent: Saturday, August 13, 2022 3:08 AM To: TTrautner/LineWeaver @.> Cc: TTrautner @.>; Comment @.> Subject: Re: [TTrautner/LineWeaver] CMake glm problem (Issue #1)

Thank you for your anwser, I have solved this problem.Very thank you！

After I read this article, my first impression is that this approach is similar to order-independent transparency rendering, but you introduce an importance function to neatly calculate the result of the final rendering. But I still have some doubts. I would like to ask what you think is the similarity and difference between this method and the order-independent method.

Sorry for taking up your time！It's very nice of you!

Best wishes!

— Reply to this email directly, view it on GitHubhttps://github.com/TTrautner/LineWeaver/issues/1#issuecomment-1213622360, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGMNTMCQHJKOMTH665T2RB3VY3YQFANCNFSM5546LV5Q. You are receiving this because you commented.Message ID: @.**@.>>