Giter VIP home page Giter VIP logo

Comments (5)

thw0rted avatar thw0rted commented on May 30, 2024 2

Dumb question: if I have Build/ThirdParty, and Build/Workers, why do I also need the ones from Source? Mine seems to be working with just

new CopyPlugin([{
    from: path.join(cesiumSource, "Assets"),
    to: cesiumTarget + "/Assets",
}, {
    from: path.join(cesiumBuild, "ThirdParty"),
    to: cesiumTarget + "/ThirdParty",
}, {
    from: path.join(cesiumSource, "Widgets"),
    to: cesiumTarget + "/Widgets",
}, {
    from: path.join(cesiumBuild, "Workers"),
    to: cesiumTarget + "/Workers",
}]),

from cesium-webpack-example.

nmschulte avatar nmschulte commented on May 30, 2024 1

UPDATED: This is a better solution which should scale without issue (it uses the force option of CopyWebpackPlugin to force overwriting destination files; in this case, overwrite "non-built" code w/ "built" code). This still has a potential issue in that it leaves (in the bundle) "un-built" source files that have no "built" equivalent (e.g. ./Source/Workers/createTaskProcessorWorker.js):

    new CopyWebpackPlugin([
        {from: path.join(paths.cesiumSource, 'Assets'), to: 'Assets'},
        {from: path.join(paths.cesiumSource, 'ThirdParty'), to: 'ThirdParty'},
        {from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets'},
        {from: path.join(paths.cesiumSource, 'Workers'), to: 'Workers'},
        {from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers', force: true},
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers', force: true}
    ])

ORIGINAL:

Some notes about the pattern ("copy source tree and overwrite with built-source tree") used in the solution:

There may be (future) problems with this solutions. For one, there may be files in the unbuilt/source directory (./Source/ThirdParty/Workers) that are not in the built directory (./Build/Cesium/ThirdParty/Workers) which don't belong in the bundle but are included anyway. This doesn't present an issue currently.

However, I tried to do this same "copy source and overwrite with built-source" routine for the Cesium Workers (./Source/Workers and ./Build/Cesium/Workers) which results in run-time issues:

    new CopyWebpackPlugin([
        {from: path.join(paths.cesiumSource, 'Assets'), to: 'Assets'},
        {from: path.join(paths.cesiumSource, 'ThirdParty'), to: 'ThirdParty'},
        {from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets'},
        {from: path.join(paths.cesiumSource, 'Workers'), to: 'Workers'}
    ]), 
    new CopyWebpackPlugin([
        {from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers'},
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers'}
    ])
Uncaught Error: importScripts failed for Workers/createVerticesFromHeightmap at http://localhost:3000/Workers/createVerticesFromHeightmap.js
http://requirejs.org/docs/errors.html#importscripts
    at makeError (cesiumWorkerBootstrapper.js:188)
    at Function.req.load (cesiumWorkerBootstrapper.js:1967)
    at Object.load (cesiumWorkerBootstrapper.js:1690)
    at Module.load (cesiumWorkerBootstrapper.js:852)
    at Module.fetch (cesiumWorkerBootstrapper.js:842)
    at Module.check (cesiumWorkerBootstrapper.js:874)
    at Module.enable (cesiumWorkerBootstrapper.js:1188)
    at Object.enable (cesiumWorkerBootstrapper.js:1561)
    at Module.<anonymous> (cesiumWorkerBootstrapper.js:1173)
    at cesiumWorkerBootstrapper.js:153

from cesium-webpack-example.

nmschulte avatar nmschulte commented on May 30, 2024 1

TL;DR -- After digging, it seems like we only need the ThirdParty/Workers content (inflate.js and deflate.js), which is unchanged between Source and Build/CesiumUnminified (Build/Cesium is a minified/UglifyJS2'd version). If you want full control over this source via Webpack, you should use the original copies from Source.

It's not clear to me what's going on with the Source/ThirdParty/Shaders/FXAA3_11.glsl file, though. It's imported from Source/Scene/FXAA.js, but the Build/CesiumUnminified code seems to lack any reference to this at all. It seems like we'll need to copy/account for this file (or the whole ThirdParty/Shaders directory) via Webpack. See my later comment for details.


This should get you everything you need (and [mostly] no more) to use Cesium as a library from Webpack. It uses the Almond-bundled-and-minified Web Worker scripts from the Cesium release, as well as the minified ThirdParty/Worker scripts (currently only inflate.js and deflate.js). It also copies the single OpenGL shader file noted above (from the ThirdParty/Shaders directory). Update: note, this shader file need not be copied.

    new CopyWebpackPlugin([
        // copy Cesium's non-JS asets
        {from: path.join(paths.cesiumSource, 'Assets'), to: 'Assets'},
        // copy Cesium's non-JS widget-bits (CSS, SVG, etc.); NOTE: this copies unnecessary JS files!
        {from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets'},
        {from: path.join(paths.cesiumSource, 'ThirdParty/Shaders'), to: 'ThirdParty/Shaders'},

        // copy Cesium's Almond-bundled-and-minified Web Worker scripts (from the "built+minified" release)
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers'},
        // copy Cesium's minified third-party scripts (from the "built+minified" release)
        {from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers'},
    ])

I think the "non-JS widget-bits" could be sourced from the "built" release directory, or have an additional ignore option, which would avoid copying JS files. I haven't tested this yet, but I believe it's accurate, as Webpack should be fully-managing the JS for "widget-bits."

        // copy Cesium's non-JS widget-bits (from the "built+minified" release, to avoid the JS widget-bits)
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Widgets'), to: 'Widgets'},

OR

        // copy Cesium's non-JS widget-bits
        {from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets', ignore: ['*.js']},

I have similar questions. First, we must realize that we're talking about the "raw" Cesium library here, not the Sandcastle or CesiumViewer or anything else. The build script(s) accommodates all of these things, and the concerns are not perfectly clearly separated there-in. The ThirdParty directory in particular holds code that is mainly used for non-library things.

As I understand, the particular piece we need from the "built" cesium is the Cesium Web Worker scripts (that leverage OpenGL/GPU shaders to accelerate computation) because Web Workers have their own "entry-point." The tutorial assumes you'll be happy using the scripts with the Almond AMD loader, and doesn't consider building them with Webpack run-time. It probably wouldn't be hard to make Webpack provide the module-loading run-time for these Web Worker entry-points too, if someone is interested; at that point, we can entirely ignore the Build directory and work with "raw" Cesium source (Source), but there are also non-library files in that ThirdParty directory (for Sandcastle, CesiumViewer, other non-library things), so making this future-proof is non-trivial.

from cesium-webpack-example.

ggetz avatar ggetz commented on May 30, 2024 1

Dumb question: if I have Build/ThirdParty, and Build/Workers, why do I also need the ones from Source?

It will work with either, but using the pre-built workers will be faster.

It's not clear to me what's going on with the Source/ThirdParty/Shaders/FXAA3_11.glsl file, though. It's imported from Source/Scene/FXAA.js, but the Build/CesiumUnminified code seems to lack any reference to this at all. It seems like we'll need to copy/account for this file (or the whole ThirdParty/Shaders directory) via Webpack.

I'm not sure what's going on here without digging, but the .glsl files are built to .js, and the .js is what's actually imported and used by the library.

I have similar questions. First, we must realize that we're talking about the "raw" Cesium library here, not the Sandcastle or CesiumViewer or anything else. The build script(s) accommodates all of these things, and the concerns are not perfectly clearly separated there-in. The ThirdParty directory in particular holds code that is mainly used for non-library things.

It is possible to copy the entire ThirdParty library if your app requires it, but they are used by the Apps/ directly provided with the Cesium source code (Sandcastle, the CesiumViewer app). The tutorial was targeted towards app development using the Cesium library as opposed to doing Cesium source code development with webpack.

The tutorial assumes you'll be happy using the scripts with the Almond AMD loader, and doesn't consider building them with Webpack run-time. It probably wouldn't be hard to make webpack provide the module-loading run-time for these Web Worker entry-points too, if someone is interested.

We used the pre-built web workers as the source web worker scripts are not compatible with webpack due to their usage of requireJS. (Also modifying the web worker scripts is fairly niche, and the npm package has them already pre-built.) So the workers scripts themselves will require modification if you would like to build them with webpack.

from cesium-webpack-example.

nmschulte avatar nmschulte commented on May 30, 2024 1

I'm not sure what's going on here without digging, but the .glsl files are built to .js, and the .js is what's actually imported and used by the library.

Ahh! I see what's going on now, I was getting confused referencing the Git repository vs the npm registry package. While the repository here on GitHub includes the Cesium releases (Build/), it doesn't include the in-place transformed GLSL -> JS, and the Build/ directory seems to be for an older release which did not include FXAA3_11 code (hence no reference in the Build/CesiumUnminified directory). The package in the npm registry has all of the necessary bits.

There's no need to worry about the FXAA3_11 GLSL specially, Webpack will properly pick up the .js file and include it in the bundle (assuming it's there; so make sure you use the npm registry package, or issue a gulp build if using the Git repository).


This sources all non-JS from the "built+minified" directory, because we're relying on it anyway (to filter Widgets to non-JS contents, and to grab the pre-built Web Workers), so might as well go all-in.

    new CopyWebpackPlugin([
        // copy Cesium's non-JS assets
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Assets'), to: 'Assets'},
        // copy Cesium's non-JS widget-bits (CSS, SVG, etc.)
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Widgets'), to: 'Widgets'},
        // copy Cesium's Almond-bundled-and-minified Web Worker scripts
        {from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers'},
        // copy Cesium's minified third-party scripts
        {from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers'},
    ])

from cesium-webpack-example.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.