I have a database of 3D models. I want user can rotate the model and view it in the web page.
So I have to implement an instant rendering algorithm for this.
A raytracing/raycasting method on CPU is preferred since the server has no GPU on it.
I understand that a primary-ray-only ray tracer with SSE and KD-Tree/BVH can be very fast. Besides, I want to add some GI effect(fake GI effect can be also OK for me, such as SSAO) in it.
How good can I achieve?
(some NPR rendering methods are also considerable)
In HTML5, you can render 3D objects with WebGL (an implementation of OpenGL) with some JavaScript. The problem is that WebGL is a client technology. Therefore, all the rendering is done by the browser.
There is one possible solution if you really want to distribute some logic on a server. You could use a server side language and send the vertices to the client through some database transactions. After, your website could make some AJAX calls to a server that would make certain operations within the server and return some vertices. The only problem is that this could require a lot of bandwidth.
Otherwise, another solution would be to use a tool such as Unity to create what you want. Then, you would need to embed the Unity Player in your web page.
Related
I'm embedding GMStudio game in browser using . I need to send some data to the game from site's frontend in JSON and to receive some data from the game in frontend to make consequent actions.
So, my idea before was to save data in cookies/localStorage and to get it in the game somehow, using HTTP functionality or DLL's. Also, I'd like to emit messages from the game using window.parent.postMessage and receive them in frontend correctly.
Alas, I did not find a way to implement this. I hope there's some consistent approach to this problem about which I do not know.
The backup plan is to use Game Maker http_post_string and web sockets to get user's data before game's start and to make frontend do something after game's ending. It's clumsy and insecure, however.
The standard approach is to make a JavaScript extension.
That is done by creating a blank extension, adding a blank JS file to it, defining the functions via the context menu on it, and then adding the implementations into the JS file. Then you'll be able to call them from GML side as per usual.
This way you can access LocalStorage\Cookies, transmit\receive data from JS backends, and overall mess with the runtime as you please (with various degrees of understanding required to access internal data).
I have a web application which create a big image (30Mo) as a bufferArray inside a web worker.
I would like to return this image to the main thread.
Return the bufferArray via the postMessage method is very slow (5 secondes) and it freeze the UI.
postMessage(data);
So, I have looking for a library to compress the image but I'm only find library which use HTML5 canvas.
Because HTML5 canvas is forbidden is Web Worker, I'm asking if you have solution to this problem ?
My goal is to take more time in the Web Worker and reduce the transfer time.
Some browsers support transferable objects but to my knowledge not all of them.
Transferable objects are basically pointers to structures that you pass from main thread to worker and/or back. Using this methodology requires sightly different invocation of postMessage()
More of this is covered here
How about to increase the concurrent web workers threads pool?
Here is two great articles which cast some lights on how to use it:
http://www.smartjava.org/content/html5-easily-parallelize-jobs-using-web-workers-and-threadpool
http://typedarray.org/concurrency-in-javascript/
Here's how use the postMessage method :
postMessage(jsonObject, [jsonObject.data.buffer]);
The first argument is the same as usual.
The second must be an array of ArrayBuffer.
Still looking for image compression library with no use of HTML5 canvas.
I opened this matrix multiplication benchmarks and my browser (Firefox 7.0.1) froze until the benchmarks finished (I opened the page in an old Asus EeePC 1000H).
I heard that web workers were invented to separate processing from displaying the web pages. Is it possible to make use of the Web Workers API to make WebGL not stall the whole web browser ?
For the sake of clarity: the benchmark that you linked to does not use WebGL at all. (I should know, I wrote it.) And in the case of that particular benchmark you absolutely could run it in a Web Worker now and it would be perfectly fine.
(Fun fact - Web Workers didn't support TypedArrays when the benchmark was built, and since most of the matrix libraries rely on that it was impractical to run it in a Worker at that time. That has since been fixed.)
Anyway, to answer your original question: No, WebGL cannot run in a worker. The core blocker to this is that in order to get a WebGL context you need to call getContext on a canvas element. Web Workers explicitly disallow DOM access (which is a good thing, BTW!) and as such you'll never be able to access WebGL from a worker.
But that's not as bad as you might think. For one, consider that most all 3D rendering is actually happening in a different thread anyway. Specifically, a whole bunch of threads running on your GPU. The only part the browser has in it is to tell your graphics driver "Hey! Start rendering some triangles using this data!" and then it moves on without waiting for the triangles to actually be rendered. As such, while the draw commands must be executed from the main process, the time it spends blocking that process is (usually) very little.
Of course, that's not what's going to eat up a bunch of your time if you were coding a realtime game. You've got animations, physics, AI, collision detection, pathfinding... there's a lot of non-graphical tasks involved that will eat your CPU alive if you let them. In some case (animation), it's usually just gobs and gobs of matrix math, just like the benchmark you linked to! Fortunately for us, however, that type of processing CAN be done in a Worker, and all we need to communicate back to the main thread is the data required to render the scene.
Yes, this introduces some challenges in terms of synchronization and data transfer, but on the whole it will be vastly preferable to locking up your browser while we try and simulate those 500 boxes colliding.
Yes, on Firefox!
https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/
We’re happy to announce WebGL in Web Workers in Firefox 44+! Using the new OffscreenCanvas API you can now create a WebGL context off of the main thread.
By default you can't use WebGL in a Web Worker as Toji explained.
You can check out WebGLWorker which is a library that lets you do WebGL stuff in a Web Worker, by transparently proxying commands to the main thread.
Here is a nice blog post that explains how it works.
What I would like to do is create a canvas that will show a network map. It's not really a network map but in terms of explaining it the network map example works best to not bog you down with details that don't pertain to my question.
On the network map I want to display routes the traffic takes. These routes change in time, sometimes as frequently as multiple times per minute. On the server side I have a log file to which each route change is appended as it happens.
I know how to create the canvas, I know how to draw my routes onto the canvas.
Is it possible to have the server push an update to the canvas without requiring a page reload/refresh, essentially requiring no user interaction at all? The routes drawn just automagically change?
This would need to work on IIS so a jscript or .Net based solution would be necessary. I won't be able to install PHP, Python, Ruby etc.
Thanks in advance for any insights you can provide.
I recommend that you look at a WebSockets solution to push the information from the server to the client (JavaScript). When you receive the update you can update the canvas as required.
Technologies you should look at if your preferred server technology is .NET would be a service like Pusher, who I work for, and our .NET APIs which let you push updates to the client via our REST API.
If you would prefer to host your own realtime infrastructure then you could look at WebSync (which is actually a Comet technology) which integrates with IIS and also XSockets. There are also a number of realtime technologies on this guide which may interest you. If you've any further questions just let me know.
Server-Sent Events: http://www.html5rocks.com/en/tutorials/eventsource/basics
( Server-sent events is a technology for providing push notifications from a server to a browser client in the form of DOM events. The Server-Sent Events EventSource API is now being standardized as part of HTML5[1] by the W3C. )
Yes, I've done this before (with an ajax-based drawing application). It's very possible. Send packets of information via AJAX (JSON or something), interpret them, and draw them on the client's canvas element. This is trivial to design (and easy to implement using something like jQuery). It seems that you already figured out you need to have a server-side script that pushes information to a web page and a web page that actually draws stuff on the canvas. That's essentially all it is.
I'm not a Web Developer, and I don't know a lot about the web application frameworks out there.
Recently, however, I got into Wt. It's a web framework written in C++ (that's why I got into it), but what impressed me the most is the idea it's based on.
Its API is different from any web framework I ever heard of (CppCMS, Yii, Django, Pylons, Zope, Drupals, Java Servlets, Struts ...): a new Application object gets created for any user session, and it stays alive until the session expires (only at this point the Application object gets destroied). This Application object works like a desktop window: you put Widgets in it (widgets like forms, links, labels ...); when the user clicks on a link (when the HTTP server receives a new GET/POST request) a function gets called on the object tight to the user session (in a nice Signal/Slot way), which can remove/add/change the widgets, thus changing the page the user will see.
As I said, I'm not very skilled with web frameworks, I develop almost only desktop applications; maybe for this reason I think this paradigm behind Wt is great.
I'd like to know what are the pros and cons of this framework API in respect to the other ones, and if there are other frameworks (also in other languages) based on the same concepts.
Wt is a great framework for its intended range of applications.
Wt is great for :
web apps tightly coupled to a session, i.e.
made to be accessed only by users that are logged in (except the landing page)
display a lot of user-dependent content (so not for a wiki)
relying heavily on state
web apps that need to have a lot of controls/buttons and user input.
For exemple, I plan to write a browser MMORPG. Pages will all be having a state tied to a user, and there will be a lot of buttons. Wt is perfect for that. I used to be a Ruby on Rails developper, and switching to Wt for this kind of app was a great moment. It's increadibly cumbersome to design forms with traditional frameworks that try to enforce pure REST.
Wt would also be perfect for a control interface on some process. For example, an interface allowing your customers to configure their adword campain, etc.
Of course, using Wt is not perfect regarding control and separation, but it allows extremely fast development when you need only the "classic" features (buttons, editors, etc.)
So as a rule of thumb, if you are trying to put a desktop application on the web (which is a great idea, removing the need to deploy and update on your customers' machines), Wt is a good candidate.
Also, if you are interfacing with an existing C++ codebase, Wt has an advantage.
I think this is generally bad idea.
Web application is very different from GUI one and there are many reasons:
99% of the web is about the content rather then about iteration.
You go to web to get or share content rather then to do some real time interaction
like drawing a picture, working with spreadsheet or anything else.
Web is content driven rather then "event driven" interactive application.
This has strong impact on how do you create most of web - you bring information
to user rather then interact with him.
The server and client programming is very different
There are some web GUI applications like e-Mail, Chats clients but to perform well
they require very good separation between the client side written
in high quality Java Script and the high quality server side backend that is used
over AJAX for content retrieval.
Hiding this separation like Wt does or (other known frameworks) lead to crappy
software and generally brings more problems then solutions in long run.
Because it should be very clear separation between server side and client side jobs
as some require real time response and some don't.
When you try to solve all this in one wait for problems. Note, there are client-server
solutions for GUI (see X-Server as example) but unlike web they designed for this
and rather work more like IPC rather then client-server solitions.
The web is stateless most of the time.
Or to be more correct the state usually keeps quite small amount of data.
Creation of instant session object is nice idea until you need to...
Scale up save state in long terms then this model becomes not so good, of course
this not "forced" model by Wt but it is general concept that fits certain concept
and some does not.
Bottom Line
If you want to design good GUI like web application. Start learning JavaScript and use good GUI JavaScript frameworks that fit well to GUI even driven design. Then combine them with some server side API using some interaction RPC model like Json-RPC, XML-RPC and other
AJAX tools.
This is the way to do things right for highly interactive applications.
If your application is more content oriented then most of server side web
frameworks do great job - concentrate on server side with its great tools suitable
for the job.
All in one solution? It just does not work...
Disclosure: I'm developer of CppCMS and I think Wt just goes in wrong way.
ASP.NET is similar; it has the same goal to make web development look like desktop application development.