Render a scene in node.js

[jacquesr]

Hi everyone,

I'm interested in finding out whether or not it's possible to render a babylon js scene in node. I am developing a component that should be able to deliver static images of a 3D scene from a (web)server to a client.

I saw that there is node-webgl but before I get fancy about it, I want to know if there is anyone with experience on that topic around here.

Regards

Jacques

[Wingnut]

Hi J!

Umm... I wouldn't call it "experience" but... I once used node-webkit, which I think is now called 'NW'.

http://www.html5gamedevs.com/topic/2571-the-wingnut-chronicles/?do=findComment&comment=94225

NW... carries a major subset of Google's Chrome browser... with it.  That subset is called "Chromium".

Let's look at a picture from that post...

http://urbanproductions.com/wingy/babylon/misc/atom_nw.jpg

I BARELY turned it on, but you can see the webpage generated at the top center (in Chromium).  Notice that the demo dynamically inserted node's version number... into the page (see the index.html window).  The "developer tools" part of Chromium... is showing in the bottom window.

I know little, but... as best I can tell, using this method... allows Node to have access to the DOM tree, AND it allows events coming from the DOM tree... to be heard by Node.  I think this is called piping or streaming or some other name you devvers thought-up.    I don't know much... I'm just here for the free beer and the door prize drawing.

Aside:  Gulping vs Grunting... is related to this.  One is... streaming (Gulp?), and the other is chunk-by-chunk (Grunt?)???  I dunno.  My brain is a mess. 

As far as I know, there is nothing stopping you from generating a BabylonJS scene... in that Chromium webpage top-center.  I don't know if this method is good or right, but... it's better than peeing on your foot, yes?    Notice what I said, there, about JS Contexts.  I had a difficult time getting the toolbar and dev tools to activate... in Chromium.  It was because I put nw.exe OUTSIDE-OF the project folder... too far out of scope from the project.  As soon as I moved it back into the project, the full-powered version of Chromium... became operational.  Yay.

If you would be so kind... keep talking about your progress as you experiment with this stuff.  I want to learn as much as I can about it... because I love generating webpages from NodeJS.  I think it's cool. My objective was to make a desktop app with HTML as the gui interface.  I was going to make my own "webby" Tortoise or Git Desktop (html GUI good. Runs everywhere, looks the same on all plats).  I bailed on the project. Too overwhelming and too many higher priorities.  I'm an artist, not a devver. 

[jacquesr]

Hey wingnut, the server may not have an online drawing context (lack of desktop inside the user running node), so chromium might be out of the question (or only a last resort if anything else fails)

[Wingnut]

Well NOW you have me thoroughly confused.  I think the term "render" infers the existence of a canvas.

Do you want to assemble a BJS Scene object (scene graph) with NodeJS?  Easy!  Just steal our scene code. 

But, delivering scene-grabs from an un-rendered scene?  Weird.   Context2D, Context3D, and ContextJacques.

Anyway, I'll shut-up now, and let smarter people talk.  heh

[prvi_treti]

As I also need to render single frame server side as well, I had looked for options. node-webgl had led me to headless-gl but didn't check it yet. But I now tend to believe (considering apparently webGL is openGL ES with some differences) that this is something that can only be done with a node module ( probably in c++ ).

I will be very happy to be proven wrong though as it sounds as suicide mission for me.

[NasimiAsl]

it is very bad solution because all render (c++ (opengl) or anything ) do it in gpu and server side is not good for graphic projects but i think you have a little problem in first and make a solution for that and in your solution you have very big problem.

go change your solution

[prvi_treti]

2 hours ago, NasimiAsl said:

it is very bad solution because all render (c++ (opengl) or anything ) do it in gpu and server side is not good for graphic projects but i think you have a little problem in first and make a solution for that and in your solution you have very big problem.

go change your solution

well, no one is talking about rendering 25 fps but rather a snapshot as on my case it is to render (google mapsish) map once it is changed which isn't frequent. If can't rely on a "headless" solution, then what's left? Maybe a node-canvas solution mimicking webGL or kind of software renderer?

[NasimiAsl]

yes i think about webgl for this question and all webgl scene need javascript to render ( javascript is client side )  Anyway, I'll shut-up too , and let smarter people talk.  heh

[prvi_treti]

10 minutes ago, NasimiAsl said:

yes i think about webgl for this question and all webgl scene need javascript to render ( javascript is client side )  Anyway, I'll shut-up too , and let smarter people talk.  heh

Well I found this https://www.npmjs.com/package/three-software-renderer , maybe it helps.

And fair enough, let smarter people talk , I give up as well

[NasimiAsl]

yes we do fun some times sorry about that( really apologize it is not professional talking ); and

we have very more smarter than us every time . we challenge other people to find better and short answer if we write wrong so it is  work ;

you r smarter right now

[prvi_treti]

28 minutes ago, NasimiAsl said:

yes we do fun some times sorry about that; and

we have very more smarter than us every time . we challange other people to find better and short answer if we write wrong so it is  work ;

you r smarter right now

I see nothing to be sorry this is simply beyond my reach atm as well

[jacquesr]

Well being able to achieve this with BJS would be great since I could copy and paste the code to a node js app (more or less). It's a very interesting topic. Performance is not a question.

A long, long time ago, I tried this with a library called mesa, which those of you going for software rendering on a server might have heard of. It fakes the openGL API but has some limitations in features.

Yet, with webGL, we of course add another problem when going server side: We want to prevent having to start a browser / online desktop app every time someone requests a static 3D frame...

 

[dbawel]

Jacques,

We are using node.js and websockets.io on our primary server, so I am familiar with what node.js is capable of. I'm certain you could adapt node.js to render a WebGL scene, but if I understand you correctly, the amount of new code and configuration to do this would probably be beyond a huge task. I can't even ponder how this might be configured. I might advise that you use your node server to initiate a thread (or threads) which controls the rendering of the scene and captures frame grabs - not in node.js, but in a standard WebGL process, using an application such as what was recomended earlier - Chrome.

This would reduce the amount of work for you by at least 99%. Good luck. I believe I know what and why you would like to do this, as I have advised and launched similar efforts years ago when bandwidth was a big issue. However, since bandwidth has and is expanding so very rapidly, I personally don't believe the need to accomplish this is justifyable today. But this is simply my own personal opinion. Regardless, Godspeed! 

DB

[jacquesr]

On 10.3.2016 at 9:53 PM, dbawel said:

Jacques,

We are using node.js and websockets.io on our primary server, so I am familiar with what node.js is capable of. I'm certain you could adapt node.js to render a WebGL scene, but if I understand you correctly, the amount of new code and configuration to do this would probably be beyond a huge task. I can't even ponder how this might be configured. I might advise that you use your node server to initiate a thread (or threads) which controls the rendering of the scene and captures frame grabs - not in node.js, but in a standard WebGL process, using an application such as what was recomended earlier - Chrome.

This would reduce the amount of work for you by at least 99%. Good luck. I believe I know what and why you would like to do this, as I have advised and launched similar efforts years ago when bandwidth was a big issue. However, since bandwidth has and is expanding so very rapidly, I personally don't believe the need to accomplish this is justifyable today. But this is simply my own personal opinion. Regardless, Godspeed! 

DB

I personally agree, yet our product management still seeks for such options. We have customers where internally, bandwidth is still an issue (whereas imho that would rather speak for a client rendering since it only creates the scene once) and it may also be possible that we need to display a still 3D image on a device uncapable of using webGL itself.

[adam]

1 hour ago, jacquesr said:

a device uncapable of using webGL

I wonder what percent of your customers that would be.

[jacquesr]

19 hours ago, adam said:

I wonder what percent of your customers that would be.

SAPGUI, embedded browser, 100% of current situation. Probably impossible to get them all to a browser based ui

[dbawel]

I might guess that the devices you speak of may support openGL and/or DirectX, and these are what we used to render 3D elements before WebGL was widely adopted. If it were me, I would probably look at rendering using openGL or DirectX depending on what you need to display. Otherwise, I personally wouldn't have the time to build a renderer in WebGL using node.js, since I assume this is cost prohibitive as well as will require a reduculous amount of time to develop this application natively rendering in the node.js framework. However, launching a thread and streaming rendered fames using H.265 would be reasonable quick to accomplish.

again, best of luck.

DB