circuithub / morpheus Goto Github PK

View Code? Open in Web Editor NEW

13.0 9.0 1.0 4.41 MB

Browser side Constructive Solid Geometry.

License: MIT License

CoffeeScript 14.04% JavaScript 85.73% Shell 0.03% CSS 0.20%

morpheus's Introduction

Morpheus

About

A plugable scriptable solid modeller for the WWW.

Licensing

Morpheus is licensed under the permissive MIT open source license. Please see LICENSE for more information.

In addition, the following licenses are used by third party libraries used in this project:

(These licenses can also be found in the licenses/ folder)

Installation

Basic installation using either npm or cake:

You already have npm:

> npm install

You already have cake:

> cake install

Running examples

Run node server.js
Go to http://localhost:8080/test/index.html
Enjoy the eye candy :)

etc...

For everything else, there's cake menu:

> cake

cake build-api            # Build the API module
cake build-generator      # Build the generator module
cake build-editor         # Build the editor module
cake build-renderer       # Build the renderer module
cake build-gui            # Build the gui module
cake all                  # Build all distribution files
cake debug                # Build all distribution files in debug (development) mode
cake fetch:tools          # Fetch all supporting tools
cake fetch:npm            # Fetch the npm package manager (always global)
cake fetch:uglifyjs       # Fetch the UglifyJS minification tool
cake fetch:express        # Fetch the express server (for running a local server)
cake fetch:libraries      # Update all supporting libraries
cake fetch:glquery        # Update the glQuery library (always local)
cake minify               # Minify the resulting application file after build
cake clean                # Cleanup all build files and distribution files

  -g, --global       Use with fetch to install supporting libraries and tools globally

morpheus's People

Contributors

Stargazers

Watchers

Forkers

rehno-lindeque

morpheus's Issues

Add a wedge node

Intersect primitves with a wedge (useful for rounded corners etc)

Additional eye candy & polish

For example, do we add a textured background / floor?

Design: 3D viewport controls

We need to think about what controls (if any) the user could use inside the viewport itself. Let's collect some ideas here.

Syntactic sugar for operator overloading on parameterized variables

Fix webworker CSM loader in firefox

It appears that the javascript file might be loading with the wrong mime type in Firefox?

Getting this error:

not well-formed
file:///home/snow/projects/active/development/contract/circuithub/mecha/static%2Flib%2Fapi.csm.js
Line 1

Materials: Shading parameters

Add shading parameters to materials

Specifically:

Specular (color, size, brightness)

To think about for later:

Reflectivity
Transparency
Ambient color

Calculate bounding boxes

(Currently busy with...)

Calculate a bounding box for the model and adapt the shaders to these bounds so that the user doesn't have to work inside fixed dimensions.

Graphical effect: Soft shadows

Shadows, might not necessarily be a good idea for an engineering view of the object, however, similar to ambient occlusion, high quality soft shadows are very easy to do with distance fields, so might be useful for some inexpensive eye candy later.

Automatically create canvas and controls in a div

Do not allow floating point values to mix with integers in primitive operations

For example

float a = 3.0;
float b = 2 * a; // is not valid: cannot multiple integer with float in glsl

Material node appears not to work with some composites?

E.g. can't use material inside wedge node a.t.m.

sphere({ radius: 0.3 })
.material({ color: [1.0, 0.0, 0.0] })
.wedge({ axis: 1, from: 0, to: 90 })

Add a difference node

This can simply be implemented in the ASM as a combination of "intersect" and "invert"

Graphical effect: Wireframe lines (Engineer/CAD-style)

Inner CAD-style wireframe lines will need to be calculated directly from the ASM.

Iterate node

For repeating patterns

Simplify compilation

It might simplify the compiler if we generate specialized nodes for certain optimizations such as corners for corner-compilation

Bug Report: 100% cpu usage in firefox on launchpage

(reported by Dirk)

OS: Ubuntu

Display javascript and syntax errors

Report error messages for javascript errors that occur inside the sandbox

Split off an application module from gui

The gui module should preferably only handle on-screen controls. The application module will package everything up and handle things like sandboxing, dynamically loading code etc.

Materials: Texture parameters

Add texture parameters to materials

A good example of where this might be needed for example is with resistors that are color coded (although it is theoretically possible to do this procedurally). Probably take a simple approach like simply projecting a texture top-down onto the geometry.

Split glsl compilation into distance field generation and shader generation

Split compile.glsl into multiple domain-specific functions and then do the main shader generation in the renderer module. The renderer should take additional parameters for shading / rendering tricks.

Controls for adjusting model parameters

Sliders, etc

Handle context lost event

Add a bend node

For both sharp bends and smooth bends, useful for electronic components' pins...

Rule tool

It would be super useful to allow the user to click on two points in the model and measure XYZ displacement between them.

Graphical effect: Cel shading

Cel shading may be useful for clarity in the models.

Adaptive rendering quality

Upgrade the rendering quality when the scene is static and degrade rendering quality during updates.

Graphical effect: Outlines

Outlines can probably be achieved by using ray march distances.

Add a mirror node

Partially implemented, still need to take into account axes and diagonal mirror

Parameterize CSM scripts

Parameterize scripts and models in order to control them using GUI controls.

Add a chamfer node

Use ray distance to compute error threshold for ray marching

The error threshold in determining a hit should be calculated relative to the pixel error on screen. Thus the threshold needs to be linear in distance and related to the camera field of view

Render full circuit board

The circuit board + all electronic components will need to be rendered (circuit taken from the footprint)

Improve normal calculation, especially at the edges of shapes

Because normals are calculated in a numerical way tiny errors may occur on the edges of objects - which causes artifacts. Specifically at the edges of solids where the opposing face is pointing away from the camera this is noticeable.

The best way to fix this is probably by keeping track of errors and using them in the depth probes of the normal calculation...

A few other notes which may be helpful:

It is easy to determine when the normal facing away from the camera
If all depth probes for the normal is positive then the point is probably outside the object

(See also issue #4 which may be related to this one)

Split mecha into packages (modules)

Split mecha into the following packages:

generator (Shader / geometry generator)
renderer (Render models to a webgl context)
gui (Create a canvas gui for viewing / manipulating the models on a canvas with optional parametric controls)
editor (Source code editor for mecha models)

Graphical Artifact: Distortion with camera proximity

When the camera is placed very close to an objects tend to become slightly distorted. This appears to be an with OpenGL's texture correction which is perhaps not 100% correct.

See http://hacksoflife.blogspot.com/2008/08/perspective-correct-texturing-in-opengl.html for some good tips on perspective correction in opengl.

(We could also apply various other quick fixes for the issue, such as using a less wide-angled FOV, switching to orthographic projection, limiting proximity to the object, using a tesselated cube etc... but for now, we'll see if we can't fix it in a straight-forward manner)

(For the parts editor in CircuitHub we should use orthographic projection anyway, so this isn't an immediate concern)

Do not pollute global Array object

Mecha is designed to be embedded into other apps, so it's not a good idea to pollute the global array object as we're doing in src/array.coffee at the moment...

Graphical effect: Ambient occlusion

Ambient occlusion looks good on mechanical models since they are very angular and adds to the perceived depth of the object.

(It is also very easy to do with distance fields)

Calculate B-rep and serialize STEP models

Possibly look at http://evanw.github.com/csg.js/ or http://research.cs.tamu.edu/keyser/geom/esolid/index.htm for this

Also, lots more info at http://news.ycombinator.com/item?id=3320089 (especially with regards to Boundary Representation versus triangles)

Boundary representation: http://en.wikipedia.org/wiki/Boundary_representation
STEP: http://en.wikipedia.org/wiki/ISO_10303

Yet another CSG library (but this is C++ only): http://code.google.com/p/carve/

Sometimes with mouse dragging rotation the model disappears

This happens when the mouse is dragged off the page area - this was already fixed in BIMsurfer: opensourceBIM/BIMsurfer-before2019#9

Also check if this needs to be fixed: opensourceBIM/BIMsurfer-before2019#61

Investigate: Should the ASM be optimized in-place?

At the moment we're doing in-place optimization, however it might come in useful to retain the unoptimized ASM for use in the user interface (I.e. for manipulating CSM primitives by their composition of parts)

Let's come back to this later...

Add operator overloading to the CSM script

Operator overloading is needed for using/manipulating parameters (see also issue #24)...

For example one might have

var a = range([0,0,0], [10,15,0.8]);
var b = range(2, 4);

box({dimensions: b * a})

where b * a is actually a relatively complicated operation that will probably be translated to some overloaded operator such as mul(b,a).

Nevermind this, one might even want operations like sqrt(b) and cross(a,r)...

Add a scale node

Use normals information for anti-aliasing

Perhaps use the same distance information gathered for calculating normals to do some kind of rough pixel coverage info - it might be possible to do a kind of cheap anti-aliasing this way...