I built a site that serves as a library for a specific category of 3d models. I currently use modelviewer to show glb files of 3d models but on mobile devices the performance isn't good. Often times the page will crash and randomly reload, and the problem occurs even more when the site is loaded through the instagram web viewer which a lot of our customers use. Ive tried sites such as thangs and sketchfab and this never happens on their website so can someone tell me what they use to show model preview.
Sketchfab uses it's own render engine with lots of optimizations applied on the fly. It's not a fork of three.js afaik.
Related
Is it possible to add a load of programs to a website that can be opened within the webpage itself. for example say the animation software blender. Would it be possible to add all the blender files to the website files and execute them within the webpage creating the GUI inside a window sized set of parameters
Updates Based on Inputs: Amazon recently released a Product/Service named Appstream 2.0 which does exactly what you had asked for, It is a proprietary platform though and has its own learning curve to even set it up. It does work well with solidworks, so it should work with most of other applications too.(Solidworks are providing the demo of their software via this service as of now(Nov18)). Also it uses a specific technique which doesn't require a live video stream and instead streams just the changes in images sprites which in itself is pretty interesting.
Another alternative is cameyo which is also a paid service.
As of opensource alternatives, I don't yet know of such a software.
-----------------------------------------------------------------------------------------
The closest you will ever get to this thing is flash and that too is NOT an exe.
About having a GUI for a software is a different thing, depends upon whether that specific software is exposing an API and maybe a service/Port that its listening to. And maybe making a script based client side GET request to that specific service on localhost, maybe.
Anyways, Wanting to run an executable on the client side is totally defeating the purpose of a website. Generally it is the other way round like say, you want to provide a service via website to compress a picture. You can pipe the submitted data to that respective software and then return the result as a response.
I want to extend AR.js by adding my own tracking backend. However, I have troubles finding any documentation on the architecture of this library or how it interacts with underlying components. Likewise, it'd be useful to have more information on how AR.js relates to ARToolkit, Tango, A-Frame, WebVR, ARCore and WebARonARCore. Since the area is quite new and striving, there are a lot of projects going on simultaneously and it's quite confusing and hard to differentiate their functionality sometimes.
The backend I need to implement is the object recognition based on YOLO. I have a prototype running - Android Unity Tango application, it offloads video captured from the device camera onto the edge node, where it is processed in real-time and the information about recognized objects is sent back to the device, where it is used to render annotations. I'd like to have these annotations to be represented as a-frame tags, in order to make content layering easy by using JavaScript.
Any ideas/pointers are welcomed.
I'm making a simple gaming platform. It's supposed to be used only on (W)LAN. One of the devices is running a node.js server, and client devices can be computers, smart phones or tablets. I'm planning to handle all the client-server communication using socket.io, as that makes it possible to have almost real-time connection and to have sessions without having to manage user accounts.
When the user joins a system on a browser, the interactioin goes like this: Starting view ---> game selection view ---> join/create game view ---> game lobby --> actual game.
The question is, what would be a good approach for changing these views? I've thought about some possibilities:
I could load a partial web page (html-document) when a page is changed
I could load one large html-document when joining the system and show/hide divs on a page change
I could use some more complex framework
Which approach would be best, considering that the application will be used on mobile phones and therefore memory usage and battery life are important factors?
I would use Backbone.js Views. It's lightweight, and you can use it without using any other component from Backbone.
While reading Not Your Parent’s Mobile Phone: UX Design Guidelines For Smartphones - Smashing Magazine, in the 'Data Transfer and Pricing' section, the below one got my attention:
Much has been said recently about Responsive Web Design. This approach does create some challenges with minimizing data transfer. Jason Grigsby has a very good write-up on the specifics. To summarize, CSS media queries — part of the magic sauce of responsive design — do almost nothing to lessen the overhead of data transfer to mobile devices. Resizing or hiding unwanted images still requires the full images to be downloaded to the browser. In addition, resources such as JavaScript libraries might be downloaded to mobile devices without even being enabled for users.
While I m reading the lengthy article by Jason Grigsby as mentioned in the Smashing mag article, I m wanted to know if any one following some best practices to avoid such issues?
Its good to allow Google to host your jQuery libraries for various reasons. Read here
Don't scatter your Javascript functions across numerous files. The lesser files the client needs to fetch, the faster. Multiple files means multiple requests.
Often, it works great to include your scripts
at the end of your HTML mark up. This makes the HTML markup load faster (page generates faster), after which the JS files are then fetched.
Learn to use sprite sheets for your CSS. A sprite sheet is basically a large image that contains various images you need. A single large image is smaller than the sum of its parts because it only needs to maintain a single color table. Also, once again, lesser files to fetch = lesser requests.
This post has some good stuff : http://www.smashingmagazine.com/2011/07/22/responsive-web-design-techniques-tools-and-design-strategies/
EDIT: Some more links
https://developer.mozilla.org/en/Web_Development/Responsive_Web_design
http://dev.opera.com/articles/view/the-mobile-web-optimization-guide/
http://www.html5rocks.com/en/mobile/mobifying.html
Are there any best practice for avoiding unnecessary resource
downloads when the same site is viewed from a mobile if those
resources are not relevant in that view
Assuming you are asking about conditional loading of resources, check out yepnope.js
I would recommend some backend solution for content adaptation. In our site, we use Apache Mobile Filter to remove excess content that wouldn't be relevant to mobile and/or tablet users, as well as image resizing to reduce load times.
There are other front-end techniques you could look into, such as lazy-loading images (only loading images when they're near the viewport -check out jQuery lazy loading) and loading social sharing buttons on demand (like TechCrunch.com).
There have been many debates about this topic already here, but none of them fully answered my question so I figured I would pose it and hope I get one or two decent answers.
We're planning on relaunching our company website in the next few months. Our current site, for the most part, is text-driven and because of this we rank very well on Google, Yahoo, and Bing for our primary keywords. We want to increase the "Wow Factor" of the site a bit (we're an interactive agency) but still maintain a majority of our search engine footing. The option to use Flash, AJAX, and other technologies that are not considered to be search engine friendly have come up numerous times in our meetings and each time we have to evaluate what kind of impact it would have on us from an SEO perspective.
Assuming a good portion of the site content will be encapsulated within a Flash (swf) file, what would be the best course of action for maintaining current rankings? I've read numerous times that Google indexes Flash files but I am unsure as to what extent. Further, is there a method of telling Google not to index a Flash file (through a variable or otherwise)?
Finally, I had an idea that seemed sound in theory and wanted to put it out into the world and see what type of feedback I receive on it:
Again, assuming the whole page is in a Flash file living on index.html, would it be possible to build out the site as normal (set up a logical directory structure, add content to static pages within said structure, etc), specify paths to those static pages in a Google XML Sitemap file, and have the spiders crawl only those pages (which are rich in content) while the user experiences some concoction of Flash/Javascript/AJAX/etc? If this works, what would be the pros/cons of this solution? Thanks for bearing with me on this slightly off-kilter question.
Well referencing Google I found that they have made impressive strides into indexing Flash based web pages. The only limitation I found from reading the article is that they are currently still limited in their ability in these three areas:
Googlebot does not execute some types of JavaScript. So if your web
page loads a Flash file via
JavaScript, Google may not be aware of
that Flash file, in which case it will
not be indexed.
We currently do not attach content from external resources that are
loaded by your Flash files. If your
Flash file loads an HTML file, an XML
file, another SWF file, etc., Google
will separately index that resource,
but it will not yet be considered to
be part of the content in your Flash
file.
While we are able to index Flash in almost all of the languages found on
the web, currently there are
difficulties with Flash content
written in bidirectional languages.
Until this is fixed, we will be unable
to index Hebrew language or Arabic
language content from Flash files.
By the sounds of it you won't have any problems with any of the 3 'problems'. Based on this document Flash sounds like a viable option for you.
Adobe has been working on their end as well to accommodate the search engines in their stride to make SWFs more search engine friendly as well. So with the combined efforts of both Adobe and Google/Yahoo if you take a dip in ranking within a year or two the search algorithms will be better than they are even now.
As far as not indexing you should be able to add in a simple
User-agent: *
Disallow: /directory/
Disallow: /directory/page.html
to your robots.txt file.
Andrew,
I've had to deal with this sort of thing a few times and I'd recommend maintaining both a Flash site (for users) and an HTML site (for search engines). Here's how you do it:
With whatever server-side stuff you're using set up some kind of switch that determines whether a particular request is for HTML or for whatever your Flash movie consumes (XML, JSON, another SWF, whatever). Every page on your site should be able to return HTML and whatever you choose to feed your Flash movie. A query string parameter like "requestType=Flash" will work just fine.
Put all of the content in your HTML pages in a div tag and make the div invisible with CSS. Use SWFObject to check if the requesting browser supports Flash and, if it does, have SWFObject replace your HTML content with your Flash movie. Search engine spiders will ignore your scripts and simply crawl your HTML pages and if you'd like to show the HTML to users with browsers that don't support Flash (like mobile browsers), just make the HTML content visible after SWFObject has determined that the browser doesn't support Flash.
Once your Flash movie has loaded, have it request whatever data it needs from the server using the same URL of the page that it was loaded on, but with the addition of the switch variable above.
Handle navigation from that point on with SWFAddress. When a user clicks a button to request a new page, pass the request through SWFAddress first, which will update the browser history using the hash mark trick, and then have your Flash movie make its request to the server.
I'm currently working on a site for a friend that uses this technique here (I should note, to protect my pride, that the site is still very much a work in progress):
http://www.casabarbuenosaires.com/
A browser request to any page on the site will first return the HTML representation of that page (you can view source in your browser to see that). SWFObject then replaces the HTML content with a Flash movie that loads a custom XML description of the same page which the Flash movie then constructs and displays.
I've worked on sites in the past that have used this technique and gotten excellent search engine results. Since you don't need to worry too much about what your HTML site looks like to humans, you can focus solely on what it looks like to search engines.
Another added benefit of building your site this way is that you are compelled to separate your site's content/copy from its visual representation. Throwing your entire site into a single SWF is generally NOT a good way to do that. It's much easier to maintain (or re-skin or scrap) a site when your content isn't all mixed up with your code.
Hope this helps,
Scott