xeolabs / xeogl Goto Github PK
View Code? Open in Web Editor NEWA WebGL-based 3D engine for technical visualization. Not actively maintained.
Home Page: http://xeogl.org
License: Other
A WebGL-based 3D engine for technical visualization. Not actively maintained.
Home Page: http://xeogl.org
License: Other
Somehow emphasise millimeters as the standard unit, like AutoDesk does.
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.
Consider using key "size" with a size array instead of "xSize", "ySize", "zSize".
..using local storage.
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.
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
.
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.
The protected XEO.Component#_setChild
method should have the option to check the type of the given component, using XEO.Component#isType
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"
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.
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);
}
mesh
becomes a XEO.Entity
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.
Doesn't have to be part of the XEO API but this interests me greatly.
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.
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.
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.
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 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.
Since the number of components is growing fast, perhaps use RequireJS, as Cesium does?
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?
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.
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--;
The spline-based camera path animation is very cool. Its link seems to be missing from the examples index.html page.
Need a XEO.Projection
base class for XEO.Perspective
and XEO.Ortho
.
XEO.renderer.ChunkFactory
is not handling chunk reuse correctly
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?
Create an example to showcase constructive solid geometry
https://evanw.github.io/csg.js
https://en.wikipedia.org/wiki/Constructive_solid_geometry
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?
Set them up so that they are aligned nicely with the default lights. Make Y the height axis.
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 _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/
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.
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
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?
Perhaps GameObject has market potential - but I prefer one word. What's an alternative to Entity?
Need a hook in the Geometry base class to force build when getting values of properties like positions
, indices
etc.
Indicate this in the API docs and tutorials. Also indicate angle units as degrees.
Boundary3D
is not transforming local-space boundary to world-space correctly.
Details soon.
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(..);
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.