gryff

Trigger Zones

Recommended Posts

I'm trying to create something I call a Trigger Zone - an area which the Free Camera can enter/exit, and when it does, it triggers an event. In something I'm working on there would be 10-20 of these zones.

 

Now I could create an invisible box and check for collisions - but there would be no way to then enter the area defined by the box.

 

I looked at the idea in Tutorial 10 where the meshes of the balls check for intersection with the planes/point - but will this work with a camera? Is the "elipsoid" - which I assume checks for collisions - an actual mesh that can be used with this kind of code:

if (camera.elipsoid.intersectsMesh(thebox, false)){// trigger event ... with conditions for exit and enter}

Or would I have to attach a a box mesh with the camera as parent?

 

A second question which relates indirectly to this, if you clone meshes, does a change made to one mesh propagate through the clones or do they have to be refreshed in some way?

 

And a final question, can the mouse functionality be disabled on the free camera and replaced by keyboard input?

 

All thoughts welcome - they may even be methods I have not thought - or even know about ;-)

 

If I can figure this out  - hopefully I can post my first simple game.

 

cheers, gryff :)

 

PS @Wingnut possible tutorials here - scene interactivity? ;-)




			
		

Share this post


Link to post
Share on other sites

About your second question, cloned meshes share vertex buffer (positions, normals, indices...), so yes if you modify a vertex, the change will be made for clones and for the source but if you modify the transform (position, rotation, scaling) or the parent of the mesh, nothing will be propagated for clones.

Share this post


Link to post
Share on other sites
but if you modify the transform (position, rotation, scaling) or the parent of the mesh, nothing will be propagated for clones.

 

 

Actually rather like how meshes behaved in VRML.

 

What about materials and textures do they propagate too - or can they be varied?

 

That is a good start gwenael TY.

 

cheers gryff :)

Share this post


Link to post
Share on other sites
// Clone    BABYLON.Mesh.prototype.clone = function (name, newParent, doNotCloneChildren) {        var result = new BABYLON.Mesh(name, this._scene);        // Buffers        result._vertexBuffers = this._vertexBuffers;        for (var kind in result._vertexBuffers) {            result._vertexBuffers[kind]._buffer.references++;        }        result._indexBuffer = this._indexBuffer;        this._indexBuffer.references++;        // Deep copy        BABYLON.Tools.DeepCopy(this, result, ["name", "material", "skeleton"], ["_indices", "_totalVertices"]);        // Bounding info        var extend = BABYLON.Tools.ExtractMinAndMax(this.getVerticesData(BABYLON.VertexBuffer.PositionKind), 0, this._totalVertices);        result._boundingInfo = new BABYLON.BoundingInfo(extend.minimum, extend.maximum);        // Material        result.material = this.material;        // Parent        if (newParent) {            result.parent = newParent;        }        if (!doNotCloneChildren) {            // Children            for (var index = 0; index < this._scene.meshes.length; index++) {                var mesh = this._scene.meshes[index];                if (mesh.parent == this) {                    mesh.clone(mesh.name, result);                }            }        }        // Particles        for (var index = 0; index < this._scene.particleSystems.length; index++) {            var system = this._scene.particleSystems[index];            if (system.emitter == this) {                system.clone(system.name, result);            }        }        result.computeWorldMatrix(true);        return result;    };

* vertex buffers are shared: positions, normals, uvs, uv2s, colors, matricesIndices and matricesWeights

* index buffer is shared

* bounding info is not shared since the transform is not shared

* material is shared

* parent is shared

* particles are cloned

Share this post


Link to post
Share on other sites

Thanks for the feedback gwenael :)  Everytime you post something, I want to experiment with the code!

 

I've actually started cloning objects - just simple stuff - as part of testing out my first question for moving the camera into meshes and checking for "intersectsMesh".

 

Hopefully, I can post a cleaned up version of my code by the weekend with a live example.

 

cheers, gryff :)

Share this post


Link to post
Share on other sites

Hi Gryff! 

 

Umm, a box never stopped a camera.  (okay, yes, but only sometimes).  This isn't real life... we can walk through walls here in 3D land.  Keep in mind that just because a box 'sensed' a collision with a camera, does not mean you need to do a 'collision reaction'.  I'm not sure this would work, but, put your box around a zone, set its visibility to low for testing, and to zero later.  Check for collision with camera, but the only 'reaction' is 'camera has entered zone'-flag/trigger.  Let the player walk/fly right through the wall of the invisible zone box.

 

Knowing if/when they are STILL in the zone, or if/when they left the zone... that's a whole other challenge... but a fun one.  :)

 

In a way, this is similar to a spacecraft sensor... that looks for black holes.  The black hole is invisible... but you want your spacecraft short-range sensors to 'detect' the black hole.  So, you put a semi-large invisible sphere around the black hole, and watch it for ship-to-sphere collisions/intersections.  When there is one, the spacecraft computer announces "bvrrt, bvrrt, bvrrt, WARNING!  BLACK HOLE DETECTED!"  :)

 

Just some ideas.  I do not guarantee them to be sane ideas.  :)

 

A little hint.  Keep your invisible zone-boxes close together.  If a user enters a different zone, that's a pretty good indication that they are no longer in any of the previous zones.  I have a feeling that you are using these "proximity sensors" to start/stop "the show" in these zones... as in... animations.  Although complicated and old, take a sniff at http://webpages.charter.net/wingthing/html/test/jackal/jackal56.htm .  It uses lots of 'motor' objects, and a servicer (timecop), and runs on the window timer.  Use tighter code than mine, though. :) But feel free to perma-borrow anything you find in that monster.  Pay particularly close attention to 'register' and 'unregister', and how the animation motors are fire'n'forget.  You will want to 'register' an animation motor and have it 'serviced' by the scene render loop.  Each time the render loop does a canvas paint, the motor is 'stepped' one step.  You might want to read about Javascript (fake) 'threading', and some new REAL threading devices called 'web workers'.  You don't want to load-down the render-loop... so you want your animation motor to move one-step per frame draw, and you want the motor to remember its 'state' until the next time it is called. 

 

I didn't mean to talk so much about animating, but, what the hell.  You might want to look at http://urbanproductions.com/webGL/zz-UP_Test09.html .  Try its 'open all' and 'close all' buttons.  This is a threeJS scene, but the principles are the same for BJS, so take a look at its source.  It might give you some ideas of how to keep an animation from bogging the render loop.  The updateIris func is called once per frame.  If the isOpening and isClosing flags are both false, no need to do any servicing... return. 

 

If isOpening or isClosing is true, we call funcs like tryOpenMore and tryCloseMore.  In both of those funcs, the first thing that's done is check IF the shutter blades are fully opened or closed.  If so, set the global flags to indicate so, and leave.  If further servicing is needed, they do the servicing (open more or close more) as fast as possible, and leave.  Next frame draw, updateIris is called again, checks flags, and services the animation as needed.  *shrug*. 

 

By the way, babylon.js has handy tools such as BABYLON.Animation... that can make animating a much simpler task.  See https://github.com/BabylonJS/Babylon.js/wiki/07-Animation .  You knew this already, didn't you?  I'm still learning it.

 

Good luck.  I can 'feel' the 'mad scientist' in you.  :)

Share this post


Link to post
Share on other sites

Well as promised I have posted a babylon scene which demonstrates the functionality that I'm looking for - a the detection of a camera as it enters and exits a specific mesh.

 

First thought let me describe what you are looking at. A basic scene with 4 walls and a floor (I used "mesh.clone" to create the walls). Inside the walls are five cubes - 4 large semi-transparent green boxes and a small blue box in wire frame mode. All these five boxes have "checkCollisions" set to false.

 

The blue box is the parent of the large green box to the directly to its right as you enter the scene. If you enter this parented green box then the blue box is set to face display and the blue box "checkCollisions" set to true. It is a test of whether "checkCollisions" get propagated from the parent to children.

 

I have parented a small box to the camera - the "camsensor" - which is used to check whether the camera has entered the mesh of a green box.

 

The green boxes I describe as "gates" in the output boxes at the top - it will give you some feed back about the camera entry and exit .

 

So try it at :  Zones test

 

 

The scene creation is nothing special,  the driving force behind the checking of the interaction of the camsensor and the green boxes is this section of code:

   //Mesh Interaction check    scene.registerBeforeRender(function () {                for (i=0; i<4; i++){            var currGate = scene.getMeshByID(thegates[i]);                        //camSensor collision -- Precise = false            if (camSensor.intersectsMesh(currGate, false)  && currGate.isEnabled()) {                                if(currGate.name == thegates[0])                {                    divOutput.innerHTML = "You touched " + thegates[0];                    divOutput2.innerHTML = "Last Gate= " + thegates[0];                    control = scene.getMeshByID("controlbox");                    control.checkCollisions = true;                    control.material.wireframe =false;                }                else {                    divOutput.innerHTML = "You touched " + thegates[i];                    divOutput2.innerHTML = "Last Gate= " + thegates[i];                }                break;            }            else {                divOutput.innerHTML = "No sensor touched";            }                }            });

Basically, the script is checking if the camera has entered a mesh with a specific name - it loops through the 4 names that are stored in a variable "thegates"

 

If it finds an intersection with a specified gate it reacts accordingly .

 

While I was cleaning up the code, it came to me that there maybe another way (as I'm not keen on the "for loop" and am looking at 20+ potential gates). Rather than check if the camsensor has entered a mesh - have the green box check if it has interacted with the camera. I'm thinking about a possible prototype box that has extended functionality - a cameraEnter/Exit function.  My javascript ability dates back to the late 90s with no knowledge of prototypes so any suggestions and help appreciated.

 

cheers, gryff :)

 

PS: Run through the green box parented to the blue box (you will see the change in the blue box) - now go back to its child - try to run through it again - was the "checkCollisions" propagated to the child?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.