Need of collaboration

[kmkolasinski]

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 ??

[CodePhase]

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 :-)

[ghost]

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.

[kmkolasinski]

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 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.

[CodePhase]

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.

[ppiecuch]

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:

#include <Core/PropertyCore.h>
#include <Core/PropertyGUI.h>

#include_cpp

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
#57 (comment)
.

More:

(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html)
(http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)

[CodePhase]

@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 :-)

[kmkolasinski]

Hi,

1. 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.
2. Yes, you are right all the texture processing are done in the: void GLImage::render(). 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...

[kmkolasinski]

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.

[kmkolasinski]

PPS: Let me rewrite the TODO list again:

• 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. This could be helpful for further memory optimalization (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 repository you can take a look there and see if you like it. Keep all the properties in the QtnProperty class.
• Divide the rendering and computation between different tasks. In my opinion this is really hard to implement in AB.
• Improve wiki, add there some examples, and algorithm explanation, tips and tricks

[ppiecuch]

1. I can prepare some initial QtnProperty description - no problem: but of
   course QtnProperty is not a goal - it is just my idea for a problem of
   complex mainwindow.ui. As it has been said: it is just a subject of
   another discussion. Maybe this could be solved some other way. Currently
   this file is hard to merge - so it is also hard to create any branch if
   changes are UI related :)

2. Yes - "textureInThread": thread process has its own context, but shared
   with main one:

   m_renderThread->context = new QOpenGLContext();
   m_renderThread->context->setFormat(current->format());
   

•    m_renderThread->context->setShareContext(current);*
  

  m_renderThread->context->create();
  m_renderThread->context->moveToThread(m_renderThread);

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,

1. 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.
2. 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
#57 (comment)
.

More:

(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html)
(http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)

[kmkolasinski]

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 :)

[ppiecuch]

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

• keeping two versions of mainwindow.ui for win/osx is even more
  problematic. Sometimes I think building UI manually in source code and not
  using Designer might be a most flexible option :)
  2 - in render function you can render to framebuffer (in background or
  foreground) and emit signal when done (that's how it is done in Qt's
  example) with rendered texture. in paint() function you only draw using
  already prepared textures

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
#57 (comment)
.

More:

(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html)
(http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)

[kmkolasinski]

1. Actually I mean something different, i.e. to rewrite mainwindow.cpp from the begining in such a way that it will be more functional and flexible for any modification (e.g. using QtnProperty etc...), and then through away the old mainwindow class since it will be no longer needed.
2. Got it! I will try to do it this week, then you can enter with the background rendering since you have experience

[kmkolasinski]

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?

[kmkolasinski]

For those who are interested in AB development: I've added intentionally one tool to the program such that you can follow this commit 22d041d
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:

1. Add new buttons in GUI, almost all images are processed by one class -- FormImageProp and integrated ui file which can be modified in the qtDesigner.
2. Add new image parameters to FBOImageProporties class such that you can change the parameters from GUI - note the huge list of variables there. Make sure to update also the void copySettings(FBOImageProporties &src) function.
3. Pay attention for proper logic in FormImageProp. If you added slider use proper slider to actualize the parameters etc. I think the best solution is to compare in which functions which qtWidget (slider/spinBox etc) is changed/updated.
4. Then you have to write proper GLSL filter (in my last commit I only updated the existing one) here: filters.frag. For example see the color inversion filter: invert for a template if you want to add new GLSL shader. And then look for occurrences of "mode_invert_filter" in the GLImage class.

Basically that's all to make things working in AB. Hope this help you understand the code a bit.

[kmkolasinski]

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:

[kmkolasinski]

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 :)

[ppiecuch]

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
#57 (comment)
.

More:

(http://komsoft.ath.cx/ http://komsoft.ath.cx/spider.html)
(http://pawelp.ath.cx/ http://komsoft.ath.cx/spider.html)

[kmkolasinski]

Ok, we will wait no problem, there are another things which can be done in parallel.

[DaOnlyOwner]

@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.

1. I would add functionality so that the metallic maps can be used in Unity. A metallic map that can be used in Unity stores the roughness data in the alpha channel and the metallic value in the red channel. The program currently only outputs two maps. They have to be tweaked and merged together somehow.
2. Add support for Unity in general.

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.

[kmkolasinski]

Hi, thank you for the ideas :)

1. This can be done easily in the code: take a look here to see how the images are saved in AB (saveAll function) code mainwindow.cpp. Implementation for metallic texture should take you few minutes. Then you must add some button do the GUI, however you want.
2. What do you mean by "in general"?
3. Currently we try to remove deprecated classes which probably cause the problem for people with old graphics cards. The branch we are working on this issue is the clean-legacy one: link. I don't know how much time it will take to make it working because it is quite complicated and I am the person who know how does the program work and I don't have too much time for this. So it would be nice to first fix the openGL contexts problems and then improve GUI.

[DaOnlyOwner]

1. Okay thank you ;)
2. Maybe put it on the assetstore? ;D
3. Okay. I'll try my best. But first, I have to read through that walls of code xD

Edit:
Oh and where do you calculate the different maps etc.? I cant find the code for that

[kmkolasinski]

1. I don't know if this is good idea... The code is completely not professional, buggy and not stable. I prefer the way it is presented now, such that people know that this is some amateur written program and don't expect too much from it ;)
2. I would suggest you to start from few last commits and issues where I (and others) put some effort to comment what we are doing (basically what was changed in the code). This is the simplest way to start.

[DaOnlyOwner]

1. Alright, as you want. But I could do some tutorials in addition to yours that focus especially on developing PB materials in Unity.. ;)
2. I see ;) I ve already forked the project.

[kmkolasinski]

1. AB + Tutorial = AwesomeIdea :) That would be great to make some professional tutorial with AB. If you will need help or instructions how to use AB properly to make a tutorial we can organise some chat.

[DaOnlyOwner]

Great, we should do that ;)

[DaOnlyOwner]

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.

[kmkolasinski]

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.