Obviously this a fairly heavy client application. But imports, exports and renders are server side operations. They manipulate the scene graph using the same code that the client side uses to manipulate the scene graph.
Live render is a great example. When you start a live render, we start a client on the server, but instead of translating the scene graph into WebGL, it translates the scene graph into V-Ray. Any changes you make to the scene are sent to the server-side client using the same mechanism used to synchronize changes between 2 users editing the same scene.
If we used a different language in the front end and the back end, we would have ended up with a lot of duplication of effort.
Comments
Here's an example: http://clara.io
Obviously this a fairly heavy client application. But imports, exports and renders are server side operations. They manipulate the scene graph using the same code that the client side uses to manipulate the scene graph.
Live render is a great example. When you start a live render, we start a client on the server, but instead of translating the scene graph into WebGL, it translates the scene graph into V-Ray. Any changes you make to the scene are sent to the server-side client using the same mechanism used to synchronize changes between 2 users editing the same scene.
If we used a different language in the front end and the back end, we would have ended up with a lot of duplication of effort.
Very cool!
I started working on a winged-edge WebGL editor--really happy to see other people getting this stuff to work!
Neat-o. We use a more convention polymesh representation. Email is in profile if you want to collaborate or interoperate.
Interesting. Thanks!