When I get the pixel value from changed offset time tick. tyflow is Very slow running
#1
When I get the pixel value from changed offset time tick. tyflow is Very slow running .

It seems that bitmaps is called every time according to the changed tick input, but I think we need to modify the function rather than find a more effective method. Please check through the commented code.The processing speed is too slow. If you check the event log, you can see that the bitmap is read redundantly. I would appreciate it if you can supplement this.

The writing is a bit short because of my lack of English skills.
The sentences may not be smooth. so please understand me.  
Thank you very much.


Attached Files Thumbnail(s)
       

.zip   slow_running_when_get a pixel value_at_offseted_Time_ticks.zip (Size: 3.02 MB / Downloads: 179)
  Reply
#2
Yes this is because each time you evaluate a texmap at a time that is different than the last, it must be re-read from disk using that different time value as the frame offset for its input sequence.

The seemingly-obvious solution would just be to cache texmaps and re-use them so that multiple calls to the same offset time do not trigger reloads from disk. However, that could cause big problems....imagine a user has a million particles and each one reads a slightly different time from the texmap. That would result in a million texmaps loaded into memory!

I think the best solution would be one implemented in your Script. If you sort your particles so that particles with the same time offset read their texmap values in sequence, the reload of the texmap won't happen for every particle.
  Reply
#3
(12-21-2020, 12:37 PM)tyFlow Wrote: Yes this is because each time you evaluate a texmap at a time that is different than the last, it must be re-read from disk using that different time value as the frame offset for its input sequence.

The seemingly-obvious solution would just be to cache texmaps and re-use them so that multiple calls to the same offset time do not trigger reloads from disk. However, that could cause big problems....imagine a user has a million particles and each one reads a slightly different time from the texmap. That would result in a million texmaps loaded into memory!

I think the best solution would be one implemented in your Script. If you sort your particles so that particles with the same time offset read their texmap values in sequence, the reload of the texmap won't happen for every particle.

thank you for the reply.
We fully respect your opinion. Nor is it that I haven't found a way to do it faster within the script through the given method. But what looks weird is that it only has 5 offset times, and reading the bitmap file assigned to the texture every tick is very different from when the processing speed is not offset. So I thought I should check the method, so I asked for confirmation.

And, as mentioned in the comments section, "Imagine a user has a million particles and each particle reads a slightly different time from the texmap. Then it loads a million texmaps into memory!" of course!!.
 If you're a tyflow user, you won't be fooled by such a problem.
Of course,  can create a predictable solution and avoid problems like this. Thanks for the answer anyway. 
And I want to express my deep respect for your efforts.
  Reply


Forum Jump: