RESOLVED: CHOP to TOP issue

Hi, when using a chopto TOP, I am getting weird errors when I set its resolution to 1 by 1, 5x5 works.
It works fine at 1x1 if I get a regular Geo’s XYZ pos values through an object CHOP. The problematic values are coming from an Oculus controller. I am using the TDVR framework. My version: TD pro 2021.10330 64bit Windows 10. GTX1080 card.
Maybe it’s not a bug but I am unable to understand what’s going on. the chopto TOP is set on 32bit RGBA Nearest pixel. I tried all kinds of settings in the chopto TOP and it doesn’t work for me.
I made a workaround in Python but I though I would signal it anyways.


All the best! P

That’s definitely odd behaviour. The only way I can reproduce it myself is if I change the CHOP to have more than 1 sample, in which case that error would be expected since it wouldn’t fit into a 1x1 texture. But based on your screenshot, you’re somehow getting it from a single sample CHOP.

Are you able to post a file that reproduces the problem? Ideally by locking the CHOP data since I don’t have an occulus controller to test it with.

I see this occasionally with CHOP data coming from external devices or other processes that may be outputting data a little faster than touch is running (aka default of 60fps). I think what’s happening is that multiple “packets” of data are arriving during a single frame of “TouchDesigner time” from said device and TD just joins them all together and presents them as one frame of multisample CHOP data that the CHOPto TOP tries to make into multiple pixels (hence the warning saying there are 7 “scanlines” - such old school terminology…) while python is probably just grabbing the first (aka [0] ) sample of data to show.

The thing is, despite bringing in multiple samples of data, TouchDesigner is still showing it as a single sample CHOP, but if you middle click on the CHOP I bet it says it’s actually 7 samples (7i) instead of just one. I don’t know why TD does this, and I’ve always wondered if the “Maximum Time Slice Size” preference in the CHOP section had anything to do with this (it doesn’t as far as I can tell)

I was kinda able to reproduce this with two TD processes running at different speeds with DMX Out and In CHOPs since DMX is what I use regularly and where I’ve seen it before:

As to why your Oculus is outputting multiple samples with such different data, I can not say, but the trick I’ve found to solve this with other external hardware is to put a Trim CHOP and a Shift CHOP in as the first two CHOPs right after the hardware input CHOP, setting the Trim CHOP to absolute 0 samples and the Shift CHOP to shift to the first frame so that single sample stops moving along the CHOP timeline along with the project timeline (which I still don’t understand)

Even better, while messing with this, I noticed they added a “Shift Start to 0” parameter to the Trim CHOP, so that gets rid of one more operator, and it seems to fix my simulated version of your problem:

Try that with your Oculus (all I have are Vives) and let us know what happens.

Thanks all! Happy to Rob, here I just locked the CHOPto. Hi Peet, I also tested the framerate at 200fps and nothing changes, I’ll check your tweaks and be back asap.
BTW: general question for anyone, is the Python solution decent in terms of speed? Or do I have to avoid it? All the best! P
CHOPTOglitch_June2021.toe (3.8 KB)

I think @Peeet is correct, in your file the select chop does have multiple samples in it so technically the error in the CHOP to TOP is correct.

I don’t have an Oculus to test with, but from a quick glance at the code, I would have assumed the only way for it to have multiple samples is if you’re running in Time Slice mode and your FPS is below your targeted frame rate.

Either way, using @Peeet’s suggestion of a trim chop should fix it, or you’re probably ok with your python method as well if you don’t mind using expressions. The expressions are optimized and on my machine at least the cook times are pretty similar.

Hi @robmc thanks! All the best, P

OK, @Peeet I did the trim tweak, and it’s OK with it :), thanks!
Also, my TD version doesn’t have the Shift start to 0 but it’s doing fine, so quick & lean fix, danke! P

1 Like

BTW I don’t know the moderation rules here, do we say the bug is fixed or workaround somewhere?
@robmc Cheers! P

I’m not sure there’s an official rule, but if it’s been identified as a specific bug that requires code changes we’ll usually prepend 'FIXED: ’ to the message, but when it’s a solution that doesn’t require code changes we often use 'RESOLVED: ’ I’ve updated the title for this one.

1 Like

Also, just a note (you might know this already so apologies if you do) but even if you set your project to 200fps, it will still only run at the max refresh rate of whatever monitor you are viewing it on when you are in the editor. If you REALLY want to test it, you need to change the “V-Sync Mode” to disabled on your perform window (go up to root and find the Window COMP there) AND be in perform mode for the FPS to be uncapped. Probably completely unnecessary for what you’re doing, but if the Oculus really is spitting out data that frequently, it may give you an even snappier / smoother response if you can get the project file to run that quickly.

And now that I think about it, if you’re rendering to Oculus, when you’re in perform mode on the Oculus (with V-Sync still on, I would assume) maybe the frame-rate can get high enough to match the CHOP data coming in and your control-reaction connection might be that much tighter assuming your file can run at the Oculus frame rate (is it 90Hz or 120Hz?)

Hi @Peeet I suspected something like this but I didn’t know it was tied to my monitor. Actually, I do want to do a few experimental psychedelic things on TD at crazy rates such as 700fps for example. How do I tell TD to operate at that speed (for the components that accept it of course)? Is disabling V-Sync enough?
Thanks a lot again BTW, P

Yeah set the desired FPS in the bottom left corner of the editor (next to the timeline) and then disable V-Sync and be in perform mode with only that one perform window open and in focus. 700 fps might be a bit much to ask for if TD is doing anything other than displaying your FPS (you can tell what FPS it hits in perform mode by displaying a text TOP in a container that is showing FPS from a perform CHOP)

Also some of the things you may be wanting to accomplish could be something achieved with “non-realtime” mode where it takes as long as it needs to render each frame, though this is usually used for recording movie files or other “rendered” data that you can cache and playback later at full speed.

Hi @Peeet thanks,
I was curious, I get that 700fps can only work if highly optimized, which components are being used etc… All I wanted to find out here is how to force TD to do it. Lets’s say some electronic sensors and devices go very fast and it would be fun to match that speed with inputs and outputs. Again I am checking scenarios for some ideas in the back of my head. Thanks for all your time and advice btw, P

Yep, this is our policy - we can make it official! :slight_smile: