Iohannes, I am not sure if understood you well, did you mean that even I have a good graphic card with my patch I am unable to exceed 60 fps? Or you meant a [metro 5] to [gemhead] to achieve 200fps and analyzing the center of gravity with pix_blob could do the job. Popesz
On Sat, 1 Sep 2018 at 01:02, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 8/31/18 2:42 PM, Csaba Láng wrote:
Just in case I send you a new Segmentation Fault log. Here I have already no method for Gemstate. I send you the patches to have a better idea what I am trying to do. trackerping.pd is the main patch, containing filecontrol. after gemwin is rendered, open languagechoice.pd there are 2 cameras placed in the main window sending to the pd ping1 and pd ping2 to languagechoice.
Basically the 2 cameras are creating one touch surface by placing them
one
above the wall facing down, the other one facing to the wall. When
camera1
gets the wall hit tells the event to camera 2 which gets the position x y
to avoid confusion, it's probably better to reserve the term "camera" for the physical device.
from pix_blob. Now when the 2 cameras send to each other info about the presence of an object, I get the segmentation fault.
so the crash appears when you you send something to [r ball] (which in turn triggers a [s english] resp [s polski]; which in turn triggers the patch-open and patch-close).
i'm pretty sure that dynamically opening and closing patches is a bad idea. what's wrong with just using [spigot] to let the gemlist through or not?
apart from that, it's crashing because of an illegal memory access in a [bng] object (that is: a graphical bang). this is either an initialization problem or some memory corruption.
anyhow, parts of the patch are missing, (the dynamically loaded patches), and i don't know where [once] is coming from.
i have a slight suspicion that you are running yet another [pix_blob] in your dynamically loaded patches, which you probably don't need (you already have a [pix_blob] on all your video sources), no?
oh, and your cameras might already support setting gain and contrast and cropping the image. if so, you might want to do these things on the camera rather than within Gem.
as for the framerate: even if you run your cams at 1000fps, Gem will run at it's own fixed framerate (which is 20fps by default, and i don't see where you've changed that). Gem's framerate is usually bound by the gfx-card (so often you cannot really go beyond 60fps). however, if you don't do any openGL rendering (most Gem-objects will do openGL, with the big exception of the pix_* family - apart from pix_texture, which does openGL), then you can have a single [gemhead] run at a higher rate by simply banging it to a [metro] running at that rate.
gmads IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list