BabylonNative questions

Questions
1

I forked BJSn a week ago. I did the git commands, but got a not found on cmake. I have VS community 2017, and thought it was in there & must have a path problem. It was Friday, and I just dropped it there.

Another Friday has arrived. I see that this fork was already 24 comits behind, which is good. I see the plugins got some attention. Reading the directions a little more closely this time, I went and got cmake & an up to date Python. (Exokit / node-gyp build requires an old Python).

I did a pull from the original repo to get the changes for the week, and did a cmake ... A bunch of stuff scrolled by, including a bunch of Missing message. Almost never a good sign. I did not redirect the output so I don’t have it, but just kept on going to see what happened next.

After starting VS, I did not have the option to change to win64. Only a win32 build, but I hit F5 anyway. Got a all these things are out of date. I continued on. A whole page of stuff listed out with a linker msg at the end saying no NativeEngine.lib.

My VS was a year out of date, so I updated it (my OS, win10/64 was also updated this week). F5 again and only 2 things out of date. Still gets the same linker error, but now with only a couple of lines, this one jumped right out.

C:\BabylonNative\Plugins\NativeEngine\Source\NativeEngine.cpp(4): fatal error C1083: Cannot open include file: 'arcana/threading/task_schedulers.h': No such file or directory

I made a complete mess, & can easily just blow this away, and start over. Just thought I would relay this, first.

Question, should I even be forking this? I think I want to make a WebAudio plugin as a wrapper around GitHub - LabSound/LabSound: graph-based audio engine . You have plugins, but they are all right in the same repo. Is this how I have to do it? Are you ready for this type of discussion yet? I have tons of other stuff to do, so that would not be a problem, if it was.

1 Like
2

Pinging @bghgary

3

Hi JCPalmer,

Just from a very quick read, it looks like you might be missing the submodules. After pulling latest, did you run

git submodule update --init --recursive

? Please let me know if that works, or if that’s something you’d already done and there’s a deeper issue. Also, as an FYI, CMake can sometimes leave behind old artifacts that can disrupt future configurations, especially if configuration failed. To be safe when trying again after a CMake configuration that didn’t work, you might have to delete all the temporary files CMake leaves in its build folder, essentially doing a clean configure. We’ll be updating the README very soon to try to make some of this more straightforward. Good luck, and please keep us posted as to what you find out!

4

I only ran that last Friday. Tried it again, and that fixed it. Killer playground :grin:, but even with just that one cube, when I rotate it, say with the white side facing me, I see like 4 ghosts, like it cannot keep up. It is because I started it from within VS?

5

Hmm… Chakra (which is the default JS runtime for Babylon Native on Windows) and VS debugging can both cause some performance concerns, but I wouldn’t expect ghosting on the cube. Screenshot?

Edit: Also, if you have the VS debugger attached, the debug output should be printing an ongoing log message about the framerate; that might help indicate whether what you’re seeing is a perf issue or something else.

6

When I Stop the last cube is then the only one, so a screen shot is not possible. Maybe it is just that scene makes easy to notice, and it always does that.

Another theory is this thing is so fast, that you are doing more than one paint per device refresh. Try spinning the cube. You don’t see that?

7

Okay, I think I know what artifact you’re talking about. You may have to move your mouse a lot to get the same effect since the ArcRotateCamera's default sensitivity is lower than our debug input mechanism has, but do you see the same artifact at all on this Playground?

https://playground.babylonjs.com/#06P9RI

If so, I believe what you’re seeing is actually just persistent pixels as an artifact of a high-latency screen: the high contrast between the light grey cube and the blue background makes it unusually noticeable that some pixels retain their intensity for a few milliseconds after they’re supposed to, and because we have no motion blur, the residual intensities retain the cohesive “ghost” of a cube. I do see that effect. To answer your question about multi-render, that definitely shouldn’t be possible and would be a bug if it was happening; we’re supposed to be locked to v-sync by default. If you don’t see the same artifact on the Web version, we should try to catch this in a graphics debugger to get a better understanding of what’s going on.

8

That was fast. Yes I see it in a browser too. I guess I just never noticed it, because it is rare to have such stark scenes.

I am done for the day, but on how / where plugins are to go, while might be convenient for the building of an app to have everything in one repo, not so sure about that for development of them.

9

Yep, couldn’t agree more! The purpose of the plugin system was to be as extensible as possible, but we aren’t expecting all the plugins to live in the Babylon Native repository. Each plugin is designed as a black box (as much as possible) with a lightweight and modular build system integration mechanism, so theoretically each plugin could live in its own repository. We don’t have a formal overarching vision for this yet (and we’d love any recommendations you have!), but our current thinking is that a small number of “standard” plugins will be supported by us and included in the repo, while other plugins can develop/live independently and be easily added to consuming projects by just adding a submodule. That way (hopefully) people will be able to easily create new assemblages of plugins with as few build system hijinks as possible. Still a work-in-progress dev story, but those are the lines we’re thinking along at the moment. :upside_down_face:

1 Like
10

What might help is taking one of your current plugins, say console, and make a sample plugin repo. The repo’s readme could serve as the documentation for dev. Go around a couple of times testing that the work flow at least this simplest case actually works.

It is kind of hard to even think about, where to even start, if you did not write BabylonNative.

2 Likes
11

Great feedback! @bghgary, let’s do something like this!

1 Like
12

@JCPalmer Thanks for trying things out! I know we still have some rough edges and the more people willing to test it the better.

I like this idea a lot!

It would be super amazing if you have the will and time to do this. Sound is something we need eventually but it hasn’t been important enough to implement yet.

13

This is a core need for what I am doing. I cannot really afford to make assumptions that as I finish up my app in late 2020 that by magic the perfect deployment vehicle is going to be just sitting there waiting.

I realize there are just somethings that I cannot control, like Occlus has finished their OpenXR effort. It was only announced a couple of weeks ago that they were just starting.

I need this to be working on the Windows port of BabylonNative before fall. The earlier the better.

I had not even heard of git submodules prior to looking at this. Read a little more today on it today, and created a repo, https://github.com/Palmer-JC/BabylonNativeWebAudio with a readme of how much can / will be implemented. I need almost the whole API.

This is just a guess, but in order to actually support plug-ins from different repos require that the N-API dependency actually be in its own repository?

14

Ok, just thinking about plug-in development workflow some more. These programs have no meaning & could never run on their own outside of BabylonNative, so the easiest way to make one is while editing the BabylonNative project. N-API would then just stay as / where it is.

If trying make it outside, after making a separate VS .sln project, the dev cycle would be:

  1. Make changes.
  2. Commit them locally.
  3. Push up to Github plug-in repo
  4. Do a git submodule update --init --recursive
  5. Compile plug-in
  6. Run

Some of those steps might be eliminated, if you temporarily used a file:// url in .gitmodules of the BabylonNative project. The most idea way is still, if you could make changes while using the BabylonNative project itself, and be able to commit & push just those changes to plug-in repo.

I opened a command shell, and changed directory to one of submodules. When I did a git remote -v, it looked like it was unaware of being part of a larger project, so hopeful.

1 Like
15

Hi @JCPalmer,

Yes, I think you’re on the right track. When you create a submodule within a Git project, the submodule functions as an entirely independent repository that is unaware of the context in which it exists.

I’m going to try to formalize these thoughts and write them out more carefully over the coming days, but here’s a quick brain dump of my current thoughts on plugin development.

I agree that the easiest way to create a Babylon Native plugin is going to be working inside an existing Babylon Native app. Long-term, that won’t actually require you to be in the Babylon Native repository itself (for example, Babylon Native could be a separate submodule), but working in that repository proper is probably the easiest place to get started at this point. With that in mind, my recommendation to get started developing a new independent plugin right now would be as follows:

  1. Create a new empty repository on GitHub called BabylonNativePluginName.
  2. Fork and clone the Babylon Native repository.
  3. At the root folder of your Babylon Native repository, create a new folder called Extensions, or something like that. (Note: This new folder isn’t strictly necessary as you could theoretically add your plugin directly to the existing Plugins folder; however, doing it in a separate folder will more closely emulate how the workflow might eventually go when creating a new plugin outside the Babylon Native repository, not directly inside it.)
  4. cd into your new Extensions folder and add your new empty repo as a submodule there.
  5. Create a new CMakeLists.txt in your extensions folder which just calls add_subdirectory(BabylonNativePluginName), similar to how this is done for the existing Plugins folder.
  6. Add a line to the root-level CMakeLists.txt that calls add_subdirectory(Extensions), similar to how this is done for the existing Plugins folder. (Note: you probably don’t want to start with the EXCLUDE_FROM_ALL feature enabled as this will cause the Visual Studio CMake generator to ignore your new project until some end-level target actually includes it, which shouldn’t be a problem but also isn’t necessary in your case.)
  7. Add a line to Apps/Playground/CMakeLists.txt to introduce a dependency on BabylonNativePluginName (you’ll create this CMake target inside your plugin repository), similar to how this is done for existing plugins and polyfills.
  8. Your Babylon Native repository is now ready to consume the plugin in your BabylonNativePluginName submodule and use it in the Playground app; I recommend committing your Babylon Native changes to a branch at this point, if you haven’t already done so.
  9. From here, you can build your plugin however you want; the only requirement is that your plugin’s root-level CMakeLists.txt expose a BabylonNativePluginName library target that will make all your plugin’s capabilities available to the Playground app. (I recommend looking at the NativeWindow plugin for a self-contained and relatively simple example of how you might structure your plugin’s repository.) Your BabylonNativePluginName submodule will function identically to an ordinary Git repository, so you can code, commit, and push from it exactly as you would with an ordinary Git project. The only addition is that, to keep the outer repository in sync, you will need to cd out into the containing repository, git add ., and commit the new state of the submodule. This doesn’t need to be done all the time; only when you feel it’s appropriate, for example when changing an exposed function or reaching a major capability milestone.
  10. Once your plugin’s contract is defined, it is likely that you will have some sort of initialization function that needs to be called in order to expose it to the JavaScript; this can most likely be called from App.cpp, as is done for the existing plugins and polyfills.

I’ll be talking about some of this in new in-repo documentation very soon, and we can explore more in additional tutorials/examples/etc. For now, is this useful to help you get started with the plugin development process?

2 Likes
16

Too late in the day to take on that long of a response. Will look at tomorrow.

2 Likes
17

Ok. The Cmake stuff is helpful. What may unique about this plug-in is that it is based on a pre-existing repo that is a fork of the original WebKit WebAudio implementations for Safari & Chrome. Fortunately, it has its own CmakeLists.txt already.

I am still at the paper phase of thinking about an architecture. Since the classes are almost on a one to one basis, I was thinking perhaps, I might just sub-class them, and put the wrapping in the sub-classes. The namespace in the repo is lab. If I used the namespace b_native, this is what I was thinking with the sub-classes at the top:

architecture
architecture1402Ă—885 444 KB

I am still reading N-API, but does anyone see an obvious problem?

On another note, FYI, yesterday Oculus released a preview of their OpenXR SDK. Perhaps a read through may inform your work. @RaananW, pinging you as you may not be reading BabylonNative topics. I know you are up at the WebXR level in the actual framework, but you might also be interested.

2 Likes
18

Thanks for the heads-up on the OpenXR drop! We’ve been looking forward to that. :smiley:

Your plan to wrap the existing types seems reasonable to me, though of course there’s a lot I could be missing. I don’t see any obvious problems. One possibility, though: if you simply wanted to depend on the existing repository instead of modifying it (thus enabling you to more easily take new versions, for example), you might could add that repository to the Dependencies folder as an unmodified submodule. Your plugin (or polyfill, as the case may be) could then depend on that and thus keep the N-API wrapping separate from the underlying implementation. This would be conceptually similar to the relationship between NativeEngine and its bgfx dependency. I don’t know if such an arrangement will actually be necessary/viable/useful for your scenario, but it’s something to consider.

19

I was already planning to have a submodule, and leaving the LabSound repo unchanged for the reason you give.

The repo I created actually does that (link a few posts up). It also has a readme with tables of exactly I want to implement. (There are a few minor Node types not implemented in LabSound). I hope you are suggesting a refinement, & not saying sub-classing & using a submodule are at odds.

20

Yep, definitely just in refinement territory. :slightly_smiling_face: From a quick glance, the approach outlined in your repo looks great to me. The only refinement I would suggest is that your plugin/polyfill repo not have its own Dependencies folder; instead, the plugin/polyfill would simply try to link to the dependency by name, and it would be the consuming repository’s responsibility to add the dependent submodule to its own Dependencies folder and make sure that it’s available to the plugin/polyfill. I’m writing a documentation page to describe this pattern in detail, but the gist of the idea is illustrated by the relationships between existing plugins/polyfills and the submodules on which they depend.