mxgmn / WaveFunctionCollapse

Bitmap & tilemap generation from a single example with the help of ideas from quantum mechanics
Other
23.18k stars 1.24k forks source link

Bug: For some examples, model.Run() returns true when false is expected #14

Closed ejmahler closed 7 years ago

ejmahler commented 7 years ago

WaveFunctionCollapse version tested: commit 333f592 (HEAD as of this writing)

In Main.cs, on line 40, we check to see if the model has found a solution with the given seed. If it has found a solution, we then save a bmp file of the solution. Thus, the expectation is that any bmp file saved via this program should be completely "collapsed".

For some examples, this is not the case, and bmp files are saved that are partially still in a "superposition" state. The only reason I can see for this is that model.run() is sometimes returning true even if it hasn't found a solution.

To reproduce this bug, delete every entry of samples.xml except one:

<samples>
    <simpletiled name="Summer" width="15" height="15" periodic="False" limit="15"/>
</samples>

And change line 38 of Main.cs from int seed = random.Next(); to int seed = 474849158;

Then run the program.

I expect to see one of two things: "CONTRADICTION" printed in the console with no bmp file created, or "DONE" printed in the console with a fully-collapsed BMP file created.

Instead, "DONE" is printed and a partially-resolved BMP file is created.

ejmahler commented 7 years ago

The same bug occurs with samples.xml

<samples>
    <overlapping name="Village" N="3" symmetry="2" limit="50" periodic="True"/>
</samples>

And seed int seed = 362313200;

This means that the bug occurs with both the overlapping model and the simple tiled model.

kchapelier commented 7 years ago

I think this is the intended behavior with the limit property : it actually limits the number of iterations the generation is allowed to do. If the number of iterations reaches this limit without hitting a contradiction condition, the generation is considered a success.

ejmahler commented 7 years ago

As I read the source of Run(), you're clearly correct.

But that doesn't seem intuitive to me -- even when providing an iteration limit, the main thing I want to know is whether or not the model now has a usable result. How would I know whether the result was complete or not? So IMO the bug still stands: I expect a return of true when the generation has completed successfully, and false otherwise.

This seems like a case of trying to cram a piece of information with three states (Complete, incomplete, impossible) into a variable with two states.

kchapelier commented 7 years ago

I see that the samples.xml in the repo actually have those limit set. I wrongly assumed you added them. The limit properties should probably be removed from the file as they seems to be debug helpers more than anything.

ejmahler commented 7 years ago

I edited the issue to indicate that that entry came from the existing samples.xml

mxgmn commented 7 years ago

I included samples with the limit param in samples.xml to show how to generate partially completed results. Because they can be pretty, like the "Circles" one linked from README.

mxgmn commented 7 years ago

@ejmahler @kchapelier Note sure if people get notifications if I don't mention their username. It seems that everybody understood each other here, closing.