Jump to content

NullEngine in v3.1


Recommended Posts


I've been diligently working on my game, and recently came upon the recently released BabylonJS v3.1 ... and I am super excited about NullEngine!

My game is multiplayer client/server; the server component is Node.js running ActionHero v18 (and of course the client is running BabylonJS!).

Taking a look at the documentation and accompanying example for NullEngine, it seems it does not run 100% out of the box. However... I've been able to get everything up and running under Node 8.9.3 with a combination of mock-browser, EventEmitter, xhr2 and sheer luck :D

// assume this file is saved as mock-browser.js

'use strict';

const EventEmitter = require('events');
class ProgressEvent extends EventEmitter {}

module.exports = {
  setupMockBrowser: () => {
    const MockBrowser = require('mock-browser').mocks.MockBrowser;
    const AbstractBrowser = require('mock-browser').delegates.AbstractBrowser;

    let window = MockBrowser.createWindow();
    let opts = { window };
    let browser = new AbstractBrowser( opts );

    global.window = window;
    global.navigator = browser.getNavigator();
    global.document = browser.getDocument();
    global.XMLHttpRequest = require('xhr2').XMLHttpRequest;
    global.ProgressEvent = ProgressEvent;

To use this, it is as simple as:


I'm curious to know a few things:

1) Since the game supports multiple users interacting in different areas (e.g. multiple "rooms", multiple users per room, users can only interact with others in the same room) it makes sense to me to manage these "virtual player namespaces" separately, as one BabylonJS Scene per "room". Does this sound like a good way to divide up the game? Are there software limitations of managing multiple scenes simultaneously?

2) Since the game-server has many other responsibilities (database saves, websocket clients, periodic tasks via a task-runner) it seems wisest to manage the client-side-equivalent of the "render loop" in a periodic task, which would be responsible for updating objects' positions based on velocity, testing collision, and issuing events (via websockets) to game clients based on movement updates/positioning rather than the typical engine.renderLoop(). I don't need the updates to be real-time, but do need them to occur 'quickly enough' (e.g. every 100ms) that my game-server can keep up with the number of objects per-scene. Does managing my own engine.render() seem sane? (Now that I write this out I feel that updates and rendering are unrelated. I guess we'll see...)

3) For geometry collision, I'd like to have "proximity" and "actual" collision-testing; perhaps BoundingSphere for quickest/optimal proximity-testing, and BoundingBox derived from a mesh for actual collision. Good idea? Terrible?

I'd love to hear the community's thoughts, and thanks for the amazing NullEngine update!

Link to comment
Share on other sites

So..You should not need window. The nullEngine is designed to work without Window and Document object. We had one bug that is now fixed in 3.2 (So no more need for mock browser, window, document and ProgressEvent)

1. No problem to manage multiple scenes. It is a good usage of it. 

2. Not at all. calling setTimeout(scene.render()) looks perfectly fine

3. Good idea :D And actually this is what I do for the collision engine (with a third level which is triangle collision check)

Link to comment
Share on other sites

19 hours ago, Deltakosh said:

So..You should not need window. The nullEngine is designed to work without Window and Document object. We had one bug that is now fixed in 3.2 (So no more need for mock browser, window, document and ProgressEvent)

Any indication when Babylon 3.2 will make its way to Github?

Thanks for the feedback to my questions!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...