
Related links:
[source](https://github.com/syntheticmagus/showroom-camera),
[demo](https://syntheticmagus.github.io/showroom-camera/),
[NPM listing](https://www.npmjs.com/package/@syntheticmagus/showroom-camera),
[PrivJs listing](https://app.privjs.com/buy/packageDetail?pkg=@syntheticmagus/showroom-camera).

## High Level Overview

Once upon a time, I was looking at the usage of 3D in e-commerce websites
when I began to notice a pattern: while the 3D models being rendered were
often diverse and exciting, the camera movements in these experiences 
tended to be very, very simplistic. Wondering about this, I speculated 
that the reason for the simplicity (with each experience usually either 
having only arc-rotate or still camera behavior) is because writing 
camera control code is something of a niche specialization, and not 
every 3D e-commerce site has the resources to invest in it. This got me 
wondering whether there was some common basis of behaviors that could be 
encapsulated in a Babylon Utility that many e-commerce sites could use 
to make their 3D cameras more exciting. After deciding that there was 
such a subset, I finally reached the biggest question: **how would I 
develop a Babylon Utility so that it could be distributed, and perhaps 
even sold, for use by other people in their own projects?**

![How do I distribute Babylon Utilities?](/img/devStories/showroomCamera/showroom_camera_question.png)

Commercial 3D engines tend to provide commercial solutions to this problem;
the Unity Asset Store, for example, is Unity's solution. As a fully free 
and open-source engine, Babylon.js doesn't have that kind of infrastructure.
However, I soon found that, by leveraging other existing open-source 
infrastructure (particularly built around NPM), I could achieve exactly the
same goal whereby I could give, and even sell, the ability for other 
developers to quickly and easily add my Babylon Utility into their own
projects.

1.  First, I created my new repository, leveraging the 
    [Template Repository Workflow](/toolsAndResources/templateRepositories#the-template-repository-workflow)
    to make it easy to redistribute later.
1.	I next implemented the new utility camera itself.
1.  To *give* away the ability for others to use my new Babylon Utility, I 
    uploaded it as an NPM package to the main public NPM registry.
1.	To *sell* the ability for others to use my new Babylon Utility, I 
    uploaded it as an NPM package to [PrivJs](https://privjs.com/), a 
    commercial NPM registry that makes it easy to buy and sell access to
    NPM packages hosted there.

![With NPM and PrivJs!](/img/devStories/showroomCamera/showroom_camera_answer.png)

And that's how I created the Showroom Camera, a Babylon Utility that
adds a specialized camera to serve needs specific to e-commerce scenarios, 
and made it available for other developers to use from free and/or 
commercial NPM registries. The actual usage of such a Utility is as simple 
as taking an NPM dependency; the Vaporwear company illustrates that in
[another Dev Story](./vaporwearConfigurator).
*This* Dev Story is about *creating* the Showroom Camera Babylon Utility,
so on that topic let's circle back to the beginning and proceed with...

## A More Step-by-Step Journey Through the Process

### Creating the Repository

Setting up a repository to develop a Babylon Utility was very similar to 
the process described in the 
[*Fruit Fallin'* Dev Story](./fruitFalling#moving-playground-code-into-a-development-repo),
but with a few key differences worth elaborating on.

1.  To start, I created and cloned down a new NPM package template repo 
    following the first six steps from the 
    [first section of the *Fruit Fallin* Dev Story](./fruitFalling#moving-playground-code-into-a-development-repo).

    ![New repo](/img/devStories/showroomCamera/01_new_repo.png)

    After that point, I deviated from that Dev Story since I wasn't 
    porting over code that was originally in the Playground.
1.  As is typically the case when bootstrapping an NPM Package Template
    repository, my first priority was to get rid of the playground.ts
    and establish the intended "shape" for the `app_package`. However,
    since this time I was creating a Babylon Utility instead of a 
    standalone experience, instead of creating an entry point I created
    a class that would contain a demo/test scene.

    ![Showroom Camera Demo](/img/devStories/showroomCamera/02_showroom_camera_demo_file.png)
1.  Into this scene, I moved all the code and infrastructure from 
    playground.ts and playgroundRunner.ts (doing some light refactoring as I 
    went), again with the goal of being able to delete those files since 
    they were not a part of my Babylon Utility.

    ![Move Playground-like functionaility to demo scene](/img/devStories/showroomCamera/03_demo_code_port.png)
1.  To finish this process, I changed the exports in index.ts...

    ![index.ts changes](/img/devStories/showroomCamera/04_index_ts_and_deletions.png)
1.  ...and modified the `test_package` to invoke my demo scene instead of 
    the deleted playgroundRunner.ts entry point.

    ![test_package changes](/img/devStories/showroomCamera/05_test_package_changes.png)
1.  Finally, I ran the test app (`npm run dev`) and checked to make sure
    my refactoring hadn't changed any behavior.

    ![Make sure everything looks good](/img/devStories/showroomCamera/06_all_looks_same.png)

Again, this setup was simply to get my repo ready to develop a Babylon 
Utility rather than a standalone experience or a Playground port. With 
the infrastructure now clean and established, I was ready to add 
showroomCamera.ts and begin implementing the class I intended to export
as a utility: the `ShowroomCamera` itself.

### Implementing the `ShowroomCamera`

Dev Stories are not coding tutorials, and a detailed overview of the 
`ShowroomCamera`'s implementation is out of scope for this narrative.
Details of the functionality are described in the 
[Showroom Camera's README](https://github.com/syntheticmagus/showroom-camera/blob/main/app_package/README.md), 
and specifics of the implementation are perhaps best described in
[the code itself](https://github.com/syntheticmagus/showroom-camera).
(Of course, any and all questions are always welcome on 
[the forum](https://forum.babylonjs.com/questions)!)
This section, then, will be limited to just a few high-level glimpses of 
some of the more significant pieces of the implementation.

1.	The `ShowroomCamera` has two behaviors: it can act like an 
    `ArcRotateCamera`, or it can act like a "matchmoving" on-rails 
    camera that follows a predetermined path (for example, orbiting a 3D 
    model to show it off from all sides). Because the goal in the 
    "arc-rotate" state is to act like an `ArcRotateCamera` (which is a 
    favorite camera of the Babylon.js Community), I decided the best 
    thing to do in that mode would be to just have the 
    `ShowroomCamera` *be* an `ArcRotateCamera`. More precisely, the 
    `ShowroomCamera` *contains* an `ArcRotateCamera`. That way, when the 
    `ShowroomCamera` enters an "arc-rotate" state, all it has to do is 
    correctly position the `ArcRotateCamera`, then enable it.
1.  "Matchmoving," the second behavior of the `ShowroomCamera`, is 
    achieved by simply using a second camera which follows a 
    user-provided `TransformNode`. Three aspects of this are noteworthy. 
    1.  The matchmoving is done using a second camera (as opposed to 
        just moving the `ArcRotateCamera`) so that the `ArcRotateCamera` 
        can remain free to position itself. `ArcRotateCamera`s come 
        pre-packaged with a *lot* of very custom behaviors, so rather 
        than try to predict what those behaviors will do in a given 
        circumstance (and risk taking a hard dependency on 
        implementation details of Babylon.js), we simply use an 
        `ArcRotateCamera` when we want that behavior and a separate 
        camera when we don't.
    1.  The choice to have the second camera follow a `TransformNode`
        was made in the interest of flexibility. The `ShowroomCamera` 
        doesn't care how the `TransformNode` is moved; all it does is use
        that `TransformNode` as a definition of the path it's supposed to
        be matchmoving, then follow along. This allows the user to move
        the `TransformNode` any way they want to: the 
        [demo](https://syntheticmagus.github.io/showroom-camera/)
        features procedural animations made with coroutines while
        [another Dev Story](./vaporwearConfigurator)
        makes heavy use of the ability to control `ShowroomCamera` 
        matchmoving using animations crafted by a 3D artist.
    1.  Note that the second camera *follows* the provided 
        `TransformNode`; it actually copies its position and orientation 
        from the `TransformNode` frame-by-frame instead of, for example, 
        setting that `TransformNode` to be its parent. This was partly 
        done to avoid muddling the hierarchy -- the `ShowroomCamera` may 
        be matchmoving many different `TransformNodes` at various times 
        in the same scene -- but it was also done to resolve difficulties 
        with handedness. For example, when using a `TransformNode` 
        actuated by an animation and imported from a glTF made with 
        Blender, the `TransformNode` the camera should be following may 
        be in a different handedness from the scene around it, which can 
        cause strange behaviors for cameras that are a part of that 
        direct hierarchy. To avoid this, the `ShowroomCamera` simply 
        follows the absolute position and orientation of the 
        `TransformNode` in world space.
1.  The final key feature of the `ShowroomCamera` is the ability to 
    seamlessly transition between "arc-rotate" and "matchmoving" behavior
    using procedural animations. These procedural animations use 
    coroutines to spread interpolation over many frames as they 
    gradually move the camera from one state to the next. This is, by 
    far, the most complex part of the `ShowroomCamera` code and was the 
    primary motivation for turning it into a Babylon Utility.
1.  The `ShowroomCameraDemo.Run(...)` function added in the prior section
    serves two roles. During development, this function is essentially
    used as a test harness where uses can be added and changed to test 
    out the new functionality and APIs. After development, this function 
    lives on as a demo illustrating what the `ShowroomCamera` can do and 
    how to use it. For larger projects with more sophisticated testing/
    demo needs, a formal test battery could serve the same purposes.

### Uploading to Share on npmjs.com

After I'd gotten the features and APIs I wanted in the `ShowroomCamera`, 
publishing it to be shared through NPM was as easy as it was in 
[the first Dev Story that showed this](./fruitFalling#deploying-as-an-npm-package).
However, there are a few noteworthy differences between the
Showroom Camera and *Fruit Fallin'* arising from the fact that the 
latter, as a Babylon Utility, is intended for consumption by other 
developers, not just my own shipping vehicles.

1.	I added a README.

    ![Add a README](/img/devStories/showroomCamera/07_readme.png)

    Note that this isn't the README in the root directory of NPM Package
    Template repository; that README won't be published because only the
    `app_package` folder gets published. Thus, the important README for
    NPM publication is in `app_package`, not the root.
1.  I updated the package.json file (again, the one in `app_package`), 
    making sure to set `name`, `description`, `repository`, and 
    `publishConfig`. I also modified the syntax of the dependency on 
    `@babylonjs/core` to make it easier for projects depending on
    `ShowroomCamera`, which will presumably already have their own
    dependencies on `@babylonjs/core`, to resolve versions.

    ![Update package.json](/img/devStories/showroomCamera/08_package_json.png)
1.  
    ```
    npm publish
    ```

    ![Publish to NPM](/img/devStories/showroomCamera/09_npm_published.png!420)

### Uploading to Sell on PrivJs.com

Babylon Utilities bear a lot of inherent similarities to the kinds of 
products bought and sold in places like the Unity Asset Store. Selling
access isn't really what the default NPM registry is for; however, there
are
[several](https://privjs.com)
[alternatives](https://basetools.io/)
on the market that allow developers to buy and sell access to NPM packages.
I personally decided to try [PrivJs](https://privjs.com/), and I was 
pleasantly surprised to find the process very easy.

1.	After signing up for a PrivJs account, I took a look at the 
    instructions they provided for publishing an NPM package on their
    registry.

    ![PrivJs instructions](/img/devStories/showroomCamera/10_privjs_instructions.png)

    Seems simple enough.
1.  I did the same things to publish on PrivJs that I did 
    [to publish on npmjs.com](#uploading-to-share-on-npmjs.com), 
    with the exception that I changed the `publishConfig` a bit.

    ![Update package.json for PrivJs](/img/devStories/showroomCamera/11_package_json_privjs.png)

    As a side-note, I also had to update my version because I had already
    published on npmjs.com and PrivJs, which is aware of npmjs.com, 
    won't accept packages with conflicting versions.
1.  ```
    npm login --registry https://r.privjs.com
    ```

    ![PrivJs login](/img/devStories/showroomCamera/12_privjs_login.png)
1.  ```
    npm publish
    ```
1.  Once your package is published on PrivJs, you can log in to 
    configure your options as a seller. Personally, I'm pretty bad at 
    setting prices, so it's unclear whether I'm ever going to make a 
    profit on this.

    ![PrivJs listing](/img/devStories/showroomCamera/13_privjs_listing.png)

Boom! Soup.

Bear in mind that NPM package marketplaces like PrivJs are much newer 
than the FOSS registries like npmjs.com, so the infrastructure for 
commercially distributing Babylon Utilities won't be quite as mature as 
the infrastructure for free distribution. However, the options are 
there, and they're *very* easy to take advantage of; so whether you want 
to sell your Babylon Utilities or give them away for free, hopefully the 
process is as straightforward for you as it was for me!

And as for *consuming* these Babylon Utilities, that should also be just 
as simple as consuming any other NPM package from the registry in
question. In fact, I know some people who have already done this -- some 
imaginary people working for an imaginary company -- but that is a topic 
for
[another Dev Story](./vaporwearConfigurator).

-syntheticmagus



Related links:
[Vaporwear website demo](https://syntheticmagus.github.io/vaporwear-react-site-deployment/),
[Chapter 1: Art](./vaporwearConfigurator/art),
[Chapter 2: 3D](./vaporwearConfigurator/3d),
[Chapter 3: Frontend](./vaporwearConfigurator/frontend),
[Bonus Chapter: WordPress](./vaporwearConfigurator/wordpress)

## High Level Overview

After 
[adding simple 3D to their existing e-commerce site](./vaporwearViewer)
and seeing first-hand the resulting 
[big boost to the customer experience](https://www.zdnet.com/article/2021-is-the-year-that-3d-and-augmented-reality-for-commerce-cashes-in/), 
Allan and Barnabas -- owner and webmaster, respectively, for the Vaporwear
smartwatch company -- were excited. The company was growing, they were
looking for ways to improve and differentiate their e-commerce business,
and they knew they'd barely scratched the surface of what they could do
with 3D on the Web. Fishing for inspiration on the 
[Babylon.js forum](https://forum.babylonjs.com/c/demos),
Allan found a
[Babylon Utility](./showroomCamera) 
allowing the seamless integration of several different camera behaviors
for a "showroom" experience. Allan and Barnabas had already been discussing
a major update to their website to coincide with the launch of Vaporwear's
newest imaginary smart watch; and with all these new opportunities in 
mind, they began to ask each other, "**What might an e-commerce site
built with 3D as part of the core design look like, and how would we 
create it?**"

![Vaporwear 3D + What = E-Commerce magic?](/img/devStories/vaporwearConfigurator/question.png)

This, of course, was not a small aim, and they didn't go in with the 
expectation they'd be able to do this in the roughly one hour it had taken
the to add the Babylon Viewer their existing site. This new Vaporwear
website would be built from the ground up to be exactly what they wanted
for their business: custom 3D assets in a custom 3D experience in a
custom, modern Web frontend. Creating such a website would require 
expertise Vaporwear didn't have on permanent staff, so they decided to 
contract three freelancers to form a team to create this new website.

-   Carlos, the artist, who would create the 3D visuals.
-   Diane, the Babylon developer, who would build Carlos's visuals into a
    3D experience.
-   Edie, the frontend developer, who would take take Diane's 3D experience
    and build the final Vaporwear website around it.

![Vaporwear 3D + Blender + Babylon + React.js = E-Commerce magic!](/img/devStories/vaporwearConfigurator/answer.png)

When assembling this team, Allan and Barnabas knew that hiring the right
people was **the single most important thing they could do to ensure the
success of their project**, so they didn't try to cut corners: much better
to spend the money to do it right than to spend the money to do it again.
Furthermore, while the three team members wouldn't all need to be 
focused on the Vaporwear site simultaneously, Allan and Barnabas didn't 
make the mistake of trying to hire them piecemeal. The most important
follow-up to getting the right people was getting those people to talk 
to each other so that expectations could be aligned, handoffs agreed upon,
and -- when something inevitably required further discussion during
development -- easy and familiar communications established.

So, to kick off the project, Allan got the whole team together in a single
meeting where he and Barnabas laid out their vision for the new Vaporwear 
site.

-   The site would be structured as a single page incorporating both 
    viewing and configuration.
-   When the site loaded, the first thing the users would see would be 
    an overall view of the watch, with the logo fading in on top of it.
-   As the users scrolled through the site and were shown information
    about the watch, the 3D watch would transition to different states
    to show off the various important features: the clasp, the face,
    and the overall design.
-   When the users scrolled to the bottom of the page, buttons would
    appear and the watch rendering would seamlessly become an interactive
    configuration experience where users could change the band, face, etc.
-   If users scrolled back up through the page after configuring, the
    configuration options would remain.
-   ...and all of this should be done with no load screens.

The experts on the team pitched in with their thoughts, offering 
suggestions and discussing challenges, and pretty soon they resolved on
a design for the website: in short, they resolved on 
[this](https://syntheticmagus.github.io/vaporwear-react-site-deployment/).

With the design in place, the high-level path forward was clear. Throughout
the development process, all five of them would remain reachable (email, 
etc.) to each other to answer questions and resolve confusion, but not 
all of them would be actively working on the Vaporwear site the whole
time. The majority of Edie's work would happen once she'd received the
3D experience from Diane, and the bulk of Diane's work depended on the
3D models from Carlos. Thus, with the team assembled and the plan decided
the first chunk of real work on the new Vaporwear website was 
[the art](./vaporwearConfigurator/art).



Related links:
Original Vaporwear site ([source](https://github.com/syntheticmagus/vaporwear-original-asset-host/tree/main/wp_sites_sources/vaporwear),
[demo](https://syntheticmagus.github.io/vaporwear-original-asset-host/vaporwear_wp_original.mp4)),
Vaporwear site with 3D ([source](https://github.com/syntheticmagus/vaporwear-original-asset-host/tree/main/wp_sites_sources/vaporwear_viewer),
[demo](https://syntheticmagus.github.io/vaporwear-original-asset-host/vaporwear_wp_with_viewer.mp4)),
[asset host](https://github.com/syntheticmagus/vaporwear-original-asset-host/).

Note about demos: For most Dev Stories, we try to make the actual usable
product from the Dev Story available for readers to explore directly.
However, the websites in this Dev Story were built using WordPress, which
is complicated (and sometimes costly) to host, so unfortunately we weren't
able to keep these sites live indefinitely. Instead, the `demo` links
above will direct you to videos showing the sites in action, while the
`source` links go to zipped files containing the raw files of the
WordPress sites.

## High Level Overview

Once upon a time, a guy named Allan owned a company called Vaporwear, which
manufactured and sold imaginary smart watches. In order to achieve scale,
the Vaporwear company sold most of its products through a traditional
e-commerce website built using common tools -- in this case, WordPress.
However, Allan had recently heard what
[fantastic effects adding 3D to an e-commerce website can have on customers](https://www.zdnet.com/article/2021-is-the-year-that-3d-and-augmented-reality-for-commerce-cashes-in/);
and since his manufacturing partners had provided him with a simple 3D
model of the latest Vaporwear smart watch, Allan asked himself, "**How can
I quickly and easily add 3D to my existing e-commerce site?**"

![How can they add 3D to the Vaporwear site?](/img/devStories/vaporwearViewer/vaporwear_viewer_question.png)

So Allan did some research and found that Babylon.js specifically
caters to e-commerce scenarios by
[including Khronos 3D Commerce conformant rendering as a core offering](/setup/support/3D_commerce_certif).
(This certification ensures that 3D rendering will be consistent so that
models always look the way site owners and customers expect them to.)
Furthermore, Babylon.js provides a
[Viewer](/features/featuresDeepDive/babylonViewer)
that makes it easy to add 3D to an existing site using only HTML-style
code. So Allan consulted with his Web developer Barnabas, and the two of
them figured out how they would add 3D to the Vaporwear e-commerce
website -- in right around an hour.

1. First, they'd spend about ten minutes adding the default viewer into
    their WordPress site.
1. Next, they spent at most half an hour getting their 3D model hosted
    online using an
    [asset host](https://github.com/BabylonJS/asset-host-template)
    from Babylon's
    [Template Repository Workflow](/toolsAndResources/templateRepositories#the-template-repository-workflow).
1. Finally, they reconfigured the default viewer to display their Vaporwear
    3D model, disabling the features they didn't need and ensuring the
    viewer was using Khronos 3D Commerce-conformant rendering. With a
    little help from the Community on the
    [Babylon.js forum](https://forum.babylonjs.com/questions),
    they spent about twenty minutes getting this configured the way they
    wanted.

![With the Babylon Viewer!](/img/devStories/vaporwearViewer/vaporwear_viewer_answer.png)

And that is how Allan and Barnabas added 3D to the existing Vaporwear
e-commerce site in right around an hour. While their site used WordPress,
the same basic procedure could be used to add 3D to sites built on a wide
variety of platforms; all that's needed is the ability to add a script and
a little HTML-style code.

## A More Step-by-Step Journey Through the Process

### Adding the Babylon Viewer to the Existing Site

Though Barnabas was quite experienced with WordPress, he'd never added 3D
to an existing site before, so the first thing he wanted to do was make
sure he coul get at least *something* rendering on the site in 3D. After
finding the
[Viewer Examples](/features/featuresDeepDive/babylonViewer/viewerExamples#basic-usage)
in the Babylon.js docs, Barnabas decided to just grab the code from there
and add it directly to his WordPress site.

1. First, he picked where on his WordPress site page the 3D content
    should go.

    ![Here's a good spot](/img/devStories/vaporwearViewer/01_deciding_where.png)
1. He then added a new section...

    ![Elementor new section button](/img/devStories/vaporwearViewer/03_new_section.png)
1. ...made it full-width...

    ![WordPress section "structure"](/img/devStories/vaporwearViewer/04_structure.png!500)
1. ...and added an HTML block to the new section.

    ![HTML block](/img/devStories/vaporwearViewer/05_html_block.png)
1. Next, in preparation for adding his own HTML, Barnabas added a new
    `div` to help keep things clearly grouped.

    ![Where to put the Viewer](/img/devStories/vaporwearViewer/06_div.png)
1. Within this `div`, he added the `script` tag he'd found
    [in the Babylon Viewer docs](/features/featuresDeepDive/babylonViewer#display-3d-models-on-your-webpage)
    to import the Viewer so he could use it on his page.

    ![Viewer script tag](/img/devStories/vaporwearViewer/07_script.png)
1. Immediately after this, he copy-pasted in the `babylon` tag code
    from the
    ["basic usage" Viewer example](https://github.com/BabylonJS/Babylon.js/tree/master/packages/tools/viewer/public/basicExample.html#L18-L31).

    ![The example code to be copied](/img/devStories/vaporwearViewer/08_copy-paste.png)
1. With that code pasted into his HTML block, all he had to do was tell
    WordPress to update the page...

    ![Update the page](/img/devStories/vaporwearViewer/09_update.png)
1. ...and then view the page outside of editing mode to see the results.

    ![A 3D model rendering](/img/devStories/vaporwearViewer/10_first_render.png)

And, just like that, there was a 3D model rendering on the Vaporwear home
page! Now to make it the *right* 3D model...

### Creating an Asset Host Repo

WordPress provides some out-of-the-box support for media files, but it
tends to be bespoke and focuses heavily on images and video. Barnabas
briefly considered trying to finesse the situation, but ultimately he
decided it would be simpler to let WordPress focus on traditional media
and use one of Babylon's recommended "asset host" repositories to serve
his 3D model.

1. To create the asset host itself, he followed the first two steps
    from the
    ["Creating an Asset Host Repo" section of a Dev Story he found in the Babylon.js docs](./fruitFalling#creating-an-asset-host-repo).

    ![Where to put the Viewer](/img/devStories/vaporwearViewer/11_create_asset_host.png)
1. Once the asset host was created, he placed a copy of his 3D model
    into the `docs` folder.

    ![Where to put the Viewer](/img/devStories/vaporwearViewer/12_docs_folder.png)
1. To double-check that his asset host was serving the model properly
    (and to see the model rendering in Babylon.js), he decided to render
    the model from his asset host server in the
    [3D Commerce-conformant version of the Babylon.js Sandbox](https://3dcommerce.babylonjs.com/).
    He'd seen in
    [a Dev Story](#creating-an-asset-host-repo)
    that the Babylon.js Sandbox has an `assetUrl` parameter that can be
    provided to cause it to automatically load an asset, so he tried that
    with his model from his local asset host.

    ```text
    https://3dcommerce.babylonjs.com/?assetUrl=http://127.0.0.1:8181/watch_original.glb
    ```

    ![Model in 3D Commerce Sandbox](/img/devStories/vaporwearViewer/13_sandbox_from_local.png)
1. With that working, he needed to publish the asset host so that he'd
    be able to access the model from anywhere, so he pushed it up to
    GitHub Pages by following steps 1, 2, and 3 of the
    ["Publishing" section of the *Fruit Fallin'* Dev Story](./fruitFalling#publishing-the-test-app-on-github-pages).

    ![Publishing the asset host](/img/devStories/vaporwearViewer/14_github_pages_start.png)

    ![Read down to here](/img/devStories/vaporwearViewer/15_github_pages_stop.png)
1. Once GitHub Pages confirmed that his asset host was live, he grabbed
    the link to the live site...

    ![Where to put the Viewer](/img/devStories/vaporwearViewer/16_github_pages_link.png)
1. ...and used it (with his model's name appended) to create a new
    Sandbox link to load his model from his own asset host.

    ```text
    https://3dcommerce.babylonjs.com/?assetUrl=https://syntheticmagus.github.io/vaporwear-original-asset-host/watch_original.glb
    ```

    ![Where to put the Viewer](/img/devStories/vaporwearViewer/17_sandbox_from_web.png)

Finally, with his model hosted and accessible from the Web, it was time
to render it on the Vaporwear WordPress site.

### Configuring the Babylon Viewer

1. Strictly speaking, just getting the model to render in the Vaporwear
    site's Babylon Viewer was as simple as changing the URL provided
    for the model.

    ![New model URL](/img/devStories/vaporwearViewer/18_new_model_url.png)
1. However, Barnabas knew the Babylon Viewer is
    [highly configurable](/features/featuresDeepDive/babylonViewer/configuringViewer),
    so he decided to tweak a few things about its appearance to make it
    look just right for Vaporwear. First, he removed the leftover code
    from the sample adding VR support. (He also cleaned up a lot of
    copied-over comments he didn't need anymore.) Since thee Vaporwear
    site was targeting a very clean presentation bordering on minimalism,
    he decided to also remove the logo and fullscreen UI from the nav bar.

    ![Remove VR support and comments](/img/devStories/vaporwearViewer/19_delete_vr_and_comments.png)
1. Lastly, he wanted to make sure the model was rendered using the
    Khronos 3D Commerce certified settings so that he could be sure it
    would look exactly the same as he'd seen it in the Sandbox earlier.
    The Babylon Viewer supports this using a `3d-commerce-certified` flag,
    available from Babylon 5.0 onward. However, since Barnabas was doing
    this during the leadup to the 5.0 release, he needed to switch to
    using the Viewer script from the "preview" CDN in order to get the
    latest hot-off-the-presses featuers.

    ![Configure nav bar](/img/devStories/vaporwearViewer/20_change_params.png)
1. He then updated the page in WordPress, switched to viewing instead of
    editing, and...

    ![The Vaporwear 3D model live on the Vaporwear site](/img/devStories/vaporwearViewer/21_result.png)

The addition of 3D product rendering added a whole new distinguishing
feature to the Vaporwear e-commerce site, breathing new life into the
design they already had. However, with the growing success of the
Vaporwear business, Allan and Barnabas had already been discussing
upgrading the site to a new and more modern technology stack; and after
seeing the Babylon Viewer on the original Vaporwear site, they started
to wonder what it would look like to have an e-commerce site that
leveraged 3D as a flagship feature built into the site's design. Allan
spent a little time browsing the
[Babylon forum](https://forum.babylonjs.com/c/demos)
looking for ideas, where he found a community-made
[Babylon Utility](./showroomCamera)
that excited him so much that he decided to make it the backbone of
the most slick and sophisticated viewer/configurator experience he and
Barnabas could come up with.

But that is a topic for [another Dev Story](./vaporwearConfigurator).

-syntheticmagus



## Dev Stories

Welcome to the Dev Stories! These are project-focused narrative retellings of how 
Babylon.js Team and Community members created various experiences. These stories
are specifically intended to "pave the golden path," quickly taking readers
through techniques and best practices that they can then reuse in their own
projects. In short, these stories are intended to serve as examples for readers
with a task in mind. We can't tell you _the_ way to do it, but if you want to 
know how _we'd_ do it, then you've come to the right place.



# Journey Beyond the Docs

Sometimes all a person needs is to know the syntax for a particular component, a no-nonsense explanation of a specific topic. Other times, more context is needed to understand a concept. After all, an isolated code snippet does not an application make (unless it's running in the [Playground](https://playground.babylonjs.com) of course). For those who want or need more context, [there's a book for that](https://packt.link/Josh)!

_Going the Distance with Babylon.js_ is a book that bridges the gap between the practical, focused information in the BJS documentation and real-world application development incorporating those concepts.

By the by - it's possible that you or your employer's subscription service has to the title for free as part of your subscription.

![book](/img/how_to/book/book.png)

## Officially Endorsed by the Babylon.js Team

With a forward by David Catuhe (not to mention cover art!) and extensive consultation with the Babylon.js team on both the book's technical content as well as the overall content structure, _Going the Distance_ doesn't just regurgitate material available in the reference docs.

The book teaches you how to build [_Space-Truckers: The Video Game_](https://space-truckers.com) from start-to-finish. In the process, you'll learn about contributing to Open-Source projects, 3D graphics concepts, simple game AI, and more! Early in the book, there is a lot of attention paid to helping familiarize readers with Bablyon.js and specific coding approaches.

As readers progress though, the pace quickens and the amount of detail changes from explaining sections of code to explaining larger components and concepts. At every step of the way however, there are numerous Playground snippets, links to external resources, and specific pointers to GitHub source code branches, ensuring that there's always a contextual, working sample of code for comparison.

## Creativity Unbound

Release any preconceptions you might be carrying about yourself like "I'm not good at math so I can't possibly understand 3D programming!", or "I don't know anything about graphics, this is impossible for me to learn!". None of that thinking will have any traction after you read  this book because you'll know first-hand how easy it can be to make what was previously a dream into reality.

The ecosystem of tools that Babylon.js provides remove much of the underlying maths messiness, allowing you to put focus where it matters - on the content. Over the course of _Going the Distance_'s fourteen chapters, you'll be exposed to and learn how to best take advantage of the rich tooling, diverse resources, and incredibly well-documented that are parts of Babylon.js.

Don't worry about getting overwhelmed though! Each chapter focuses on a  group of related features and functionality that are used to construct the next part of _Space-Truckers: The Video Game_. As you progress through the book you'll also be building up the application starting from first principles and ending with a full application that can be published to an app store.

What are you waiting for? [GO GET YOUR COPY!!!](https://www.amazon.com/Going-Distance-Babylon-js-maintainable-browser-based/dp/1801076588/ref=sr_1_1?keywords=going+the+distance+with+babylon+js&qid=1664490295&sprefix=going+the+dist%2Caps%2C141&sr=8-1)


Dev Stories

Dev Stories

Coming next

Playground to Production - Fruit Fallin'

A Dev Story about how to transform Playground demos into production software.

3D for E-Commerce - Viewer in WordPress

A Dev Story about adding 3D to an existing e-commerce website, the fast way.

Babylon Utilities - Showroom Camera

A Dev Story about creating a Babylon Utility to share and sell for others to use in their own projects.

3D for E-Commerce - Custom Experience

A Dev Story about creating an e-commerce website with a 3D viewer/configurator built into the design.