Congrats Roman, a huge achievement, got it on my nexus phone ;)

Btw, the non-blocking viz. workflow is a big deal... thanks for pushing that one!

So I see cad exchanger is only able to be installed on tablets, not phones?

Hi Jelle,
Thank you for your support. CAD Exchanger should run on phones (we did have engineering versions running). The point is that the layout has not been optimized for phones yet, so user experience can be suboptimal.
We certainly have phone port on our roadmap.
Thanks again,
Roman

hi Roman,

Ah, so i tried installing through google play, but its stated that the app isnt compatible with my phone, which is an LG nexus 5

Too bad. Sorry Jelle. I've filed a bug report to our developers for them to check. Please stay tuned.

Hi Roman,

I've just started to work on porting some of the pythonocc code to QML.
I read that a lot of hard work was done such to port OCC to be able to utilize QML, right? I'm working on refactoring the GL widget to use Qt5's QOpenGLWidget rather than Qt4's QGLWidget. Can you comment on the minimal OCC version to be able to use QOpenGLWidget? Is that 6.8.0? IIRC that's the first demonstrating CAD Assistant / running on android, right?

Thanks! I think you guys have been sponsoring this transition, and I'm really looking fwd combining (python)OCC and QML...

-jelle

Hi Jelle,

The minimal appropriate OCC version is 6.9.0. You might certainly want to refer to samples/qt/AndroidQt.

A couple of notes on peculiarities which we had to take into account:
- connection to existing OpenGL context;
- use of shaders instead of fixed pipeline
- dedicated threads to UI, rendering and computations;
- use of FBO.

Good luck with the port!
Roman

Hello Roman,

Could you maybe elaborate how you did setup OCC to render into an FBO and render that FBO into a QQuickItem?

I tried with something based on
https://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/

But I cannot get it to work. Maybe the QQuickFrameBufferObject is not the way to go because it itself is already an FBO

Would really appreciate it,
Thanks,

Dirk

Hi Dirk,

Sorry for getting that long to respond - although on my TODO list your inquiry got buried too quickly with other stuff.
Anyway, if that is still relevant here are some tips shared by our lead GUI developer who made that QML/Android port:
There are two approached to combine OCC rendering with Qt 5:

1. Render OCC to Qt Quick Window directly when "beforeRendering" signal is emitted.

See AndroidQt occ 7.0.0 sample and "OpenGL Under QML" Qt example (http://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html).

Pros of this approach are:
- minimum actions to use OCC with QtQuick;

Cons:
direct rendering to window (so it take all window space), so you cannot use QtQuickItem transformations, rotations, effects, etc.

2. Render OCC to QtQuickFrameBuffer.
OCC cannot use QtQuickFrameBuffer for rendering, but you can use as follows: render to OCC frameBuffer (see V3d_View::ToPixMap method as reference), then blit OCC frame buffer to Qt frame buffer (see OpenGl_View::blitBuffers method as reference).

Pros:
- full compatibility with recommended Qt Quick item rendering;
- all features in Qml code;

Cons:
- complicated implementation and some memory overhead;
- OCC frameBuffer size should be kept in sync with Qt frameBuffer size;
- Qt Quick use multi-threading rendering, so you should guarantee all OCC rendering methods be called in a dedicated render thread.

Hope this will give you some food for thought.
Good luck!

Thanks for the hints Roman!

I will take a look!

Dirk

Hi Roman,

I finally had some time again to play with qml and OCC and managed to implement rendering by using a framebuffer and bltting the OCC FBO in the QQuickFramebufferObject::Renderer derived class.

Now I am trying to implement mouse interaction and my first attempt was to queue all the important mouse messages and synchronize them in the renderer. Then in the render function I loop through all the messages in the queue and call view->Rotation view->Pan which now render in the FBO accordingly. If the queue is not empty I call update which schedules to call render again. This works but mouse interaction and visually seeing the result lags behind a bit. It feels more natural if the changes are immediate. How did you solve mouse interaction if I may ask?

Kind regards,

Dirk

Hi Dirk,

We collapse sequential events of the same kind in the queue and only process the resulting one.

Qt mouse events can be emitted very often (once every 1-2 ms), but rendering occurs less often. If to process all the events in order, the renderer will spend a lot of time for rendering: every view manipulation will require a piece of time. But during frame rendering a lot of new mouse event will be received and they will be processed only on the next frame rendering. So we use mouse event reducing before view manipulation to avoid unnecessary time spending.

For instance, the renderer received:
1. Pan mouse event
2. Pan mouse event
3. Pan mouse event
4. Rotation mouse event
5. Rotation mouse event
6. Rotation mouse event

What you can do with events:
1. Start panning.
2. Merge with previous event.
3. Merge with previous event.
4. Finish panning (because a new operation has been detected). Start rotation.
5. Merge with previous event.
6. Merge with previous event.
7. Finish rotation (because no events in the queue).

As a result only important updates can be applied to the 3D view.

Just in case, we provide a simple visualization example based on Qt/QML. Of course, it's connected to CAD Exchanger SDK but if this is something you are open to consider, just let me know.

Good luck!
Roman

Hi Roman,

Thanks very much, makes perfect sense!

Dirk

Hi Roman,

This makes perfect sense! Thanks very much.
I replied earlier but it didn't come through so it seems.

Dirk

Sure Dirk! Glad this helped. Good luck!