Creating Multiple meshes from ribbon

[TheDude]

Also only works for your alphabet heightmap

[Wingnut]

Yeah, I need to get back to work on this, try to fig why the top/bottom seams suck so bad. 

I like your scaling kludge-fix... it made me smile at your inventiveness.  But, you know, it was a workaround for a bigger unsolved issue. 

I'm going to stare at the code for a while... do some more on-screen extra canvases... see if I can find out what I screwed up.

Sorry for the delay on this.  I hope you are cool with me "camping" this project, somewhat.  I got a tent, a week's worth of food, plenty of TP... I'm ready to kick this thing's butt, once and for all.  It might take a month, though.    Nah.  I hope not.

Done any tests on your end, TD?   I hope you aren't losing too much enthusiasm.  I'm still excited... but somewhat stumped.  There is really no reason why the north/south seams should be as far off as they are.  Yet, they are. 

I can find this.  I might need 16 canvas elements placed on the screen, but I'll find the reason.  I will.  Have an ambulance standing-by just in case, though, okay?  heh.

Correction:  I mentioned before that my control-leftbuttondrag (for arc-cam dolly left/right and ped up/down) ... wasn't working.  I was wrong.  It is working, but on that 12500-per-tile thing... it barely moves.  Now, let's see... its called panning on the camera object, because there is a ._useCtrlForPanning Boolean prop on our camera.  Probably should be named ._useCtrlForDollying... but it's all cool. 

I REALLY need to find... .panningSensibility and crank-up that value.  Let's see, where did I put that property?  It's on this camera object SOMEWHERE... maybe. 

Update:  Yay, I see the problem that idiot Wingnut did.  Look carefully at http://playground.babylonjs.com/#21TQJT#18

The rows are in the wrong order!  The problem is in the tile positioning code... lines 172 and 173!  DUH, Wingy.  As we look from the camera, row 4 should be row1, row 3 should be 2, row 2 should be 3, and row 1 should be 4.  The rows are exactly backwards from what they should be.

And... boom!  http://playground.babylonjs.com/#21TQJT#20

A little sign adjusting in lines 145 & 146 (positioning offsets)... and in lines 174 & 175 (positioner code)... and everything is a-ok!

I even put the if/thens into lines 151/152.  Notice in lines 139/140... I have set xSpan/ySpan to 256?  Yet we see no "thick" top and right rows?  Yep, by shortening the top row tiles and right column tiles... by one pixel... we don't run out of image to sample.  Yay! 

ALL other tiles (not in top row and not in right column)... are actually 257 wide... going one row of vertices long.  And that row of vertices... should be an exact copy of the FIRST row of vertices in the attaching (adjacent) tile!  And we all know what it means when last row of vertices... matches first row of vertices on the next tile, right?  NO SEAM!  YAY!  (Wingy dances around like an idiot... but is actually afraid to carefully check if the seams are perfect. He's saving that for later.  Now, it's Miller Time!)   

Ok, ok, here's a tiled Norway, first, with exaggerated height. http://playground.babylonjs.com/#21TQJT#21  Fun!!!   @gryff showed us a website, recently, where we can get a heightMap for anywhere in the world.  I'm thinkin' Devil's Tower, Wyoming. 

[TheDude]

@Wingnut That's great that you got it working. I'll continue work on the other parts of what could be included in this system, like picking one of the terrains. Maybe this could be called CreateChunksFromHeightmap? And I would imagine that this function create the heightmaps itself and have a parameter for removing loading chunks as you arrived at it's position kind of like my early demo. Still,never saw someone do this in so short a time considering the large topics I see around here on the subject.

[TheDude]

@Wingnut, sorry to burst your excitement but after checking a bit the y seams are not perfect only 99% perfect. This is good but still a little bit off. 

[Wingnut]

Ok, thanks for checking.  We're close.  Still off by one, somewhere... I guess.  hmm.  Darn.  All my 256's need to change to 255's, and all my 255's need to change to 254?  err... darn.

In the line 135 area...

cellStart.x = col*(xSpan);
cellStart.y = row*(ySpan);
cellEnd.x = (col+1)*(xSpan);
cellEnd.y = (row+1)*(ySpan);

It used to look like this...

cellStart.x = col*(xSpan+1);
cellStart.y = row*(ySpan+1);
cellEnd.x = (col+1)*(xSpan+1);
cellEnd.y = (row+1)*(ySpan+1);

(all the xSpan and ySpan had that +1 on them)

I don't know why I put them in there, originally.  Maybe I was trying to do the far-reach thing... go one pixel-row wider/taller at the end of certain tiles... so the ending edge would be a copy of the beginning edge of the mating tile. 

Not sure if I screwed something up when I removed those, or not.  I'll let you fiddle.  I have faith that you are going to find the off-by-one... for us. 

But we invite everyone to test and troubleshoot... PLEASE.    I still think our modified MeshBuilder.CreateGroundFromHeightMap (before line 90) is good.  I think the issue is within the createScene area.  It's weird.  256-wide sub-images (chunks, as you call them), each 0-255 actual pixel locations... erf.  I'm off-by-one in the brain!   Going goofy.

C'mon TD, gun this down for us... and make us a LOW rez playground to play-with, and to easily view seams.    I'll attack it again tomorrow.  It HAS TO BE an off-by-one error, somewhere.  Easy fix.  (erf). 

[Wingnut]

http://playground.babylonjs.com/#21TQJT#24

Changed image, lowered tile size, dropped subdivs, changed lots of hard-coded numbers into variables, over-layed a wireframe, etc.  Control-drag around out there.  Man, it is SO CLOSE to perfect... but... hmm.  *sigh* 

I'm gonna go beat my dog for awhile... maybe that will help. 

[gryff]

9 hours ago, Wingnut said:

@gryff showed us a website, recently, where we can get a heightMap for anywhere in the world. 

@Wingnut : Not sure how I got mentioned in this thread as it looks like a super coders thread. And I don't claim to be one of those geniuses

However, here is the website: Terrain Maps

cheers, gryff

 

[Wingnut]

Thank Gryff.

   TD, I have another idea... regarding closing the seams.  Remember how I had to adjust the positioning of the rows and stuff, changing the signs on one of the offsets?  The rows were out of order.

Just maybe... instead of going one row of pixels LONG on the edges of certain tiles, I start one row of pixels "early".  To word it simply... instead of ending the top and right sides of each tile... with a copy of the first row on the bottom and left side of mating tiles, maybe I need to START each tile with a copy of the LAST row of tiles below/left. 

Perhaps, put the extra row of pixels on the beginning edge of mated tiles, not on the end.   (okay, okay, that wasn't worded simply)

Let's illustrate, using "selective labeling" taught to me by Deltakosh.  http://playground.babylonjs.com/#21TQJT#25

MOST of the time that I have worked this challenge, I was thinking that tile 0-0 was on the bottom left.  But since the tile re-positioning, we can see that tile 0-0 is in the UPPER left. 

Images start in the bottom left corner, but our ground is like a webpage... with tiles starting at the top left.  So really, wherever I did "one extra top row"... I should have been doing one extra bottom row.  In other words... start one row early.  Tile 0-0 still needs to go one row of pixels taller, but on its bottom edge, not it's top edge.

So, hope is still alive.  I have a good feeling about this.  I'll try some experiments soon.

[Wingnut]

Ok, here's another attempt...  http://playground.babylonjs.com/#21TQJT#29

Close the gaps @ line 152.  Turn off the wire frame at line 212.

Let's look.

http://playground.babylonjs.com/#21TQJT#30

Yep, we can still see the tile intersections.  BUT... is this a lighting anomaly?  I think so!  (but I've been wrong SO many times... in this thread, eh?)

I don't think there are any height problems at the seams.  (but I have said that before, eh?)

I am sending out a forum-wide APB  (all points bulletin).  HELP!    Please!  Anyone!  heh.  I wrote 'help' in bold so it would be louder and more desperate-sounding. 

In PG #30, see the ground.convertToFlatShadedMesh() at line 190?  Boy, does THAT fail nicely.  I think I know why.      console.log(ground.getVerticesData(BABYLON.VertexBuffer.NormalKind)) returns null.  These tiles seem to have NO normals... which means... we need to add some.... somehow.  I didn't know a mesh could be lit or rendered at all... without normals.  hmm.

[adam]

Here is what the normals look like.

http://playground.babylonjs.com/#21TQJT#31

[Wingnut]

Wow, thanks @adam !  Nicely done!  Now let's see what can be learned (like Wingnut learning to fetch mesh normals, eh?)    I must have been checking for normals before the mesh completed rendering.  Yep... I should have figged that.

I think... once we get the normals identical on each side of every seam, the discoloration at seam lines... will disappear.  I sure hope so.  I need a vacation from this topic. 

@adam, did you have any comments on what you see?  Have any thoughts about "averaging" each pair of cross-seam normals, and then setting both sides to that new value?  (thx)  A little sewing, to keep photons from falling to their death in the crevices?

Thx again for the normals viewer.  That tells a BUNCH.

[TheDude]

@Wingnut Wow. Well it seems that you are in the path to sorting it out. Funny how it went from me asking  for help to you asking for help. I guess I'll make a mesh function to include this code and add the ability to pick this terrain/use actions and add chunking.

[adam]

@Wingnut Averaging the shared edge normals sounds like a good solution.  I'll give it a shot some time in the next few days if someone hasn't already done it.

[Wingnut]

Thanks @adam  (and anyone else who tries/does it)  Yeah, at each 4-tile corner intersection, 4 normals need getting, averaging-together, and re-setting.  Nice.  I think this needs yet another nested (double) for-loop.  Cool.  Scary.  My dog just started whining.  heh  And and and... what if... the grounds get convertToFlatShadedMesh()?  (seemingly broken)  Vertices nearly triple, and so do the normals!  Omg!  (My dog just passed-out)

@TheDude... actually it went from me asking for help, to you asking for help, to me asking for help again.    I tried doing this once before (about 6 months ago), but using the createTiledGround system instead.  I begged Jerome to help me fig it, but he wouldn't bite.    But then you and I went wandering around on the context2D pages, and you talked about putImageData, and I went and looked at it, and then I saw the dirty rectangle thing... and then I went searching to see how others were using it, and found the cropping page... and and and and...  well... it's just a mess of teamwork. 

Really, I just "bent" your thread away- from ribbons and toward grounds, and then we both were "in-over-our-heads".  heh.  But we are in the general vicinity of success, now.  Yay!

Do you agree that our edges are lining-up, now, and we only have color-at-seam issues?  You have good eyes... for seam checking.  I did some control-dragging around on the seams.... and I think they look pretty good, other than the discoloration.

As far as "what the hell is this thing?", that modified MeshBuilder.CreateGroundFromHeightMap is the primary piece... with its 2 new params. 

Step #1 would be to clean-up and make that method very efficient.  Then... we'll talk to Jerome and Deltakosh and other big dogs... see if it can be tightened even more than what you and I (and maybe Adam) can do.  (Adam is a hot coder... he's cool!  Hot and cool at the same time.) 

Then into Typescript, tighten more, and see if we can get a Github pull request (PR) approved by the core Gods.  AFTER that gets approved, IF it does... then we can look-into some helper funcs that might help us use this new "feature".  But I don't think there is much we can do (integrating it into the core framework) with the other code.  It's "user code"... but others will surely copy it, and we could defintely use it for a demo playground in a new Tiled Ground and/or Context2D tutorial.

TD, do you know anything about subMesh?  I know little, but maybe we could do this thing more efficiently (our code, not necessarily the modified MeshBuilder.CreateGroundFromHeightMap).  For now, perhaps you can use the code as it is... in your project (after we sew-up the normals). 

If you do the Typescript modification and the Github PR, you'll get your "I Contributed to BJS Core" merit badge.  Yay!   

Actually, you already got it, just because your post sent us down this trail of exploration and discoveries. 

But, in general, try not to be in a hurry to name this thing.  Also, "chunk" is not a "proper word" for programming frameworks (imho). 

But then again, someone put the .mode property on cameras, and that's just as informative (not at all) as "chunk" is. 

The most important thing... get TD the stuff he needs to do his project(s). 

Our modified MeshBuilder.CreateGroundFromHeightMap has a lot of extra crap in it - all that cropping code.  It needs cleaning, perhaps.  We have a few tests to run, too... such as non-power-of-2 images, various x-by-y configs, and possibly some error reporting from context2d about things that might go wrong.

Possibly, MeshBuilder.CreateGroundFromHeightMap will need a brand new helper...  maybe bufferImage(url, start, stop, invert)... "wrapping" that Context2d "dirty rectangle" feature into a function that can be used for MANY things (such as dynamicTexture). 

Maybe bufferImage() is the first of many "tools" that we put on Babylon.Tools.Context2D class.  Perhaps another tool method might be putImage() or putBuffer()... all these functions allowing "subImage" (the dirty rectangle) (the image chunk).  This could be the start of some really nice Context2D tools, and they could also work with Canvas2D, our new canvas layer feature.  These tools could also affect the future of sprites and animations on mesh faces. 

Context2D tools could also help us draw our own images... with JS/SVG.  Context2D is a DOM thing (document object model, part of HTML spec), not a BJS/webGL thing.  So, it could be part of an even bigger package... Babylon.Tools.DOM.  Wow!

You and I and others could be developing these things for the next 10 years!  Who knows?  Maybe your DOMtools package... becomes famous and is used by MANY frameworks, not only BJS... and you might have to go on talk shows and lecture tours, and move into a mansion.    This could be big big big!  heh.  (oh no, eh?)

[Wingnut]

Hi again guys.  http://playground.babylonjs.com/#21TQJT#35

I put an empty .subMeshes array on each ground-tile, so the convertToFlatShadedMesh() works again.  Then I sent a bunch of before/after length-of-normals-array values... to console.  I think it takes 4 directional lights to light this properly... so I added all 4... and tried to set their directions wisely.

Because of my professional lighting prowess (yeeeah, right)... the no-gap version looks... somewhat seamless. 

Each tile is 867 verts (and normals) before conversion, 4608 after.  5.3 times larger!  woah.  That seems too much, but I know little about the conversion algo.

So, for now, we'll hope... that at a basic edge-point... there are (no more than...) 3 verts.  But there may be 4.  The original vert/normal... might have been repeated.  (explaining the > triple vert-count increase).  We can't see the repeat-of-original verts/normals in the scene, because their normal lines are laid precisely atop the original.

If there ARE four verts where one vert previously was positioned, then there will be 16 verts/normals to process at every 4-way intersection.  Let's look at a scenario.  Let's pretend we are about to process the first (original) vert (of maybe 4 total) found at the southeast corner position of tile 0x0.  We need to find the ORIGINAL corner-verts that are on the tiles east, southeast, and south of this point, average all 4 together, and put them back.

Later in the iteration, we do the same with the first ADDED vert/normal at that location, and average it with the first ADDED point at the other three corners.  Then later in the iteration, we'll hit the second added vert, and average it with the second added verts on the other three corners.  Then the third added verts/normals... and pray like hell there's not a FOURTH added vert there.    OUCH!

All in all, if we expect our normals "sewing machine" to work on flat shaded grounds... um... we are going to get some fresh tumors... designing it.    Pseudo:

- retrieve a point along a mated edge
- retrieve its cross-seam mate ( but... how do we determine which vert/normal... of the possible FOUR verts positioned there... is the correct mate?  erf! )
- do the averaging
- stow/write the new averaged-normals values... somewhere
- rinse/repeat... way too many times.

I guess the other option would be... make sure you run the sewing machine FIRST, and later (as wanted)... do the conversion to flat shaded.  I think that would be wiser than trying to build a post-conversion-ready sewing machine.  erf. 

[Wingnut]

Status:  For those following-along at home, I started working on some pieces of the normals sewing machine.  To quickly re-brief... when we remove the gaps between the tiles, we have good heightMap seam-less-ness, but we noticed that the NORMALS for verts on ONE seam mate... don't match the normals for the matching vert on the other side of the seam.  SO, we have lighting discolorations at the seams (when gaps are removed - see line 277). 

We (I) seek to grab the normal at each point along the seam, reach across the seam and grab the mating-vert's normal, average their values together, and put them both back.  This should remove the lighting discoloration at the seams. 

At each 4-way corner of tiles, FOUR normals will be average together and written back to the mesh geometry... instead of just two.  This is an important point (ar ar ar)... .because we could accidentally do repeat/incomplete averaging of 4-way corner normals.  The normals at each 4-way might need temp storage, then let the X seams get averaged, then the Z seams get averaged, and THEN average the temp-stowed 4-pack of corner normals... and put them back... overwriting any normals-adjusting that the X and Z along-the-entire-seam sewings... previously did.  Wow, huh?

Was that a "quick re-brief"?  Erf! 

Ok, moving on.

http://playground.babylonjs.com/#21TQJT#40

Lines 19-78... 5 funcs added. 

4 get-edge-verts funcs (one-each for +z, -z, +x, -x edges) and 1 putMarker(here) func.

Only the -z edge-verts-getter... (getNZEdgeVerts)... is currently in-dev.  The other 3 getters are completely wrong (using xspan and yspan instead of subdivs - dummy wingy).

So, getNZEdgeVerts() is where the current work is happening (lines 55-67) and you can see it called in line 360.  I am trying to "get" a subdivs+1 length array... from the bottom edge (negZ) of tile hm_0x0.  Currently, subDivs on hm_0x0 is 16, so I need to gather 17 vert positions.

Console says I have 17... but the little red marker boxes that I am using for sanity checking... say I am still broken, both programmatically and mentally.    They are positioned all over the place!  They SHOULD be creating a pretty line of red marker boxes along the bottom edge of tile hm_0x0.  hmm.  More dev ahead.   They need to be offset... the amount that hm_0x0 is translated from scene origin.... at minimum.  But there's more wrong with them than lack of positional offset.    They (the red markers) should STILL be in a straight line X/Z -wise.

Even if Adam or others need to help us complete this... later, having these 4 tileEdgeGetter funcs... (possibly later consolidated into a single func)... will be a big assistance to them.  Now, where's that damned dog of mine? 

Minor update:  http://playground.babylonjs.com/#21TQJT#43  "redrod!  redrod!"  (and some bluerods too)  Success!  (for this baby-step)    -z edge verts of hm_0x0 (red rods) and +z edge verts of hm_1x0 (the tile below it) gathered!  SO, my NZ and PZ funcs are working!  YAY!  Mind you, I have only gathered the vertices along both seams, not the normals FOR those vertices, yet.  But, it's progress!  Mini-party!

[Wingnut]

Aw heck, let's start a fresh ramble.  That last one is getting big.  

http://playground.babylonjs.com/#21TQJT#44

I'm very proud of that.  Indexing into arrays is not my strong point.  But, I did it!  Wowzers, Penny!  (Wingy sings a little ditty and performs a little soft-shoe dance.)

Ok, enough with the self-petting.  All 4 of those GetEdgeVerts funcs are working (lines 19-71), and I've used them to gather four 17-vert arrays of positions... and marked them with the rods.  -z red, +z blue, +x pink, -x yellow.  Purrrrrdy.

Next, 4 "setter" funcs.  These would be... for putting-back averaged normals... into a local myNormals array... preparing for the final vertexData.setVertices(normalsKind) (on both mated tiles at each seam).  I wonder... if I run a getter function BACKWARDS... ahh never mind. 

I'm talking to myself, aren't I?  *nod*.  That means I'm scared.    Butt hay (not very tasty to horses), things have gone pretty well so far.  Esp true, considering Wingnut is like an infant... playing with a fully-throttled chainsaw... on THIS project.

[TheDude]

@Wingnut been busy! Have an update my end hopefully by tomorrow.

[Wingnut]

Hey, what I am doing.... is on your end, too. 

You think I'd be pulling my hair out with this normals normalizer if you didn't have a dire need for it... for your projects?

Okay, yeah, I still would.  heh.  I want to see the end result.  I don't think anyone has done tiled heightMaps in BJS as well as our little team has done, so far.  We're hot!

But yeah, if you show-up tonight with a finished normals sewing machine... and it works perfectly... that would definitely be sweet.  I won't expect it, though.  It's harrrrd, and I'm scared.  But I'm going to keep going until I nail it, or until the Coast Guard rescues us. 

Did you check out the colored marker rods, TD?  They are perfectly aligned, Y-axis-wise, across the two test-seams.  Know what that means?  Yep, we got perfect seams... just discolored... due to mis-aligned normals.  The worst is over-with.   YAY! 

We're gonna win BJS Team Of The Month... if we get done in 5 more days or less.  heh

Know what we need badly?  We need something that gathers the 4 normals of every 4-way intersection... no matter how many tiles wide or deep the ground is... and stores them in an array of vector3's.  Better yet, an array of sub-arrays each containing 4 vector3's.  They need special processing, late in the sewing process.  Ouch, huh? 

All the other points along an edge... require averaging of 2 normals together.  At 4-way intersections, 4 normals need to be averaged.  (My dog just ran-off, scared) 

Note:  On the #44 PG, the control-dragging is not working... because of the setTarget in line 317.  Disable that line to activate control-drag slewing.

[TheDude]

@Wingnut yeah definitely not getting work done tonight as someone who slept over on Tuesday is still here! 

[Pryme8]

Did you guys ever look at my TERIABLE demo? A lot of this was figured out already.... I'll have the infinite version done here soon too that you can look at

[Wingnut]

Hi P8.  Hey, if you wrote a func or two... that does exactly what we need done here, and want to donate it, glad to have it.  We need to see it done, on the #44 playground, though.  It needs to average the normals across the seams... for 1 x 100 tile-grounds, for 100 x 1, for 100x100, for 1x1 (no action), and for any subDivs setting.  It can't use any hard-coded values.  It must be universal/reuseable.

Show us what ya got... in the #44 (and beyond) playground.  We are looking for a very specific function, and I don't think either of us wants to dig it out of your game.  We need a "utility" func, here... with an exact purpose, and no deviations.  If you have that, bring it on... show it to us in PG #44.  Then I'll torture test it with various tile layouts and visual inspections of the white normals lines along our seams, and maybe we can party in streets.  Thanks.

[Pryme8]

	TERIABLE.CreateBlock = function (sizeX, sizeY, detail, scene, posX, posZ, id){
			this._ground = BABYLON.Mesh.CreateGround("block"+id , sizeX, sizeY, detail, scene, true);
			
			this._ground.position.x = posX;
			this._ground.position.z = posZ;
			
		
		
			this._ground.material = teriableBasic;
					
			TERIABLE.Region.push(this._ground);
			//console.log("Made_Block"+id);
			//console.log("TERIABLE.Regions.length: "+TERIABLE.Region.length);
			
		}
		
		
		TERIABLE.Action.CreateNewRegion = function(scene){
			TERIABLE.Action.fadeGui();
			var bsX = $('#block-size-x').val();
			var bsY = $('#block-size-y').val();
			var rsX = $('#region-size-x').val();
			var rsY = $('#region-size-y').val();
			var detail = $('#block-detail').val();
			
			var regionWidth = (bsX*rsX);
			var regionHeight = (bsY*rsY);
			
			TERIABLE.regionWidth = regionWidth;
			TERIABLE.regionHeight = regionHeight;
			TERIABLE.scene = scene;
			
			
			setTimeout(function(){TERIABLE.Action.RegionGenerate(scene, 0, 0, bsX, bsY, rsX, rsY, detail, regionWidth, regionHeight);},0);	
			TERIABLE.ResetCam();
			
		}
		
		TERIABLE.Action.RegionGenerate = function(scene, x, y, bsX, bsY, rsX, rsY, detail, regionWidth, regionHeight){
			if(y<rsY){
				var offSetY = ((regionHeight/2)*-1)+ (y * bsY);
				var offSetX = ((regionWidth/2)*-1)+ (x * bsX);
				if(x<rsX){
					TERIABLE.CreateBlock(parseInt(bsX), parseInt(bsY), parseInt(detail), scene, offSetX, offSetY, String(x)+","+String(y));
					x++;
					return setTimeout(function(){TERIABLE.Action.RegionGenerate(scene, x, y, bsX, bsY, rsX, rsY, detail, regionWidth, regionHeight);
					TERIABLE.Action.UpdateProgressBar(rsY*rsX, (y*rsX)+(x+1));
					},0);
				}else{
					y++;
					x = 0;
					return setTimeout(function(){TERIABLE.Action.RegionGenerate(scene, x, y, bsX, bsY, rsX, rsY, detail, regionWidth, regionHeight);
					TERIABLE.Action.UpdateProgressBar(rsY*rsX, (y*rsX)+(x+1));
					},0);
				}
			
			}
			return	setTimeout(function(){TERIABLE.Action.UpdateProgressBar(0, 0); TERIABLE.Action.fadeGui('main');},10);
			
		}
		
		TERIABLE.UpdatePositions = function (block, state, activeItem, count) {
			//console.log(block.name);
			//PERLIN 2D
			if(state =="Perlin2D"){
				console.log(state+" applyed");
				
				var xDiv = $(activeItem).children("#perlin-2d-x-divider").val();
				var yDiv = $(activeItem).children("#perlin-2d-y-divider").val();
				var height = $(activeItem).children("#perlin-2d-height").val();
				var seed = $(activeItem).children("#perlin-2d-seed").val();
				var mode = $(activeItem).children("#perlin-2d-mode").val();
				
				
				
				var maskTrigger = 0;
				var maskArray = [];
				if($(activeItem).attr('maskArray')){
					maskTrigger = 1;
					maskArray = $(activeItem).attr('maskArray').split(',');
				}
					
							
				var vertexData = block.getVerticesData(BABYLON.VertexBuffer.PositionKind);
				
				var maskIndex = 0;	
					for (var i = 0; i < vertexData.length; i += 3) {
						var x = vertexData[i]+block.position.x, y = vertexData[i+1]+block.position.y ,z = vertexData[i+2]+block.position.z;
						if(mode!="Mask"){
							var maskAmount = 1;
							if(maskTrigger){
									noise.seed(maskArray[3]);
									maskAmount = noise.perlin2(x/maskArray[0], z/maskArray[1])		;				
							}
						noise.seed(seed);
											
						switch (mode){
							case "Absolute":
								vertexData[i+1] = ((noise.perlin2(x/xDiv, z/yDiv))*height)*maskAmount;
								break;
							case "Additive":
								vertexData[i+1] += ((noise.perlin2(x/xDiv, z/yDiv))*height)*maskAmount;
								break;
							case "Subtractive":
								vertexData[i+1] -= ((noise.perlin2(x/xDiv, z/yDiv))*height)*maskAmount;
								break;		
						}
						
						}
					}
					
					

					
					if(mode!="Mask"){
					block.updateVerticesData(BABYLON.VertexBuffer.PositionKind, vertexData, 0, 0);
					return;
					}else{
					
						if($(activeItem).next('item').length){
							$(activeItem).next('item').attr('maskArray',xDiv+','+yDiv+','+seed);
							return;
						}else{
						return;	
						}
					}
			}

this is the old version of that stuff, but it works!

Umm you would need to add your own noise functions or use Das Noise (which is why I made it) and you can edit this accordingly.
Here is the infinite version no noises are added but you can see how to spawn infinite terrain.

Give me like 2 more weeks and TERIABLE will be done and most of your guys procedural terrain needs will be met.
I already have prototypes for a vegetation system and custom regions where you can build on and manipulate the map as well in game.

Sorry If it took me so long to notice this thread, Been super super busy lately.  Im writing a new tutorial on webworkers because everyone has been ooogleing over multiplayer games and stuff, so Im doing a simple pong game for the first part and then showing how to hook up a simple simulated socket server.

Basically what you guys need to worry about is the size of your blocks and how you want to measure them to each other.  So assuming you have an origin of 0,0,0 and you spawn your first block you prolly want the ground to be centered on you so you first need to offset the spawn of all maps by a negative position 1/2 x and z.  Then when ever you spawn a new block you take that offset into account.

the normal are never an issue until you really really push the crap out of the meshs, but even then its only at the absolute extreme, if you use a basic ground element.

Now for your LOD you just have a distance calculation when you spawn the new tiles (look at infinity) and each time a tile if its far off make it spawn multiple instances of it with different levels of subdivs and activate/deactivate accordingly.


@Wingnut I hate the playground.  and I use hate as a strong word here...  Um I would be cool and just upload my editor that replaces it but y'all gonna have to wait for that for special reasons (and cause its my baby)... I mean what kind of person wants the ability to construct model texture and script entire scenes and serialize them into a single text document o_O... haha btw Wing TOWER is like 70% done.

 

[TheDude]

@Pryme8 cool.

[Pryme8]

ohh my bad you prolly want to see them in action:

http://pryme8.github.io/TERIABLE/
 

http://pryme8.github.io/TERIABLE/infinity.html

Honestly the script to infinity is more relevant for you guys then the basic Teriable, the mesh manipulation is not the hard part and nore is spawning the new zones the hard part would be the LOD stack if you wanted to incorporate that.  Mainly because you would not want to add lets say 3 meshs onto the draw stack with each spawn, but would want to trickle them to it in essence, I know that sound crazy... but maybe Ill do a LOD example here soon too.  There is just so much on my plate at the moment with me looking for a new major contract now and having to learn Drupal (uhg) for one of my clients.