AMZN-stankowi 6b5f5bc666 Bundled release build bug fixes cherry picked from development (#5270)
* Fixed some files missed when groundplane_521 was renamed to 512 (#4958)

* Fixed references to 521x521 to reference the correct 512x512 FBX file

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Fixed asset hints

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Moved the Asset Catalog loading from LmbrCentral to the AzFramework::Application (#4568)

* Moved the loading of the AssetCatalog from LmbrCentralSystemComponent to AzFramework Application

Modified the AssetCatalog::InitializeCatalog function to no longer rely on the TickBus to send out the `AssetCatalogEventBus::OnCatalogLoaded` event.
It now queues a function on the AssetCatalogRequestBus to send the OnCatalogLoaded event as soon as the dispatching for the AssetCatalogRequestBus has completed on the current thread.
This is done by updating the AssetCatalogRequestBus to use EBus ThreadDispatchPolicy to add a callback to invoke any queued function has soon a thread has finished dispatching and has released its DispatchMutex

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Updated the AssetCatalogRequestBus to add a custom DispatchLockGuard

The AssetCatalogRequestBus uses the custom lock guard to dispatch queued
events after it has unlocked it's context mutex for the current thread.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removed GetContext call from the
AssetCatalogRequests::PostThreadDispatchInvoker

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Updated the definition of FileTagQueryManager::GetDefaultFileTagFilePath
function to return a path

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Updated the AZ_CONSOLEFREEFUNC macro to actually use the _NAME

The _NAME parameter was not being used before, resulting in the Console
stringified name of the function being used.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removed CrySystem dependencies from the BundlingSystemComponent

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Moved the loading of the AssetCatalog from LmbrCentralSystemComponent to AzFramework Application

Modified the AssetCatalog::InitializeCatalog function to no longer rely on the TickBus to send out the `AssetCatalogEventBus::OnCatalogLoaded` event.
It now queues a function on the AssetCatalogRequestBus to send the OnCatalogLoaded event as soon as the dispatching for the AssetCatalogRequestBus has completed on the current thread.
This is done by updating the AssetCatalogRequestBus to use EBus ThreadDispatchPolicy to add a callback to invoke any queued function has soon a thread has finished dispatching and has released its DispatchMutex

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Updated the AssetCatalogRequestBus to add a custom DispatchLockGuard

The AssetCatalogRequestBus uses the custom lock guard to dispatch queued
events after it has unlocked it's context mutex for the current thread.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removed GetContext call from the
AssetCatalogRequests::PostThreadDispatchInvoker

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Updated the definition of FileTagQueryManager::GetDefaultFileTagFilePath
function to return a path

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Updated the AZ_CONSOLEFREEFUNC macro to actually use the _NAME

The _NAME parameter was not being used before, resulting in the Console
stringified name of the function being used.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removed CrySystem dependencies from the BundlingSystemComponent

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Addded missing template parameter to AssetCatalogRequests

The fixes the compile error.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding AssetBus::MultiHandler::BusDisconnect call

The BlastSystemComponent was connecting to the Bus, but not
disconnecting from it, causing an assert to fire to it being a
multi-thread bus

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Added support for DataDrive lifecycle events to the ComponentApplication

The events are using the SettingsRegistry NotifyEvent to track when
certain keys are modified to signal handlers.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Corrected invalid JSON creation in ModuleManager::DeactivateEntities

Resolved clang warning about used type alias

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Fix for dangling reference in lambda registered to the SettingsRegistry
Notifier event

This was causing the EditorPythonBinding tests to crash due to the
following circumstances.

First Python has created an instance of a SettingsRegistryProxy
Second the SettingsRegistry sends an event during the time when the
SettingsRegistryProxy exists.

This issue was exposed due to the ComponentApplication Lifecycle events
using the SettingsRegistry to dispatch during various times of the
application workflow.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Added the generated cmake_dependencies.*.setreg files to engine.pak (#5073)

* Copied the generated cmake_dependencies.*.setreg file to the Cache
directory

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removed the platform name from the bootstrap.game.*.setreg

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Fixes for release builds with DCO fix (#5164)

* This set of changes is work toward allowing release builds to work with asset bundler generated bundles and legacy, non-prefab levels. This requires some other in-flight changes before this work is complete.

    Updated engine seed list + fixed automated test
    ComponentApplicationLifecycle has the ability to automatically register events if asked to register a handler and the event doesn't exist. This is only intended for cases where you need to register a handler early in startup before the settings registry file is loaded.
    Added two new lifecycle events: One after the system entity has been activated, and one after the system interface has been created.
    If you load an archive before the system entity has been activated, archive.cpp caches information about those archives until that time, so it can finish registration. This is because the serialization system and BundlingSystemComponent both need to be available to do this registration, but the bundles have to be loaded before those are initialized so that the settings registry file can be loaded.
    Fixed an error were mounted pak files were searching for levels.pak and not level.pak, and not finding them. I'm pretty sure this logic doesn't do anything functional either way, but I've been testing legacy levels with this change and they work now.
    Moved wildcard pak loading to where engine.pak is loaded. This is because the settings registry file that defines the IO stack to spin up must be available early in application startup, and this file must be within a mounted pak file. If you're using asset bundler generated bundles, they need to be loaded at this time so that file can be loaded.
    Atom's BootstrapSystemComponent.cpp no longer initializes on AssetCatalogLoaded, and instead initializes on the ApplicationLifecycle event SystemInterfaceCreated. This is because the base assetcatalog.xml file is really just a development time concept, this file should not be used in packaged release builds, because those builds will make use of delta catalogs in each bundle loaded. The asset catalog contains the list of all assets that were in the cache at development time, and this contains content that developers don't want to ship, and they may want to specifically hide from their customers, so data miners don't find secrets about upcoming game content.

Recovering from a branch that had incorrect DCO

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Fixed an incorrect ebus disconnect and removed an include that's no longer needed

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Fixed a copy and paste typo from trying to recover the previous pull request

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Updated product IDs for the settings registry builder to no longer collide with the JSON builder. Now they are based on a hash of the configuration.
Updated the engine default seed list to include the new asset ID info for the renamed bootstrap file

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Updated the path to the application lifecycle events, because runtime settings aren't included in the merged bootstrap file.
Addressed some feedback on printing out a string view on an error

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Removed a test that uses old assets that aren't relevant. We may not need this test anymore, but if we do we've backlogged a task to create a new test to cover this behavior without using old assets.

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

* Renamed SystemInterfaceCreated event to LegacySystemInterfaceCreated
Removed SystemEntityActivated event. Now that I have the rest of the fixes in this pull request, this new event wasn't needed, the already existing SystemComponentsActivated event does what I need.
Changed list to vector

Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>

Co-authored-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
2021-11-04 06:46:11 -07:00
2021-03-08 14:30:57 -08:00
2021-07-02 12:10:40 -07:00
2021-03-08 14:30:57 -08:00
2021-06-28 12:53:49 -07:00
2021-07-19 14:58:18 -05:00
2021-03-08 14:30:57 -08:00
2021-08-19 19:13:23 -04:00
2021-03-08 14:30:57 -08:00

O3DE (Open 3D Engine)

O3DE (Open 3D Engine) is an open-source, real-time, multi-platform 3D engine that enables developers and content creators to build AAA games, cinema-quality 3D worlds, and high-fidelity simulations without any fees or commercial obligations.

Contribute

For information about contributing to Open 3D Engine, visit https://o3de.org/docs/contributing/.

Download and Install

This repository uses Git LFS for storing large binary files.

Verify you have Git LFS installed by running the following command to print the version number.

git lfs --version 

If Git LFS is not installed, download and run the installer from: https://git-lfs.github.com/.

Install Git LFS hooks

git lfs install

Clone the repository

git clone https://github.com/o3de/o3de.git

Building the Engine

Build requirements and redistributables

For the latest details and system requirements, refer to System Requirements in the documentation.

Windows

Optional

  • Wwise audio SDK
    • For the latest version requirements and setup instructions, refer to the Wwise Audio Engine Gem reference in the documentation.

Quick start engine setup

To set up a project-centric source engine, complete the following steps. For other build options, refer to Setting up O3DE from GitHub in the documentation.

  1. Create a writable folder to cache downloadable third-party packages. You can also use this to store other redistributable SDKs.

  2. Install the following redistributables:

    • Visual Studio and VC++ redistributable can be installed to any location.
    • CMake can be installed to any location, as long as it's available in the system path.
  3. Configure the engine source into a solution using this command line, replacing <your build path>, <your source path>, and <3rdParty package path> with the paths you've created:

    cmake -B <your build path> -S <your source path> -G "Visual Studio 16" -DLY_3RDPARTY_PATH=<3rdParty package path>
    

    Example:

    cmake -B C:\o3de\build\windows_vs2019 -S C:\o3de -G "Visual Studio 16" -DLY_3RDPARTY_PATH=C:\o3de-packages
    

    Note: Do not use trailing slashes for the <3rdParty package path>.

  4. Alternatively, you can do this through the CMake GUI:

    1. Start cmake-gui.exe.
    2. Select the local path of the repo under "Where is the source code".
    3. Select a path where to build binaries under "Where to build the binaries".
    4. Click Add Entry and add a cache entry for the <3rdParty package path> folder you created, using the following values:
      1. Name: LY_3RDPARTY_PATH
      2. Type: STRING
      3. Value: <3rdParty package path>
    5. Click Configure.
    6. Wait for the key values to populate. Update or add any additional fields that are needed for your project.
    7. Click Generate.
  5. Register the engine with this command:

    scripts\o3de.bat register --this-engine
    
  6. The configuration of the solution is complete. You are now ready to create a project and build the engine.

For more details on the steps above, refer to Setting up O3DE from GitHub in the documentation.

Setting up new projects and building the engine

  1. From the O3DE repo folder, set up a new project using the o3de create-project command.

    scripts\o3de.bat create-project --project-path <your new project path>
    
  2. Configure a solution for your project.

    cmake -B <your project build path> -S <your new project source path> -G "Visual Studio 16" -DLY_3RDPARTY_PATH=<3rdParty cache path>
    

    Example:

    cmake -B C:\my-project\build\windows_vs2019 -S C:\my-project -G "Visual Studio 16" -DLY_3RDPARTY_PATH=C:\o3de-packages
    

    Note: Do not use trailing slashes for the <3rdParty cache path>.

  3. Build the project, Asset Processor, and Editor to binaries by running this command inside your project:

    cmake --build <your project build path> --target <New Project Name>.GameLauncher Editor --config profile -- /m
    

    Note: Your project name used in the build target is the same as the directory name of your project.

This will compile after some time and binaries will be available in the project build path you've specified, under bin/profile.

For a complete tutorial on project configuration, see Creating Projects Using the Command Line Interface in the documentation.

License

For terms please see the LICENSE*.TXT files at the root of this distribution.

S
Description
Open 3D Engine (O3DE) is an Apache 2.0-licensed multi-platform 3D engine that enables developers and content creators to build AAA games, cinema-quality 3D worlds, and high-fidelity simulations without any fees or commercial obligations.
Readme 150 MiB
Languages
C++ 82.6%
Python 13.1%
CMake 1.5%
Roff 1.2%
Lua 0.5%
Other 0.8%