Change In Environment Refresh Behaviour in 2018

simoncsmith

New member
Hi,

We've been using the following code pattern to force an update of the VPR due to a dynamic environment texture data change (driven by our plugin).

LWInstUpdate *lwupdate = (LWInstUpdate*)ourplugin_global->global( LWINSTUPDATE_GLOBAL, GFUSE_TRANSIENT );
lwupdate(LWENVIRONMENT_HCLASS, ourplugin_environment_instance);


This used to ensure that after our texture data had changed, the VPR view would refresh.
Under 2018 this no longer happens and so once we have programatically changed the texture data in memeory, the VPR does not refresh.

Should we be using/adding a new call for forcing the invalidation of the environment texture now?

-Simon.
 

UnCommonGrafx

Wandering about
Simon,
The following is a suggestion, not an answer:
File a bug report. Use the Help->Submit a bug feature. The person at the desk will generally answer your question quickly and engage you in conversation to get it resolved. Or so has been my experience.

I hope Sensei stops by and answers, one of the 3rd party Programming Gurus in our midst. The above may get it quicker.

Good luck,
Robert
 

simoncsmith

New member
Thanks Robert - I've submitted a bug through that system too.
I'll report back here if I hear outside of this forum on the off chance it helps someone else later!

- Simon.
 

Sensei

TrueArt Support
As a temporary workaround, until they fix it, I suggest checking if setting some item some parameter key will cause update of VPR..
Read key value -> set to the same value.
It should cause redraw.
 

simoncsmith

New member
Thanks for the help so far - I think the problem may be due to calling the lwupdate function from another thread.
This worked fine on previous version so Lightwave, but I want to try to ensure that I can perform this on the main thread to test the theory.

Is there an handler extensions that I can implement that will give me a callback every "tick", or a method to post a message from another thread (and handle back on the main thread) so that I can set up a simple system to ensure that the update calls are performed on the main thread?

- Simon.
 

jwiede

Electron wrangler
Is there an handler extensions that I can implement that will give me a callback every "tick"

Can you clarify what you mean by "tick" in context? Are you referring to every time the "current time/frame" value in LW's UI changes? Or something else?
 

simoncsmith

New member
Can you clarify what you mean by "tick" in context? Are you referring to every time the "current time/frame" value in LW's UI changes? Or something else?

Hi John,

By tick I was meaning a callback (from Lightwave) regularly so that I could check for a "invalidate" state in my plugin from the main thread.
In the end I used a LWTIMER_GLOBAL timer, setting the period to a few hundred milliseconds to maintain good latency (using a LW mutex to access my invalidate flag)
I'm not sure if this is "best practice", but it certainly does the job.

I summary, one could get away with being able to refresh the VPR from non-main threads in previous versions, but not any more!

Thanks to everyone for helping me out here - lovely to see such good support from the LW community :)

- Simon.
 
Top Bottom