Closed kmkolasinski closed 8 years ago
While I'm a novice at best as a developer and don't have a ton of time myself, I can probably help out a little bit. I'm not familiar with OpenGL or graphics code in general, but I might be able to fix small bugs and improve some of the code logic. Because of my limitations I'm probably not a good candidate to become an official maintainer though so keep that in mind :-)
I would like to help with the development of AB, but I'm not even familiar with the C++ language, much less Qt and OpenGL. I hope I can help later on in the project, but I don't have the necessary skillset.
To be honest my knowledge of C++ ends on then first class of this language :) As you probably noticed I put everything public, because I'm to lazy to write those get/set functions. So basically the code is one big collection of classes which just work as a simple containers for some objects. There is nothing specially complicated in the code. Basic knowledge of C++ or even Java is enough to start writing some code. I was thinking about few things which could be added:
Those are my proposals. I can supervise you where to start and what to do, maybe even I will do some of those points if I find a time.
Thanks, it makes it a little easier to have a task wish list. I have actually been working on creating a cmake compilation/install solution for AB to make it much easier to verify dependencies, build the software, and do a lot of automated but customizable build and install procedures. Hopefully that will be accepted into the codebase at some point after it's ready. Then I can check into these other tasks.
Hi - I would be glad to help - here are some of my thoughts: 1) one of my biggest problem when working on osx port was that huge (170k) mainwindow.ui - I have tried to apply some changes (like smaller margins etc) but it always lead to conflicts - manually merging file took days. My idea was to replace all these settings views with much more coherent property panel:
Using QtnProprty lib we can describe all props in external text files, like this:
enum COLOR { red (1, "red"), blue (2, "blue"), green (3, "green") }
enum FLAGS { opt1(1, "Option1"), opt2(2, "Option2"), opt3(4, "Option3") }
enum SHADINGMODEL { pbr(0, "PBR shading"), bumpMapping(1, "Bump mapping") }
enum BLENDINGMODE { blendNormal(0, "Normal"), blendMultiply(1, "Multiply"), blendAdd(2, "Add"), blendSubtract(3, "Subtract"), blendDifference(4, "Difference"), blendDivide(5, "Divide"), blendScreen(6, "Screen"), blendOverlay(7, "Overlay"), blendDodge(8, "Dodge"), blendBurn(9, "Burn"), blendDarkenOnly(10, "Darken Only"), blendLightenOnly(11, "Lighten Only") }
enum INPUTIMAGE { inputCurrent(0, "Current image"), inputHeightInput(1, "Height (Input)"), inputHeightOutput(2, "Height (Output)") }
property_set AwesomeBump { // Diffuse image property_set DiffuseImageType DiffuseImage { description = "Diffuse Image"; QString Dummy { description = "Dummy"; } }
// Normal imageproperty_set NormalImageType NormalImage { description = "Normal Image"; QString Dummy { description = "Dummy"; } }
// Specular image property_set SpecularImageType SpecularImage { description = "Specular Image"; QString Dummy { description = "Dummy"; } }
// Occlusion image property_set OcclusionImageType OcclusionImage { description = "Occlusion Image"; QString Dummy { description = "Dummy"; }
}
// Roughness image
property_set RoughnessImageType RoughnessImage
{
description = "Roughness Image";
QString Dummy
{
description = "Dummy";
}
}
// Metallic image
property_set MetallicImageType MetallicImage
{
description = "Metallic Image";
QString Dummy
{
description = "Dummy";
}
}
// Materials image
property_set MaterialsImageType MaterialsImage
{
description = "Materials Image";
QString Dummy
{
description = "Dummy";
}
}
// Grunge general settings
property_set GrungeGeneralSettingsType GrungeGeneralSettings
{
description = "Grunge general settings";
Int OverallWeight
{
description = "Set common blending weight factor for all textures
blending.";
value = 0;
minValue = 0;
maxValue = 100;
stepValue = 1;
}
Int Randomize
{
description = "When 0 - use orginal image, otherwise generate random
seamless image.";
value = 0;
minValue = 0;
maxValue = 100;
stepValue = 1;
}
Int Scale
{
description = "It scales the UVs of generated random image. Value 1
is neutral.";
value = 1;
minValue = 1;
maxValue = 100;
stepValue = 25;
}
Int NormalWarp
{
description = "Warps grunge texture pixels along normals of normal
texture.";
value = 0;
minValue = -100;
maxValue = 100;
stepValue = 1;
}
QString Predefined
{
description = "Load predefined grunge map from list. Note that
predefined grunge textures are located in Core/2D/grungefolder. You can paste there your own images in oder to make your own list of grunge images." ;
delegate List
{
items = QStringList() << "one" << "two" << "three" << "four";
}
}
Bool RandomTranslations
{
description = "Random translations.";
value = false;
}
Bool ReplotAllTexturesWhenChanges
{
description = "Replot all textures when changes.";
value = false;
}
} // end group
// Grunge pattern
property_set GrungePatternType GrungePattern
{
description = "Grunge pattern";
Enum BlendingMode
{
description = "Blending modes are same as in GIMP program.";
enumInfo = &BLENDINGMODE::info();
value = BLENDINGMODE::blendNormal;
}
Int GrungeWeight
{
description = "This is blending factor for grunge image. 0 - no
grunge.";
value = 0;
minValue = 0;
maxValue = 100;
stepValue = 1;
}
Int ImageWeight
{
description = "This is blending factor for this image. 0 - no grunge."
;
value = 0;
minValue = 0;
maxValue = 100;
stepValue = 1;
}
} // GrungePattern
// UV settings
property_set UVSettingsType UVSettings
{
description = "UV Settings";
QString Dummy
{
description = "Dummy";
}
}
// Input image
Enum InputImage
{
description = "Choose the input image for further processing.
Warning: when current image is selected and UV transformation are applied then output normal image may not by transformed properly.";
enumInfo = &INPUTIMAGE::info();
value = INPUTIMAGE::inputCurrent;
}
Float DepthInPixels
{
description = "It changes the depth of the calculated normal map in
pixels unit. For example: lets assume that you have picture of wall of size 1x1 m2 in real world with bricks pattern and your image has size 1024x1024 pixels. Then you want to generate normals for texture which depth is 3cm = 0.03 m. So the depth in pixels is 0.03*1024 = 30.72 ~ 31 pixels.";
value = 20;
minValue = 0;
maxValue = 1000;
stepValue = 1;
}
//Action RecalculateFromNormals {
// description = "";
//}
}
QtnProprty is quite powerfull - we can add c++ code directly into description file, create custom types, handlers, etc. It is easy to serialize properties, adding new ones, working on look&feel etc. All other controls should go to toolbar, so main window would be a clean property + opengl previews.
2) my second improvement that I once worked (but failed because was not able to merge these changes) was to separate calculation and drawing. Currently (I think) all calculation is done inside paint methods - this might not be efficient: having separate update method allows to render to texture in background thread and paint these texture after the calculation is done (there is a background rendering example in Qt)
Regards
Pawel
On Mon, Nov 9, 2015 at 9:15 AM, Krzysztof Kolasinski < notifications@github.com> wrote:
To be honest my knowledge of C++ ends on then first class of this language :) As you probably noticed I put everything public, because I'm to lazy to write those get/set functions. So basically the code is one big collection of classes which just work as a simple containers for some objects. There is nothing specially complicated in the code. Basic knowledge of C++ or even Java is enough to start writing some code. I was thinking about few things which could be added:
- Add the possibility to translate GUI to any language -- now all GUI is hard-coded which means that there is no easy way to change language, but with a bit of patience one may put all the labels to some file and load them during the initialization. This is rather easy but time consuming task. (How hard: easy, Time consumption: 10-20 hours)
- Second one is: Add some memory usage statistics, currently there is one label which works only with NVIDIA cards (How hard: easy, Time: few hours).
- Batching images would be nice, if one has few images which has similar properties (lightning/colors/patterns) it would be nice to automate the process. This would require to create a new QtWidget with list of images (How hard: easy, Time: few hours).
- I would be also nice to add the possibility to work on whole mesh not only on one image i.e. mesh would consist of few material and different textures, this is also possible in AB but that would be rather hard to do for person who does not know the code very well (How hard: medium - if know know where to start, Time: few days)
- There is also a possibility to add new filters for image processing. This task is very easy unless you don't know how to write GLSL filter :P (Time: depends how complicated GLSL filter is, after that you just need few copy-paste operation to make it work in AB)
- Better GUI - there is a prototype of new GUI in @ppiecuch https://github.com/ppiecuch repository you can take a look there and see if you like it.
Those are my proposals. I can supervise you where to start and what to do, maybe even I will do some of those points if I find a time.
— Reply to this email directly or view it on GitHub https://github.com/kmkolasinski/AwesomeBump/issues/57#issuecomment-154993779 .
More:
(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html) (http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)
@ppiecuch : I think it might be better to discuss your ideas in a separate issue because it might be a bit of an involved conversation with lots of branching topics. I would like to say that I think you'd be a valuable contributor since it seems you know quite a bit about Qt and its GUI architecture. That's one of my limitations. I really like your idea about separating render calculations from the main thread though. Performance on one of my older machines is a bit slow now and I think your idea would bring a good improvement. FWIW I'd trust your expertise on the QtnProperty thing and it sounds good to me. Not my project though :-)
Hi,
PS: I would like to make this project 'us' not only mine, since this is the only way to improve this program. If one person like me have no time for that there will be always another fresh and motivated person to add his few cents to this project.
PPS: Let me rewrite the TODO list again:
Yes - "textureInThread": thread process has its own context, but shared with main one:
m_renderThread->context = new QOpenGLContext();
m_renderThread->context->setFormat(current->format());
I think thread rendering should be an option: thread/non-thread rendering. What would be good at the beginning is to logically split updating and painting. Later updating could be make threaded/non-threaded.
Regards
P.
On Tue, Nov 10, 2015 at 10:38 PM, Krzysztof Kolasinski < notifications@github.com> wrote:
Hi,
- QtnProprty - sounds nice, but since I'm not familiar with the concept of property, I don't even know where to start to add this functionality in AB, It would be nice if you could start update some part of code such that I will able to image how do you want organize it. Then, I will able to help you.
- Yes, you are right all the texture processing are done in the: void GLImage::render() https://github.com/kmkolasinski/AwesomeBump/blob/master/Sources/glimageeditor.cpp#L318. The processing pipeline in that function depends for example what tab is chosen or what are the current user actions i.e. user wants to resize all the textures, user want to recalculate ambient occlusion etc. The whole function is quite complicated since all the functionality of the program is there. That is why there is a lot of "if" statements. Dividing calculations from rendering would be nice from the user point of view -- smooth rendering -- but I don't think if it will be faster. Now, if there is no action on the textures, the only processing is the 3D processing namely PBR, bumpmapping, DOF, Lenses etc. But if you want to change something, all the calculations are done sequentially using the available GPU resources (only few filters uses CPU to perform some calculation) within the render( ) function. Dividing task on: rendering and calculations separately divides your resources, and processing time, since not every task can be done parallel on GPU -- in my opinion -- unless you want to do the calculation for small textures, which usually do not need large amount of GPU resources to be used. Another question -- if you divide the task as you described above do you need to have multiple GL contexts? If yes I think that would require rewriting the whole program :/ Which also could be nice :) But nobody has time for that, especially, if you do it for free :) Do you remember the name of the Qt demo with background rendering: it is textureinthread? Basically, I think that it is a good idea, but I also think that it may require a huge amount of work, such that it would be even easier to start writing AB from the beginning than doing merges...
— Reply to this email directly or view it on GitHub https://github.com/kmkolasinski/AwesomeBump/issues/57#issuecomment-155574969 .
More:
(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html) (http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)
Hi, 1) Maybe it would be easier to rewrite whole mainwindow.cpp and related ui from the begining, such that GUI will be scalable and editable. It should be easy since you know exactly what it has to do to work. Starting from scratch and adding new features should be quite easy. 2) splitting rendering from calculation - the idea is to write two functions render() + draw() instead of two, if I well understand you? Normally, when there is no action only the draw() function will be called to render textures, otherwise some filter will be applied with render() and draw() to display result? If yes I think I can try to do this :)
Hello 1 - correct - this is an option too - but not sure if this is an easier. You could eg: split mainwindow.ui into several smaller ones. But this still would be a challenge to eg: change margins for each controls or something similar. This is what stops me at some point: I wanted to make a look more OSX friendly but after all I was not able to merge these. On the other side
Regards P.
On Wed, Nov 11, 2015 at 7:14 PM, Krzysztof Kolasinski < notifications@github.com> wrote:
Hi, 1) Maybe it would be easier to rewrite whole mainwindow.cpp and related ui from the begining, such that GUI will be scalable and editable. It should be easy since you know exactly what it has to do to work. Starting from scratch and adding new features should be quite easy. 2) splitting rendering from calculation - the idea is to write two functions render() + draw() instead of two, if I well understand you? Normally, when there is no action only the draw() function will be called to render textures, otherwise some filter will be applied with render() and draw() to display result? If yes I think I can try to do this :)
— Reply to this email directly or view it on GitHub https://github.com/kmkolasinski/AwesomeBump/issues/57#issuecomment-155865352 .
More:
(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html) (http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)
Hi, I did some changes in the glImage class. You can take a look and tell me if it is what you need: Basically now in paint function there is a "if" which decides if there will be some operation on the texture performed: if YES, then rendering is performed -- final result is drawn to renderFBO. If NOT simple draw of "paintFBO" is done. After rendering the "renderFBO" is copied to "paintFBO". I think this render function can be done in thread, however in that function there are still textures which are used by the glWidget (the target* variables), so if you run this function in a thread glWidget may try to read the textures which are currently processed... :/ I think I know how it can be solver but it will require more amount of memory usage. But there is another problem which will require a lot of work, consider the threading will work: user wants to process some texture, now if the processing is running there is no way to start another process, so there will be no collisions. If you want to have two threads you now have to take care about such possibility. Or maybe I'am wrong?
For those who are interested in AB development: I've added intentionally one tool to the program such that you can follow this commit https://github.com/kmkolasinski/AwesomeBump/commit/22d041dc00be2542bc9a4e018728599d059391f2 to understand what needs to be done in order to add new features/filters for image processing. Basically the way how it works in AB is terrible :D it definitely should be done using some more sophisticated methods, but just I told you many times, at the beginning AB was a toy for playing with texture, so I did not care about the logic at all :/ Now is too late :P Ok, so what has to be done to add something new to AB:
Basically that's all to make things working in AB. Hope this help you understand the code a bit.
Ok, in the next step I will try to improve the "3D settings" window, which im my opinion is the most annoying widget in AB. Maybe it would be nice to have it floating not inside the GUI? I'm talking about that:
Ok, the issue above is solved, I created separated class for managing this window. Current version, is just a proposal if you think people will not like it (the tab widget inside 3D window). Then I think @ppiecuch may to implement this qtnProperty to show us how it should be done. Then It would be also nice to think about the possible translation of the GUI. I waiting for your proposals :)
Still working on my GUI but because of my daily job I think I will get it at the end of the week.
Regard P.
On Sun, Nov 15, 2015 at 12:23 AM, Krzysztof Kolasinski < notifications@github.com> wrote:
Ok, the issue above is solved, I created separated class for managing this window. Current version, is just a proposal if you think people will not like it (the tab widget inside 3D window). Then I think @ppiecuch https://github.com/ppiecuch may to implement this qtnProperty to show us how it should be done. Then It would be also nice to think about the possible translation of the GUI. I waiting for your proposals :)
— Reply to this email directly or view it on GitHub https://github.com/kmkolasinski/AwesomeBump/issues/57#issuecomment-156757224 .
More:
(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html) (http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)
Ok, we will wait no problem, there are another things which can be done in parallel.
@kmkolasinski I would like to help and contribute to this project since its kinda equal to most of the commercial products. Here is, what I can do.
Why that great emphasis on Unity?
Unity is used by more than 4.5 Million developers. Many of them, I would say a 3/4?, are indie developers that cannot spend the horrendous sum of 150$ for Allegorithmics B2M or any other Bump Mapping Tool. People like me. My "game" was looking bad because I only had flat surfaces, a bad normal map, no height and occlusion map etc. Until I discovered AwesomeBump (I used InsaneBump which was unintuitive and not userfriendly). After some minutes of pushing sliders and stuff, I was able to produce some results that looked fantastic, especially in Unity. If the GUI is cleaned up and support for Unity is added, this project is definetly going places. Thus there is the possibility to reach thousands (think of ten thousand and more) of developers that are in need of a strong mapping tool.
Hi, thank you for the ideas :)
Edit: Oh and where do you calculate the different maps etc.? I cant find the code for that
Great, we should do that ;)
So, if you can spare some time, just let me know. I ve already got the gist, but some features are not clear to me. Thus I would like to ask you a few things, program related and code related, so I hope I can reach some people with my tutorials then. Email me: karstentorman1122@gmail.com, so we can get in contact.
I'm closing this issue. Some of the enhancements mentioned in that issue were done during up to this time, but some not. I have no time work on this project. In few days I will prepare final release for 5.0 version.
Hi there, Since I saw that there is quite large group of people who are interested in making this software better, maybe it would be a good idea to make AB more accessible for other people. The problem is that this program is poorly written, I started from nothing then I was adding new features, some part of the code are commented some not, some are in Polish :D
I think that would be nice to improve this software, but unfortunately I have no time for that :/
Because I'm the only one person who knows this software the best I could guide you and explain how does it work and where to start, such that you could improve AB in future. Of course any person who would be interested in such collaboration will become an co-author of this project (btw this project does not have to be related to my github profile). There is still a lot of to do!
Is there any person who would like to participate in AB development ??