Page 2 of 4

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 10 Apr 2018, 23:20
by AnyOldName3
If OpenMW is built using OSG >= 3.6 (which was just released) or using our fork, then there should be the ability to load a DDS image uncompressed. Otherwise, we might have to rely on the QtDDS image module which the Qt people have decided to stop building by default and to exclude from their binary releases because of security concerns (although I'm told that those security concerns apply equally to any bit of software that works with DTX/S3TC compressed images somehow).

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 11 Apr 2018, 10:10
by unelsson
If I understand the code at imagemanager.cpp correctly, it should automatically decompress loaded textures. In the case of "textures/tx_sand_01.dds" the function loads the image from cache, and apparently at some point in the program, (some/all?) textures have already been cached in compressed format.

I can think of solutions like overloading the Resource::ImageManager::getImage function with version that has two arguments: (const std::string &filename, boolean forceLoad) or just creating another function getNewImage or GetImageLoadNew that never loads from cache. Another, probably best, solution would be to implement software decompress also at terraintexturemode.cpp - there's code for that already in imagemanager.cpp, so it should not a big deal to copy paste the algorhitm.

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 11 Apr 2018, 12:18
by unelsson
Well now, that indeed doesn't work with osg 3.4, as setColor just isn't there. I wonder if it's important for new features to work with older versions of osg too?

Code: Select all

    std::string textureName = "textures/tx_sand_01.dds";
    Resource::ImageManager* imageManager = mData.getResourceSystem()->getImageManager();
    osg::ref_ptr<osg::Image> brushTextureOsg = new osg::Image();
    brushTextureOsg = imageManager->getImage(textureName);

    std::cout << "Pixel format before: " << brushTextureOsg->getPixelFormat() << std::endl; //33776 (compressed)

    if (brushTextureOsg->getPixelFormat() == 33776)
    {
        std::cout << "Software decompress" << std::endl;
        osg::ref_ptr<osg::Image> newImage = new osg::Image;
        newImage->setFileName(brushTextureOsg->getFileName());
        newImage->allocateImage(brushTextureOsg->s(), brushTextureOsg->t(), brushTextureOsg->r(), GL_RGB, GL_UNSIGNED_BYTE);
        for (int s=0; s<brushTextureOsg->s(); ++s)
            for (int t=0; t<brushTextureOsg->t(); ++t)
                for (int r=0; r<brushTextureOsg->r(); ++r)
                    newImage->setColor(brushTextureOsg->getColor(s,t,r), s,t,r);
        brushTextureOsg = newImage;
        brushTextureOsg->setInternalTextureFormat(GL_RGB8);
    }

    std::cout << "Pixel format after: " << brushTextureOsg->getPixelFormat() << std::endl; //6407, GL_RGB

    const uchar *qImageBuffer = (const uchar*)brushTextureOsg->data();

    QImage img(qImageBuffer, brushTextureOsg->s(), brushTextureOsg->t(), QImage::Format_RGB888);

    QPixmap pixmapObject(QPixmap::fromImage(img));

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 11 Apr 2018, 16:17
by AnyOldName3
We need to at least continue supporting our fork of 3.4, even if we end up dropping support for upstream 3.4.

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 12 Apr 2018, 09:48
by Zini
Correct. There are apparently a few concerns about stability issues with 3.6. I don't think we can make it mandatory now. The feature of showing the texture on the button is optional. I suggest we put it on hold for now. We can add it in later if the situation has changed/cleaned up.

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 06 May 2018, 20:41
by unelsson
Here's another question I feel silly to ask: After my branch has been merged to OpenMW, can I delete the branch from my github without worries?

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 06 May 2018, 21:00
by psi29a
unelsson wrote:
06 May 2018, 20:41
Here's another question I feel silly to ask: After my branch has been merged to OpenMW, can I delete the branch from my github without worries?
Yes, it was merged in so all your commits are merged. You may safely delete your branch.

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 06 Jul 2018, 17:20
by unelsson
Fixing https://github.com/OpenMW/openmw/pull/1769 requires some osg skills, so, any guidelines? Where to start? What do I need to know? Where's all the rendering code for OpenCS (or OpenMW)?

I've browsed through some osg code, and played a bit with osg examples, but that's all.

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 06 Jul 2018, 23:23
by AnyOldName3
When I looked over that PR, it didn't seem to involve too much OSG, and the bits that it did do seemed fairly simple. The only mistake was a general confusing-a-pointer-to-an-array-with-the-array-itself error, which is general C++ stuff rather than OSG-specific. You're doing okay already.

Re: Beginners' questions: Understanding OpenMW/OpenCS code

Posted: 07 Jul 2018, 10:00
by unelsson
Well, I'm kind of in a deadend with osg-code with my level of understanding. There's also some fundamental value in learning osg, so it wouldn't hurt to actually get some skills regarding that. I didn't write the code in the PR for osg, my skills regarding osg are still below that. The fix you mentioned alone doesn't fix the segfault, and although I kind of understand the reasoning behind (ref_ptr is not an array, but is some other kind of osg-thingie), getting deeper into fixing it requires more knowledge.

Another, kind of generic C++ question, is whether it's good to use typedef's/declarations in the code in order to shorten and simplify code segments? Developer reference of OpenMW says: "Using declarations (e.g. "using std::cout") are tolerated, but should be used only in the innermost possible scope (i.e. usually function scope). Fully qualified names are still preferred." I also personally like fully qualified names, as I feel the code is easier to read like that, but some authors recommend shortening code almost in any way possible. I've read something about it online, but what do you think, any comments regarding this?