diarmidmackenzie / instanced-mesh Goto Github PK

View Code? Open in Web Editor NEW

31.0 31.0 4.0 29.82 MB

License: MIT License

JavaScript 30.04% HTML 69.51% CSS 0.46%

instanced-mesh's People

Contributors

Stargazers

Watchers

Forkers

seeingred0 rchovatiya88 slecorne qleveque

instanced-mesh's Issues

Issues upgrading to A-Frame 1.4.1

Have been testing compatibility with A-Frame 1.4.1. A few issues have come up...

Here's a list of the examples & tests that seem broken...

Tests

3d-models-multi-mesh

Colors are wrong:

(also other tests that use the same model have the same problem)

env-map-example

Colors are wrong + instancing not happening.

Errors in console:

core:cubemap:warn <a-cubemap> did not contain exactly six elements each with a `src` attribute. 
13:30:33.677 browser.js:111 core:a-assets:warn Asset loading timed out in   3000 ms
13:30:33.690 browser.js:111 utils:src-loader:warn Selector "#env" does not point to <a-cubemap>

movement-multi-mesh

hits error:

[GET http://127.0.0.1:8080/tests/framed-cell.js ](movement-multi-mesh.html:6          GET http://127.0.0.1:8080/tests/framed-cell.js net::ERR_ABORTED 404 (Not Found))

(maybe not a new issue?)

pbr-example

hits error:

http://127.0.0.1:8080/tests/assets/snowball/Snow_002_DISP.jpg 404 (Not Found)

(maybe not a new issue?)

Examples

animated-spheres

Not working at all - likely the same issue as with env-map-example

coloring-blocks

Seems basically OK, but on deleting blocks, hit a few errors:

instanced-mesh.js:793 Member block-5-7-7 not found for modification

(maybe not a new issue, though I don't recall seeing it before)

Instanced mesh events

Is it possible to catch mouseenter event on instanced mesh?

Code:

<!DOCTYPE html>
<html>

<head>
    <script src="https://aframe.io/releases/1.3.0/aframe.min.js"></script>
    <script src="https://cdn.jsdelivr.net/gh/diarmidmackenzie/[email protected]/src/instanced-mesh.min.js"></script>
    <script>
        AFRAME.registerComponent('cursor-listener', {
            init: function () {
                this.el.addEventListener('mouseenter', function (evt) {
                    console.log('Mouse at: ', evt.detail.intersection.point);
                });
            }
        });
    </script>
</head>

<body>
<a-scene>
    <a-camera><a-cursor></a-cursor></a-camera>
    <a-box color="blue"
           instanced-mesh
           id="instanced-mesh"
    ></a-box>
    <a-box color="red"
           position="-3 1 -10"
           cursor-listener
           scale="3 3 3"></a-box>
    <a-entity
            id="instanced-mesh-member"
            position="3 1 -10"
            scale="3 3 3"
            cursor-listener
            instanced-mesh-member="mesh:#instanced-mesh"
    ></a-entity>
</a-scene>
</body>

</html>

Just dropping by to ask if there's any particular reason why changing the default position attribute in A-Frame doesn't change the position of the instanced meshes dynamically? I see you're using a separate component for moving the meshes, but it seems kind of counter-intuitive to how I'm used to working with A-Frame.
What are the chances of getting something like the following to work?

var block0 = document.querySelector('#block0');
block0.setAttribute('position', '2 1 3');

Have a great weekend
Jasper

GLTF models with multiple meshes

Query:

I have a GLTF file with 3 meshes under a node. When used with instanced-mesh it only shows 1 of the 3 meshes.

GLB Models

Hi! Does this instanced mesh component work when feeding it glb / gltf models? I am trying to replace the sphere example with feeding it 3d models.

Are unique IDs necessary for members?

Query:

I noticed in your sample you had an id for every child as well as in the readme doc it says "Every entity must have an id that is unique within the mesh". But in the glitch link above it seems to work ok for the next set of objects without having an id? I ask because there are many objects in the scenes we're making (like tons of trees or flex posts) that don't really need a unique id. If it's actually a requirement for the component I can create a random value or something similar.

A-Frame 1.5.0 Frustum Culling issue due to THREE.js PR 25591

From A-Frame 1.5.0, we have an issue with frustum culling due to three,js changes to how this works for Instanced Meshes.

The key change is this one:
mrdoob/three.js#25591

Key changes are that:

frustrum culling is enabled on instanced meshes by default
the bounding sphere for frustum culling is automatically computed, the first time it is needed
the key property is a new boundingSphere property on the InstancedMesh itself. The values set on this override anything set on the geometry of the InstancedMesh.
however, applications need to manually recompute this every time they add or modify an instance's position using setMatrixAt()

Up to this point, frustum culling support in this component allowed the user to manually configure a bounding sphere using the fcradius and fccenter properties.

This still works OK if an instance mesh has members at start of day.

However if an instanced mesh is empty at start of day, the boundingSphere property on the InstancedMesh gets set to an empty sphere initially, and is never updated.

A further change is that the bounding sphere specified using fcradius and fccenter will now be applied to every instance, which can give a larger overall bounding sphere than specified, if the instances are spread out.

Restoring previous function should be a fairly simple fix. When we set boundingSphere on the InstancedMesh's geometry, we also set it on the InstancedMesh itself. This should also be back-compatible with the pre-1.5.0 way of doing things.

However, it could also be good to make available the new functionality to auto-compute boundingSpheres. How to do that, while continuing to offer the old interface, needs a little more thought.

Furthermore, three.js also auto-computes a boundingBox for the InstancedMesh, but again applications need to re-compute this on each add/remove/move. This is used when an InstancedMesh is passed in to Box3.expandByObject(). Perhaps we should try to make that function work as well?

Differences in mesh color when using drainColor

Hi Diarmid,

Been loving this component, super useful and convenient to use, thank you for creating it!

I noticed a small discrepancy in my mesh colors when using the drainColor property and was wondering if there was a bug in the component? I am using A-Frame v.1.4.1.

The image below shows 2 a-boxes colored with the same hex value #8DA34E, the higher one is a non-instanced mesh while the lower one is an instanced-mesh with drainColor:true and the color is set through the colors property. You can see the instanced-mesh cube is much lighter than the regular one, I wonder if the base white color is bleeding through or if I'm doing something wrong in the implementation?

relevant code:

<a-box id="mesh2" color="#8DA34E" position="0 4 -2"> </a-box>

<a-box id="mesh1" color="#456C22" instanced-mesh="drainColor:true;"> </a-box>
<a-entity id="block1" position="-2 2 -2" instanced-mesh-member="mesh:#mesh1; colors:#8DA34E;">
</a-entity>

Separate out examples & tests

Currently the "tests" folder contains a mish-mash of use-cases. Some have a primary purpose of testing functionality. Some are good examples of usage.

Tidy up & split out into 2 separate groups

examples carefully selected to show capabilities & usage
tests intended to easily check key functions are working correctly.

(eventually we should add unit tests to supplement the live tests, but that might take a while longer)

getting basic example working on glitch

Hi Diarmid, not urgent but I was trying to get a basic example working but was not successful. Here is the sample project, all it is doing is loading a street and then trying to load 1 instance of an instanced mesh. Is there anything obviously wrong with my setup here or is this a bigger issue related to #28 ?

https://glitch.com/edit/#!/3dstreet-simple-instanced-mesh

Positioning of children not working as expected

Query:

Positioning of children beneath the parent entity does not work as expected. (For example a parent entity with position="0 30 -60" doesn't seem to move the children instanced mesh entities by the same amount as I would expect normally.) Is this the same issue as "Diverse Frames of Reference" mentioned in the readme? Regarding the performance consideration, maybe it'd be possible to allow initial setting of the position but then not after that for children unless explicitly requested?

Any support for animation-mixer? Env-map not being applied?

Great work on this component!

I've got my glb instanced - standard animations seem to be working, but when I'm setting:

el.setAttribute("animation-mixer", "timeScale: 1; loop: once;");

within a component I'm not getting anything - I can see the 'animation-mixer' component is added to the correct entity, but no animation? I don't think it's classed as a SkinnedMesh as there are no bones - the animation has been baked to keyframes in blender as an action.

I also have an envMap which isn't being applied to the instanced meshes?

Any help/guidance on the above would be greatly appreciated.

PhysX and Cannon limitations with Instancing + Physics

I've been working on instancing compatibility will the various A-Frame physics systems.

Current status is as follows:

Ammo works fine in 2 different modes

Manual fitting, without per-member meshes
Auto fitting, with per-member meshes.

Cannon only works with auto fitting, with per-member meshes.

Cannon manual fitting does not work, because even with manual fitting, Cannon driver code assumes the entity will have a geometry.

PhysX doesn't work at all.

PhysX doesn't currently offer any manual fitting mechanism
PhysX auto-fitting with per-member meshes isn't working yet. Issue is not clear. Part of the issue is with PhysX expecting to find a 'geometry' component. However the PhysX code does appear to fall back to looking directly at the THREE.js geometry on the mesh, so not clear yet why this isn't working, but looks like fixes are needed on the PhysX side.

Create showcase

I'd love to have a page in this repo that showcases projects that have used this component.

In advance of constructing that, I'll keep a list here of projects that I know used instanced-mesh:

Blocks Arcade - https://blocksarcade.xyz/
3D Street - https://www.3dstreet.org/

Instanced Mesh lags a frame behind in auto updateMode

If you enable "debug" mode in the physics examples, you can see that Instanced Mesh rendering lags a frame behind the physics engine's view of the world.

Possible this could be fixed by somehow making sure the instanced-mesh tick() (when we copy entity positions into the insance matrix array) happens afterthe physics tick(), but that might not be enough, and I think we can do better.

I'd like to find a way to move this copy into the render pipeline, after THREE.js has done a full update of all matrices, but before actually doing the rendering. Can probably use techniques similar to [this].(https://github.com/diarmidmackenzie/aframe-multi-camera#add-render-call)

Benefits of this would be 2-fold:

no need to update matrices other than the updates THREE.js already does.
matrix data would always be up-to-date at the point of copying.

Even in manual update mode, we should queue up the upates, and actually perfrom them at this later stage. That would avoaid the need to do additional matrix updates over & above those already done per-frame by THREE.js, so we could also solve #12 at the same time.

Flat shading with custom texture

Hello Diarmid,
Thank you so much for this great addition to A-frame. Resolving draw calls adds so many possibilities to what we can create.

However, it seems using custom textures and normal maps on a mesh first up just doesn't work, and if you force it through a component with Three.js's API, it breaks the lighting of the mesh and becomes flat shaded.

Is this something inherent to the way the instancing component works and is hard to fix or am I just doing something silly? It would mean the world to me if it could work with normal maps. I can provide example code, or anything else you might need help with.

All the best

Performance improvements for manual updates

Been working on auto-update mode & performance.

Remaining perf issue with manual updates - each manual update currently runs updateMatrixWorld() on the parent, and computes the inverse of the parent matrixWorld.

It would improve performance if we could calculate these once for multiple updates. One approach would be to batch mesh member position updates together, and do them in bulk on the tick, as we do with auto updates.

We already have a queuing mechanism for these updates, so not too much work.

Didn't do this as part of the auto-updates / perf work on the basis that we now have auto updates, and can always switch to that update mode if there's so many mesh member transform updates as to cause a performance issue in manual mode.

In other words:

if a use case has few updates, manual update perf shouldn't be a big deal
and if it has lots, then auto updates is probably a better solution anyway...

Not clear at this point that there's any use cases in between that would provide motivation for this fix.

Add support for instanced morph target animations

If this PR gets merged into three.js...
mrdoob/three.js#27616

... I would look at adding support to a-frame instanced-mesh.

Max limit 100

By default, 100 objects can create. how can edit limit?

Frustrum Culling makes bad assumptions about Geometries & hence doesn't work in most cases.

Longstanding problem revealed when I reworked the framed-block component used in tests to not create a new geometry for every instance...

Frustrum Culling logic modifies the bounding sphere on the geometry. This only works if each mesh has a unique geometry, which won't be the case most of the time.

I guess the solution is to clone he geometry when setting Frustrum Culling parameters, so that we have a unique geometry to work with. But worth some investigation into the A-Frame geometry component & system - will this create a problem for subsequent updates to the geometry?

Raycasting + Instanced Mesh

Three.js supports raycasting on anInstanced Mesh as per this example:
https://threejs.org/examples/?q=instancing#webgl_instancing_raycast

It would be great to support raycasting in this component.

Unfortunately that's not completely straightforward and looks like it will require some changes to A-Frame itself, tracked here:
aframevr/aframe#5035

Error hit when deleting blocks in coloring-blocks example

Open the coloring-blocks example, and right click quickly to delete a series of blocks.

In the console it's fairly easy to generate this error:

instanced-mesh.js:793 Member block-5-7-7 not found for modification

Suspect some sort of face condition, but haven't investigated. Could be an issue with the example code, or perhaps an issue with the instanced-mesh code itself.

Upgrading to A-Frame 1.5.0

Mostly works with 1.5.0, but upgrading all the examples has revealed a handful of issues.

color changes in some examples. This is due to previously bugged code, using A-Frame 1.4.2 and colorManagement: true, calls should be made to applyColorCorrection, when using THREE.js Color() directly. This is handled automatically in 1.5.0. Where these calls were missing, the examples were previously showing the "wrong" colors, and are now correct.
physics-ammo.html

Hits error when re-spawning a ball.

ReferenceError: body is not defined

To be investigated under c-frame/aframe-physics-system

updates.html & updates-multi-mesh.html

When mesh capacity is updated, a large instance appears at the origin, and frame rate drops (particularly noticeable with the multi-mesh example).

This requires further investigation.

diarmidmackenzie / instanced-mesh Goto Github PK

instanced-mesh's People

Contributors

Stargazers

Watchers

Forkers

instanced-mesh's Issues

Tests

Examples

Recommend Projects

Recommend Topics

Recommend Org