Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Moving through a plane with "reusable" calculated pixels



  • Hi,
    I am planning an application where a user can navigate/"drive" through a (perspectively) transformed view of an (at least for now) 2-dimensional field, in which every single pixel has to be calculated in respect to its position on the field.

    When moving forward on this imaginary pane the view has to advance on the field, meaning that new pixels will definitely have to be calculated.

    The calculation itself is quite costly and cannot be approximated or conflated. I probably cannot use textures, as no part of the whole "field" is exactly repetitive. On the other hand, I haven't worked with textures yet, perhaps I misunderstand what they do.

    Therefore I'd like to have only those pixels to be calculated, that come into view. Those in view (already calculated) will just have to move (or diappear), as in the view of a driver, who moves through his/her world.

    I need advice on which basic component / item / I should base the whole thing on. Is there anything (perhaps in Qt-3D) that can offer parts of what I need?

    Any idea would be gratefully appreciated!
    SeDi


  • Lifetime Qt Champion

    Hi
    Do you have a picture of such "world" ?

    Im having a hard time to understand what the " calculated pixels" are. :)



  • @mrjj: I have not delved into that, because I don't want to discourage anybody with math geek stuff. It is not necessary for the problem to understand how the pixels are generated, I just need to fly over them.

    Anyway, of course I am happy to explain it:

    It's about fractals related to the Mandelbrot set / Julia set cosmos, which results from iterations of the formula x(n+1) = x(n)^2 + c, as brilliantly explained here. If you use complex numbers, this spans a 4D-vector space, where the pixels of the famous Mandelbrot set represent one (complex, thus 2D) parameter. My first stage would be just to "drive"/"fly" through a Mandelbrot-landscape.

    I do not want to just zoom in, as in this beautiful video, but rather have the graphics as a horizontal "field" that the user drives an imaginary bike over.

    Due to the fractality and iterational background of the backgound (pun intended), there is no faster way than to iterate each pixel. To be correct: there are a few speed-up possibilities in the original Mandelbrot set, where you can detect a position in its "head" (circle) or "body" (cycloid) and spare yourself that calculation - but such simplfications won't help me when I start to change the pane's position in the 4D space.



  • I am opening my QML with QQuickView to use SceneGraph as shown in the bottom.

    Would using a QtQuick Canvas be a good approach? Or is QQuickPaintedItem a better strategy? Or something else? I am lacking experience here and I don't want to base all that work on a wrong fundament....

    int main(int argc, char *argv[])
    {
        QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
    
        QGuiApplication app(argc, argv);
    
        MandelbrotIterator mandelbrotIterator;
        QQmlApplicationEngine engine;
        engine.rootContext()->setContextProperty("MandelbrotIterator", QVariant::fromValue<MandelbrotIterator*>(&mandelbrotIterator));
    
        QQuickView *view = new QQuickView;
            view->setSource(QUrl::fromLocalFile("qrc:/main.qml"));
            view->show();
    
        return app.exec();
    }
    

  • Lifetime Qt Champion

    Hi
    Its all much clear now. Hope you make a video when its finished.

    I cant say what is the very best approach.
    However, docs says

    "Also, if possible, prefer QQuickPaintedItem and implement drawing in C++ via QPainter instead of the more expensive and likely less performing JavaScript and Context2D approach."

    So QQuickPaintedItem might be faster.



  • It would be the fastest, if I had to recalculate every pixel on each paint event - but that's way too slow...

    So the question actually remains very open:

    "Therefore I'd like to have only those pixels to be calculated, that come into view. Those in view (already calculated) will just have to move (or diappear), as in the view of a driver, who moves through his/her world.

    I need advice on which basic component / item / I should base the whole thing on. Is there anything (perhaps in Qt-3D) that can offer parts of what I need?"


Log in to reply