Skip to content
This repository has been archived by the owner on Jan 15, 2024. It is now read-only.

Assertion failed: afterSize - beforeSize == 1 #1

Open
XBOOS opened this issue Jan 21, 2019 · 5 comments
Open

Assertion failed: afterSize - beforeSize == 1 #1

XBOOS opened this issue Jan 21, 2019 · 5 comments

Comments

@XBOOS
Copy link

XBOOS commented Jan 21, 2019

Thanks for your excellent work!
I successfully built the project on windows 10 x64, but when I run the exe for the three example jsons provided, I got them fail on the assertion(afterSize-beforeSize == 1)
which is in the rtcommon.h
`

          size_t afterSize = mMeshes.size();

	// we can't have > 1 mesh per light source
	assert(afterSize - beforeSize == 1);

`

How should I deal with that?
Or is there possibility that we use some wrong dependencies?

@jamornsriwasansak
Copy link
Owner

I think it is unlikely to be caused by the dependencies issue.
I, however, don't have time to check it yet and will take a look over this issue within the next few days.
Before that, please state the .json file that triggers this problem.

Thank you for flagging this issue. :)

@XBOOS
Copy link
Author

XBOOS commented Jan 21, 2019

Thank you for your response!
I just used the example jsons provided in the scene folder.
There are 3 jsons like
../scene/buddha/buddha_ours.json
../conference/conference_ours.json
../livingroom/livingroom_ours.json

I also tried some of the jsons with postfix "_pm" " _vpl" . Haven't found one that does work.
Or could you specify one json that did work well?

Thank you so much for your kind help.

@jamornsriwasansak
Copy link
Owner

jamornsriwasansak commented Jan 21, 2019

Thank for your reply :)

I decided to pull the code and recompiled everything.
I checked the mentioned json files and I didn't find any problem.
If possible, I hope you don't mind print out the value of "afterSize" and "beforeSize".

In the framework, we always use an absolute path of ascii characters to refer to a file.
I think one possibility is that the framework can't find the mesh because of this.
eg. Your "evplp" folder is inside a folder with Chinese characters.
In such a case, moving the "evplp" folder to "C:" might resolve the issue.

@XBOOS
Copy link
Author

XBOOS commented Jan 24, 2019

Thank you for your kind help.
I printed out the values which shows "afterSize =0 . beforeSize = 0". So it cannot pass the assertion.
And the path of the folder is in engilish. I also tried to move it to the C: foler, still failed. -_-
What should the beforeSize and afterSize be?
Another change I did to the original project is that I could not compile and build the project with the original denpendencies so I replaced some of the lib files and dll files to make it work (by downloading the assimp-vc140-... etc, or use the x64 version of glew32.... and then build successfully. I have x64 windows 10 ) . I am not sure whether this would have some affects.
Then I run the reflectcuts.exe and had the above error.

Not sure from which direction to debug this error. It seems to have something to do with meshes.

@jamornsriwasansak
Copy link
Owner

jamornsriwasansak commented Jan 24, 2019

I think the problem is likely to stem from the Assimp in which we used for loading .obj meshes.
My guess is that, by partially replacing the Assimp, you could still compile the program. The number of mesh that Assimp could read is, however, zero maybe due to version mismatch or other compatibility issues.

Since you're now rolling with an Assimp of your own version, my best suggestion is to completely replace the Assimp that provided inside the framework.

  1. use CMake to make a fresh Assimp of any version that is >= 3.3.0. very important
  2. .1 replace the Assimp .lib in dependencies/lib64.
    .2 replace the Assimp .dll in dependencies/dlls.
    .3 replace the Assimp headers folder in dependencies/include (you probably forgot this step last time)

If possible, please also show the compiler message that prevents you from compiling in the first place. We might be able to figure out what originally cause this problem.

Another possibility is to completely purge the Assimp and replace it with tiny_obj_loader. This is highly doable, doesn't cause any compatibility issues, and surely fix Assimp related problems. It will, however, take a considerable amount of time. I suggest this only as the last resort.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants