Infinite Procedural Terrain Engine

Showcase
41

Every time I run your baker the terrain changes even if I pass a value to it as id = 666 for example. Looked at Python docs seems id is a builtin function that returns the internal id number of the object, which obviously changes every invocation. Seems this collides with your useage, Idle highlights id as purple just like True, False etc. Going through and changing it to terrainSeed. Hopefully this works OK.

Tried to transplant your terrain code into my original framework based on Craig’s code and ran into another gotcha. Even after straightening out the difference between the height functions I have two odd glitches one is that the texturer fails totally resulting in blank gray geomip tiles and two the returned heights always totally crazy, leaving me 3000-90000m ABOVE the terrain.

I’m going to have to ZIP up what I’ve got and put it somewhere you can get at it, have Google code and GIT but can’t figure out how to use them.

I don’t want to toss my whole framework, I have a cool bottom nav bar, an avatar with swimming action, a tracking sky with clouds sun moons and a tracking waterplane. And a mostly operational 1st 2nd 3rd view cam with orbit and joystick interface.

Going back to a copy of your framework to try the “id” mod to see if I get stable terrain tho.

YIP! YIP!
the “Dirty ol Fox”

42

Tried the modification on an original copy of your engine. Terrain is still totally random and different every time, perhaps this means that the randomness is getting introduced inside the Perlin noise functions themselves, IDUNNO. It does however mean I will have to look into the possibility of grafting your texturer shaders on top of Craig’s bakery. For what I’m doing I need consistent terrain to generate, right now as it stands its like that Phillip Jose Farmer novel “The Lavalite World” I need the slope thing for cliff faces and your system seems easier to expand the number of texture levels than Craig’s. Also I should be able to adjust the snowcap level based on latitude easier than with his scheme which I just find too hard to understand let alone modify.

43

Sorry for not responding for a month! I’ve been a bit busy for programming lately. I noticed you’re right about the terrain always randomizing. It turns out I did something very stupid causing one layer of each perlin noise stack to always get a seed of 0, thereby causing it to randomize itself. I’ve committed a fix to the repo.

44

And I looked and looked at that but couldn’t find it, knew something was wrong tho, Thanx,

45

It would slow down generation again, but have you considered integrating procedural trees (ala the demo) and grass placement? They could have a pop-up distace well short of the terrain itself as long as the “ground” colors match fairly well. Also, is there provision for setting a water table height and having river bottom/sea floor textures for regions below it?

  • dNN
46

Those are the kinds of things I’m working on adding now. Moving over from Craig’s infinite terrain code to Steven’s I’m having to also redo my mouse and camera code, had a three view orbitable camera I now have to rework and gamecontroller/mouse integration ( Logitech F310 X controller ). Currently reworking the skydome to redo my two moons and nighttime starfields. Have been adding onto the terrain populator as well to add more species of trees and plants, and also not to plant them under the water. Lots of improvements that all take time. I work second shift in a warehouse and have a long bus ride to and from so most work is done mornings anbd weekends, hoping to soon have everything done and be getting back onto doing terrain SQL databases editor and multiplayer P2P networking code. Its a big project and currently I’m it as far as programmers here on the FoxyWorlds version of this engine, If it wasn’t for Stephen and Craig I wouldn’t even be this far. Also teaching my GF Tanzzy Lightningtails to code Python.

TTFN
“the dirty 'ol fox”
hoping to put up a zip of it all soon

47

Edit: D’oh! I only just realised that LGKitsune, who just replied, wasn’t the OP! Oops… Still, most of this still holds true.

Also, while I’m not familiar with that specific controller (and need to rush off to an appointment rather than googling it and getting distracted again ATM) my own plan is to target to a standard Playstation-style gamepad with kbd/mse as a fallback; controls being most similar to Kingdom Hearts or the Traveler’s Tales LEGO games.

That sounds great - and I can certainly understand being the only person on a project :wink: Just to complicate things even more, have you considered ways to scatter random settlements? (I’m going on about this because procedurally generated planets for an infinite game-universe feature heavily in the game design documents I’ve been working on sporadically for… good grief, over a decade now. And yet, I don’t have a better project name than Ninja Robot Space Fighter…) The procedure I’d come up with (no code involved, just the logic) was to have a base point be created at fairly rare intervals, that would then engage a seperate module from the base terrain generator to create a street grid, populate it with buildings and a few NPCs (shopkeeper NPCs being inside their instanced shops) and then find a 2d n-gon that describes the outlinbe of the settlement, find the mean altitude of all terrain geometry within that n-gon, and flatten it to that level, using a second border region with the same n-gon scaled 2x to transition from the values of the procedurally generated terrain and also to kill procedural plant and monster placement so there’s a clear zone around the settlement.

I also have a rather extensive flowchart for generating infinite sidequests for those NPCs, but it’s too complicated to remember off the top of my head and those game files are on a laptop I have to try to ressurect from CPU fan failure when the replacement arrives sometime next week. I shall be rather put out if the operation is not a success; that machine’s optical drive failed over a year ago so there’s no backup of a lot of the contents, including some of my best transforming mecha models.

To get back on the point, your generator seems to be focused on fairly mountainous/temperate-to-semitropical terrain right now. and setting it up to make sand dunes or arctic steppes would probably require considerably different settings to the algorithm. Genrating an earthlike planet, though, requires numerous different climate/terrain types and large patches that are just ocean, so I’m proposing a simple sphere-unwrap that would be a planetary-level overmap (which could also serve as the view from high altitude/orbit) which determines which set of regional terrain generation settings are used based on the pixel the generated ground-level terrain corresponds to. Experimenting with the procedure and shader settings to make different terrains to actually apply would be the challenge from there…

I’ve just started with Python, with 1/2/3/400 level C courses and intros to Java and FORTRAN now several years behind me, so I’ve got quite a ways to go before I’d be able to help in any meaningful way with coding. I’m primarily a 3d modeler, as well, with only a few forays into texture maps as far as working with surface materials is concerned - figuring out how to do environment mapped reflections in Blender was a big step forward recently. All the same, this and MV3D look like the the Panda projects most likely to be useful as the foundation for what I want to do, so as I (hopefully) get up to speed in the code-oriented aspects they’re what I’m likely to work from, and of course will return my tweaks to the community. My installation is v1.7.2 right now, though, so I guess I’ll have to upgrade - not being too confident in my coding I wanted to stick with the stable release.

  • dNN, tends to run on a bit
48

Yeah I even looked at MV3D as a way to get things up faster, but could never even get it to run… also its based on an earlier ver of Panda/Python and I’ve already upgraded to the latest ver ( 1.8/2.7 ).

I'm doing this in a layered approach, as soon as I'm done fleshing out Stephen's terrain populator with more tree and plant species and giving it the ability to set where they can appear ( latitude, altitude, slope and so on ) so they don't grow out of the water ( except for cattails and mangroves ) I want to add in a very few of Craig's procedural ferns and treetrunks to spice it up as well as some egg model palms etc. These tend to be more CPU intensive so will use sparingly.

Then I move on to adding SQL Lite DB files and cacheing to the terrain tiles, procedurals can be serial numbered into the DB so land can be "cleared" for roads and buildings. I'm wanting to do a "Sim City 4" like terrain editor that can modify the cached heightmaps. You have obviously been thinking along similar lines for some time, so I hope your "data recovery" goes well. As for your usefulness, you are undoubtable farther along in understanding Blender and your knowledge of C++ would be very helpful when it comes time to put all this Python code thru Cython and generate a faster C++ version of the app. But this probably won't happen till the distributed P2P networking layer is done with Twisted Core and Entangled.

Also I need more of the game logic in place, asset packaging and so on. I've spent a few years working on design as well see here:

sites.google.com/site/foxyworld … hitepapers

My eventual goal is to totally destroy the economics of “virtual land” as they exist on totally server based sites like Second Life. $9.95 a month for a squtty little 25 meter square with only 1500 primitive objects is just outrageous price gouging and limits VR only to those with a credit card. UNACCEPTABLE

sincerely,
Lord Raven gengoro Foxfire-Ninetails

49

… wow dude, you’re bitter. Also, and not to be insulting, but magenta-on-black is perhaps not the most readable of website color schemes.

Your whitepapers go a lot more into the technical aspects (which is important) where I’ve mainly got content-related stuff like the various special abilities (magic, martial arts, etc.,) user-level interface function, the game system in the tabletop-RPG sense, a 3000 year plot for 1p/co-op Story Mode (the Prologue shows your character being created as one of a more-intelligent Star Wars Ep1 style robot army and having the responsible would-be-conqueror wiped out by government forces, then get assigned to a civilian contractor (read mercenary company, the replacement for fantasy-mmo guilds) who’ll try to integrate you with regular society while turning your skills to a marketable use. Customising or replacing your body is one of the core mechanics so you have no fixed lifespan;) a couple of minigames, that kind of thing. I also had a good dozen or so character and enemy models on the dead computer, but can’t find the one thumb drive I’m pretty sure I’d backed them up to recently, jammit.

Regardless, we shouldn’t hijack the thread for talking about our stuff, I suppose, where it doesn’t have relation to terrain generation. I’ve pretty much already covered everything relevant to that, so I’ll stop now.

ETA: Inspired by your whitepaper listing for non-spherical and outer space worlds (even though it’s just a “To be done” my system of having an overworld map that controls terrain gen by which pixel your location corresponds to would also apply there - just define how the cartesian texture map applies to the nonstandard shape, and as the user travels from one area to the next they’l automatically move around a whatever world shape you set. The only real issue would be working out how to tell the skybox to put in the other side of the ring when it should be overhead - though at least the overmap would make sure you already had a texture for it.

One possibility would be to actually create an example of whatever the world shape is and use render-to-texture to put it into the skybox - it would of course be FAR FAR beyond camera cutoff to just put the thing literally into the sky. This system would make it relatively straightforward to use, though. My own favorite shape for a world comes from a paper model I once made of a bunch of tetrahedrons assembled into a hollow tessellated icosahedron with a few of the faces missing so you could get into the hollow interior. I don’t at this point, remember how many or in which positions, but about thirty seconds looking at a d20 would solve that.

ETA2: Don’t be too impressed by my C courses - only the 300-level even touched on the basics of 2d graphical interfaces. 400 was entirely about data structures and manipluating them, IIRC… basically what having taken them means is that I know how to read an API document and can usually get the examples from one to work using my variable and function names, after a suitable amount of… “incantations” and time.

As to modifying the generated terrain, I’ve never actually played any of the Sims games so I don’t know what you mean by “Sims-Like” but essentuially all I’m saying in my previous post is that you have XY patch of “ground” that’s defined as flat or by a height map, and spot it into your infinite procedural section by defining a zone around it where the z-values get mixed from one to the other - like the way a soft-edge brush transitions from the background color to the active color using alpha mixing, or texture splatting on terrain image maps.

Exactly like texture splatting on a terrain image map in fact, if you’re using a height map. I’d expect a similar fuction to be necessary to transition between overmap-pixel regions.

  • dNN, rock on!
50

I apologize for further thread hijacking, but I feel somewhat strongly about these three issues:

People have said this before - I really think you should take notice.

And, from the FoxyWorlds TOS:

If FoxyWorlds is truly open-source - according to the OSI’s definition- you cannot keep this part of the TOS (see clause 1, “Free Redistribution”, and clause 7, “Distribution of License”). As a matter of fact, that part of the TOS is, in all likelihood, legally invalid.

Also, from another part:

This part is probably also legally invalid since it goes against clause 6 (“No Discrimination Against Fields of Endeavor”) of the OSI’s open-source definition.

Please don’t take this the wrong way - I just wanted to make sure you knew there were a few problems with your TOS.

51

First I do have another thread open maybe we should use it for discussing my version of the infinite terrain.

[url]new project FoxyWorlds]

As to the color scheme two things:
1) the magenta on black is kinda our thing to visually differentiate us from all those black on white “standard” pages
2) About 8 yrs ago I suffered a ruptured cerebral aneurism ( 75% fatality rate ) this sort of page is a lot easier for me than the standard black on white which causes me eyestrain, wish I could figure out a way to get Idle to do it for coding.
3) it aint gonna change … so quit whining, be glad Google won’t let me put it in our chosen font of “Mistral” LOL

As to the TOS/License:
1) the split personal/commercial license may well be undefensible under OSI, but IF somebody else DOES make money off of it I’d like to at least see a “donation” so I can continue the Work.
2) I have seen similar terms about weapons systems on other packages in the past, again these were probably indefensible as OSI but maybe not as a TOS???
3) I do include a “severability” clause for that very reason.

Right now I’m still migrating things from the previous ver using Craig’s terrain to Stephen’s version and am having a time of getting features like floating avatar labels and chat text areas to work and don’t fully have my camera controls integrated with his. Mouse and keyboard controls still in the rework as well.

Hope to post a ZIP of the current demo as soon as I get these done.

52

Great work! I’ve tested the browser demo, a bit laggy when using boost mode, but when walking normally there’s not a single lag, which is pretty amazing for a browser demo!

However, the source code repository is down. Any chance to get it somewhere else?
github.com/AnimateDream/Panda-3 … ain-Engine