Mesh disappears after 3++ hours (ofMesh/raspberrypi/arm/opengles)

hello all,

tl;dr: after 3 to 4 hours running the project my 3d mesh/model disappears ;/

i hacked together a little xmess eyecandy from some of the examplecodes.
first i tried using 3dmodelloader, which didnt work as expected, second i tried
ofxAssimp, which failed to compile due to lack of assimp.h although path and file
exists (probably a raspberry problem, read something about it in the tubes), so
i used ofMesh after converting my 3d object to .ply … now all worked as supposed,
added some snow particle from the particle demo and wanted the snow to kinda bounce
off the 3dmodell, which i didn’t got working so i faked it a bit.
anyway, some transparent faces occure, dunno why, but let’s call this the art of glitches,
i can live with. my only problem is, after a couple of hours running that thing, around 3 to 4
hours the 3d modell/mesh disappears, no verbose log message or whatsovever, the snow
still runs and the app too.

any ideas?
i try to attach the source. thnx for help in advance. and of coz feel free to use the source.

used latest of 0.8.0 and also tried against a nightly git trunk.

7752a2d22c44309561429d178f47468d *

reup since bf seems to be down atm:

your code doesn’t compile out of the box so I am not sure this is the latest (“src/main.cpp:4:19: fatal error: ofFBO.h: No such file or directory” ofFbo.h is what you are looking for but you don’t need to include it as you are already including ofMain.h)

I would first remove the ofGetElapsedTimef code/check its value

compiled fined for me they way it is, i supposed i added ofFBO because
i got errors when using it without the include …

and yeah, the ofGetElapsedTimef is what i first thought could be the
problem. but isn’t this supposed to be endless? how can i accomplish
it without that?

edit: removed include ofFBO … did indeed compile. but this ain’t the
problem… since it already compiled fine with that included…

is it compiling on your end when you remove the include? and why do you get that error? shouldn’t ofFbo.h exists in every OF?

thnx for help

Looking inside ofGetElapsedTimef it is doing this

float ofGetElapsedTimef(){
        return ofGetElapsedTimeMicros() / 1000000.0f;

I thought maybe the float was going out of range of 32bit - numbers are tricky in c++ and limits can vary on platform. I’m going to run ofGetElapsedTimef for a while on the RPi and see what it outputs. In the meantime I would maybe try to modify your code to use ofGetElapsedTimeMicros() as it is an unsigned long long.

Yes - it compiles when I removed the include. The error is because Linux is case-sensitive so ofFBO.h is different than ofFbo.h. I understand that that is not the root of your issue - I was just trying to make you aware that people looking at it will probably not be able to compile it without modifying it.

ofGetElapsedTimef is endless (not technically endless, but can count up to MAX_FLOAT) but the further away from 0 you get, the less precise the float is. I had an installation up recently where I used sin(ofGetElapsedTimef()) as an animation source and after about a day, it would get sort of crunchy, since floating point numbers make bigger jumps the further away from zero they get (one way to imagine it is you have 7 or so decimal places of resolution, as the number gets bigger 1, 10, 100, 1000, you loose decimal resolution on the decimal places). A quick solution is to use a double based on this:

double elapsedTimed = ofGetElapsedTimeMillis() / 1000.0

which should not suffer from the same problems.

well, it suffers from the same problems, just much later. :smiley:

Why not use ofGetSystemTimeMicros() or even ofGetUnixTime()? It might not be as comfortable to use, but at least the output should stay predictable, if the program is going to run for a long time.

true! but in my case, it meant it would take months and not days for that behavior to occur.

I also did stuff like this:

to help fix the problem, which was a version of ofGetElapsedTimef() that works specifically for sin or cos, and shouldn’t have any problems as long as ofGetElapsedTimeMillis is ok.

yeah thnx for the point, cant change the link to the source though since
i’m currently on the move. will reup it fixed asap!

yeah i was thinking about using unixtime, but hadn’t had the time yet to try it out.

aside from the hopefully ofGetElapsedTimef-problem anyone get the transparent faces on the 3d model?
any hints/comments on why is that, i’m a noob when it comes to opengl, i usually do stuff in vvvv which is quite different approach as you might know.

that could be something similar to

hey again,

went over the code and got rid of the use of ofFbo, i had it used it initially to
use shaders, but since i dropped this idea for the particle system there was no
reason to use FBO and voila, the problem with the backfaces are gone.

with FBO:

without FBO:

new source code for testing/confirming: (494.2 KB)

note: i haven’t looked into the disappearing. will check this later.

cheers and thanx to all for help!

1 Like