Beginners' questions: Understanding OpenMW/OpenCS code
- AnyOldName3
- Posts: 2678
- Joined: 26 Nov 2015, 03:25
Re: Beginners' questions: Understanding OpenMW/OpenCS code
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
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.
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
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));
- AnyOldName3
- Posts: 2678
- Joined: 26 Nov 2015, 03:25
Re: Beginners' questions: Understanding OpenMW/OpenCS code
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
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
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?
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Beginners' questions: Understanding OpenMW/OpenCS code
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.
I've browsed through some osg code, and played a bit with osg examples, but that's all.
- AnyOldName3
- Posts: 2678
- Joined: 26 Nov 2015, 03:25
Re: Beginners' questions: Understanding OpenMW/OpenCS code
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
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?
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?