I am using SvelteKit with SvelteCubed to run Three JS within a Svelte component. For the materials I am using (rather large) textures. ThreeJS's THREE.TextureLoader(); requires document to work, since it creates an image and sets src.
However, this means that to use it, I need to put it in onMount(), which seems to stop the images being cached and removes the snappiness of SvelteKit using clientside rendering, since they are loaded fresh every time, and often require a manual reload.
I am using Vite's import image from "path", but this doesn't load the image into a format useable by a shader, it just gives me a path to use. Is there a non-DOM based option that I can use before mounting and SvelteKit will cache?
Related
Im building an app with Aframe that requires fetching images saved onto AWS.
I was getting consistent cors rejection, and after resolving that, my images are passing cors but SOMETIMES they are not, I then utilized asset caching to render the images and the error has changed from mentioning cors to Tainted canvases
Im thinking that cors is effected by the clients internet speed or location?
Im also using aframe react and im wondering if react-rerenders on startup are causing the issue.
Make sure to have <img crossorigin="anonymous"> set, and try without the React layer (which I don't recommend using anymore for perf and scalability reasons for VR, and seeing it mishandled most of the time).
I've implemented many 3D viewers in THREE where the assets are hosted somewhere, but I'm running into a unique situation where we'd like to preview a model before it gets stored on the server.
How would you go about uploading an OBJ with MTL textures and be able to render it by having these formats reference once another, just as they would if you were retrieving them as a served resource?
Is there a way to save and load stringified objects with three.js?
I found this: https://github.com/josdirksen/learning-threejs/blob/master/chapter-08/03-load-save-json-object.html
but they use localstorage to save and load, which won't work between sessions or different computers.
Is there a way to load files just like the model is loaded? This should be like loading data files for a game.
I run the webgl client with Autodesk viewer locally with http-server.
If the Object can be written to localstorage it can just as well be exported as a file. You can send them to a server and store them there (maybe something like firebase would be useful here), or you can intiate a "download" directly from the browser. This is explained in Create a file in memory for user to download, not through server.
For loading a file, you can use the file-api, which is shown here: How to open a local disk file with Javascript?.
You just need to replace the localstorage-parts in your example accordingly.
Adding to Martin's answer, the Autodesk Viewer uses files translated and hosted by Model Derivative API. It's possible to show multiple files into the same scene. The Viewer is read-only. There is a getState and loadState functions to get the objects that represents the current zoom/explode/view information, and that can be serialized and stored somewhere.
There are some samples showing how to move a geometry on the model, for instance, move the geometry of a wall (from a building model). But that is not persistent, meaning you need to implement a JavaScript (client) + back-end infrastructure to save and restore those transformations.
I currently have a mapping application written in Phonegap (Cordova), using OpenLayers that loads image tiles from the local file system. This works out of the box.
I would now like to load the images from another source (e.g. a database) and still use the same OpenLayers map component with tags (DOM rendering).
I know data URIs are an option, but performance for decoding the base64 string and loading the images in general is considerably worse (less caching?). I tried this.
Is there an alternative approach? Could I somehow implement a custom protocol handler (myimagesfiles://...) and serve the binary data from some other source?
The approach would have to work on iOS and Android. Writing some native code for this would certainly be ok.
OK so I've got this addon where I'm trying to load a bitmap from a file:/// URI and draw it to canvas.
All that goes fine until I need to get the data off the canvas using getImageData, then I run into a security exception. I go to Moz Chat and am told that because I'm loading the image from a page modded HTML File, it's a cross domain policy issue and not allowed.
The solution, they say, is to go to the main module and load the image there, copy it to a canvas, then serialize the data with getImageData and send it back to the HTML doc.
One problem: Jetpack doesn't know what "Image" is because it doesn't have an HTML DOM, thus the operation seems to be rendered more or less impossible.
Why is this a cross domain policy issue in the first place? Beyond that, how do I load the image without access to the DOM?
The simpler and best example of communication between main.js module and a content script you can read is in Add-on SDK docs: look for the section under the title Communicating With Content Scripts.
Basically, this is how the main module tells the content script (the pagemod in your case) something:
worker.port.emit("getElements", tag);
and this is how it listens to whatever the content script tells him:
worker.port.on("gotElement", function(elementContent) {
console.log(elementContent);
});
On the other side, the content script listens to what the main module says to it this way:
self.port.on("getElements", ...
And finally, a case this example is missing is how the content script may emit an event to tell something to the main module:
self.port.emit("myCustomEvent", var1=someValue, var2=otherValue, ...)
But that's the idea. I also recommend you to tale a careful look at this more general explanation about how content script (pagemods, widgets, tabs, panels, etc) work because this is the mosst important concept to understand how sdk addons work.
Last, about the cross domain issue on content scripts you can read more here.