I'm getting several build warning in x64 on Visual Studio 2019 related to size mismatches. This happens when size_t's are being implicitly converted to 32-bit types, like int. Here's the full output:

1>------ Build started: Project: FastWFC, Configuration: Release x64 ------
1>propagator.cpp
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\include\propagator.hpp(72,1): warning C4267: 'initializing': conversion from 'size_t' to 'const unsigned int', possible loss of data
1>wave.cpp
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\propagator.cpp(13,20): warning C4267: '=': conversion from 'size_t' to '_Ty', possible loss of data
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\propagator.cpp(13,20): warning C4267: with
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\propagator.cpp(13,20): warning C4267: [
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\propagator.cpp(13,20): warning C4267: _Ty=int
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\propagator.cpp(13,20): warning C4267: ]
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\wave.cpp(39,26): warning C4267: 'initializing': conversion from 'size_t' to 'const unsigned int', possible loss of data
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\wave.cpp(96,26): warning C4458: declaration of 'nb_patterns' hides class member
1>wfc.cpp
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\include\wave.hpp(58,18): message : see declaration of 'Wave::nb_patterns'
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\include\propagator.hpp(72,1): warning C4267: 'initializing': conversion from 'size_t' to 'const unsigned int', possible loss of data
1>C:\bob\proj\dev\dl\3rdParty\FastWFC\src\lib\wfc.cpp(44,70): warning C4267: 'initializing': conversion from 'size_t' to 'const unsigned int', possible loss of data
1>FastWFC.vcxproj -> C:\bob\proj\dev\dl\3rdParty\FastWFC\bin\Release\x64\FastWFC.lib
1>Done building project "FastWFC.vcxproj".

I've tried to alternate a bit algorithm with my poor understanding of it by changing function Wave::set to accept true values:

bool Wave::set(unsigned index, unsigned pattern, bool value) noexcept
{
	bool old_value = data.get(index, pattern);
	// If the value isn't changed, nothing needs to be done.
	if (old_value == value)
	{
		return false;
	}
	// Otherwise, the memoisation should be updated.
	data.get(index, pattern) = value;
	if(!value){
		memoisation.plogp_sum[index] -=  plogp_patterns_frequencies[pattern];
		memoisation.sum[index] -= patterns_frequencies[pattern];
		memoisation.log_sum[index] = log(memoisation.sum[index]);
		memoisation.nb_patterns[index]--;
		memoisation.entropy[index] = memoisation.log_sum[index] - memoisation.plogp_sum[index] / memoisation.sum[index];
	}else{
		memoisation.plogp_sum[index] +=  plogp_patterns_frequencies[pattern];
		memoisation.sum[index] += patterns_frequencies[pattern];
		memoisation.log_sum[index] = log(memoisation.sum[index]);
		memoisation.nb_patterns[index]++;
		memoisation.entropy[index] = memoisation.log_sum[index] - memoisation.plogp_sum[index] / memoisation.sum[index];
	}
	// If there is no patterns possible in the cell, then there is a
	// contradiction.
	if (memoisation.nb_patterns[index] == 0)
	{
		is_impossible = true;
		//todo: print imposible pattern
	}
	return is_impossible;
}

Idea is after removing some wave patterns manually, to be able to add some waves patterns, if needed.
But no matter what i do, even if I call this before propagate, algorithm always fails.
Can this work at all? Maybe someone can point or give a hint why this wont work?

half_min_plogp is used as an upper bound for the noise added to the entropy of a cell when choosing the min entropy cell to observe. A symptom of this problem is the noise applied to the entropy for certain source images being 0. I confirmed this by building and running wfc modified to print out half_min_plogp.

I think this is a symptom of a different problem - namely the function get_plogp gets passed frequencies of patterns (ie. the number of times each pattern appears in the source image), rather than the probabilities of patterns appearing in the source image. Notably, when the source image contains a pattern which appears exactly once, the value of log([distribution[i]) is 0 for at least one i (since log(1)=0). Since half_min_plogp is based on the minimum value of the output of get_plogp, a 0 in its output results in half_min_plogp being 0.

Hey, I would like to use this implementation in another cpp code. Are there plans to also make something like a libfastwfc with headers?

Hello. Can i add constraint in this code to use WFC to generate river between two points, which i choose?

Hey, I am trying to build but I am getting this error:

~/git$ cd fast-wfc/
~/git/fast-wfc$ cmake .
-- The CXX compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Setting build type to 'Release' as none was specified.
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
FASTWFC_LIB
    linked by target "wfc_demo" in directory /home/username/git/fast-wfc/example

-- Configuring incomplete, errors occurred!
See also "/home/username/git/fast-wfc/CMakeFiles/CMakeOutput.log".

It seems that the CMakeLists.txt from examples, require the library already built and installed.

find_library( FASTWFC_LIB
  NAMES
    fastwfc_static
  HINTS
    /usr/local/lib64
    )

But the CMakeLists.txt for the library, require the examples to be built!

add_subdirectory(example)

I had to comment the above line from the library (last line from CMakeLists.txt), build it, before building examples.

Using windows 10 with VS Code and Msys64 to compile.

for some reason all the output's remain the same.

and half of them consistently fail? I assume that is intended at the moment.

Is there a way to fix a specific tile somewhere? As I know, in ovelaping mode there is a way to do that, but not in tiling. Why so? Do I miss something?

in example/lib/main.cpp file line 27 get_random_seed() function:

if use msvc compiler, may be also can use random_device()() function to get a true random seed, just like use it in linux

int get_random_seed() {
  #if defined(_MSC_VER) || defined (__linux__)
    return random_device()();
  #else
    return rand();
  #endif
}