What is the deal with pivy?

[triplus]

Currently in my opinion Pivy/Coin3D situation is still manageable. The real challenges ahead are likely related to new technologies, such as supporting potential successors of OpenGL, Qt beyond Qt Widgets, some bug on some platform emerging and not being easy to fix ... Here situation could become daunting, but it hasn't become yet. As for OSG, not having Python bindings, that is an issue for us.

P.S. If anybody would like to explore porting to some other library for our viewport purposes in code, fell free to do that.

[Joel_graff]

OpenSceneGraph, at least on Debian, also depends on Coin, btw.

Really? How odd. Any idea why?

[Joel_graff]

As for OSG, not having Python bindings, that is an issue for us.

I thought of that after I posted and looked it up. There's an inactive project that dates back to 2012, I think. I suppose we'd have to resurrect that... Otherwise, OSG does haves Lua bindings. Hmmm.

In any case, while I've never anything like a Python binding class, for as daunting as I suspect that would be, it sounds interesting. It also seems like something I'd do once - and never again.

[tanderson69]

OpenSceneGraph, at least on Debian, also depends on Coin, btw.

Really? How odd. Any idea why?

I have spent quite a bit of time with OSG and feel confident in saying "The OSG coin dependency is only for reading/writing the inventor file format. OSG is a complete, separate and (IMHO)better scene graph".

[Joel_graff]

I have spent quite a bit of time with OSG and feel confident in saying "The OSG coin dependency is only for reading/writing the inventor file format. OSG is a complete, separate and (IMHO)better scene graph".

That explains it. Sounds like a dependency that could be managed separately to make the packaging easier. Now to just write some Python bindings that integrate seamlessly with pivy.

[tanderson69]

Now to just write some Python bindings that integrate seamlessly with pivy.

Good luck with that.
http://forum.openscenegraph.org/viewtopic.php?t=17235




Vulkan Scene Graph (VSG)
https://www.youtube.com/watch?time_cont ... VGcNAGhXQM

[Joel_graff]

Vulkan Scene Graph (VSG)

phpBB [video]

Reposting the video link with video tags.

Thanks for that. I totally needed an hour long presentation to consume my attention.

[looo]

To have a project that cannot be reliably built on one of the target platforms...I dunno, to me that's not a very "live" project.

It would seem that a first priority should be to make the project buildable.

Come on, this is really not part of a project to care about distro xy with dependencies in different versions. We test the FreeCAD/pivy repo with conda for all 3 major plattforms (that is what we need, right, one build which works on nearly all linux). If distro xy has problems to compile pivy please report your problems, but it's maybe a bit more difficult to get it working, because of the version mess coming with different distros (different Python versions, different coin versions...) Virtual envs are the much cleaner approach for handeling different versions of the same packages. Therefor I prefer conda.

[ezzieyguywuf]

Come on, this is really not part of a project to care about distro xy with dependencies in different versions. We test the FreeCAD/pivy repo with conda for all 3 major plattforms (that is what we need, right, one build which works on nearly all linux). If distro xy has problems to compile pivy please report your problems, but it's maybe a bit more difficult to get it working, because of the version mess coming with different distros (different Python versions, different coin versions...) Virtual envs are the much cleaner approach for handeling different versions of the same packages. Therefor I prefer conda.

I don't expect the project team to worry about every distro. Rather, I expect that if I have the necessary dependencies available, that I be able to:

1. Configure the project (i.e. mkdir build && cd build && cmake ..)
2. build the project (I.e. make)

The current issue I am having with pivy is that I cannot configure it due to some issues with assumptions that the setup.py is making about the availability of a Coin.cmake file.

By parsing through setup.py, I was able to determine that cmake is being used - after which I was able to manually edit CMakeLists.txt to provide the necessary variables.

Even if we disregard the steps needed to get the project to configure (which, in my opinion, are already non-intuitive), after making the adjustments I was able to build and install the package, but it is still unusable.

So now, I'm left in a weird spot:

1. Is the issue due to a missing dependency? Well, the README doesn't mention any specific dependencies. I guess I need Coin, but I have that...
2. Is the issue due to my manual specification of Coin_FOUND, Coind_VERSION, etc...? How would I know?
3. Is the issue actually upstream?

I have no clear way to determine this due to state of the project.

Please don't misunderstand me - I am not attempting to start any sort of argument or dispute. I am far from any sort of professional programmer or software guy. I'm nothing more than a humble mechanical engineer who likes to do some coding.

These thoughts and views are solely my own opinion, and should in no way be taken to mean that anyone should do anything differently.

Edit: All that to say - I'm probably just too thick to realize that I'm doing something wrong.

[looo]

Even if we disregard the steps needed to get the project to configure (which, in my opinion, are already non-intuitive)

If you know how to make it more intuitive, go ahead and make a proposal. Maybe rewriting the config with cmake would work. But this is for sure also not an easy task.

Why things might not work for you:
1. You are using coin from package manager which might be too old and doesn't contain cmake configs
2. You might use latest coin which introduced incompatibilities
3. The coin cmake configs are not correctly I stalled by your system package manager
4. The paths are formated in a different way and need to get special treatment.

To solve 1 and 2 you can have a look at the commits/version used for conda-packages:
https://github.com/conda-forge/coin3d-f ... ta.yaml#L3
https://github.com/conda-forge/pivy-fee ... ta.yaml#L2

BTW.: What distro are you using?

Even if we disregard the steps needed to get the project to configure (which, in my opinion, are already non-intuitive)

Blaming about non intuitive configuration won't solve your problem. Either you get active or other users of your distro might see the same issue.

... I was able to build and install the package, but it is still unusable.

Again several reasons:
- Incompatible coin versions
- wrong install paths
- ...

We need some reports, else we cannot suggest anything.

I am far from any sort of professional programmer or software guy. I'm nothing more than a humble mechanical engineer who likes to do some coding.

There is no excuse. I do not had any specifications to start porting pivy to python3. For sure with help of @wmayer and others. But in the end I often had situations where I felt like I can't solve a problem. Looking at the source, googling similar problems and trying to make some assumptions what's possible wrong helped most of the time. If you really have no clue how to solve the problem, try to write a good report what is failing. Often writing about your problem already gives you an idea what's wrong.