Forma Developer Forum
Welcome to Autodesk Forma Developer Forum. Share your knowledge, ask questions, and explore popular Forma API topics.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Keeping track and clearing canvas textures

Message 1 of 3
158 Views, 2 Replies

Keeping track and clearing canvas textures

Hello Forma Team,

I'm reaching out to discuss the operational aspects of our extension, particularly the utilization of the ground Texture API for presenting a variety of geospatial data. Our current process includes executing an HTTP call, retrieving an image URL, loading the image onto a canvas, and subsequently integrating the texture.


This procedure is repeated each time a user experiments with different images. However, when revisiting a previously loaded image, rather than duplicating the entire download and setup process, our goal is to seamlessly reapply the already-created texture.


This however produces these challenges:


  • Tracking textures: To implement the desired functionality, we must maintain a record of texture names, associating them individually with their respective images. This involves regularly updating a substantial list of objects, which can be cumbersome with each new selection.


  • Reactivating textures: Currently, there is no efficient method to reactivate an already applied texture. My workaround involves utilizing the updatePosition() method and assigning a higher 'z' Position value to bring the texture to the foreground. The drawback of this method is the necessity to manually adjust the 'z' positions, which is both time-consuming and prone to errors.
  • Storage API concerns: Following a previous suggestion to use the storage API for retaining texture names, I've found this approach results in frequent HTTP calls and the storage of non-essential lists. Since textures are removed upon a user refreshing or reloading the extension, persisting texture names in storage is not required.


  • Texture cleanup on exit: When exiting the extension, all textures persist on the canvas. An ideal solution would entail an automatic clearance of all textures, as opposed to the current method of manually invoking the remove() function and managing multiple Promises to cleanse the canvas.


I'm reaching out for your advice and particularly for finding a more streamlined approach to managing and reactivating textures, as well as efficiently clearing the canvas upon user exit. Any insights or recommendations you could provide would be greatly appreciated.


Thank you for your attention to these details, and I look forward to our continued collaboration to enhance the user experience of our extension.

Tags (2)
Labels (1)
Message 2 of 3
in reply to: iklimis


Thank you for the detailed report.  🙂


Tracking textures
I'm not sure I fully understand this issue. Is this related to the Storage API concerns point? Could you add another layer of abstraction on your end to make this an object so that it is easier to work with? 

Reactivating textures
Could you be more specific about 'efficient method', have you measured that swapping textures takes too long for the app to be responsive, or is it more that it is not convenient to do this with our API? I actually think that the z position hack is quite clever to be honest. I could check internally if we could deem something like z = -1 a special location which would disable rendering. 


Storage API concerns

Have you considered other techniques like custom in-memory, or localStorage or sessionStorage apis of the browser? They seem applicable if you do not need permanent persistence of these. 

Texture cleanup on exit
You can consider this a bug in the current implementation. For the RenderAPI we force the cleanup when you exit the extension as we do not want to assume that every extension does this correctly, and we do not want to pollute the 3d scene. So this a planned change on our end. 

Message 3 of 3
in reply to: havard.hoiby

Hi! @havard.hoiby 

Implementing an additional layer of abstraction seems to be a viable strategy when no clear alternatives present themselves. That includes utilizing localStorage or an In-Memory approach.

Texture Reactivation Considerations

The issue at hand is not related to the duration of texture swapping, as the timing is acceptable and is, in fact, a critical aspect I rely on. Rather, the focus is on the conveniency part. Ideally, I am looking for a method that enables the activation of a selected texture while automatically deactivating all previous ones. Currently, I am burdened with the task of tracking which texture is active at any given moment, and when a new texture is introduced, I must manually relegate the previous texture to the background and promote the new one to the foreground.

Conclusion and Further Inquiry

In light of the fact that the 3D scene acknowledges a previously loaded texture  — implying that it remains in memory — it seems reasonable to conclude that the already applied textures are preserved within the Forma main environment. This leads me to question whether it would be feasible to introduce a method capable of retrieving all the applied textures. Such a method would significantly streamline the process, potentially integrating this functionality within the GroundTextureApi.

Thank you very much 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th

Autodesk Design & Make Report