First of course, thanks a lot for your hardwork, the plugin is great!
(using TouchEngine For UE 5.1 latest release)
I’m currently trying to use two TOP textures (32bits RGBA) to drive the positions and velocity of the particles in a Niagara system. So far everything is working as expected. The particles follow the positions from the TOP POS and I use my TOP VEL to calculate the orientation of the particles according to their velocity. Each texture is a 124x124px 32bits RGBA.
The problem is I noticed some weird movements/positions, and after a lot of testing I thought it comes from a pixel format problem. In Niagara I’m using the Sample Texture module to get the positions of each particles (1 pixel = 1 particles with RGB acting as XYZ). To be sure that the problem doesn’t come from Niagara, I created a static texture in Touch pixel values within a -500/500 range, and saved it as a .EXR. When using it, all the particles are at the right place (setting the imported texture as RGBA 32f + Filter = Nearest).
After more testing I identified the problem I think: The Texture coming from TouchEngine TOP doesn’t have its “Filter” set as “Nearest” in Unreal.
Can you confirm?
Any idea on how to change that in BP after the “GetTouchEngineOutput” or “OnToxLoaded” events?
Hey @JetXS, thanks for the answer! For now the plugin is great and an amazing tool for my workflow. I love it! Thanks a lot for your hard work. I will take some time on monday you send you an email at support to show you what I’m trying to do (feeding a Niagara system with live point cloud data from TouchDesigner. The result is pretty cool so far, but should be even better and cleaner without this bug of course )
I tested a few things to identify from where the problem come from:
In my UE blueprint, I used some nodes to save on disk the texture received from TouchEngine as an .exr, and checked it in TouchDesigner.
=> the texture is OK!
Back in UE, I fed this saved texture to my Niagara system.
=> same problem as before, the points are not aligned as they should. If I go to this texture settings and set the filter to “nearest” and compression to “RGBA32F”, the points are now aligned properly.
=> The problem is indeed that the Texture coming from TouchEngine TOP doesn’t have its “filter” set as “Nearest” in Unreal, and can’t find a way to force it manually
So I also tested some solutions just in case:
Set the received texture to “compression = RGBA32F” and “Filter = nearest” in BP
=> seems to have no effect (maybe these two nodes are not working as I expect)
Create a custom TextureLODSettings in UE (TEXTUREGROUP_Project01) and rename it “CloudData” with “inMagFilter=point,MipFilter=point,MipGenSettings=TMGS_NoMipmaps” settings
=> no effect either.
So for now I’m stuck! It’s not so problematic as this is only R&D for now, but I would love to make it work properly to include this idea in a future installation as the potential is huge! Can’t wait to see what you will include in the next update!
As a quick and ugly workaround to fight the filter problem, I had the idea of upscaling the textures in Touchdesigner with a simple fit TOP (the textures are 124*124px, and I set them 5, so 620620px with nearest pixels in Touchdesigner). It’s not perfect but it helps a lot addressing the filter issue in Unreal as there is a lot more pixels to work on. Waiting for a better solution!
→ Nvidia Flex simulation in Touchdesigner
→ Output particles position and velocity as two textures
→ Feeding the textures to Unreal via the plugin
→ Using a Niagara system via TextureSample to render the particles
→ Using velocity to calculate orientation and tweak particle color and scale
As described the main problem in this setup is that the textures coming from TouchEngine TOP doesn’t have its “filter” set as “Nearest” in Unreal, which is a problem when dealing with particle data as a texture.
The workaround I found for now:
→ Upscaling the textures in Touchdesigner with a simple fit TOP (the textures are 124x124px, and I set them x5, so 620x620px with nearest pixels in Touchdesigner)
→ In Unreal Niagara, tweaking the UV used in TextureSample to try to avoid the blurry filtered parts
It’s not perfect but this workaround helps a lot addressing the filter issue in Unreal as there is a lot more pixels to work on, and doesn’t have a huge impact on performances.
Can’t wait to play with the next release of the plugin!
Thanks a lot for your hard work on this!
hey would love to hear your progres on this!
also what techniue are you using to drive the niagara sim with the texture?
does the texture sample allow for pos data?
The next version of the plugin we post, 1.3.0, will have a new node which allows to refresh the filter of an Unreal UTexture when you updated its filter property.
I will give a try to the latest release today.
For the process, yes you can drive niagara sim using a texture, were each pixel is a position (RGB channels are used as XYZ position), you simply need to extract each channel in niagara with a texture sample and assign the values to your particles. (this unreal tutorial will show you the basics: https://www.youtube.com/watch?v=pKjUaRt1-Rs)
Hey! So for some feedback on the plugin. The latest release is awesome (1.2.0), I really like the rework on CHOPs and the overall modifications/improvements. Great work, thanks a lot! Now I’m waiting patiently for the 1.3.0 to solve my filter problem (yes I tried some workarounds, but this future new node will help a lot using TOPs to drive Niagara particles or instances in a clean way).
I will take some time on monday you send you an email at support to show you what I’m trying to do (feeding a Niagara system with live point cloud data from TouchDesigner. The result is pretty cool so far, but should be even better and cleaner without this bug of course 
Can’t wait to see what you will include in the next update!
