Add world or scene as a root ECS object

[vorg]

Given that pex-renderer is no longer Renderer but generic ECS machine should the main object be called World or Scene?

import createWorld from "../index.js";

const world = createWorld() //OK

world.addSystem(renderer.geometrySystem()); //OK
world.addSystem(renderer.transformSystem()); //OK
world.addSystem(renderer.renderSystem()); //OK


const lineBuilder = world.entity({ //OK
  transform: world.transform(), //Ugh
  geometry: world.geometry({ ... }), //Ugh
  material: world.material({ ... }), //Ugh
});
world.add(lineBuilder) //OK

[vorg]

If we would get rid of component constructors and allow

const lineBuilder = world.entity({ //OK
  transform: { positions: [0, 0, 0] }
  geometry: createCube(),
  material: { baseColor: [1, 0, 0, 1] }
});

how does one discovers possible components and their values?

[dmnsgn]

Given that pex-renderer is no longer Renderer but generic ECS machine should the main object be called World or Scene?

Do we need a separate pex-ecs for world/entity adding?

import createContext from "pex-context";
import createWorld from "pex-ecs"; // or if too many packages, import { createWorld } from "pex-renderer"
import { systems as rendererSystems } from "pex-renderer";

const ctx = createContext()
const world = createWorld({ ctx }) // world properties

world.addSystem(rendererSystems.geometry());
world.addSystem(rendererSystems.transform());
world.addSystem(rendererSystems.render());

If we would get rid of component constructors and allow

const lineBuilder = world.entity({ //OK
  transform: { positions: [0, 0, 0] }
  geometry: createCube(),
  material: { baseColor: [1, 0, 0, 1] }
});

how does one discovers possible components and their values?

I am all in favour of using plain object and removing renderer.material() calls that are a bit heavy to parse.

[vorg]

i don't see value in completely separate pex-ecs (I can see use cases like html canvas projects) but i would just use pex-renderer createWorld with 100% custom systems first as a test case. systems namespace is fine although i prefer flat apis. Any particular reasons for world.geometrySystem() -> rendererSystem.geometry() ?

[dmnsgn]

v4: we settled on:

• world: as a list of entities and systems and keeping track of deltaTime for animation in update.
• default renderEngine: update (all its system, kind of like world?) and render selected entities
• components: pex-renderer components which goal is to set default values. If that's 100% true, why are systems still checking so many default values

  pex-renderer/systems/renderer/standard.js

  Lines 445 to 452 in 90a39cb

  	sharedUniforms[`uDirectionalLights[${i}].castShadows`] = light.castShadows;
  	sharedUniforms[`uDirectionalLights[${i}].projectionMatrix`] = light._projectionMatrix || tempMat4; //FIXME
  	sharedUniforms[`uDirectionalLights[${i}].viewMatrix`] = light._viewMatrix || tempMat4; //FIXME;
  	sharedUniforms[`uDirectionalLights[${i}].near`] = light._near || 0.1;
  	sharedUniforms[`uDirectionalLights[${i}].far`] = light._far || 100;
  	sharedUniforms[`uDirectionalLights[${i}].bias`] = light.bias || 0.1;
  	sharedUniforms[`uDirectionalLights[${i}].shadowMapSize`] = light.castShadows ? [light._shadowMap.width, light._shadowMap.height] : [0, 0];
  	sharedUniforms[`uDirectionalLightShadowMaps[${i}]`] = light.castShadows ? light._shadowMap : dummyTexture2D;

[dmnsgn]

• are renderEngine and world overlapping (both a collection of systems with an update method)
• we need to check who sets default value instead of having it define it 2 places (components and renderer) cc Where to keep default values #307

[vorg]

Also relevant: how do we plan on adding and optimising queries / searching for nodes with given component. Right now every system filters all entities. This could be something that the world takes care of.