Intersecting Sub Meshes?

[JohnK]

For my project I form a model from a number of meshes (which may not be adjoining) by assigning them the same parent and forming a bounding container around them. I then check to see if two different models are in contact by first using intersectsMesh on the two bounding containers and if true checking to see if any of the meshes from model A are in contact with any of the meshes from model B and only in this case putting contact of models to be true.

 

Would this be possible be merging the meshes to form a model instead and if so would it be any more efficient..

 

A playground example is here http://www.babylonjs-playground.com/#1XNAP4#1

 

When box1, box2 and box3 are merged into box and cube1, cube2 and cube3 into cube it appears I lose access to the original meshes.

 

What I would like to do is when cube intersects with box I want to check if boxes 1, 2 or 3 are in contact with any of cubes 1, 2 or 3.

 

In the case of

cube.position = new BABYLON.Vector3(-9, 3, 0);

I need a function that returns false

 

and in the case of

cube.position = new BABYLON.Vector3(-12, 3, 0);

the function should return true.

[Wingnut]

Hi John!  I just have a few thoughts, nothing wonderful.  As best I understand merged meshes... you don't lose COMPLETE access to merged meshes.  You still have access to each box's vertexData.  The vertexData(positionKind) for the resulting BOX mesh (the master mesh)... SHOULD contain 24 vertices... 8 for each sub-box.  So, you can still rotate, translate, and carefully scale... each sub-box.... by using something like transformCoordinates() or addInPlace().

So, yes, you lose access in one way, but you still have SOME access.  You'll need to make sure you set box and cube updatable = true... so that the engine knows to use a DynamicVertexBuffer instead of a static VBO.   Sprites and particles are done like this, I believe.  Each particle in our particleSystem is part of a single mesh.  Each are drawn in such a way as to make them appear to be many separate quads/planes. 

It's one mesh, but its parts are not all connected together with indices.  You see how well our particles fly... appearing well-separated from each other.

https://github.com/BabylonJS/Babylon.js/blob/master/src/Particles/babylon.particleSystem.js#L86

That is the "iterate thru the particles array" area... with the actual particle-moving section starting at line 96.

Let's take a quick look at "particle".  https://github.com/BabylonJS/Babylon.js/blob/master/src/Particles/babylon.particle.js 

Fascinating, eh?  It's not a mesh, it's an object "structure"?  Your box1, box2, and box3 could be similar. 

Are you starting to see something cool, here?  *nod*  This method of mesh-wrangling is the reason why our particleSystem can have SO MANY quads moving at the same time, and still maintain high-performance.

So, you see, you might want to invent a NEW method of adding, removing, rotating, positioning, and scaling your sub-boxes.  You might want to do each.... by adding, removing, and transforming/addInPlace groups of 8 vertices (boxes)... to/from the MASTER mesh's dynamicVBO.  You could have 1000 boxes in the scene, and they are all part of a single master mesh.  And that means... FAST! 

I suggest that you totally get to know our particleSystem.  There's many playgrounds available where folks have "hijacked" the entire particle system into a playground... here's one... http://playground.babylonjs.com/#1UNX9H  Unfortunately, it doesn't work anymore... framework changes caused my hijacking to go stale.  (somebody fix at will, thx)  Notice the heavily-modified update function at line 128... most of the addInPlace() funcs for flying the particles... are disabled.  This scene (when working) placed stationary particles on the ground around the knot... to simulate ground fog.

You can still get the idea.  Take a moment to get to know the particleSystem, and it MIGHT lead you to a new way of dealing-with sub-boxes... something that could deliver super performance.

Start off by pretending "particleSystem" and "this"  ==  AllJohnsBoxes.  Pretend "particle" == oneJohnBox.  Let that soak-in. 

Can you imagine all the extra fun that you can have... knowing that all your boxes are really particles?  Drop them from the sky into their positions, blow them up in all directions, slide them into the scene from the side, spin them around axes, all sorts of fun things.  You will have the performance you need... to do those fancy things... IF you build your project based around the tech found in our ParticleSystem.

I'm not sure HOW MUCH this idea differs from other subMeshing methods.  I once had some time to study our particleSystem.  I found it fascinating and full of learning, and I fell in love with it.  (I fall in love with nearly anything - plight of the lonely)    I think you will, too, and I think you will be able to apply its tech and speeds... to your project. 

Good luck, keep us posted.  Surely, others will have more comments (better ones), and maybe correct the wrong things that I've likely said here. 

[Wingnut]

Oooookay, I just thought about something.  You might have folks sliding boxes around with controllers and keypresses... and therefore... that is why you are concerned with intersects and overlaps... which I did not address in my previous post.

Yuh yuh yuh...  see the brain tumor that grew out of the middle of my forehead, just now?  Yep... John's new .makeSureNotOverlapping() function caused that .  heh   Yep, when treating subMeshes as if they were separate mesh (geometries?)...  then... hmmm... you are going to need quite a fancy Al Gore Rithm ... to make sure your geometries (subMeshes in the dynamicVBO)... are not overlapping... and not allowed to do so.  Phew.

Yeah, it can be done.  I'm glad it's YOU coding it, and not me.  hah

But... maybe... hmm... maybe we should ask one of the Gods to write some special framework code that can help with this.  You will need to be updating VBO positionKind data WHILE a mouse drag is happening... and WHILE constantly checking for overlapping and preventing it (stopping the mouse drag when the result of the move would cause overlap).  Wow.  Coooooooooool.  (Wingy rubs his new brain tumor, and makes a grunting noise). 

But I have an idea.  When PLACING a box... the user is dragging a standard babylon box... and thus we can check for intersects and proper "butting" more easily.  Then, when the user releases the mouse button (finishes the drag), then delete the standard box, and add 8 vertices to the VBO buffer (and add needed indices to define the box shape) and update both vertexData arrays.  (permanentize the box)

Speaking-of the indicesKind data that needs to travel with those 8-packs of positionKind data for each subBox... THOSE indices determine the separation lines of each box in the master vbo box.  In simpler words... you can choose whether to SHOW or HIDE the lines between the boxes of a wall of boxes. 

If a user had a pyramid of stacked boxes... you would likely use IndicesKind adjustments... to allow user to see the subBox lines, or not.  Maybe the subBox lines would only be turn-on when in EDIT MODE.  *shrug*   Seams on/off. 

I suppose you want to let the users select permanentized boxes that are part of the master vbo, too, eh?  That would require the opposite actions...  removing 8 vertices (and their indicesKind data) from the dvbo.  Ow! 

Captain John's Super Sonic Box Stacker v1.0... look out!

You're going to need "snap", too.  That won't be easy... using a dynamicVBO.  Got balls?    (John says "NO, I GOT BOXES!")

A snap algorithm based-on vbo geometry overlaps.  Oh my goodness.  I sure hope I don't have to code that.  Maybe you should stay-with using standard boxes and bail from my goofy dvbo idea.    Maybe you should completely ignore everything I have said today.  heh

[JohnK]

Really enjoy reading your posts Wingnut. So far I will stick with my method it does work after all. I select my models with the mouse and move them with keys. Have you had a play with Cubees yet or the Lathe? Would like to know what you think.

[Wingnut]

Yes I have, and they are well done and fascinating.  Nice work.  Sorry, I forgot that you were using these cube shapes as "holders" for other shapes.  Somewhere I got the idea that it was all boxes and no shapes IN those boxes... and so my previous posts don't perfectly apply to your project.  Sorry about that.  But you should know that Jerome and Jahow? were recently able to addMeshShape() to the SPS particle system... and that... would work for you, though quite a drastic modification from your current way. 

 

I wouldn't mind seeing a Cubee scene with LOTS of shapes... to see how the performance holds-up.  I'm not sure if using SPS would gain you any performance.  Maybe.  All in all, somebody would need to build a HUGE Cubee scene to see if performance is an issue at all.  Can you programmatically fill a scene with Cubees... maybe... 500 of 'em, and let us browse it?  It doesn't have to look pretty.  We just need a "load"... to test-with, on various machines.

 

I also think the rotation commands should be on keypresses and buttons on the main screen, and not require choosing selection menu.  Maybe SHIFTED cursor keys and shifted <> for rotating a Cubee (in 90 degree steps, of course).  *shrug*  No biggie, of course. 

 

I don't see many/any issues at all... with your project.  It just plain looks good and works good.  Shall we talk about child attention spans. 

 

I see a potential "line of patience" that could be a concern.  Real young children will need to be TOLD that those shapes are trees and chairs and houses... because... they see real trees and chairs and houses... in real life.  They are sure to ask "Why doesn't it look like a tree?".  For us almost-adults, we see that it is a tree, because of its general shape.  But kids might not be so understanding.  I suspect an average USA child would throw a temper tantrum until mom bought them a real tree.  hehe. 

 

I have a feeling that they will, instead, boot dad's SpinTires game and use the same cursor keys as mom/dad... to spin trucks around in the mud and go crashing through the woods, crushing trees and climbing rocks.  I think children quickly become bored and impatient... and will be drawn-away to more exciting things.

 

Hey, you wanted my opinion.    I think it's coded great, and it functions perfectly.  And, it's an excellent idea! 

 

I think it would be wise to eventually have gamepad controller options, and it might be cool if you attached a "periodic funny thing" side-function... based on delta time.  Even if a child is not building, they MIGHT stay around longer if they are watching for the next fun/goofy thing happening.  I'd say build a character... a buddy for the children...  Captain Cubee.  Sometimes he runs thru a scene or construction room, waving.  Sometimes he flies past... waving... his cape fluttering in the wind.  Sometimes he walks out onto the screen and start talking in gibberish, then waves and walks-off... or cartwheels-off.   

 

Another area to exploit... is children's love of pets.  If you can build animations of cats, birds, hamsters, dogs and rabbits... even flat animated gifs on planes that can be put into dog houses, doll houses, rabbit cages, or just visit the scene from time to time, that would make the kids be entertained as they construct.  Those features could be turned-off, of course, and these types of things can be added later. 

 

Don't let me adjust your objectives, though.  If you have a plan (you obviously do), and if you see a user base, then you are perfectly on-target.   You seem to have everything needed to be a great tool/game writer... smart, creative, innovative, nice guy, and you are certainly putting your ideas into action.  I enjoy your BJS work... in all areas, and I really like reading your posts, too.  You rock, John!  I really like hanging around with you, and I'm glad you're with us.  Don't ever leave, ok?    Party on!

[JohnK]

You are right about having the rotations on the main page, at some stage I'll do something about it. Wasn't really thinking about children that young but the teacher in me goes - fun what fun get on with your learning. However you could well be correct on the level of concentration. Perhaps I could take it further so that having put together the models into a scene they could make a simple game with it.