michalbe / cervus Goto Github PK

Right now it's in milliseconds. Which requires us to do a lot of / 1000 everywhere.

Setting Entity.rotation to a quarternion should be enough if we expose quat.fromEurler and quat.setAxisAngle to the user.

• Entities should be as small as possible (the only logic there should be probably managing children entities and components)
• Components:
  • Body (like unity's transform)
  • Renderable
  • Movable

Perhaps vec3.up etc. would be sufficient.

• Colors should transform hexes to vectors when set.
• there's no need for Entity::color.vecat all then.

Features like moving, mouse look, rendering, or get_view_matrix should be abstracted and promoted to separate components which can be enabled/disabled and added/removed to Entities on runtime.

Right now, if we want to support both, WSAD & ZQSD with:

 game.camera.get_component(Move).dir_desc['81'] = 'l';
 game.camera.get_component(Move).dir_desc['90'] = 'f';

Only the latter will work.

Random utilities added to The Moment Lost In Time. should be part of Cervus.

I initially suggested to @michalbe that the Z axis be the "up" axis, to stay in line with Blender. However it's clear to me now that this goes against OpenGL. Let's change it back.

While most of the time this isn't a big issue, it comes up as a problem during the look at and target to rotations. These operations should orient the forward face toward a point. Instead they assume that Z is forward and they currently orient the up face.

Since basically every 3d software can export FBX format, let's use it in Cervus as well.
The MORPH component could probably be used in here, but further research is required
to confirm that.

Questions & concerns

• Maybe md5 would be easier to work with?
• The easiest would probably be simple JSON model format from this Online 3D Converter, it exports FBX animations and bones to JSON (tested on Mixamo models)

Ideas:

• Entity can take a target entity and follow it all the time
• this could also be a method that forces camera to change rotation (do entities need to have a forward and right vector then? They probably should - #13).

I mean, fix them, they're broken as hell right now...

Keep in mind that each component keeps a reference to an Entity it's assigned to, and this Entity has map of components, so standard deepCloning won't work here.

Related issues:

• #95

And Entity class should use vectors and math from the Camera class.

It would be nice to have an ability to save the current game state as JSON, and then build the game using this JSON.

Related issues:

• #76

• Remove key listener from the camera module
• move it to the core or separate module
• subscribe camera actions to this listener, and expose it outside.

Right now they duplicate too much code.

Scale setter isn't working correctly, it's scaling by the vector, not to the vector.

Repro

• set entitie's scale [5, 5, 5]
• scale it down to the initial size with entity.scale = [1, 1, 1];
• not that nothing happened, because entity.local_matrix was just scaled by [1, 1, 1] vector.

it's currently broken and I've removed it in #37. Let's bring it back.

Let's find a way to render multiple cameras to different parts of the screen. This way it will be easy to implement minimaps, VR rendering, etc.

Where components are inheriting from basic components (like Entity), and public methods are visible from the editor when not contain _ in name.

• How to handle enums there?
  • and other data types?

... but bundle only methods that we use in the output file.

#45 added Entity.look_at which currently always assumes that the look-at rotation should align the object's left direction with the world`s horizontal plane.

This might be helpful: https://stackoverflow.com/questions/8942950/how-do-i-find-the-orthogonal-projection-of-a-point-onto-a-plane

When using mouse look it will helpful to provide an option to hide the mouse cursor.

💡 Inspirations:

• Types of light in Unity
• Dynamic lighting
• Threejs lights

Casting rays is something that could be used in collision detection, or mouseclicks on elements.

Docs

It would be nice to have some. Investigate possibilities here.

Repro

• Notice the red sphere in the middle. It's moving + 0.06 in the x direction each frame:
  
• Now, let's rotate it in every frame:

  sphere.rotate_ud(16/1000);
  sphere.rotate_rl(16/1000);

With the same movement logic, the scene looks like this now:

core/math could simply export const vec3 = ...; and export const mat4 = ...'. This will allow the following usage in other files: import { vec3 } from './core/math'; vec3.method_name();.

@stasm ideas?

• docs

For instance, mat4.create could be implemented as:

return Float32Array.of(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1);

Previous discussion: #23 (comment)

By removing Entity.origin we can keep the API surface small. The same effect can be achieved by introducing an intermediate parent in the object hierarchy. This solution also has the benefit of being consistent: rotating ancestors results in consistent rotation of all descendants relative to the ancestor's origin. With Entity.origin it's weird that rotating the entity may not happen around it's (0, 0, 0) point.

Most of the current use-cases will want to set position directly. If needed, move_along can be used.

Maybe Group can just be an empty Entity? Investigate this. If not, they sure can share most of the code.

When perform_ticks executes update() multiple time (when ticks_qty is > 1), all update() calls will the the input data stored in game.keys. Because this code is synchronous, any key events will fire callbacks when the updates are already done.

We could possible save space by using Object.assign(this, options) and a default options parameter.

As a first step here, it would be nice to create cervus bindings to any 3d physics library available.

• Ammo
• Cannon this one isn't building with rollup, there's plenty of errors in the code
• JigLibJS
• Bullet
• microphysics
• Physijs Threejs plugin
• Oimojs this one looked nice but is hardbundled with ThreeJS.
• Goblin

Let's make it possible to imports parts of the engine so it will treeshake better. It should be possible to use final version this way:

import { Box } from 'cervus/shapes';
import { Phong } from 'cervus/material';

const voxel = new Box({ material: Phong });

I removed Entity.origin in #37 because of implementation troubles. I know @michalbe would like to see it back, so let's discuss this here. Previous discussion: #35.

Some deeper research should be done here, but from what I know today, there are two basic approaches to that topic:

• UBERSHADER, that contains the data for all materials, lights, textures etc. in just one, huge shader. Since if statements are slowing shaders down, all the branches should be handled with preprocessor commands. This way shaders handled for instance in Horde3D.
  If written in a smart way, this can support user defined rules as well (for instance using #ifdef CUSTOM_RULES const).
• Another method is implemented in BabylonJS, where shaders are including needed parts of the program in the main material shader. Variation of this method could be something like GLSLify, a require kind of tool for glsl programs.