API for Video Textures


(Luminux) #1

I'm working with a developer on using the Sketchfab API to support video textures on a model. A few questions have come up that I'd like to share as well as the current code we're using.

Is there a way to tell the video to loop?
Is there a way to manipulate the underlying video object somewhere for further HTML5 video controls?
How do we initialize the texture with an existing video element? The example below was uploaded via .fbx and exposed the original still texture that came with it. Can we point to the video file path instead?

Link to current attempt: http://codepen.io/ritchie-revdev/pen/LbNWyX

(Cedric) #2

Hi Luminux,

Video support is very limited for now. We can improve the support in the viewer api but using an url directly in the editor will not happen in a short term.

Let me check what we can improve.


(Luminux) #3

Thx Cedric,

One looping file playing back and no URL input would be just lovely.


(Mauricesvay) #4

@luminux does your developer has a preference on the style of the API he would like to use? We might implement something, but want to make sure the API is simple and usable.

(Ritchie) #5

Hi @cedric and @mauricesvay, many thanks for looking into this for us.

I see a few ways forward for this, but am not familiar enough with your architecture to know the ramifications of each. I've listed the options in order of my preference from most to least.

  1. Allow us to texture image data per frame into an initialized texture. This follows the WebGL model, and is probably the easiest to understand from a developer perspective, although it adds more of an animation frame-based concept to your current API. https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL

  2. Allow us to pass in existing img, video, svg, or canvas object to the .addTexture() method, in addition to a resource URL. I can maintain access to the object and manipulate it directly using the browser-native methods provided on it.

  3. Continue to supply .addTexture() with a CORS URL, but return a closer-to-native object from .getTextures() or from .addTexture(), or a way to get a native object given a textureUid (.getDOMObject(textureUid) or similar).

  4. Just auto-play and loop videos by default. Auto-play is dependent on browser so if I load the sketch on mobile I don't even see the first playthrough of the video (because mobile browsers don't auto-play by default in deference to letting users choose data consumption). Overriding the auto-play and loop behavior would standardize this experience, although you'd have to see how it lines up with the rest of your mobile support roadmap.

  5. Add playback transport methods to your API, something like .play(textureUid), .pause(.textureUid), .loop(textureUid). This seems like the least friendly and most maintenance-requiring option.

Thanks for considering!


(Earlybirdvisual) #6

Just like @luminux and @ritchie we are also looking for ways to playback videos as textures on models within Sketchfab. The ability to loop video, and easily replace videos would also be great. Looking forward to seeing how this develops. Thank you!

(Prelite) #7

Indeed, more control over video content would be fantastic! The first two listed by Ritchie seem like fine ideas that I think would be a huge step in the right direction. It seems a "loop" attribute would be the easiest short-term solution, however introducing controls would greatly improve collaboration for the viewers. Perhaps even integrating Spout (or similar), to be run by an administrator in a collaboration group. The only down-side to that, I think, would be for those who want to access the portal when there is no "administrator" present. Just a thought...

Thanks very much!

(Luminux) #8

@cedric and @mauricesvay - checking in to see if there is any momentum around making changes to the API for video textures. Thx!

(Cedric) #9

Not started yet. We are thinking about returning an video object that could control the video playback. Something like

api.addTexture( 'url', function( error, success ) {

   var textureUID = success.uid;
   var video = success;
   video.setLooping( true );

} );

It could synchronize our video object in the viewer context. This way we could probably add a few other methods like seek or something equivalent.

It's an idea but would break the viewer API on addTexture. Also instead of using only an url as input we could also change it to an object like:

   url: 'url'
   loop: true,
   preload:  none

It could help to initialize the video object or texture.

Anyway we can't expose dom elements so we need a way to communicate with something similar with what we use internally on texture.

(Ritchie) #10

@cedric and @mauricesvay, do you have any further updates on this?

When you say you can't expose DOM elements, are you able to accept DOM objects? Or will this API always be URL/file-based?

In any case, while the return of a Sketchfab-proprietary video object doesn't seem ideal from a web standards and development perspective, it'd get us through our current use case.