I know i sounded a bit salty 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.
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.