
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](/setup/templates/repos/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](/guidedLearning/devStories/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 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).



<Alert severity="warning" title="Warning">
  This story references the [legacy Babylon Viewer V1](/legacy/babylonViewer). When building new experiences, please use the [Babylon Viewer V2](/features/featuresDeepDive/babylonViewer).
</Alert>

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](/legacy/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](/setup/templates/repos/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](/legacy/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](/legacy/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](/legacy/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](/guidedLearning/devStories/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
