Remove default light from viewer

man working with the babylon viewer is really testing my patience … there is simply no documentation to self help…?

Like how to remove the default light it creates in the scene…

show me where in the documentation you can find out how to do that? Anyway , please just tell me how to do it for now.


also not hacking in post load in javascript … i mean via the markup

TL/DR: removing analytical lights lights="" and environment texture environment-map=""

By default the viewer is using this config: Babylon.js/extended.ts at master · BabylonJS/Babylon.js · GitHub

where you can see all the props in use and the dom attributes are following this rule Configuring the Babylon.js Viewer | Babylon.js Documentation

so mixing both you can remove either the lights or env map.

@RaananW might help if anything is missing in the doc.


thanks for the kind answer,

I know i sounded a bit salty :wink: I know I said no post load solutions … but I just did it now post load in javascript … faster than digging in all that haha

This is actually what im probably frustrated by…

Is the no logical manner to derive the mark up based on the engine object? There must be system in place, I want to be able to make an educated guess to the tags required based on the engine schema /structure.


The viewer was built a few years ago, and as much as I agree it certainly needs a modernization, I am not sure what you are missing in regards of configuration or documentation.
The viewer was not meant as a replacement for code. It was meant as help for people who want to embed a single mesh on their page, with as little configuration as possible. It’s not a declarative HTML renderer for babylon.js and was never planned as one. It is very flexible, but it is not AFrame-to-three.js . It would sometimes be simpler to use javascript instead of the viewer.

The docs @sebavan referenced are explaining the abstract way of configuring the viewer, while at the end of this page you can find the entire configuration interface, which is what the viewer supports. Everything is optional, and you don’t have to start with the default configuration. You can fully configure it yourself.


You know, I have to agree. A helper that would require complete configuration wouldn’t be a helper anymore. This cannot come without a downside. And nobody is forced to use the helper. Personally, I don’t use it because I want to have full control. But from what I see here, it’s actually helping many people for a quick set-up and that’s fine by me.


understood , i have no personal need for it. Just I had a client using it and then they needed all sorts of edits and changes.

Anyway , to be honest , coding those solutions in javascript post load is a viable way to handle it . I was not in the best of moods , many apologies chaps. :pray:


@shaderbytes nw, and if you are frustrated, other ppl might be as well so it is valuable insights for us :wink:

To be honest, I have to admit that at one point I was also looking for a separate ‘bolean’ in parameters to include either light or camera (or both). I suppose mainly because of the naming that says ‘createDefaultCameraOrLight’ (as opposed to AND).
This kind of suggests that you can choose to create one or the other or both.

On the other hand, there’s already the two derived versions of ‘createDefaultCamera’ and ‘createDefaultLight’ so I really don’t see it as an issue.

1 Like