Boundary3D is not transforming local-space boundary to world-space correctly.

Details soon.

I tried latest xeoEngine glTF loader (Built on 2016-01-29).
But, I have noticed that the texture of the duck is funny.
Probably I think the texture is turned upside down.

http://jsdo.it/cx20/4rxr
https://github.com/KhronosGroup/glTF/tree/master/sampleModels/duck/glTF

Need a XEO.Light marker base-class for XEO.AmbientLight, XEO.DirLight and XEO.PointLight, so we can verify correct types when attaching those to XEO.Lights.

When creating multiple scenes that each create their own default canvas, make XEO lay the canvases out in a flow layout, so they are at least visible. Also need to organize their input-event overlay DIVs accordingly.

XEO.renderer.ChunkFactory is not handling chunk reuse correctly

..using local storage.

• Use same document layout as the glTF spec
• Show which glTF elements are loaded by highlighting them in this diagram
• Mention how each glTF mesh becomes a XEO.Entity
• Perhaps maintain a node->mesh mapping in the model, or use metadata

Not sure if I am just missing something, but whenever I am trying to add a CameraControl to the camera of my scene, the code stops working.

Tried referencing the scene's default camera directly, or using {camera: null} so that it would default to the parent scene's camera (as described in the API) - alas to no avail.

I altered one of your examples in this fiddle, and at the end try to add the CameraControl (currently commented out). Where am I going wrong? or did I stumble onto a bug?

https://jsfiddle.net/quaxquax/pb2Ls5s2/

I'm a big fan of lightweight libraries. But XEO.Group feels too lightweight. I miss being able to add objects to other objects and operate on them all as a whole. I'm not proposing GameObject.addGameObject in the primary library necessarily - but maybe some additional class like GroupableGameObject.addGameObject.

Need a _destroy method on XEO.SkyBox, in which internally-created child components are destroyed.

On the xeoEngine website, consider providing hashtag link to community created examples on JSFiddle, CodePen, CSSDeck. I have one example to post right now - a simple voxel editor.
https://jsfiddle.net/5ek3w0p8/8/

I don't current have a code sample to post - sorry. But when I place a transparent GameObject inside another transparent GameObject, the interior GameObject is not drawn at all. Using BoxGeometry.

The goal is to have a fully transparent voxel container for picking but also use as a cursor where the interior cursor shape is not fully opaque.

Need a hook in the Geometry base class to force build when getting values of properties like positions, indices etc.

https://github.com/xeolabs/xeoengine/blob/master/src/geometry/boxGeometry.js#L218

Really small issue - just something I noticed. This project is wicked awesome. I am a cheerleader.

I assume that I ought to use GameObject.destroy and that it would get removed from a scene. But I don't think this actually works. How should I go about removing a game object from a scene?

I understand how to construct components with the default XEO.scene. However when I create a new scene or additional scenes, why is it necessary to pass the scene to every new component I create? Is there some other alternative?

The protected XEO.Component#_setChild method should have the option to check the type of the given component, using XEO.Component#isType

Consider using key "size" with a size array instead of "xSize", "ySize", "zSize".

Set them up so that they are aligned nicely with the default lights. Make Y the height axis.

Perhaps GameObject has market potential - but I prefer one word. What's an alternative to Entity?

Create an example to showcase constructive solid geometry
https://evanw.github.io/csg.js
https://en.wikipedia.org/wiki/Constructive_solid_geometry

I'm using a build from December 23rd. I don't seem to be able to save and load a scene.

https://jsfiddle.net/philmaker/ueodzjjj

What am I doing wrong? I also tried this using the latest build but saw an error relating to _src.slice and " Cannot read property 'slice' of undefined"

Seems to better imply a container of components.

It's not strictly a collection, but it seems OK to use the term since there's not much chance of anyone implementing a complete collections API within the XEO namespace in future, ie. OK to use the term loosely.

If we use a technique like weighted blended order-independent technique (which is used in Cesium), then we never have to use XEO.Layer nodes to manage blending order.

The XEO.Visibility component is intended to allow a UI to toggle the visibility of XEO.Entity types.

However, we also need a XEO.Cull component, through which visibility culling processes can also influence the visibility of XEO.Entity's.

The visibility of each XEO.Entity would then be the cobination of its XEO.Visibility and XEO.Cull states.

This sort of mutability makes the engine very complex internally:

var entity = new XEO.Entity();
var camera = new XEO.Camera();
entity.camera = camera;
camera.project = new XEO.Perspective();

Investigate whether this is worth it, since it imposes a lot of complexity on user-defined components, where those components must synchronize their structure accordingly.

Maybe it's OK to have immutable component compositions, where once a component is composed of other components, eg:

var camera = new XEO.Camera({
       project: new XEO.Perspective()
});

var entity = new XEO.Entity({
    camera: camera
});

we would then not be allowed to do this:

entity.camera = new XEO.Camera(..);

Pros

• Makes engine simpler
• simplifies contract for user-created components that are composed from other components, where the user components don't have to worry about those other components being modified in this way

Cons

• No possibility of making a visual node-based editor, which would allow component associations to be edited

The viewing transform is always a XEO.Lookat (or subtype) because we use eye and look positions for various essential things within the scene and renderer.

Thinking about this for a bit first though, because we might be able to derive eye and look from matrices made by other potential viewing transforms.

However, it would be nice to be able to access viewing component like this:

myCamera.lookat.eye = [2,3,4];
myCamera.lookat.look = [0,0,0];

Need a XEO.Projection base class for XEO.Perspective and XEO.Ortho.

This was not a priority for SceneJS architecturally and it's probably not a priority for xeoEngine. Consider creating a basic shadow mapping demo for xeoEngine.

Doesn't have to be part of the XEO API but this interests me greatly.

See http://xeoengine.org/examples/#boundaries_CollectionBoundary

Indicate this in the API docs and tutorials. Also indicate angle units as degrees.

The spline-based camera path animation is very cool. Its link seems to be missing from the examples index.html page.

Somehow emphasise millimeters as the standard unit, like AutoDesk does.

30 FPS is the maximum speed we can get from this camera rotation example.

We should get 60 FPS, but I think the way the input event notification is deferred until the next "tick", which triggers the view matrix rebuild, which is deferred until the next "tick". So there's always two ticks between input and final camera update.

Need to collapse somehow.

Add a busy spinner component that would be used by XEO.Model while loading, and also by app code that wants to indicate business.

The spinner has a processes count that indicates how many currently-active processes it represents. As a process starts, it would increment the count, then as it completes (or fails) it would decrement it again.

The spinner is only visible while the count is greater than zero.

Example

var spinner= myScene.canvas.spinner;

// Increment count of busy processes represented by the spinner;
// assuming the count was zero, this now shows the spinner
spinner.processes++;

// Increment the count again, by some other process;
// spinner already visible, now requires two decrements
// before it becomes invisible again
spinner.processes++;

// Decrement the count; count still greater
// than zero, so spinner remains visible
spinner.process--;

// Decrement the count; count now zero,
// so spinner becomes invisible
spinner.process--;

Since the number of components is growing fast, perhaps use RequireJS, as Cesium does?

Links: http://xeoengine.org/examples/billboards_spherical_clouds.html and http://xeoengine.org/examples/billboards_spherical_clouds.html
Browsers: Chrome and Firefox
GPU: Intel® HD Graphics 4600
Console text :

[ERROR] [XEO.GameObject 2510]: Draw program failed to validate



Vertex shader:

uniform mat4 xeo_uModelMatrix;
uniform mat4 xeo_uViewMatrix;
uniform mat4 xeo_uProjMatrix;
uniform vec3 xeo_uEye;

attribute vec3 xeo_aPosition;

varying vec4 xeo_vViewPosition;
varying vec3 xeo_vViewEyeVec;

attribute vec3 xeo_aNormal;
uniform mat4 xeo_uModelNormalMatrix;
uniform mat4 xeo_uViewNormalMatrix;
varying vec3 xeo_vViewNormal;

attribute vec2 xeo_aUV;
varying vec2 xeo_vUV;
void billboard(inout mat4 mat) {
   mat[0][0] = 1.0;
   mat[0][1] = 0.0;
   mat[0][2] = 0.0;
   mat[1][0] = 0.0;
   mat[1][1] = 1.0;
   mat[1][2] = 0.0;
   mat[2][0] = 0.0;
   mat[2][1] = 0.0;
   mat[2][2] = 1.0;
}

void main(void) {

   vec4 modelPosition = vec4(xeo_aPosition, 1.0); 
   vec4 modelNormal = vec4(xeo_aNormal, 0.0); 
   mat4 modelMatrix = xeo_uModelMatrix;
   mat4 viewMatrix = xeo_uViewMatrix;
   mat4 modelNormalMatrix = xeo_uModelNormalMatrix;
   mat4 viewNormalMatrix = xeo_uViewNormalMatrix;
   vec4 worldPosition;
   mat4 modelView =  xeo_uViewMatrix * xeo_uModelMatrix ;
   mat4 modelViewNormal =  xeo_uViewNormalMatrix * xeo_uModelNormalMatrix ;
   billboard(modelMatrix);
   billboard(viewMatrix);
   billboard(modelView);
   billboard(modelNormalMatrix);
   billboard(viewNormalMatrix);
   billboard(modelViewNormal);
   worldPosition = modelMatrix * modelPosition;
   vec4 viewPosition = modelView * modelPosition;
   vec3 worldNormal = (modelNormalMatrix * modelNormal).xyz; 
   xeo_vViewNormal = (viewNormalMatrix * vec4(worldNormal, 1.0)).xyz;
   xeo_vViewPosition = viewPosition;
  vec3 tmpVec3;
   xeo_vViewEyeVec = ((viewMatrix * vec4(xeo_uEye, 0.0)).xyz  - viewPosition.xyz);
   xeo_vUV = xeo_aUV;
   gl_Position = xeo_uProjMatrix * viewPosition;
}

Fragment shader:

precision highp float;

varying vec4 xeo_vViewPosition;

uniform vec3 xeo_uDiffuse;
uniform vec3 xeo_uSpecular;
uniform vec3 xeo_uEmissive;
uniform float xeo_uOpacity;
uniform float xeo_uShininess;
uniform float xeo_uReflectivity;

varying vec2 xeo_vUV;
uniform sampler2D xeo_uOpacityMap;
uniform vec3 xeo_uLightAmbientColor;
uniform float xeo_uLightAmbientIntensity;
varying vec3 xeo_vViewEyeVec;
varying vec3 xeo_vViewNormal;

void main(void) {

   vec3 ambient = xeo_uLightAmbientColor;
   vec3 diffuse = xeo_uDiffuse;
   vec3 specular = xeo_uSpecular;
   vec3 emissive = xeo_uEmissive;
   float opacity = xeo_uOpacity;
   float shininess = xeo_uShininess;
   float reflectivity = xeo_uReflectivity;
   vec3 viewNormalVec = normalize(xeo_vViewNormal);

   vec4 texturePos = vec4(xeo_vUV.s, xeo_vUV.t, 1.0, 1.0);
   vec2 textureCoord;

   textureCoord = texturePos.xy;
   textureCoord.y = -texturePos.y;
   opacity = texture2D(xeo_uOpacityMap, textureCoord).b;

   vec3  diffuseLight = vec3(0.0, 0.0, 0.0);
   vec3  specularLight = vec3(0.0, 0.0, 0.0);

   vec3  viewLightVec;
   float dotN;
   float lightDist;
   float attenuation;

   gl_FragColor = vec4( (specularLight * specular) + (diffuse * (diffuseLight + ambient * xeo_uLightAmbientIntensity)) + emissive, opacity);
}

I want to create one scene on top of another. The goal is for the second scene on top to provide additional controls without the camera of the first scene affecting the controls of the primary scene. The problem I'm running into is that the input overlay of the second scene is obscuring the primary scene mouse input. What's the best approach?

The billboarding matrix adjustments are only compiled into the drawing vertex shader. They should also be compiled into the vertex shaders for object and primitive picking.

Therefore, attempts to pick billboarded entities will sometimes miss, because picking is quietly done on a non-rotated version of the target entity, while a rotated version is rendered.

[LK: This is actually related to https://github.com//issues/36]

Seem to have stumbled onto another bug. Same fiddle as before https://jsfiddle.net/quaxquax/pb2Ls5s2/

When adding a definition for a Collection it goes dark, and throws an "unreachable code after return statement" on the browser console.

Uncommenting the line 25 that contains 'var myCollections = new XEO.Collection();' makes everything whole again.

The examples online don't seem to load on Chrome OS/Chromebook.

Refused to display 'http://xeoengine.org/examples/animation_CameraFlight_Entity.html' in a frame because it set 'X-Frame-Options' to 'DENY'.

BTW, the san-serif font for the examples page looks nice.

Nasty hardcoded treatment of "XEO.Entity" types prevents their subclasses from being processed as entities also.

Need some kind of "typeof" test that tests if a component instance is a subtype of a target class.